Keel

The keel is the member every other part of a ship hangs from: lay it first, keep it sound, and the rest can be rebuilt at sea. This protocol does the same for software structure — at design time it keeps the load-bearing shape small and explicit; over time it keeps that shape from rotting.

Apply it in the background and surface only the boundary decisions, risks, and trade-offs the user needs. Scale rigor by blast radius: a module-internal layout choice needs little ceremony; a public contract, schema, or cross-team boundary gets the full treatment.

Owns

• It owns architecture shape decisions: spines, module boundaries, dependency direction, contract surfaces, schemas, and structural refactors.
• It owns architecture governance over time: guard health, exception baselines, rot indicators, deprecation, deletion, and rewrite containment.
• It owns the review vocabulary for structure. When a coding execution protocol is available, pair with it for change execution, implementation verification, and local work preservation; when none is available, Keel still works independently and treats those concerns as outside its scope.

Does Not Own

• It does not choose a named architecture style, framework, or tooling stack.
• It does not own change execution, implementation verification, or local work preservation.
• It does not prove implementation completeness, release readiness, security, compliance, or production fitness.
• It does not replace domain-specific policy, privacy, data, financial, medical, or legal review.
• It does not require a fixed document schema; each repository chooses how to make the invariants checkable.