Skip to main content
A blueprint is a generated mockup, diagram, or spec that shows what Kana understood. Blueprints are produced before any code is written, so you can confirm they match what you meant. A misunderstanding caught in a blueprint costs a comment. Caught after delivery, it costs a rebuild.

​
Blueprint types

Blueprint examples shows the planning types for one example outcome, rendered and as source. It doesn’t include Exploration Canvas, Code Graph, or Code Wiki, because those come from free-form planning or from analysing your existing code. For the editors and review tools, see Blueprint editor and tools. Outcome blueprints describe the change. Once an outcome is completed, its blueprints are promoted into the vision’s shared baseline, so the next outcome starts from an up-to-date picture.

​
Reviewing a blueprint

Open a blueprint from its outcome in the workspace, or from the link Kana posts in chat.
  • Approve it when it matches what you meant. You can add a comment.
  • Reject it with a reason and a clarifying question. Kana revises the blueprint and asks you to review again.
  • Annotate a specific part to start a thread about it, or edit the blueprint directly. Data models, state machines, domain models, and user journeys have visual editors.
Approved blueprints become part of the evidence package for the outcome.

​
Understanding gaps

An understanding gap is a place where what Kana understood may not match what you meant. Gaps appear in the workspace and in chat as questions for you. You resolve a gap by answering it, deferring it, or marking it not applicable. Risk, escalation, spec gap, intent drift, comprehension, and context gaps are blocking: the outcome can’t move from Review to Execution until they’re resolved. Any gap raised before planning starts must be resolved before planning can begin.

​
Spec drift

A spec drift is a place where what was built no longer matches the approved spec or blueprint. Drifts come from two places:
  • An agent finds that the code diverges from the spec while it’s building or checking a task.
  • You or Kana edit a task’s content or acceptance criteria after approval, which records an Outdated doc drift so the docs catch up.
Each drift has a type (Missing feature, Incorrect behavior, Outdated doc, or Deviation) and a severity from Low to Critical. They’re listed in the Specification Drifts panel. The easiest way to deal with drifts is to ask Kana to take care of them. She checks each one against the code and the spec, fixes whichever side is wrong, and marks it resolved. You can also choose Mark Resolved yourself. Drifts don’t block phase changes. They’re separate from the retrospective’s drift check, whose Drift blocker verdict does hold up completing the outcome (see Accepting a delivery). Separately, during a task’s pipeline, a blueprint conformance check verifies the implementation against its API contract blueprint, and that check does block the task until it passes.