Keel: Design, Review, and Govern Load-Bearing Architecture

Keel first classifies the job: Decision when a load-bearing arrangement must be established or compared; Judgment when a supplied design or RFC must be tested without silently replacing it; Governance when drift, recurring bypasses, exceptions, migration, retirement, or removal are at issue; and Exit when architecture is already fixed and execution belongs to another workflow. It maps only the spine that matters, grades each surface by its compatibility promise, and separates fact authority, decision authority, accountable ownership, writers, partitions, replicas, commit, conflict, and recovery instead of collapsing them into a single owner. Public, persisted, and cross-boundary surfaces need an explicit compatibility or cutover strategy, while private implementation stays cheap to change. Plausible negative paths—timeouts, duplicates, concurrency, retries, restarts, and uncertain commits—must close with detection, a recovery owner, repair or reconciliation, a terminal invariant, and evidence. Keel adds guards only when they can change action, keeps exceptions shrink-only, makes the governed path economical, and treats migration, retirement, and deletion as routine. It does not pick microservices, DDD, or a framework, and it hands coding and test mechanics back to the focused execution workflow.