Audit trail

OpenGantry is not a certification. It is a local evidence engine: every mission leaves a chain in Git that a reviewer can open without trusting IDE chat or a hand-waved “passed locally.”

Chain

The chain

If the gate fails, a quote is missing, or an anchor is wrong, verify fails closed. Nothing passes because a model said so.

1

Legislate

A Planner runs `gantry legislate` to write scope in `.gitagent/missions/MSN-XXXX.yaml` and commits `[MSN-XXXX]`.

2

Execute within TMVC

An executor edits only inside TMVC roots declared in the Mission YAML.

3

Trace evidence

Evidence lands in `EXECUTOR_LOG.md` as verbatim PASS quotes tied to DoD rows.

4

Verify

`gantry verify` checks the gate command and maps every claimed PASS to a real quote. Fail closed.

Evidence

Weak vs strong evidence

Regulated and security-sensitive teams get asked one question: can you prove the agent was authorized, stayed in scope, and ran your gates? The tabs below contrast what assessors reject vs what they can actually replay from Git.

Prove authorization, scope, and execution in Git

Strong evidence is a chain a skeptical reviewer can open in five minutes: a Planner `[MSN-XXXX]` commit that legislates mission YAML, edits confined to declared TMVC roots, verbatim gate output quoted in `EXECUTOR_LOG.md`, and `gantry verify` pass (or structured failure JSON) that maps every PASS claim to a real quote. Retention, signing, and branch policy follow your normal Git controls.

  • `git log --grep='MSN-0042'` → Planner commit modifying `.gitagent/missions/MSN-0042.*.yaml`
  • Mission YAML lists `tmvc_roots` + `gate_command` — scope and gate are explicit law
  • EXECUTOR_LOG.md contains verbatim `npm test` output matching mission `trace_rows`
  • `gantry verify --json` → `status: passed` + `mission_file_path` + gate phase PASS
  • Optional: digest-only attestation receipt under `.gitagent/history/receipts/`

Review

What to open in a review

Mission YAML

Scope, gate command, trace rows — the law for one MSN.

Planner commit

`[MSN-XXXX]` in the subject — who authorized the change.

EXECUTOR_LOG.md

Verbatim PASS quotes tied to DoD rows.

Verify JSON

Gate result and structured failures from `gantry verify --json`.

Attestation receipt

Digest-only outcome under `.gitagent/history/receipts/` (optional `--sign`).

Output

Sample verify JSON shapes

{
  "status": "passed",
  "envelope_schema_version": 3,
  "phase": "full",
  "msn_id": "MSN-0042",
  "mission_file_path": ".gitagent/missions/MSN-0042.ship-feature.yaml"
}

Attestation receipts

gantry attest and gantry verify --receipt write schema-stable JSON receipts under .gitagent/history/receipts/ (git-ignored). Payloads contain digests and outcomes only — no source file bodies.


          
          gantry receipt list
        
          
          gantry receipt show MSN-0042
        

Default flight telemetry is hash-only (chunk_sha256 + byte counts, no raw gate stream bodies). Use gantry doctor --policy <expected-digests.json> offline to compare MANIFEST, TARGET_ARCHITECTURE.yaml, and config digests.

Compliance context

OpenGantry does not replace your QMS, pen test, or auditor. It gives you developer-native artifacts you can attach to control narratives. For SOC 2 change management, mission commits plus verify JSON show scoped, gated changes instead of opaque agent edits. For ISO/IEC 27001 logging themes, Git history plus EXECUTOR_LOG.md plus deterministic gates read as a reproducible audit log.

Certification outcomes still depend on policies, access control, infra, and training across the whole environment.

Break-glass

gantry verify --break-glass --reason "..." exists for emergencies. It is explicit, reasoned, and note-backed. Forbidden-zone policy is never bypassed.

Further reading