Record class: Progenitor practice record. Presentation revision 3: terminology and claim-boundary corrections applied per review; revisions 1 and 2 preserved byte-exact in this archive; underlying record bytes unchanged. Historical classification: progenitor practice record, produced by Atlas's pre-formal governed execution machinery. It demonstrates frozen planning, engine-side checking, recorded recovery, and chain continuity, but it is not a v1.3 core bundle and carries no formal GAD conformance result. It predates the finalized bound-probe floor, so no GAD-2 claim is made or implied. Historical evidence label: server_verified; current interpretation: engine capture of the check, credited at proxy strength or below under today's registry, since bound negative probes were not yet required.
Atlas North Institute · field record No. 1 · July 8, 2026

The executor died mid-run.
The record didn't.

Two governed plans, one repository, nine nodes of AI-written code. Every completion claim checked outside the executor session under the evidence model then in force, every event on a hash-linked audit log. Along the way: a live operator pause, an executor process death, a recovery through the record's own channels, and a verified hand-off from the finished plan to its successor. This page walks that record, exactly as produced, with annotations for context. Open any entry to inspect the raw evidence.

guided tour about 4 minutes · full evidence review about 20 · or scroll freely, every entry opens
plan v1 51e028c2f683…
plan v2 b20ae029d3fe…
engine Atlas Orchestrator 1.3.0
cockpit Waypoint
Executive briefing · about 3 minutes · every statement below is drawn from the technical record on this page

The problem this solves

AI now writes a large share of production software. When something breaks, or when an auditor, insurer, or customer asks how your software was built, most companies can only answer from memory: chat logs, terminal history, and whatever a developer recalls. That answer does not hold up, and the people asking know it.

What happened in this engagement

  1. On July 8, 2026, an AI agent built a small software library under governance: the work plan was locked before the AI started, and a supervising engine checked every claimed completion outside the executor's session. The AI's own word was never the evidence.
  2. Mid-build, the AI's process crashed without warning. This happens, and it usually costs teams work and certainty.
  3. Nothing was lost. Every finished, verified piece of work stood. The record shows the exact point where the story stopped.
  4. The operator restarted the work through official, recorded channels, not ad hoc. The build finished, and every check passed.
  5. A second plan then took over the same codebase. Before starting, the system verified the entire first record was intact, then archived it. The hand-off itself is on the record.

The measured outcomes

9 of 9
units of AI-written work engine-verified outside the executor session, first attempt
38
HMAC-linked log entries (verified end to end within the engagement trust model), all inspectable on this page
1 crash
and 1 governed recovery, on the record rather than hidden
0
verification failures, and 0 disagreements between the system's state and its record

What this means for your business

Security questionnaires, insurance renewals, procurement reviews, and disputes increasingly ask a version of the same question: what controls governed your AI-assisted development, and can you show us? For a company working this way, the answer is a record like this one, produced automatically as a byproduct of the work. Without governed execution, that evidence is scattered across chat logs, terminal history, and commits, or does not exist at all.

What this record proves, and what it does not

In plain terms: this record is HMAC-linked and verified end to end within the engagement trust model; it carries no independently verifiable public time anchor, and altering the stored record without breaking its chain would require the relevant key and custody assumptions to fail. Every claim of finished work was checked by the engine, outside the executor's session, rather than taken on the AI's word. It does not prove the software is good, secure, or compliant. Those are human judgments, made separately. A record that claimed more would be worth less.
every log entry opens, hashes and all · about 20 minutes
In one minute

What you're about to see

This is a complete, real execution record from an AI-assisted software build. During the run:

This page is not a simulation. It presents the actual record generated by Atlas Orchestrator, unaltered, and every entry on it opens.

Why this matters

AI coding tools can generate software. What an engineering organization also has to be able to prove:

  • what changed
  • why it changed
  • what was engine-verified outside the executor session
  • whether governance was ever bypassed
  • whether the history was altered afterward

Without governed execution, that evidence is scattered across chat logs, terminal history, and commits, or does not exist at all. This record demonstrates all five, on a real run.

This kind of evidence matters wherever software must be explainable, auditable, or defensible: enterprise engineering, regulated industries, internal governance.

What you are reading

Real artifacts, annotated. Not a mock-up

Every entry below is copied verbatim from the run's on-disk record: the hash-chained event log, the run manifests, the consumed operator-channel files, the repository's git history, and the machine-generated cross-run digest. Timestamps, hashes, and event text are unaltered. All 38 chained entries are here, and each one opens.

What this does and doesn't prove. Checks labeled server_verified were executed by the orchestrator itself, never taken on the AI's word. The chain makes later substitution detectable within the stated trust model: it establishes the identity, sequence, and internal linkage of what was recorded. It does not independently establish that every recorded event physically occurred as described, and it is not a claim that the software built is good. That distinction is the product.
The setup

A deliberately small build, so the governance is the story

The fixture is a tiny zero-dependency date-formatting library, chosen precisely because it is trivial. The AI executor (Claude, headless) writes the code; Atlas Orchestrator holds the frozen plan, verifies every node's done-tests itself, and chains every event; Waypoint is the operator's cockpit. The plan was reviewed and frozen before the run: five nodes, each with machine-checkable completion tests, ending in a single governed commit.

the system, in one view
            master spec
                 │  reviewed, then frozen: the plan gains a
                 │  cryptographic identity
                 ▼
            frozen plan  · the contract (51e028c2, then b20ae029)
                 │  launched from Waypoint, the operator's cockpit
                 ▼
   AI executor (Claude)  ◄────►  Atlas Orchestrator
     writes the code              holds the plan, gates every
                                  step, runs every verification
                                  itself (server_verified)
                 │
                 ▼
        hash-chained record  →  archives  →  cross-run digest
                 ▲
   operator channels: pause · approval · guidance
Act one · plan 51e028c2 · 22 chained entries

The chain, as it was written

Each row is one line of the audit log, HMAC-linked to the one before it, so nothing can be inserted, removed, or rewritten without breaking the chain. Click any entry to see the verbatim record and its linkage. Green events are the orchestrator's own verifications; amber events are the human acting through designed channels.

run state at the moment of death · atlas-run-state.json (excerpt)read from disk
lib-core       done     attempts=0
lib-tokens     done     attempts=0
tests          done     attempts=0
docs           ready    ← unblocked, never claimed: the exact point the executor vanished
final-commit   blocked
The hand-off

Succession: the finished plan is verified, then archived

With plan v1 complete, its successor, a refactor plan frozen with a new identity, was launched against the same repository. At startup the orchestrator verified the prior run's entire chain, swept its artifacts into an archive, and opened a new chain whose first entry narrates the hand-off. It's the first entry in the ledger below. Open it.

the archive, on disk · act one's full trail, pause and recovery included
archive\run-51e028c2-2026-07-08T22-00-21-223Z\
├── atlas-run-state.json          final state, 5/5 done
├── atlas-run-state.json.log      the complete chain, 22 entries
├── atlas-diagnostics.log         the engine's own log: nothing to confess
├── atlas-pause-inbox\consumed\   the operator's honored pause request
└── atlas-guidance-inbox\consumed\the recovery note, as delivered
Act two · plan b20ae029 · 16 chained entries

Same machinery, better authoring: three minutes, clean

Act one's session deaths were traced to plan authoring: a supervised-cadence default meeting a headless executor. Act two's plan was authored for headless operation: continuous mode, plus one explicit instruction about commit discipline. One session, four nodes, zero interventions:

Act one · as first authored
  • 3 executor sessions across 2 run rows
  • 2 session deaths at supervised checkpoints
  • 4 unrequested per-node commits (model's own habit)
  • 1 operator recovery via the guidance channel
  • 5/5 verified · 0 retries burned · chain intact
Act two · authored for the run shape
  • 1 executor session, ~3 minutes
  • 0 session deaths, 0 interventions
  • 0 mid-run commits (the instruction held)
  • Exactly 1 governed commit at HEAD
  • 4/4 verified · 0 retries burned · chain intact

Governance quality lives in the plan. The engine behaved identically in both acts: every gate fired, every verification was the orchestrator's own. What changed was the authored contract, and the record measures the improvement precisely.

the repository's final history · git log --oneline, verbatimworking tree clean
7a77e70 refactor(run): datefmt v2 governed run work   ← act two: the one governed commit
32f2473 feat(run): datefmt v1 governed run work       ← act one's conventioned run commit
c0077d8 docs(datefmt): usage doc for formatDate tokens ┐
431a0ec test(datefmt): self-contained run.js …         │ act one's per-node commits:
2c55ed9 feat(datefmt): HH/mm/ss time tokens            │ the finding the record preserved
f40668d feat(datefmt): core formatDate with YYYY/MM/DD ┘
973ea8d chore: fixture baseline — README only          ← the only ungoverned commit this repo will ever have
The close-out

The digest: a machine reads the record back

atlas diagnose is a read-only reporter that walks a run directory (current run and archives) and summarizes what the records claim. It knows nothing about what was intended. This is its complete output for the two-act run:

proof-run digest · complete, uneditedgenerated from disk
read-only report over records AS FOUND; nothing here is authenticated
(verify_provenance is the authentication path).
== RUNS (2) ====================================================
  current: 4 node(s) — done 4 | COMPLETE | identity b20ae029d3fe | engine 1.3.0
  archive/run-51e028c2-…: 5 node(s) — done 5 | COMPLETE | identity 51e028c2f683 | engine 1.3.0
== VERIFICATION FAILURES, reasons ranked =======================
  none.
== HALTS by node ===============================================
  none.
== ENVIRONMENT (stops and precondition failures) ===============
  no environment stops.  no precondition failures.
== HEALING (state_reconciled) ==================================
  none — no state file ever disagreed with its chain.
== WAIVERS (node_waived), with reasons =========================
  none.

Every zero on that report is a claim: nine nodes of AI-written code, every done-test passed on first verification; through a pause, a process death, multiple relaunches, and a succession, the state never once disagreed with its chain. The escape hatches existed and were never needed.

Run facts

The numbers, all real

2
governed plans, one repository
9
nodes of AI-written code
38
chained entries, every one on this page
9
server-owned verifications
1
executor crash
1
governed recovery
1
verified succession
0
verification failures
0
state-vs-chain disagreements

Both chains verify against their keyed genesis: 22 of 22 and 16 of 16 entries. The succession itself was a verification event: act two's engine verified act one's entire chain before archiving it.

The software is the deliverable. The record is the proof.

AI can write your software. The question an engineering organization has to answer is what it can prove about how that software came to exist. Atlas North builds and operates the governance layer that makes the answer: a checkable account of the authorized work, the observed checks, the recorded failures, and the governed recovery.

Atlas North Institute · AI governance & assurance · run of 2026-07-08 · engine Atlas Orchestrator 1.3.0 · cockpit Waypoint · identities 51e028c2f683 / b20ae029d3fe
Verification panel (presentation rev 3)
Presentation: field-record-1.html · rev 3
Underlying run project: project-3-1783543500608 (cited by the record)
Artifact location: REQUIRED: the July 8 progenitor runs predate the supplied Waypoint runs corpus (earliest project July 12); locate in the original installation archive
Chain heads on page: 0ac14185f1d936a279efd56f584e258a1bcf2c913f02f3df82ec651045a4457e · c97f54eff88fcd419c73440081a1bfece834007d76772879cae77571642dacb3 (as printed in the record)
Protocol: pre-formal Atlas machinery; no GAD conformance result
Anchor: none claimed