Contract Graph

Audience guide

Keep delivery understandable as generation speeds up.

You do not need to author YAML. You do need a place where outcomes, boundaries, and decisions survive the next chat. Contract Graph is that place.

Watch the intro How work is split

Why it exists

The bottleneck moved from writing code to keeping it in the right place.

Coding models changed the economics of development. Producing code is dramatically faster; understanding, integrating, and maintaining the accumulated result is not. Without a stronger map, speed increases the amount of software that can become coupled or misplaced before anyone notices.

What you get

A durable overview of the system, a route to the smallest responsible piece of work, and a record of what must stay true while implementation changes.

What you review

Phase outcomes, acceptance gates, recorded decisions, prototype experience, and whether sign-off actually closed on a truthful graph.

What you can ignore

Skill protocol, hop tokens, and most YAML field names. Those are for the agent and the engineer maintaining the graph.

Where you sit in the workflow

Agree one question at a time. Do not let later stages quietly change it.

  1. 01

    Prototype

    When the experience is still unclear, iterate on a running preview. Your acceptance is about the experience, not production readiness.

  2. 02

    Plan

    Agree ordered phase outcomes and what “done” looks like. You are not yet deciding files, branches, or implementation.

  3. 03

    Decisions

    Expensive or protected choices are logged before they are asked. Silence is never approval. Independent work can continue while you answer.

  4. 04

    Sign-off

    Close a phase only when its gate is green and durable knowledge has moved into contracts, product rules, or lasting docs—not a plan you are about to delete.

Plans are temporary. If deleting docs/plans/ would lose a rule, the rule was stored in the wrong place. The next session should trust the contract graph, remaining roadmap items, and accepted decisions.

How to work with the team

Review the map. Do not become the map.

  • Ask where a change belongs before asking for more code

    The useful first question is which contract owns the request. If nobody can answer from the graph, the work is not ready to fan out to agents.

  • Treat generated governance as a proposal

    Public beta: review contracts, product rules, and structural findings before merging. Warmup describes existing behavior; restructuring it identifies should become planned work.

  • Keep product rules in the product catalog

    Repository-specific constraints belong in P rules bound to the contracts they constrain. Global architecture opinions are not yours to invent in chat.

  • Do not expect proof of every import

    Verification today proves the authored graph is closed. It does not yet prove the implementation contains no undeclared child or that every import matches the graph. That honesty is part of the product.

Read the vision See the lifecycle