IMPLEMENTAUDIT
On this page
  1. What the gate model does
  2. Where it appears
  3. What to inspect
  4. Boundaries
  5. Gate sequence
  6. Context and trace surfaces
  7. Annotated ten gates
  8. Gate failure handling
Core model

Audit gate model

The non-skippable gates that stop a run from advancing without evidence.

A gate is a proof checkpoint.

The run may advance only when the current checkpoint has evidence.
If policy, scope, baseline checks, after checks, or final audit cannot pass honestly, the run stops and records the blocker instead of treating momentum as success.

What the gate model does

It turns a repo request into a sequence of evidence gates.

  • Read policy.
  • Bind the request.
  • Inspect real files.
  • Record a before-check.
  • Edit inside a phase.
  • Record an after-check.
  • Audit closure.

The important reader promise is simple: if a gate cannot pass honestly, the run stops and records why instead of pretending the work is done.

Where it appears

In the overview terminal, gates show up as work binding, run-folder creation when phased, state writes, before/after checks, failure rows (Andon rows), and final audit markers.

In source docs, this maps to the execution-gates section of README.md and the execution spine in skills/implementaudit/SKILL.md.

What to inspect

For phased work, open the run folder, then check:

  • STATE.md
  • ROADMAP.md
  • phase checklists/specs
  • before/after evidence (Smoke A/B)
  • failure log (Andon log)
  • final audit ledger.

For compact direct work, inspect the bound work record, final audit ledger, transcript markers, and any before/after evidence the run cites.

If the run says complete without AUDIT_COMPLETE before IMPLEMENTAUDIT_RUN_COMPLETE, the gate model failed.

Boundaries

Audit gates do not authorize commit, push, tag, release, publication, provenance, or host installation claims.
Those remain separate owner-gated actions.

Gate sequence

  1. Safety read: confirm repo policy, host policy, authorization, AGENTS.md conflict rules, CONTRIBUTING.md, CI/workflow files, and repo policy.
  2. Input gate: bind the request to an evidence-bearing work record (audit object).
  3. Pre-flight: detect tools, ownership, generators, constraints, optional sidecars, and prior run state.
  4. Smoke A: record baseline evidence before mutation.
  5. Implement: patch bounded phase work only.
  6. Smoke B: compare post-change evidence against Smoke A.
  7. Trace: preserve causal history, ledgers, boundaries, and continuity decisions.
  8. Self-check: verify quality-bar invariants before final response.

Context and trace surfaces

The gate model also asks what prior state governs the run and whether a reviewer can reconstruct why the run changed.

  • Context / continuity preload: inspect live files, applicable AGENTS.md, the bound work record or run folder, applied context, and authorized sidecar status.
  • Trace / checkpoint: preserve final audit records, transcript markers, owner/source notes, and any separately authorized ActiveGraph mirror after run-root evidence exists.
  • Boundary: checkpoint assistance or an optional mirror is not lifecycle authority or correctness proof; live files, the run root, before/after evidence, and final audit closure remain higher-priority proof surfaces.

Annotated ten gates

This table keeps the ten reviewer questions visible while the canonical execution spine stays the source of runtime behavior.
Each gate has an owner and source of truth, evidence, and a halt condition.

The teaching view is 10 = 8 + 2 split-outs: the skills/implementaudit/SKILL.md execution spine remains canonical, while this page splits inspection, routing, and phase-spec questions so reviewers can audit them.

  1. Safety read

    Question
    Is this action authorized here?
    Evidence
    AGENTS.md, README.md, CONTRIBUTING.md, CI/workflow files, repo policy, and host constraints.
    Halt
    Policy conflict or missing authorization.

  2. Input bind

    Question
    What work record is being closed?
    Evidence
    Request, audit file, handoff, or synthesized audit object.
    Halt
    Empty, unsafe, or unbounded input.

  3. Repo inspection

    Question
    What real files own the change?
    Evidence
    Real-file notes, owner/source, generated-file owner.
    Halt
    Owner/source unclear.

  4. Route choice

    Question
    Is this repair, design, or mixed work?
    Evidence
    Routing note, phase route, scope/non-scope.
    Halt
    Route cannot be justified.

  5. Plan and phase spec

    Question
    Can the work be verified?
    Evidence
    ROADMAP.md, phase checklist/spec, criteria.
    Halt
    Criteria are not falsifiable.

  6. Before evidence

    Question
    What baseline will after-checks compare to?
    Evidence
    Smoke A command/output or accepted prior evidence.
    Halt
    No baseline for a claimed check.

  7. Bounded mutation

    Question
    Did edits stay inside scope?
    Evidence
    Changed-file list and owner/source notes.
    Halt
    Unowned or unrelated mutation.

  8. After evidence

    Question
    Did the relevant check improve or pass?
    Evidence
    Smoke B command/output and comparison.
    Halt
    Regression or failed criterion.

  9. Failure interrupt

    Question
    Was abnormal evidence handled visibly?
    Evidence
    Failure row (Andon row) with class, cause, countermeasure, and rerun evidence.
    Halt
    Hidden retry, missing cause, or fake pass.

  10. Final audit

    Question
    Can the run close honestly?
    Evidence
    AUDIT_VERIFY, AUDIT_COMPLETE, final audit ledger.
    Halt
    Open gap, blocked handoff, or missing marker order.

Think of the ten-gate view as annotated reviewer questions over the canonical execution spine, not a competing runtime.

Gate failure handling

A failed gate is not a prompt to keep going.
It enters the error interrupt:

  • classify
  • inspect cause
  • choose a countermeasure
  • rerun the relevant check
  • escalate with new evidence
  • hand off when blocked.