Kaname Values

Five Values

Kaname is built on beliefs about how software is built. It also requires a set of behaviors. These five values are not aspirational. They are operational - the team either lives them or it is not running Kaname.

01

Specification

The team commits to the specification as the single source of truth - not intuition, convenience, or verbal agreement.

Why this value

AI has no memory between sessions except the context you provide. The spec is that memory. When a team operates on verbal understanding instead of written specification, each AI session starts from a different set of assumptions - and the output drifts with each iteration. Specification is not documentation written after the fact. It is the decision, made explicit, before any implementation begins.

In practice

  • Before generating any code, the relevant spec section is reviewed and confirmed complete.
  • "I thought we agreed" carries no weight. What does spec.md say?
  • Spec changes go through the Spec Owner. A task description update is not a spec change.
  • When implementation reveals ambiguity, work stops and returns to the Spec Owner - it does not continue under assumption.
  • The spec is the contract between the team and the AI. Both sides are held to it.

Without this value

The team runs on shared understanding. The AI generates feature A in week one and feature B in week three, both prompted with different verbal summaries of "what we discussed." By week eight, nobody knows what the system is supposed to do. A new team member reads the code to understand intent. The code is wrong. The spec was never written.

02

Accountability

Each role is accountable for its defined scope without delegation. Every artifact has a named owner. Accountability cannot be shared, transferred, or left unassigned.

Why this value

AI-augmented delivery creates a new failure mode: diffuse accountability. When the AI generates the plan, reviews its own output, and implements the tasks, it is tempting to treat the AI as accountable. It is not. The human who approved the plan is accountable for the plan. The human who cleared the gate is accountable for what passed through it. Named accountability is what makes human governance real rather than nominal.

In practice

  • Every artifact - constitution.md, spec.md, plan.md, tasks.md - has exactly one named human owner.
  • You can delegate the work of a role. You cannot delegate the accountability.
  • When a gate is skipped, the person whose gate it was is accountable for what shipped without review.
  • "Someone should handle this" is not an assignment. A name and a role are required.
  • If any artifact lacks a named owner, the team is not running Kaname.

Without this value

Team lead runs a standup. "Who is reviewing the plan?" Silence. "Someone should pick that up." More silence. The plan is implemented without review. The architecture introduces a security boundary violation that the Constitution Guardian would have caught. Everyone is responsible. Nobody is accountable. The post-mortem produces no corrective action because there is nobody to correct.

03

Transparency

Work, decisions, and blockers are visible to the full team at all times. The board is the team's shared reality - not a reporting tool.

Why this value

AI moves fast. Without transparency, the team discovers conflicts late - two tasks produced incompatible implementations, a gate was quietly skipped, a blocker sat for three days while work continued downstream. Transparency is not reporting to management. It is the mechanism by which the team catches problems before they compound. A blocker surfaced on day one costs an hour. The same blocker discovered on day four costs a week.

In practice

  • The board is updated when work starts and when it stops - not at standup, not at end of day.
  • Blockers are surfaced immediately, not resolved silently or held until the next ceremony.
  • Gate decisions - approved or rejected - are recorded on the board with the reviewer's name and a brief rationale.
  • Assumptions made during implementation are flagged immediately, not buried in the diff.
  • If something went wrong, it is visible. The team does not manage perception; it manages the work.

Without this value

A Task Implementer hits an ambiguous spec. Rather than surface the blocker, they make a reasonable assumption and continue. The task is marked done. The Spec Owner reviews the output four days later. The assumption was wrong. Three connected tasks built on the same assumption are also wrong. The blocker that would have cost two hours on day one costs two days on day five.

04

Governance

Every human gate is exercised without exception. A gate skipped once is a gate that no longer exists.

Why this value

The human gate is the only mechanism standing between AI-generated code and the delivery system. When the team is fast and confident, gates feel like friction. That is precisely when they are most important - fast, confident teams skip gates; slow, careful reviews catch what confidence misses. An optional gate is not a gate. It is a suggestion.

In practice

  • "We are in a hurry" is not a valid reason to skip a gate. Urgency increases risk; gates manage risk.
  • A gate is either cleared by a named human with explicit approval, or it is not cleared. There is no partial pass.
  • The Constitution Guardian's veto is absolute. It cannot be overruled by schedule pressure, product priority, or consensus.
  • Gates run in sequence. Gate 3 cannot be cleared before Gate 2.
  • Governance applies equally to small tasks and large ones. The WIP limit does not have exceptions.

Without this value

Deadline pressure is high. "The spec looks solid - let's go straight to implementation, we'll catch anything in review." Gate 1 is skipped. Implementation begins. Halfway through, the spec has three unresolved edge cases that only become visible during implementation. Work stops under pressure. The hours saved by skipping the Specification Gate are spent five times over resolving ambiguity in the middle of a delivery cycle.

05

Flow

Work is pulled when capacity exists. WIP limits are enforced. The system is not overloaded. Finishing matters more than starting.

Why this value

AI can generate 40 tasks from a specification in ten minutes. Without flow discipline, the temptation is to start all 40 immediately. A team with 40 tasks in progress has not increased throughput - it has multiplied review load, increased context-switching, and degraded the quality of every gate. WIP limits are not bureaucracy. They are the mechanism by which review quality is maintained and delivery remains predictable.

In practice

  • When a stage hits its WIP limit, no new work enters that stage. The limit is a hard constraint, not a guideline.
  • Picking up additional tasks while blocked is a WIP violation. The blocker is resolved first.
  • Lead time - the time from start to done for a single item - is the primary health metric. Throughput is secondary.
  • The Flow Review inspects the system, not the people. The output is a policy change, not an action item for an individual.
  • A task is done when it has passed its gate - not when the AI has finished generating the code.

Without this value

Monday morning. AI generates 40 tasks in 10 minutes. The team pulls all 40 into In Progress because capacity feels unlimited. By Wednesday, 40 diffs land in the review queue simultaneously. The Plan Reviewer spends a week in review. Quality drops under volume. Bugs pass through. The team concludes that review is the bottleneck and decides to do less of it. The governance system degrades from the inside.

The full guide covers all five roles, the delivery cycle, and human gates.

Back to Kaname↓ Full Guide PDF