Trust it · Verification

Done is a proof. Not a feeling.

45% of AI-generated code ships at least one OWASP Top 10 flaw. The same spec generates different code on different runs. "It works on my machine" is not convergence. Six binary gates must all pass — simultaneously — for the Living Blueprint to declare a version converged. Schema matches spec entities. All acceptance criteria have test coverage. Every guard rule is wired to every endpoint it covers. Zero unguarded routes. Zero protocol violations. All must be true. All must stay true.

6/6
binary gates — all must pass for convergence
0
unguarded endpoints in a converged Blueprint
0
stale or drifted nodes allowed
100%
acceptance criteria must have test coverage
01

The 6 convergence gates

Every gate is binary. All 6 must pass. No partial credit. No "close enough." A single failing gate holds the entire graph in the non-converged state. Source: convergence-checker.ts, ConvergenceState interface.

01
Gate 1

Implementation complete

Every spec node (spec_entity, spec_endpoint, spec_workflow, spec_guard, spec_service, spec_ui_page…) has at least one bridge edge to an impl or code node. Zero unimplemented spec nodes allowed.

02
Gate 2

No drift

Zero nodes with staleness IN ("STALE", "INVALID"). Staleness is computed from the staleness column — not needs_revalidation. Code that changed since its spec was written is stale. Stale means non-converged.

03
Gate 3

Criterion coverage

Every acceptance criterion node has at least one test node linked to it. Acceptance criteria without test coverage hold the convergence gate open.

04
Gate 4

Guard coverage

Every guard rule has both positive (rule passes) and negative (rule blocks) test cases. Guards tested only for the happy path are considered untested — the gate fails.

05
Gate 5

No security violations

Zero unguarded endpoints. Every API route exposed in the spec must have at least one guard rule (auth, rate limit, validation, or scope check) applied and wired.

06
Gate 6

No protocol violations

Zero unresolved gap_protocol_violation nodes. Protocol violations are framework-level constraint failures: Inngest functions that mutate state outside a step, API routes missing required middleware, and similar structural violations detected by the rule engine.

02

Violation distance and the CEGIS retry loop

When a gate fails, the system tells you exactly how far from passing — and drives the fix loop automatically.

01

Violation distance v2

Each failed gate produces a structured w′(G) distance score. Not "build failed" — "3 unimplemented spec nodes, 1 unguarded endpoint, criterion coverage at 87%." The distance must strictly decrease each retry iteration.

02

Projected convergence

Given the open gap list and each gap's estimated resolution effort, the system projects when convergence will be achieved — updated in real time as gaps close.

03

CEGIS retry loop

Counter-example guided inductive synthesis. When codegen fails a gate, the system generates counter-examples from the violation distance and drives the Code Engine to retry. The loop runs until all 6 gates pass or the distance stops decreasing.

Ready to see your project in the graph?

Convergence Gates

0 / 6

Type Safety

0 type errors — compiler verifies every interface

G1

Structural Consistency

12/12 spec nodes accounted for in generated code

G2

Data Flow

CPG analysis — component A writes user_id, B reads user_id

G3

Endpoint Coverage

8/8 spec endpoints have route handlers — 100%

G4

Guard Application

3/3 guard rules applied to covered endpoints

G5

Integration Agreement

FE and BE agree on every shared interface

G6

Verification Report

Type errors0
Orphan spec nodes0
Orphan code nodes0
Endpoint coverage100%
Guard application100%
CEGIS retries0

Violation Distance

Distance from convergence0

The 11-term violation distance metric scores every gap as a numbered distance from convergence. Zero means every condition is satisfied.

Command Palette

Search for a command to run...