Advanced and internals

This section is the internal engineering record

Everything linked from this page is written for the people building and verifying ctower, not for someone integrating with it. It is audit material: capability matrices, verification evidence, bounded operational checkpoints, and the canonical design and decision sources.

It is preserved deliberately and in full. It is placed here — behind the product documentation rather than in front of it — because reading it first gives a misleading impression of what is available. If you want to know what ctower is and how to use it, start at the Overview and the Quickstart.

Delivery state and boundaries

Page	What it records
Delivery state	The capability matrix: what is a development fixture, what is verifier-only proof, what is diagnostic, planned, or unsupported
What is deliberately unavailable	The explicit do-not-attempt list
Current operational boundary	What the checked-in Compose file is and is not

The vocabulary those pages use is deliberate:

• Development fixture — executable code and tests exist in a controlled developer or verifier setup. It does not mean a supported product path exists.
• Verifier-only proof — a stronger property is exercised by an isolated test topology, not offered as a deployment.
• Diagnostic only — the artifact informs a later decision without satisfying it.
• Planned — the design may name a capability; no reader should attempt to use it.
• Unsupported — no installation, operations, compatibility, or recovery promise is made.

Checkpoint identifiers such as CP3-C, CP3-D, I1.7A, and CT-I2-005 are internal sequencing labels from IMPLEMENTATION-ROADMAP.md. They are not product versions and they are not release names.

Verification

Page	What it records
Repository setup	Prerequisites for the gates
Exercise the development walking slice	What the full gate does and does not prove
Observability	Health vocabulary and redaction rules
Secret handling	Secret-reference discipline

Bounded recovery checkpoints

These describe local, verifier-only evidence. None of them is an operator runbook, an installation path, or a production recovery service.

• Backup and anchors
• Key recovery
• Isolated restore
• Rollback
• Recovery evidence
• ctower-project cutover

Canonical sources

These four files are the authority. This documentation site explains them; it never overrides or extends them. Where this site and a canonical source disagree, the canonical source wins and the site is a defect.

Source	Role	Mutation rule
SPEC.md	Current product, architecture, workflow, acceptance, and build contract	Reviewed revision; contradictions removed rather than accumulated
DECISIONS.md	Operator decisions and rationale	Append only. An accepted decision is never rewritten, only superseded by a new entry
ARCHITECTURE.md	Derived terminal-safe atlas	Updated with SPEC.md; never creates requirements or a second architecture truth
IMPLEMENTATION-ROADMAP.md	Non-normative sequencing proposal	Does not approve scope, activate backlog items, or authorize implementation

SPEC.md is also a code-generation input: generated/.generated-manifest.json records its digest, so editing it without regenerating fails just check.

Contributing

Development guide · Coding standards · Documentation policy · Releases