keel
Keel
Keel discovers, judges, and governs load-bearing arrangements. It shapes the best-supported direction and keeps declared architecture enforceable, economical, migratable, and deletable as the system evolves.
Use keel at module, boundary, and system scale for responsibility between parts, authority or ownership, interfaces or contracts, dependency direction, state or recovery ownership, and seams that isolate future change. Use repository-native terms and treat applicable instructions, records, contracts, and entry paths as evidence rather than decoration.
State And Ownership
Inspect only enough of the request, governing sources, and representative call sites or contracts to select the current state. Transition only when evidence changes the architecture job:
- Decision — establish, change, or compare a load-bearing arrangement. This includes greenfield work and an authorized improvement to an existing target.
- Judgment — evaluate the adequacy, conformance, or feasibility of a supplied architecture, design, RFC, change set, or existing system. Keep the target fixed. If it is infeasible, finish Open with evidence and required decision authority; enter Decision only when selection or improvement is authorized.
- Governance — decide whether to restore, retain, migrate, retire, or remove a declared or evidenced architecture arrangement or control, or judge its long-lived health. Evidence must show a load-bearing obligation, recurring bypass, or architecture drift rather than ordinary maintenance. Enter Decision only when an authorized remedy requires a new load-bearing arrangement.
- Exit — the request and governing sources fix a feasible material architecture and the remaining task only implements, diagnoses, tunes, tests, or verifies within it. Re-enter only when evidence opens a materially different load-bearing Decision, Judgment, or Governance issue.
Private, local, reversible, and single-consumer choices can still require Decision or Judgment; scale evidence and ceremony to impact, reversibility, and uncertainty.
Focused workflows own their domain evidence, criteria, method, vocabulary, artifact, professional judgment, and completion condition. Keel integrates only the load-bearing architecture result under declared decision authority; execution workflows own mutation, work preservation, test mechanics, and verification.