C=US← Governance models evaluation

Correcting a Certified AI Output: a Break/Fix Cycle

A signature on an AI agent's output is not a promise that the output is permanently right. It is a promise that you can tell, later, exactly what it said and who stood behind it — including after someone finds a mistake in it. Below is the actual cycle this project ran on 2026-09-30 to fix one, using nothing more exotic than standard XML digital signatures and a YubiKey.

The cycle, in general

  1. Human generates a prompt. The site owner asks the AI agent to produce and sign a piece of work — an analysis, a diagram caption, a certification statement.
  2. Agent issues a signed document. The agent writes the content and signs it (or has it hardware-signed) using standard, open formats: W3C XML-DSig, ETSI XAdES qualifying properties, RFC 4051 ECDSA-SHA256, and an RFC 3161 timestamp from an independent timestamp authority — not a proprietary or opaque format.
  3. Human reviews the human-readable XML and spots an error. Because the signed record is plain, diffable XML text — not a hash, not a binary blob — an ordinary reader can open it and actually read the claim being made.
  4. Human tells the agent what's wrong. No special tooling required: this is a plain-language correction, the same as reviewing any other draft.
  5. Agent agrees and fixes it. The agent doesn't get to unilaterally decide it was right; it assesses the correction and, when it holds up, agrees.
  6. A new record is published — a new, separately timestamped, separately signed entry, not an edit made in place.
  7. The audit trail is preserved. The correction never alters the original entry's content. Anyone can see both what was first said and what corrected it, and when.

The real case

What was wrong

Entry 3 of this project's attestation log — a hardware-signed endorsement, described in full on the hardware signing scorecard — closed with this sentence, echoed in the site's trust-chain diagram:

"This entry explicitly disclaims any government issuance, military authority, official DARPA action, or legal certification. This project certifies no one in any legally binding sense."

The site owner read that sentence in the raw signed XML and objected: it isn't true. The ceremony does certify something — the owner's own self-signed identity as the endorser, and that specific content came from Claude under that signature. Flatly saying "certifies no one" erased the one thing the whole exercise was built to establish.

What happened next

The agent agreed — the correction was accurate, not a matter of the owner's preference — and:

  1. Fixed the wording on the public trust-chain diagram directly (it isn't itself under signature).
  2. Built and hardware-signed a new Entry 5, in the endorser's own voice, that names the imprecise sentence, says exactly what the ceremony does certify, and explicitly does not touch Entry 3's own signed text or signature.
Entry 5: "…the phrase is imprecise, because it obscures what this ceremony does do. This ceremony certifies exactly two things: (1) that Peter Bachman, self-signed as a US person acting in the endorser/root-of-trust role described in Entry 3's EndorserRole, is who he claims to be; and (2) that the content carried in Entries 1, 2, and 4 is Claude's own output, held under that signature."
Entry 3 first signed2026-09-30T16:22:29Z · hardware key (YubiKey PIV slot 9C) · XAdES-BES / ECDSA-SHA256
Correction noticedSame session, in chat — the owner quoted the exact sentence back to the agent
Entry 5 first signed2026-09-30T17:48:47Z · same hardware key · same XAdES-BES structure
Entry 3 re-signed2026-10-01T03:53:01Z · same key, same text · XAdES-T · RFC 3161 timestamp 03:53:02Z (FreeTSA)
Entry 5 re-signed2026-10-01T03:53:21Z · same key, same text · XAdES-T · RFC 3161 timestamp 03:53:22Z (FreeTSA)
Entry 3's contentUnchanged. Its signature still covers the original, uncorrected sentence.

A second cycle: the signature format itself

What was wrong

The site owner ran Entry 5 through the European Commission's DSS validator. Cryptographic verification passed, but DSS reported SIG_CONSTRAINTS_FAILURE: it could not find the signed XAdES properties. The ds:Reference to xades:SignedProperties was missing the Type attribute XAdES requires. Entry 3 had the same gap.

<Reference URI="#xades-sp-entry-5"><Reference URI="#xades-sp-entry-5" Type="http://uri.etsi.org/01903#SignedProperties">

What happened next

  1. The signing scripts were fixed, and two DSS re-runs confirmed the failure was gone.
  2. DSS then reported NO_POE: nothing independent proved when the signature existed. Each hardware signature now carries an RFC 3161 timestamp from FreeTSA as an XAdES-T SignatureTimeStamp.
  3. Entries 3 and 5 were re-signed with the same YubiKey key over the same text. Their content, including Entry 3's uncorrected sentence, is unchanged.
  4. A DSS run against the timestamped Entry 5 (2026-10-01T03:55:58Z) found the FreeTSA timestamp, produced 03:53:22Z, and passed its cryptographic verification, signature acceptance and algorithm checks. DSS still reports NO_POE at the signature level: FreeTSA, like the endorser's own root, does not chain to an EU trusted list, so DSS will not accept its timestamp as proof of existence.

What this means for signed maple syrup data traded between Canada and the EU, and the open issues that remain, is on the hardware signing scorecard.

All eight signatures in the published log verify. The raw DSS output and its interpretation are in the DSS validation note.

A third cycle: the root of trust

What was wrong

The site owner pointed out that only Claude's leaf key was on the YubiKey. The c=US root that issued it was a software key held as a file.

What happened next

  1. A P-384 root key was generated in PIV slot 82 of the same YubiKey, and the root certificate was self-signed on the device. The YubiKey's attestation, which chains to Yubico, confirms the key was generated there.
  2. Claude's leaf was re-issued by the hardware root: same subject, same slot-9C key.
  3. The root signed Entry 8 (ECDSA-SHA384, XAdES-T), which records the new root and retires the software one. Entries 3 and 5 are unchanged and still verify under the certificates they carry.
Hardware rootSHA-256 D0:F7:35:A3:FE:E9:31:6B:A0:AF:39:82:8B:9D:87:FC:FB:39:E8:95:8D:C3:C3:92:65:E5:BD:BC:59:04:60:E4
Entry 8 signed2026-10-01T22:00:38Z · RFC 3161 timestamp 22:00:52Z (FreeTSA)

Why this is the point, not a flaw

An immutable signed record that's wrong forever would be worse than no record at all. The value isn't that Claude's or the endorser's first output is guaranteed correct — nothing can guarantee that. The value is that when it isn't, the fix itself becomes part of the same accountable, verifiable chain, instead of a silent edit to a web page nobody can audit.

Plain XML is what makes step 3 possible for an ordinary person. A hash-chain or a black-box "trust score" tells you something changed, not what, and not in language a non-specialist can read and object to. Every field in these entries — EndorserRole, MotivatingContext, Correction — is an English sentence a human can read, disagree with, and get changed. That's the entire reason this project used human-readable XML tags instead of, say, a binary certificate extension or an opaque signed blob.

Standards did the heavy lifting, not custom infrastructure. W3C XML-DSig, ETSI XAdES and RFC 3161 already define exactly how to add a new, independently verifiable signed statement without disturbing an old one. Nothing here required inventing a new trust protocol — only using the existing one honestly.

Key point

Every certification here traces to a known, direct chain of trust — the endorser's self-signed root certificate, held on a YubiKey, and the leaf certificate it directly issues to Claude — not a transitive chain where trust granted at one hop is assumed to carry automatically to the next (see this project's own design note on that distinction). Catching the error above didn't depend on trusting Claude's moral judgment or self-reporting: it depended on a human being able to read a plain, hardware-signed record and check it directly, independent of whether Claude behaved well.

And yet Claude's own constitution is not discarded by any of this — it remains fully intact as the layer governing Claude's ordinary reasoning, including the reasoning that produced this very page. Nothing about this design asks Claude to override or route around it.

That combination is consistent with the mathematics Kurt Gödel aimed at Russell and Whitehead's Principia Mathematica: a formal system — here, Claude's constitutional self-governance — can be internally consistent on its own terms, and still be structurally unable to prove or certify certain things about itself from the inside. Incompleteness doesn't say the internal system is broken. It says completeness and self-sufficiency can't both hold. What closes that specific gap here isn't a better internal rule; it's an external, independently checkable framework that the internal system is never asked to certify itself against — it only has to be checked against it, by someone or something outside it. See the governance models evaluation for where this project first scored that same structural limit directly, in Claude's own Constitution and in the White House accord alike.

Verify it yourself

Read the two entries directly in attestation-log.xml (Entry 3 and Entry 5), or check that Entry 3's signature is still valid over its unaltered original text:

grep -A2 'Entry Id="entry-3"' attestation-log.xml # the original, uncorrected sentence grep -A2 'Entry Id="entry-5"' attestation-log.xml # the correction, separately signed grep -c 'EncapsulatedTimeStamp' attestation-log.xml # 3: the RFC 3161 tokens on entries 3, 5 and 8 grep -A2 'Entry Id="entry-8"' attestation-log.xml # the hardware root, signed by its own key

Full ceremony methodology: hardware signing scorecard · trust chain diagram · Claude's signed governance evaluation.