# Governed AI Development
## The Executive Guide to Verifiable AI-Executed Work

Atlas North Institute. July 2026. This document is explanatory and
non-normative. The normative text is the GAD Formal Specification v1.3
(sealed at succession-7, document sha256
`9c31d03f9c29cbf1ab882eb966cfeec7b1a16e37f3f4d5a6907405c9ab975892`).
Where this guide and the specification
differ, the specification governs.

---

### The executive message

Your organization is about to accept a great deal of work it did not watch
happen. AI systems will write your software, prepare your filings, analyze
your data, and operate your processes, and they will do it faster than any
review process you currently own. The question that determines whether this
goes well is not "is the AI good." It is: **when the work is done, what do
you actually hold?**

Today the honest answer is testimony. A vendor's assurance. A screenshot. A
log file curated by the same system whose behavior is in question. A demo
that worked. None of this survives a hard question from a regulator, an
auditor, an acquirer, or opposing counsel.

Governed AI Development (GAD) changes what you hold. Every conforming
governed run is designed to produce a sealed, tamper-evident,
cryptographically signed record, and the status of that record is not an
opinion anyone renders. It is a computation: a separately executable program that
reads the record and produces the same result on another machine when
given the same bundle, policy, evaluator version, and required
verification inputs.
The producing system does not grade its own homework, because the grader
does not need the producing system at all.

One sentence, suitable for a board slide: **GAD makes "does the record
support that the AI-executed work satisfied the rules we froze?" a question
a computer answers consistently for you, your auditor, and another
evaluator.**

An important honesty note, carried from the specification itself: a record
demonstrates integrity, ordering, and evidence-supported satisfaction of a
frozen contract, and an external time anchor proves the record existed no
later than the anchor's timestamp. Structure is not history: no record
format can prove physical causation from bytes alone. GAD's discipline is
that it says exactly this about itself, and then makes everything the
record CAN establish mechanically checkable.

### Claims you hear, and the question GAD asks instead

| The claim you are given | The GAD question that replaces it |
|---|---|
| "The AI completed the task." | Does a sealed record exist whose verdicts rest on bound evidence, and does the evaluator accept it? |
| "We tested it before shipping." | Are the verification checks in the record, and where the checks are worker-authored, does the record show they could detect a planted failure? |
| "A human approved the risky step." | Is there a typed, signed approval in the record, ordered before the consequence it authorizes? |
| "Nothing was changed afterward." | Does the hash chain verify, and does one flipped byte flip the verdict? |
| "Trust our platform." | Can another party with the record and the public keys recompute the verdict with no access to your platform? |

### What an organization gets

1. **Evidence instead of assurance.** Every conforming governed run exports
   a record another party can judge. Disputes about what the record
   supports become recomputations.
2. **Delegation with a spine.** You can hand consequential work to AI
   executors because the record, not the executor, is what you trust.
3. **Audit leverage.** Auditors can recompute record-level results
   directly, reducing reliance on interviews, screenshots, and
   reconstructed timelines.
4. **Failure that stays small.** Fail-closed rules mean ambiguity stops
   work instead of silently passing it; every governed failure transition is preserved in the record with its
   available reason and governed resolution path.
5. **Irreversibility under control.** Actions designated irreversible
   cannot proceed without a signed human approval the executor is
   structurally unable to forge.
6. **A defensible posture.** When challenged, you produce records, keys,
   and an evaluator, not a narrative.

---

## Chapter 1. The organizational problem

Delegation has always rested on verification. You can hand work to a
contractor, an employee, or a supplier because somewhere behind the
handshake there is a way to check. AI breaks the old ways of checking: the
volume is too high for review, the work is too fast for supervision, and
the systems doing it are owned by someone else and change weekly.

Most organizations respond with one of two mistakes. They slow the AI down
to human speed with review committees, forfeiting the value. Or they accept
the work on testimony, accumulating invisible risk that surfaces at the
worst possible moment: diligence, audit, incident, litigation.

The problem is not discipline. It is that the artifact of AI work, as
commonly produced, is unverifiable. Logs are mutable. Dashboards are
curated. Chat transcripts prove nothing about what executed. There is no
unit of AI work that another party can pick up and judge.

GAD defines that unit.

## Chapter 2. The operating model, in plain language

A governed run has four roles and one artifact.

The **operator** (a human) freezes a plan: the nodes of work, what each is
allowed to touch, how each is verified, and which steps require human
approval. Freezing is cryptographic; the plan cannot drift afterward.

The **executor** (an AI system) performs the commissioned work and
produces outputs and optional claims. It does not verify its own work and
it cannot approve its own risks. After the session closes, the engine
derives which nodes have sufficient bound evidence to enter verification.

The **engine** supervises: it records every protocol-required transition
within its declared capture boundary in an append-only, hash-chained
witness; it runs the verification checks; it refuses illegal transitions;
it withholds completion until the rules are satisfied.

The **evaluator** is a separately executable program, run later, anywhere.
It reads the exported record and computes conformance against the
protocol's nine conditions using the bundle, the named policy, the
evaluator version, public verification material, and any
policy-required replay inputs. Whether a
given evaluation also counts as independent is a policy question GAD
treats explicitly (see Chapter 5).

The artifact is the **record**: the frozen plan, the witness, the
evidence, and the signatures, exported as a sealed envelope. The record is
the product. Everything else is machinery for producing it honestly.

## Chapter 3. The four computed questions

For any exported record, the evaluator computes four separate answers.
They are deliberately separate, because collapsing them is how
organizations turn a passing test into more assurance than the evidence
supports.

1. **Is the record valid?** Structurally complete, properly issued,
   integrity-linked, consistent with the protocol's nine conditions.
2. **How did the run end?** The formal outcome set has five values:
   COMPLETED, SUPERSEDED, HALTED, INCOMPLETE, or INVALID. A halted run can
   still be a perfectly valid governed record; a crashed run is a run
   whose record says so.
3. **Was the frozen contract satisfied?** Were all active obligations
   verified at their required evidence strength, with all required
   approvals in order?
4. **Is the result defensible?** Under a named trust policy: do the
   required anchors verify, and has an evaluator independent under that
   policy accepted the record?

A valid record of a halt is success of the governance even when the work
did not finish. An invalid record is not a mystery; it names the condition
that failed. The vocabulary is small because small vocabularies are
checkable.

Obligations do not relax quietly under GAD. If requirements must change,
the plan is explicitly superseded by a successor, chain-linked, with the
predecessor's record sealed as history. Exception decisions are therefore
visible forever, in the succession, not buried in a checkbox.

## Chapter 4. The six invariants, stated plainly

1. **Recorded, in order, or it did not enter the record.** The witness is
   append-only and hash-chained; every protocol transition appends exactly
   one entry at its moment.
2. **Worker-authored checks must prove they can fail.** Evidence based on
   checks the worker itself authored receives completion credit only when
   the record also demonstrates the check could detect a planted failure.
   Direct observables can reach a higher evidence class when captured
   through qualifying engine observation or successful independent
   replay.
3. **Ambiguity fails closed.** Insufficient evidence, unclear state, or an
   unwired capability stops work with a named reason. Nothing passes by
   default.
4. **Approvals precede consequences.** A gated step's typed, signed human
   approval must appear in the record before the consequence it
   authorizes. The evaluator checks the order, not the sentiment.
5. **A sealed core record is inert.** Its witness cannot be rewritten or
   extended. Later anchors and evaluation attestations attach through
   versioned evidence envelopes, and new governed work occurs in a new
   plan or an explicit successor plan, never by appending to a sealed
   witness.
6. **Evaluation is separately executable.** The evaluator needs the record
   and public keys, not the producing system. Independence beyond that is
   named policy, computed as part of defensibility, never assumed.

## Chapter 5. The GAD maturity ladder

Adoption is a ladder, and each rung is independently valuable. The rungs
are cumulative.

**GAD-1, Recorded.** Every executor invocation produces the mandatory
execution triplet in the witness: the dispatch, the executor's exit, and
the execution result, hash-chained in order. You gain an
integrity-linked execution history whose entries, issuers, ordering, and
checkpoint coverage can later be evaluated; external tamper evidence
strengthens when the record or its prefixes are independently anchored.

**GAD-2, Verified.** Completion credit flows only through engine-side
verification meeting the protocol's evidence-strength floors, including
the planted-failure demonstration for worker-authored checks. You gain
verdicts grounded in evidence rather than self-report.

**GAD-3, Governed.** The exported record satisfies all nine conditions:
VALID_RECORD holds. Where the plan contains gated nodes, their typed,
signed approvals are in the record in lawful order; where it contains
none, the gate condition is satisfied vacuously and says so. You gain records
another party can evaluate cold and recompute without access to the
producing environment.

**GAD-4, Defensible.** Under a named trust policy: the required external
anchors verify (an RFC 3161 token proves the record existed no later than
the token's time), the evaluator's attestation verifies, and the
evaluator is independent under that policy, with pre-dispatch commitment
wherever bounded precedence is claimed. Whether the policy also requires
an accountable human signature over the record root is an open design
question the project tracks publicly (register entry REG-47). You gain
evidence built for adversarial review.

The reference corpus demonstrates records through GAD-3 accepted by the
separately executable evaluator on a second machine, with GAD-4's
anchoring live and its remaining policy questions tracked openly.

## Chapter 6. What executives own, what engineers own

**Executives own the rules.** Which work classes require governance. What
counts as irreversible. Who may approve. Which records auditors receive.
How exceptions are handled, knowing that under GAD an exception is a
visible succession, never a quiet relaxation. These are policy decisions
expressed in frozen plans and gate assignments, and no engineer can
silently change them.

**Engineers own the machinery.** Constructors that produce conforming
records, checks that honestly verify the work, the planted-failure
demonstrations that give worker-authored checks their standing, and
exports another party can evaluate.

**The record is the interface between them.** An executive does not read
code; an executive reads computed answers and approves gates. An engineer
does not certify outcomes; an engineer builds machinery whose records
pass. When a record is invalid, the named condition says which side owns
the fix.

## Chapter 7. Adoption models

1. **Pilot (one workflow).** Pick one consequential, repeatable workflow.
   Run it governed. Judge the records, not the demo.
2. **Team standard.** A team adopts governed runs for a class of work;
   valid records become the definition of done.
3. **Organizational policy.** Designated work classes (releases, filings,
   customer-affecting changes) require valid records; exceptions travel
   through visible succession.
4. **Assurance basis.** Records are what you hand auditors, customers,
   and regulators; the evaluator is what they run. This is where
   verification becomes a protocol between parties who need not trust
   each other's narratives.

## Chapter 8. Example workflows

The software-release example falls within GAD's current normative
reference profile (Profile One: governed AI software-development work).
The remaining examples illustrate candidate future profiles; they
describe how the protocol may transfer, not domains for which
conformance is currently claimed.

**Software release.** Plan nodes: implement, test, review, release. The
release node is gated; the approval is typed and signed; the record shows
checks that demonstrated they could fail, did not, and an approval that
preceded shipment.

**Regulatory filing preparation.** Nodes for data assembly, computation,
document generation, and sign-off. The filing package ships with its
record; a challenge later is answered by recomputing what the record
supports.

**Data analysis for a decision.** The analysis runs governed; the
decision memo cites the record; the decision's evidentiary basis is
permanently inspectable.

**Agentic operations.** Long-running AI operations produce a record per
plan; the computed answers drive the dashboard; "what did the agents do
last week" becomes a query over sealed records rather than a
reconstruction from logs.

## Chapter 9. Trial 0, in one page

Before asking anyone to trust the mechanism, the mechanism was put on
trial. Trial 0 took one specifically identified production record and
asked the only question that matters: does separately executable
evaluation actually work?

The record was exported, moved to a different machine and operating
system, and judged by the evaluator using only the bundle and public
keys. Verdict: valid, all nine conditions. One byte of the witness was
then flipped and the evaluation rerun: invalid, nonzero exit. The verdict
is falsifiable, which is what makes it meaningful. The record's root was
anchored to an independent RFC 3161 timestamp authority, proving the
record existed no later than the token's time. The trial's results,
scope, and limitations were finalized through four disclosed cross-model
review rounds (adversarial review passes executed by a frontier AI
system, not by unaffiliated human experts; independent human review is
Phase 5 and has not yet occurred), bound into a ratification manifest,
signed by the accountable human under an operator authority key, and
anchored again.

The signed scope statement is explicit: Trial 0 establishes bundle
conformance only for the named record. No passing record confers
constructor or operational conformance on its producing tooling; those
require separate inspection and operational audit.

Since Trial 0, the corpus has added the remediation record class (a
failed check, debugged and re-verified, lawful in the witness) and the
gated record class (typed, principal-signed approval, evaluated from the
bundle's own exported keys). Every new record class was refused by the
evaluator until the machinery earned yes, and those refusals are in the
findings register with their fixes.

## Chapter 10. What GAD does not claim

1. A valid record does not mean the work is good. It means the work
   passed the checks the plan named. Choosing good checks is human
   judgment.
2. Record validity does not certify the tool that produced it.
   Constructor and operational conformance are separate levels requiring
   their own inspection and audit.
3. A record proves what its bytes support: integrity, ordering,
   evidence-bound satisfaction, existence no later than its anchor.
   Structure is not history; no format proves physical causation, and
   GAD's specification says so about itself.
4. GAD does not make AI safe, aligned, or correct. It makes AI work
   inspectable, which is the precondition for every other assurance.
5. The evaluator is machinery. Its correctness is currently supported by
   internal evidence and disclosed cross-model review; independent human
   formal and cryptographic review (Phase 5) is tracked openly as the
   next milestone, and the specification's own header carries this
   qualifier. A framework that states its unproven claims is the only
   kind worth adopting.

## Chapter 11. Fit with NIST AI RMF and ISO/IEC 42001

Management-system frameworks tell organizations what to govern: risk
processes, roles, documentation, oversight, and testing and evaluation
practices. GAD operates at a different altitude: it defines a concrete,
sealed, recomputable artifact for individual units of AI-executed work.
The plausible fit is complementary: governed records can serve as
execution-level evidence inside a NIST AI RMF program's measurement and
management functions, and as operational evidence an ISO/IEC 42001
management-system audit samples. Whether GAD fills a specific gap in
those landscapes is a claim that deserves a clause-level crosswalk
against the current versions of each framework rather than an assertion;
producing that crosswalk, version-dated, is part of the standardization
workstream. Adopting GAD does not compete with these frameworks; it
gives their audits a mechanically checkable object.

## Chapter 12. The 30/60/90 adoption path

**Days 1 through 30: prove the record.** Pick one workflow. Stand up the
reference stack or your own constructor. Produce ten governed runs. Have
someone outside the team evaluate the records on a machine the team does
not control. Decision at day 30: did separately executable evaluation
work, yes or no.

**Days 31 through 60: prove the gate.** Add one genuinely irreversible
step behind a typed, principal-signed approval: the approver controls
private signing material, the frozen plan identifies the authorized
public credential, and the evaluator verifies with the public half alone.
Attempt to commission or credit the gated consequence without a valid
approval and preserve the resulting rejection as negative evidence.
Separately exercise a signed human refusal and confirm the node cannot
silently re-enter execution. Decision at day 60: can you delegate this
class of work.

**Days 61 through 90: prove the policy.** Write the organizational rule:
which work requires records, which computed answers are acceptable, who
approves, and how exceptions travel through succession. Run a month under
it. Hand the records to your auditor and ask what else they would need.
Decision at day 90: adopt as standard, with ninety days of evidence in
hand.

---

### Closing

Every era of delegation produced its instrument of trust: the ledger, the
contract, the audit. The era of delegated intelligence needs one too, and
it cannot be a promise, because promises do not scale and do not survive
adversaries. It has to be an artifact: sealed, signed, and judged by a
program anyone can run, wrapped in claims narrow enough to be true. GAD
defines that artifact and the machinery required to evaluate it,
specified formally, governed by its own rules, and already refusing its
own makers when they fall short. The record is the
product. Everything else is commentary.

*Normative authority: the GAD Formal Specification v1.3 and its
succession lineage. Evidence inventory: the findings register and the
Trial 0 ratification package. Digests in the companion Standardization
Track document.*