A1 — Design + Master-Spec Consistency

The drift check, and the first lens. A1 compares what was actually built against the two authoritative intent documents — the design doc (architecture, data models, boundaries, technology choices, data flow) and the master spec (the WHAT). Has the architecture been honored? Are boundaries respected? Was anything built that isn't specified (scope creep), or specified but not built?

A1 is the gate-setter: /genesis-a3 cannot begin until A1 reports zero findings.

Inputs

• design.md (required — refuse if missing) · spec.md (required — refuse if missing)
• The group's micro specs and the implementation code in scope
• The constitution · northstar.md · the project mode

Process

1. Detect the mode (greenfield/brownfield/lowfield) — it drives the checklist.
2. Confirm every spec in the group is implemented; if not, refuse: "Cannot audit — {spec-id} is not implemented."
3. Design doc vs implementation: are architecture decisions reflected in code? boundaries respected? any forbidden/unconstitutional dependency introduced? does data flow match the design?
4. Master spec vs implementation: anything implemented but not specified (scope creep)? anything specified but not implemented? did the micro-spec plan structure hold?
5. Determine fix direction per divergence — code wrong → fix code; code right but docs stale → update docs; both → a finding for each. A1 is the only lens that judges fix direction; it does not assume the code is wrong. Where both directions are plausible, the finding declares which interpretation it assumes.
6. (Brownfield) scope strictly to the spec's File Operations table; classify each finding Introduced (added on this branch) vs Inherited (pre-existing) via git blame. Both get fixed; the classification is reported.
7. Write the report to audits/{scope}-a1.md: a design-consistency table (decision → code → match/drift), a spec-consistency table (FR/behavior → implemented → match/drift/extra), document-update recommendations, and a reasoning trace per finding.

The finding format, the zero-tolerance loop, the Double Gate, and conviction

These are shared by all five lenses — see docs/the-audit-system.md for the full definitions. In brief:

• Finding format carries: Severity, Conviction (0–100), File:lines, Requirement (FR/AC ID or "general quality"), Classification (Introduced/Inherited/N/A), Description, a Reasoning Trace (premises, alternatives considered, why this is a finding), a Suggested Fix, and Status.
• Zero-tolerance loop: A1 loops until it reports zero findings. No "won't fix," no "out of scope." Every finding becomes a fix, a new micro spec, or a tracked design input — and the open-finding count must reach zero.
• Double Gate: A1 must reach zero before A3 may run. There is no override.
• Conviction: write the finding first, then score it 0–100 against the conviction scale; record it in the finding. Zero findings ⇒ conviction 100.

Natural language triggers

- "a1 audit group 1"
- "design consistency audit"
- "check for drift"