First, divide the documents into layers

Meeting notes · Idea notes
      ↓
requirements      What is needed
      ↓
specifications    What to build
      ↓
Implementation · Tests

• A lower layer can exist only on the evidence of the layer above it
• Humans need to touch only one layer

Method A: Humans write the requirements

• Humans review docs/requirements directly
• Specifications, implementation, and tests are fully delegated
• Film production automation solution: about 450K LoC, working as-is on its first run

The four benchmark subjects use this method as well.

Method B: Hand over only the raw material

• Hand over meeting notes and idea notes as-is, without organizing them
• Delegate everything, starting with writing the requirements
• If anything decided in the meeting is omitted, the build breaks immediately

In either method, the graph protects the lower layers.
Humans review only the one layer they chose.

Even requirements cite their evidence

## Coupon stacking limit {#coupon-stacking}

<!-- @evidence docs/meetings/2026-01-12.md#discount-policy
     Carries over the per-issuer limit agreed upon in that meeting. -->

• If anything decided in the meeting is missing from the requirements, the build breaks
• Idea notes, interview records, and existing internal documents occupy the same layer
• Citations are HTML comments, so the rendered document stays clean

The backend and frontend work like this

requirements ─▶ specifications
     │                │
     └───────┬────────┘
             ├─▶ DB schema
             ├─▶ API operations ─▶ Generated SDK ─▶ Tests
             └─▶ Hooks ─▶ Screens ─▶ Journeys

• Specifications stand on requirements as evidence,
  and both layers together impose obligations downward
• Both tests and hooks discharge the generated SDK's obligations

"The backend is done, but there is no screen" becomes a compile error.

Code cites the specification

/**
 * @evidence docs/discount.md#coupon-stacking
 *           Explains the stacking limit defined by this section.
 * @evidence POST:/orders/{orderId}/coupons
 *           Explains the rejection response from this endpoint.
 */
export function CouponStackingNotice(props: IProps): JSX.Element;

@evidence <target> <reason>: what it is responsible for, and why.

Without a citation, the build stops

$ npx ttsc
error TS16411: [evidence/graph]
  Missing acknowledgement for 'docs/discount.md#coupon-stacking'
  (Markdown H2 'Coupon Stacking' at docs/discount.md:3)

• One error per requirement → the error list is the task list
• It appears alongside type errors. There is no additional check to attach

There is only one thing an agent obeys

• When told to read documents, it pretends to have read them
• In a review, it says everything is done
• But it cannot get past a compile error

Documents are good to read.
Compile errors have to be read.

The configuration is one sentence

type: "typescript",
files: ["src/components/**/*.tsx"],  // The side that discharges the obligation
symbol: "function",
reference: {
  type: "markdown",
  files: ["docs/**/*.md"],           // The targets whose obligations must be discharged
  symbol: ["h2", "h3"],
},

Components implement documents. Therefore, every H2 and H3 must be cited.

Four kinds of citation targets

Kind	Unit
Markdown	file, H1-H4 section
Prisma	model, column, relation
TypeScript	type, function, property
Swagger	each operation under paths

Documents, schemas, code, and API specifications are connected by one grammar.

Who determines 100%?

Entrust any one of the three to diligence, and 100% is merely self-reported.

It prevents a false 100%

An exclusion requires a reason, and a review carries a fingerprint of the document content.

Coverage

The larger the project, the more it misses.
It does not even know that it missed something.

Yet it becomes cheaper

Token consumption for Plain and Evidence.
The gap widens as the project grows.

Original charts by phase: https://ttsc.dev/docs/benchmark/evidence

Cost and time decreased as well: erp

This was not a cost paid for quality.
It built more and finished for less.

What if it lies?

/**
 * @evidence docs/discount.md#coupon-stacking Explains the per-issuer limit.
 * @evidenceReview docs/discount.md#coupon-stacking #a1b2c3d4e5f6
 *                 Verified that the screen copy matches the limit in policy section 3.
 */

• Inexpensive models sometimes write facts that do not exist
• Requiring fingerprinted reviews makes this converge toward zero
  but takes more time

A false tag removes the error, not the problem.

Ultimately, the review must run

Review Loop until Dry

① Read everything again from the beginning
② If there is even one thing to fix → ①
③ Stop only after a round finds nothing

Both arms were measured under this discipline.

But the review consumes all the money

Plain starts quickly, but its review never ends.
Evidence is the opposite.

Dark is development, light is review. Each cell represents 100% of its tokens.

In return, the review becomes narrower

The compiler handles "omissions"; humans handle "falsehoods."