Kaname Team

Five Roles

Kaname operates through five named roles. Four own a primary artifact and one layer of the delivery governance chain. The fifth owns the delivery system itself. No accountability may go unassigned.

Roles are not job titles
One person may hold multiple roles
Accountability cannot be shared or left unassigned

At a Glance

01constitution.md

Constitution Guardian

Accountable for the integrity of the system's architectural, security, and quality boundaries.

Owns: Gate 1

02spec.md

Spec Owner

Accountable for the completeness and precision of behavioral specifications.

Owns: Gate 1 + Gate 4

03plan.md

Plan Reviewer

Accountable for the architectural soundness of the AI-generated technical plan.

Owns: Gate 2

04tasks.md

Task Implementer

Accountable for executing work using AI coding assistants within the constraints set by the specification and constitution.

Owns: Gate 3

05No primary artifact

Delivery Coach

Accountable for the health of the delivery system: policies, WIP limits, gate criteria, and board state.

Owns: All gates (oversight)

01

Constitution Guardian

constitution.md

The Constitution Guardian defines what the system may and may not do, independent of any specific feature or delivery cycle. Their authority is not subject to stakeholder pressure, schedule urgency, or team consensus. When the Constitution Guardian vetoes an implementation, the veto stands.

Accountable for

  • Authoring and maintaining constitution.md
  • Reviewing AI-generated output for constitutional compliance
  • Approving all changes to constitutional constraints
  • Vetoing implementations that violate architectural or security boundaries
  • Jointly clearing Gate 1 alongside the Spec Owner

Not accountable for

  • Authoring spec.md or deciding what features to build - that is the Spec Owner's domain
  • Generating or approving plan.md - that is the Plan Reviewer
  • Daily board management or WIP enforcement - that is the Delivery Coach
  • Implementation - the Constitution Guardian does not write code

Events

  • Spec Review Session
  • Constitution Review (facilitates)
  • Plan Review

Key principle

The Constitution Guardian is one person. Others may propose constitutional changes. Only the Constitution Guardian ratifies them.

02

Spec Owner

spec.md

The Spec Owner translates stakeholder intent into a form that both humans and AI agents can act on without ambiguity. They are the bridge between what stakeholders want and what the team builds. A specification that requires clarification during implementation is an incomplete specification - and that is a Spec Owner failure, not an implementation failure.

Accountable for

  • Authoring and maintaining spec.md and all Use Cases
  • Ensuring each Use Case defines complete inputs, outputs, variants, and acceptance criteria
  • Reviewing AI-generated output for specification alignment
  • Approving specification changes before implementation proceeds
  • Jointly clearing Gate 1 with the Constitution Guardian
  • Performing end-to-end verification of all Use Cases at Gate 4
  • Facilitating Spec Review Sessions and Delivery Reviews

Not accountable for

  • Technical architecture decisions - those belong to the Plan Reviewer
  • Implementation - the Spec Owner does not execute tasks
  • Constitutional boundaries - those belong to the Constitution Guardian
  • Board health and WIP limits - those belong to the Delivery Coach

Events

  • Spec Review Session (facilitates)
  • Queue Replenishment
  • Plan Review
  • Delivery Review (facilitates)

Key principle

Stakeholders may express intent. The Spec Owner determines how that intent is encoded. This distinction is what makes the specification authoritative.

03

Plan Reviewer

plan.md

The Plan Reviewer bridges behavioral intent and technical implementation. They do not author the plan - the AI generates it from the specification. The Plan Reviewer determines whether what the AI generated is acceptable: architecturally sound, constitutionally compliant, and complete enough for implementation to begin without ambiguity.

Accountable for

  • Reviewing AI-generated plan.md, data model, and API contracts
  • Identifying architectural risks before implementation begins
  • Verifying that the technical plan conforms to constitutional constraints
  • Approving the plan before tasks are generated and pulled
  • Clearing Gate 2

Not accountable for

  • Authoring plan.md - the AI generates it from spec.md
  • Writing specifications - that is the Spec Owner
  • Implementing code - that is the Task Implementer
  • Deciding what features to build - that is the Spec Owner and stakeholders
  • Gate 1 or Gate 4 - those belong to the Spec Owner and Constitution Guardian

Events

  • Plan Review (facilitates)
  • Spec Review Session (when delivery cycle is being prepared)

Key principle

The Plan Reviewer does not accept a plan that is architecturally unsound simply because the specification asked for it. If the spec requires something constitutionally prohibited, the plan cannot accommodate it - and both artifacts return for revision.

04

Task Implementer

tasks.md

The Task Implementer is the primary interface with AI execution tooling. They pull tasks from the board as capacity allows, run AI agents with the appropriate artifact context, and verify that the AI-generated output satisfies the linked Use Case before marking the task done. They do not resolve specification ambiguity - they surface it.

Accountable for

  • Pulling tasks according to WIP limits
  • Operating AI agents with the correct Use Case and plan component context per task
  • Verifying AI-generated code against the relevant Use Case acceptance criteria
  • Flagging specification ambiguities discovered during implementation
  • Clearing Gate 3 for each task before marking it done

Not accountable for

  • Resolving specification ambiguity unilaterally - ambiguity returns to the Spec Owner
  • Architectural decisions - those belong to the Plan Reviewer
  • Constitutional compliance judgments - those belong to the Constitution Guardian
  • Pulling more tasks than WIP limits allow, even when blocked

Events

  • Spec Review Session (at least one attends)
  • Delivery Review

Key principle

Task Implementers do not mark a task done because the AI finished generating code. They mark it done after reviewing the AI output against the Use Case acceptance criteria. These are different things.

05

Delivery Coach

The Delivery Coach owns the delivery system itself - not what the system produces, but how it operates. In AI-augmented delivery, this role is the primary guardian of human gates: the speed of AI generation creates constant pressure to move faster and skip governance. The Delivery Coach holds that line. They do not make content decisions. Specification, architecture, and implementation remain with the roles that own them.

Accountable for

  • Facilitating the Flow Review and Queue Replenishment
  • Ensuring all Kaname events are held as defined
  • Ensuring all gates are exercised without exception
  • Monitoring board health, WIP limits, and blocked items between events
  • Surfacing impediments and escalating those that cannot be resolved within the team
  • Coaching team members on Kaname practices and values

Not accountable for

  • Specification content - that belongs to the Spec Owner
  • Architectural decisions - those belong to the Plan Reviewer
  • Constitutional boundaries - those belong to the Constitution Guardian
  • Implementation quality - that belongs to Task Implementers and the gate system
  • Clearing any specific gate - gates are owned by the roles defined for them

Events

  • Queue Replenishment (facilitates)
  • Flow Review (facilitates)
  • All events (oversight and attendance)

Key principle

The Delivery Coach has no primary artifact. This is intentional. Their accountability is the system as a whole, which requires independence from any single artifact's concerns.

Small Teams

Role Compression

Kaname roles are not job titles. One person may hold multiple roles. What may not be compressed is accountability - each artifact and the delivery system must have a named owner, even if that owner holds two or three roles simultaneously.

What can be compressed

  • Constitution Guardian + Plan Reviewer: both require architectural judgment and pair naturally
  • Spec Owner + a stakeholder representative: common in product-led teams
  • Task Implementer + any other role: implementation is a parallel track to governance

What cannot be compressed

  • Spec Owner + sole Task Implementer with no other reviewer: Gate 3 becomes self-review. Self-review is not governance.
  • Accountability itself: if no one is named for a role, the role does not exist and the team is not running Kaname.

Each role exercises its accountability through the human gates.

Human Gates↓ Full Guide PDF