Human Governance

Four Human Gates

Kaname defines four mandatory gates - decision points at which human judgment must approve before work advances. No AI agent can carry work across a gate boundary. Gates cannot be bypassed by any role, including the roles that own the upstream artifacts.

Gates are not bureaucratic checkpoints. They are the mechanism by which human intent is preserved across generations of AI-generated code. An optional gate is not a gate - it is a suggestion.

Cost of Failure

The cost of catching a problem grows at each gate. Every gate that passes without catching a problem multiplies the cost when the problem is eventually found.

Gate 1

Hours

Gate 2

Half a day

Gate 3

A day

Gate 4

Days to weeks

No gate

Production incident

These are relative costs for catching the same class of problem at different stages. Problems caught in production carry additional costs: user impact, emergency response, and fixes applied without specification coverage.

Specify

Gate 1

Spec Gate

Plan

Gate 2

Plan Gate

Implement

Gate 3

Impl Gate

Review

Gate 4

Delivery Gate

Done

Gates run in sequence. Gate 3 cannot be cleared before Gate 2. Work does not skip stages.

1

Specification Gate

Reviewers:Spec OwnerConstitution GuardianBoth must approve

Verify that the specification is complete and precise before technical planning begins. This is the cheapest gate to fail. A specification problem caught here costs hours. The same problem caught at Gate 4 costs days.

What they verify

  • Every selected Use Case has a defined actor, goal, successful path, variants, and failure conditions
  • Every acceptance criterion is independently verifiable by a human - not "system behaves correctly" but a specific, observable outcome
  • No acceptance criterion requires AI judgment to evaluate
  • No Use Case assumes a technology or architectural decision that contradicts constitution.md
  • A Task Implementer reading this Use Case cold could execute it without requesting clarification

If this gate fails

Use Cases return to the Spec Owner for revision. The Constitution Guardian and Spec Owner re-review. Work stays in the Specify stage until Gate 1 passes. No implementation cost is incurred.

Returns to: Specify stage

If this gate is skipped

Specification ambiguity discovered during implementation. Task Implementers stop work, escalate to Spec Owner, implementation is revised under pressure. Every hour spent in ambiguous implementation is wasted.

2

Plan Gate

Reviewers:Plan ReviewerSpec Owner (coverage verification)

Verify that the AI-generated technical plan is architecturally sound and specification-aligned before task generation and implementation begins. The Plan Reviewer approves; the Spec Owner confirms coverage.

What they verify

  • Every Use Case in scope maps to at least one named technical component
  • The data model supports all Use Case data requirements
  • API contracts define all inputs, outputs, and error conditions
  • No component uses a technology prohibited by constitution.md
  • The implementation sequence is feasible: no circular dependencies, no undefined prerequisites
  • No architectural pattern is introduced that constitution.md has not approved

If this gate fails

If architecturally unsound: AI regenerates the plan under corrected constraints. Plan Reviewer reviews again. If Use Case coverage is missing: gap is identified, AI regenerates the missing plan sections. Work stays in the Plan stage.

Returns to: Plan stage

If this gate is skipped

Architectural violations discovered mid-implementation. Code has been written against a plan that contradicts constitution.md. Rework begins. In worst cases, the data model is wrong and all tasks built on it must be redone.

3

Implementation Gate

Reviewers:Task Implementer

Verify that AI-generated code satisfies the linked Use Case before it is merged into the codebase. This gate runs per task, not per delivery cycle. It may run dozens of times in a single cycle.

What they verify

  • AI output compiles and automated tests pass - necessary but not sufficient
  • Every acceptance criterion in the linked Use Case is demonstrably met by the code
  • No functionality was added beyond what the Use Case specifies
  • No dependency was introduced that violates constitution.md
  • The Task Implementer can point to specific acceptance criteria that each material code change satisfies

If this gate fails

Code returns to implementation. Task Implementer re-runs the AI agent with better context or constraints. If the failure reveals genuine specification ambiguity - not an implementation error but a spec gap - the task is escalated to the Spec Owner. The Use Case may need to return through Gate 1.

Returns to: Implement stage (or Specify if spec is the problem)

If this gate is skipped

Incorrect code is merged into the codebase. Later tasks may build on incorrect foundations. Gate 4 catches this - but now the cost is end-to-end verification failure plus rework across multiple tasks, not a single task revision.

4

Delivery Gate

Reviewers:Spec Owner

Verify that the delivered system - as an integrated whole - satisfies all Use Cases in the current delivery cycle. A release is not authorized until this gate passes. This is the most expensive gate to fail.

What they verify

  • Every Use Case in the delivery cycle can be exercised end-to-end
  • Each Use Case produces the outputs defined in the specification for every defined path and variant
  • Interaction between Use Cases does not produce undefined or unspecified behavior
  • All acceptance criteria across all Use Cases in the cycle are met by the integrated system
  • No constitutional boundary is violated by the integrated delivery

If this gate fails

Specific Use Cases return to the Review or Implement stage. If failure reveals missing specification coverage - a gap only visible in integration - Use Cases return all the way to the Specify stage. Gate 1 must be re-cleared for the affected Use Cases before implementation resumes.

Returns to: Review stage - or back to Specify if spec is the root cause

If this gate is skipped

The delivered system does not do what the specification said it would. This is not caught until production. Users encounter undefined behavior. Emergency fixes are applied without specification coverage. The next delivery cycle begins under the weight of undocumented workarounds.

Gate Violations

How gates get skipped

Gate violations rarely look like violations in the moment. They look like pragmatism. They look like moving fast. The consequences arrive later, compounded.

The deadline skip

The delivery cycle is behind. Product pressure is high. "The spec looks solid - let's go straight to implementation." Gate 1 is skipped. Three Use Cases have ambiguous acceptance criteria. Task Implementers discover this mid-implementation, make assumptions, and continue. Gate 4 fails. The time saved at Gate 1 is spent five times over in rework.

The silent merge

A Task Implementer reviews the AI output briefly. Tests pass. They merge without comparing the output against each acceptance criterion in the Use Case. The code is "working" but implements the wrong variant. Gate 4 catches it - after all other tasks in the cycle have been built on this foundation.

The consensus override

The Constitution Guardian flags a constitutional violation in a task output. The team discusses it. Three people agree the violation is minor. The Constitution Guardian is overruled by consensus. The veto is not honored. The architectural boundary is now breached. The next delivery cycle builds on the breach. Remediation, when it comes, is proportionally more expensive.

Beyond the Four Gates

The Constitutional Veto

The four gates are stage transitions. The Constitution Guardian's veto is continuous - it operates at any point in the delivery cycle, independent of gate sequence. If the Constitution Guardian identifies a constitutional violation in any artifact or any AI output at any stage, they may halt work.

The veto is absolute

The Constitution Guardian's veto cannot be overruled by any other role, by team consensus, or by schedule pressure. If the veto can be overruled, it is not a veto - it is an opinion.

The veto is specific

A veto names the constitutional clause being violated and the specific artifact or output that violates it. "I don't like this" is not a veto. "This API design violates the security boundary defined in constitution.md section 3" is a veto.

All five roles, gate ownerships, and accountability boundaries are in the full guide.