Verified Digital Agents → The governance cycle

The enterprise AI governance cycle

From a compliance standard to evidence an auditor can verify without trusting us — and the specific block that does each step. No single block answers the questions below. The composition does.

The two questions this exists to answer

These are what regulators and auditors actually ask, and they are the reason the blocks compose:

The organising principle

The cycle

  C2MD ──genesis──▶  GIT  (governance v1, plain Markdown)
                      │
                      │   ACP owns the lifecycle from here
                      ▼
            ┌────────────────────────┐
            │ ACP: author → PR       │
            │  → Compliance Guard    │
            │  → adversarial tests   │──ratification──▶ HITL ──sealed──▶ WITNESS
            │  → merge → sign        │
            └───────────┬────────────┘
                        │  signed, versioned, content-hashed bundle
                        │  built from APPROVED git state; activation sealed
                        ▼
                     AGENTS ── fetch → verify → cache → evaluate LOCALLY
                        │
                        │  every runtime evaluation sealed
                        ▼
                     WITNESS ──▶ EU AI Act Art. 12 evidence · GDPR Art. 35 DPIA
                        ▲
                        │  admission credential issued + verifiable
                   ONBOARDING

Step by step

1 — A standard becomes rules an agent can follow

C2MD takes the control — a NIST SP 800-53 ID, an ISO 42001 clause, an EU AI Act or GDPR article — and produces MUST / MUST NOT / MAY rules for this agent, each keeping its clause-level citation. Translate a control → · Generate the bundle →

Why this step matters: "implement appropriate technical and organisational measures" cannot be evaluated at runtime. "MUST NOT return a decision if the logging path is unavailable" can.

2 — Governance lands in git and is treated like code

ACP owns everything after genesis. Changes are authored against a Compliance Guard, run through an adversarial test suite, and reviewed as a pull request. Authority is read from git's own mechanisms — CODEOWNERS and branch protection — rather than a parallel permissions system nobody maintains.

3 — A named human ratifies what actually carries risk

Risk-driving values — autonomy level, data categories — are raised to HITL as a ratification item. An authorised person resolves it, HITL seals the decision to Witness under customer-managed custody, and ACP's activation gate is fed by that sealed resolution.

4 — Approved governance is signed and distributed

ACP builds a signed, versioned, content-hashed bundle from approved git state and seals the activation to Witness against the commit hash.

Agents never git pull. Git is not a runtime distribution channel — it is mutable by a repo admin and is not the evidence layer. Agents fetch the signed bundle, verify the signature offline, cache it, and evaluate locally.

5 — Every governed decision is sealed

Witness seals decisions to a tamper-evident, hash-chained record. On the Anchored tier the trail is committed to external transparency logs — Sigstore Rekor and RFC-3161 timestamp authorities — which is what makes it provable even against us.

6 — The trail becomes evidence an auditor can check

The sealed record is read back as an EU AI Act article-by-article readiness board and a GDPR Article 35 DPIA — built from a real run rather than a template. Evidence & Readiness Report →

In attested mode the auditor's copy is verified offline against pinned public infrastructure with no key shared with anyone, including us. The verification does not depend on trusting VDA — which is the only kind of evidence worth having.

Start with one block

Each block is useful on its own; they are stronger composed. You do not adopt a cycle, you adopt a block and grow into it.

Honest status