OpenChainGraph Standard v0.8.8

Conformance Language

"MUST", "MUST NOT", "SHOULD", and "MAY" are used per RFC 2119. An implementation is v0.4-conformant if and only if it (a) emits artifacts that validate against openchain-graph-v0.4.schema.json, and (b) passes every gate in §15. Conformance is defined by the schema plus the gates, not by prose alone.

Artifact Schema (v0.4)

The complete artifact envelope at v0.4. Fields marked new are additions in v0.3 (§8–§9); the v0.2 envelope fields (@context, buildType, the in-toto audit_signature) are retained, and all v0.1 and v0.2 artifacts remain valid; implementations may omit any optional field.

{
  "@context": "https://ainumbers.co/chaingraph/context/v0.3/context.jsonld",  // JSON-LD context (§3); ISO 20022 tools use an array adding iso20022-context.jsonld (§8)
  "chaingraph_version": "0.4.0",
  "compute_mode": "server",  // NEW in v0.4 — "server" | "browser" (§12); excluded from hash preimage
  "buildType": "https://ainumbers.co/chaingraph/context/v0.2#WebCryptoSHA256",  // version-independent algorithm URI — unchanged in v0.4 (§4)
  "mandate_id": "uuid-v4-string",
  "tool_id": "ain:art-01",
  "mandate_type": "ap2_mandate_chain_record",
  "semantic_profile": "iso20022:pacs.008-subset",  // NEW in v0.3 — optional ISO 20022 alignment (§8)
  "execution_hash": "sha256:3f9a1b2c8d7e4f0a5c6b2e1d9f3a7c4b8f1e5d2a9c0b6f3e7d4a1b8c5e2f9d0",
  "supersedes": ["sha256:…"],  // NEW in v0.7 — optional: execution_hashes this artifact corrects or replaces; declared at creation, no reverse link, no status registry
  "anchor_bindings": […],      // NEW in v0.7 — optional §20 anchor evidence; attached AFTER hashing, excluded from execution_hash scope
  "chain": {
    "parent_hashes": ["sha256:abc123..."],
    "parent_tool_ids": ["ain:art-00"],
    "chain_depth": 1
  },
  "policy_parameters": { /* tool-specific inputs */ },
  "output_payload":    { /* tool-specific outputs */ },
  "compliance_flags": [],
  "audit_signature": {                          // UPDATED — now in-toto envelope (§4)
    "payloadType": "application/vnd.openchain.graph+json;version=0.2",
    "payload":     "<base64url(canonical_json_of_artifact_without_this_field)>",
    "signatures": [
      {
        "keyid": "sha256:<fingerprint_of_ed25519_public_key>",
        "sig":   "<base64url(ed25519_signature_over_payload)>"
      }
    ]
  }
}

Versioning model

An artifact carries several version numbers and, by design, none of them is the headline release number. OCG uses layered, decoupled version identifiers, following the in-toto / SLSA convention where additive changes do not move the wire identifier (a SLSA predicateType URI resolves to the latest minor version and only changes on a breaking revision). Read each one for what it answers:

The unifying rule: every additive layer (the vc export of §13.11, and the §16 proof, §17 build_identity, and §18 compute_proof attestations) is hash-excluded and rides under audit_signature, so it never moves chaingraph_version: a v0.6 artifact still validates under the frozen v0.4 schema. chaingraph_version is the schema version ("parse me with this"), not the standard release (which is spec_version). Renaming chaingraph_version to a clearer format_version or a self-describing type URI would itself be a breaking envelope change (the envelope root is additionalProperties:false), so it is reserved for a future major revision.

Hash Preimage Construction (unchanged from v0.1)

The canonical preimage for execution_hash is deterministic and reproducible by any party. No timestamps, nonces, or process-specific state may enter the preimage.

Algorithm

preimage = {
  "output_payload":    artifact.output_payload,
  "policy_parameters": artifact.policy_parameters
}

// 1. Serialize with keys sorted lexicographically (deep sort — all nested objects)
canonical_json = JSON.stringify(preimage, sorted_replacer)

// 2. Encode as UTF-8 bytes
bytes = TextEncoder().encode(canonical_json)

// 3. SHA-256 via WebCrypto (or any compliant SHA-256 implementation)
hash_buffer = await crypto.subtle.digest("SHA-256", bytes)

// 4. Hex-encode
execution_hash = "sha256:" + hex(hash_buffer)

mandate_type Taxonomy

The recommended internal taxonomy for mandate_type: prompt_template, payment_mandate, payment_policy, compliance_mandate, liquidity_mandate, capital_assessment, risk_control, settlement_mandate, infrastructure_mandate, credit_assessment, treasury_mandate, account_mandate, model_governance, attestation_mandate, cryptographic_mandate, aml_rule, risk_parameter. This is an internal AINumbers taxonomy, not AP2 v0.2 vocabulary.

The schema treats mandate_type as a non-empty string, not a hard enum: shipped nodes also use agent_guardrail_mandate (fit diagnostics) and scheme_rule, and the enum is not CI-enforced. New tools SHOULD prefer a type from the recommended taxonomy where one fits.

JSON-LD @context: W3C PROV-DM Alignment

Publishing a JSON-LD context makes OpenChainGraph artifacts interpretable by any system that speaks W3C PROV (regulatory tooling, DORA/Basel/EU AI Act compliance platforms, semantic web processors). The mapping is additive; existing tools need not change their output format.

Published context URL: https://ainumbers.co/chaingraph/context/v0.2/context.jsonld

{
  "@context": {
    "@vocab":   "https://ainumbers.co/chaingraph/context/v0.2#",
    "prov":     "http://www.w3.org/ns/prov#",
    "dcat":     "http://www.w3.org/ns/dcat#",
    "schema":   "https://schema.org/",

    // Tool = prov:Agent that performed the computation
    "tool_id":          { "@id": "prov:wasAttributedTo" },

    // policy_parameters = prov:Entity (the input data consumed)
    "policy_parameters": { "@id": "prov:used" },

    // output_payload = prov:Entity generated by the activity
    "output_payload":    { "@id": "prov:wasGeneratedBy" },

    // chain.parent_hashes = set of prov:wasDerivedFrom relations
    "parent_hashes":     { "@id": "prov:wasDerivedFrom", "@container": "@list" },

    // execution_hash = prov:hadPrimarySource (the content-addressed identifier)
    "execution_hash":    { "@id": "prov:hadPrimarySource" },

    // mandate_type = schema:additionalType (semantic classification)
    "mandate_type":      { "@id": "schema:additionalType" },

    // chain_depth = schema:position (ordinal distance from root)
    "chain_depth":       { "@id": "schema:position", "@type": "xsd:integer" }
  }
}

PROV-DM conceptual mapping

Signature Envelope: in-toto Format

The audit_signature field is upgraded from an opaque string to a structured in-toto Attestation Framework envelope (ITE-6 compatible). This enables independent signature verification using any in-toto-compliant verifier, and future integration with Sigstore and Cosign.

The buildType URI identifies the specific hash construction algorithm used for the execution_hash. The currently defined values:

Envelope construction

// 1. Build a copy of the artifact without the audit_signature field
artifact_for_signing = omit(artifact, "audit_signature")

// 2. Serialize canonically (sorted keys, no extra whitespace)
canonical_json = JSON.stringify(artifact_for_signing, sorted_replacer)

// 3. Base64url-encode the UTF-8 bytes — this is the "payload"
payload = base64url(TextEncoder().encode(canonical_json))

// 4. Sign (see §5 for Ed25519 details)
sig = base64url(ed25519.sign(private_key, TextEncoder().encode(payload)))

// 5. Embed the envelope
artifact.audit_signature = {
  payloadType: "application/vnd.openchain.graph+json;version=0.2",
  payload:     payload,
  signatures:  [{ keyid: key_fingerprint, sig: sig }]
}

Verification

// 1. Extract payload and signature from the artifact
{ payload, signatures } = artifact.audit_signature
{ keyid, sig } = signatures[0]

// 2. Look up the vendor's public key from the Graph Index (§7)
public_key = graph_index.tools
  .find(t => t.tool_id === artifact.tool_id)
  .signing_keys
  .find(k => k.keyid === keyid)
  .public_key

// 3. Verify Ed25519 signature
is_valid = ed25519.verify(
  public_key,
  TextEncoder().encode(payload),  // message = the payload bytes
  base64url_decode(sig)
)

// 4. Separately, verify the execution_hash (as in v0.1)
artifact_body = base64url_decode(payload)
recomputed_hash = sha256(canonical_preimage(artifact_body))
hash_matches = ("sha256:" + recomputed_hash) === artifact.execution_hash

Ed25519 Signing Algorithm

OpenChainGraph specifies Ed25519 (RFC 8032) as the signing algorithm. Ed25519 is compact (32-byte keys, 64-byte signatures), fast, and the algorithm mandated by SLSA L2+ provenance attestations.

Key lifecycle

// Generate key pair (store private key in a secure enclave or HSM)
const { publicKey, privateKey } = await crypto.subtle.generateKey(
  { name: "Ed25519" },
  true,           // extractable (for export)
  ["sign", "verify"]
)

// Export public key as raw bytes → hex → publish in Graph Index
const raw = await crypto.subtle.exportKey("raw", publicKey)
const pub_hex = Array.from(new Uint8Array(raw))
  .map(b => b.toString(16).padStart(2, '0')).join('')

// Key fingerprint = sha256(raw_public_key_bytes), hex-encoded
const fp_buf = await crypto.subtle.digest("SHA-256", raw)
const keyid = "sha256:" + Array.from(new Uint8Array(fp_buf))
  .map(b => b.toString(16).padStart(2, '0')).join('')

Signing

// payload = base64url string (from §4 step 3)
const message = TextEncoder().encode(payload)
const sig_bytes = await crypto.subtle.sign("Ed25519", privateKey, message)
const sig = base64url(sig_bytes)

Verification

// Import vendor's public key from Graph Index (raw format)
const pub_raw = hex_to_bytes(graph_index_public_key_hex)
const publicKey = await crypto.subtle.importKey(
  "raw", pub_raw, { name: "Ed25519" }, false, ["verify"]
)

const is_valid = await crypto.subtle.verify(
  "Ed25519",
  publicKey,
  base64url_decode(audit_signature.signatures[0].sig),
  TextEncoder().encode(audit_signature.payload)
)

OpenTelemetry Span Mapping

An OpenChainGraph artifact can be exported as an OpenTelemetry span, making decision chains visible in any OTel-compatible APM stack (Datadog, Grafana Tempo, Jaeger, Honeycomb) without new infrastructure. The mapping is read-only; OTel data flows from OpenChainGraph, never the reverse.

function artifactToOtelSpan(artifact, rootHash, emitTimeNs) {
  const hexSlice = (h, bytes) => h.replace('sha256:','').slice(0, bytes*2)
  return {
    traceId:       hexSlice(rootHash, 16),
    spanId:        hexSlice(artifact.execution_hash, 8),
    parentSpanId:  artifact.chain.parent_hashes[0]
                     ? hexSlice(artifact.chain.parent_hashes[0], 8)
                     : undefined,
    name:          artifact.tool_id,
    kind:          1,  // INTERNAL
    startTimeUnixNano: emitTimeNs,
    endTimeUnixNano:   emitTimeNs,
    attributes: [
      { key: "ocg.mandate_type",       value: { stringValue: artifact.mandate_type } },
      { key: "ocg.mandate_id",         value: { stringValue: artifact.mandate_id } },
      { key: "ocg.chain_depth",        value: { intValue:    artifact.chain.chain_depth } },
      { key: "ocg.chaingraph_version", value: { stringValue: artifact.chaingraph_version } },
      { key: "ocg.buildType",          value: { stringValue: artifact.buildType } },
    ],
    status: {
      code: artifact.compliance_flags?.some(f => f.severity === 'ERROR') ? 2 : 1
    }
  }
}

DCAT 3.0 Graph Index

The Graph Index (chaingraph.json) is the machine-discoverable catalog of a vendor's OpenChainGraph-conformant tools. v0.2 expresses it as a W3C DCAT 3.0 catalog, making it crawlable by data portals, regulatory reporting platforms, and semantic web processors, without removing any existing fields.

{
  "@context": {
    "dcat":  "http://www.w3.org/ns/dcat#",
    "ocg":   "https://ainumbers.co/chaingraph/context/v0.2#",
    "prov":  "http://www.w3.org/ns/prov#",
    "dct":   "http://purl.org/dc/terms/"
  },
  "@type":           "dcat:Catalog",
  "@id":             "https://ainumbers.co/chaingraph/chaingraph.json",
  "dct:title":       "AINumbers OpenChainGraph Suite",
  "dct:description": "48 Policy-Mandate-emitting, hash-anchored financial decision tools.",
  "dct:publisher":   { "@id": "https://postoaklabs.com", "dct:title": "Post Oak Labs" },
  "ocg:conformance_level": "L4",
  "ocg:mcp_endpoint": "https://mcp.ainumbers.co/mcp",

  "dcat:dataset": [
    {
      "@type":        ["dcat:Dataset", "ocg:DecisionTool"],
      "@id":          "ain:art-01",
      "dct:title":    "AP2 Mandate Chain Validator",
      "dct:description": "Validates AP2 mandate chain integrity with execution_hash.",
      "ocg:mandate_type": "ap2_mandate_chain_record",
      "ocg:consumes": [],
      "ocg:feeds":    ["ain:art-02", "ain:art-17"],
      "ocg:mcp_tool_name": "validate_ap2_mandate_chain",

      // Ed25519 signing key published here for artifact verification
      "ocg:signing_keys": [
        {
          "keyid":      "sha256:<key_fingerprint>",
          "public_key": "<hex-encoded Ed25519 public key>",
          "valid_from": "2026-01-01"
        }
      ],

      // DCAT access service — MCP endpoint for this specific tool
      "dcat:accessService": {
        "@type":            "dcat:DataService",
        "dcat:endpointURL": "https://mcp.ainumbers.co/mcp",
        "dct:conformsTo":   "https://modelcontextprotocol.io/spec/2025-11-05"
      }
    }
    // ... one entry per tool ...
  ]
}

ISO 20022 Semantic Profile

v0.2 gave the provenance envelope a semantic standard (W3C PROV-DM). v0.3 gives the financial payload one. The ISO 20022 semantic profile is an optional, additive overlay that maps a curated subset of payload fields to ISO 20022 business elements and adopts the ISO external code lists by reference. It is minimal by design (amount, party, and agent fields only) and it never enters the execution_hash preimage (§2 is unchanged).

Published context URL: https://ainumbers.co/chaingraph/context/v0.3/iso20022-context.jsonld

{
  "@context": [
    "https://ainumbers.co/chaingraph/context/v0.3/context.jsonld",
    "https://ainumbers.co/chaingraph/context/v0.3/iso20022-context.jsonld"
  ],
  "chaingraph_version": "0.3.0",
  "tool_id": "ain:rca-03",
  "mandate_type": "compliance_mandate",
  "output_payload": {
    "instructed_amount": { "amount": "15000.00", "currency": "EUR" },  // ActiveCurrencyAndAmount · Ccy=ISO 4217
    "debtor":    { "party_name": "ACME SA",  "lei": "529900T8BM49AURSDO55" },  // ISO 17442
    "creditor":  { "party_name": "Beta GmbH", "lei": "391200X3K8N4WLB9AB12" },
    "debtor_agent":   { "bicfi": "DEUTDEFFXXX" },  // BICFI · ISO 9362
    "creditor_agent": { "bicfi": "BNPAFRPPXXX" },
    "settlement_date": "2026-11-23",  // IntrBkSttlmDt · ISO 8601
    "remittance_information": "INV-2026-0042"  // RmtInf
  }
}

Field mapping

Party Identity: LEI & did:key

v0.3 formalizes two optional identity anchors that already appeared informally in the v0.2 guides. Both are optional; neither changes the hash preimage.

did:key as the recommended keyid

The in-toto signature envelope's keyid (§4) SHOULD be a did:key identifier: a multicodec-prefixed, base58btc encoding of the raw Ed25519 public key (the z6Mk… form). This makes the signer self-describing and resolvable without a separate key registry, while remaining compatible with the Graph Index signing_keys lookup (§7).

LEI for regulated party identity

A publisher or tool MAY carry an ISO 17442 Legal Entity Identifier. This binds an OpenChainGraph vendor (and, where relevant, the signing key) to a regulator-grade legal-entity anchor that banks, PSPs, and supervisors already consume. The LEI is the natural identity bridge between the §8 ISO 20022 profile (where debtor/creditor parties carry LEIs) and the §4/§5 signing identity.

{
  "publisher": {
    "name": "Post Oak Labs",
    "lei":  "<ISO 17442 LEI, if registered>"       // optional
  },
  "audit_signature": {
    "signatures": [
      { "keyid": "did:key:z6MkrJVnaZkeFzdQyMZu1cgjaeW7MoFaNKg4tLCf4g3kEhWh", "sig": "…" }
    ]
  }
}

OKF Companion Bundle

v0.3 publishes an Open Knowledge Format (OKF) companion bundle (a directory of markdown concept files, one per Graph Index node) auto-generated from chaingraph.json. It is the narrative knowledge layer that complements the machine-readable DCAT catalog (§7): DCAT is the catalog an agent plans a chain from; OKF is the curated context an agent or human reads to learn what a tool means and when to use it.

okf/
├── index.md                 # root · progressive disclosure
├── log.md                   # generation history
├── mandate-types/
│   ├── index.md
│   └── <mandate_type>.md
└── tools/
    ├── index.md
    └── <tool_id>.md         # one concept per live node; consumes/feeds → markdown links

Each concept carries OKF YAML frontmatter (type, title, description, resource, tags, timestamp); the node's consumes/feeds edges become markdown links between concepts, reproducing the graph. The bundle is regenerated on every Graph Index change and is fully reversible: nothing in OpenChainGraph's verification path depends on it. The generator and consumer walkthrough are in the OKF integration guide.

Profile Conformance

v0.3 introduced ISO 20022 alignment via an inline semantic_profile string token. v0.3.1 makes that conformance a first-class, machine-resolvable assertion using the W3C Profiles Vocabulary (PROF) and Content Negotiation by Profile: a profile is a dct:Standard published at a dereferenceable URI and declared with dct:conformsTo. This is fully additive: the execution_hash preimage is unchanged and semantic_profile tokens stay valid as registered aliases.

Published profiles

Token → URI registry

The authoritative token↔URI map is published at chaingraph-standard/profiles/registry.json (Content-Negotiation-by-Profile permits a short token alongside the mandatory URI). Each profile URI dereferences to a PROF prof:Profile document listing its schema (the v0.3 ISO 20022 context) and guidance resources.

{
  "@context": [
    "https://ainumbers.co/chaingraph/context/v0.3/context.jsonld",
    "https://ainumbers.co/chaingraph/context/v0.3/iso20022-context.jsonld"
  ],
  "chaingraph_version": "0.3.1",
  "ocg:semantic_profile": "iso20022:pacs.008-subset",        // token alias (retained)
  "dct:conformsTo": ["https://ainumbers.co/chaingraph/profiles/iso20022/pacs008-subset.jsonld"]  // authoritative, dereferenceable
}

Compute Binding new in v0.4

OpenChainGraph v0.4 introduces Compute Binding: the mechanism by which an MCP tool computes a node's decision function server-side and returns a fully verifiable v0.4 artifact in a single round-trip, instead of delegating to the browser. This makes every gpu:false node with a registered kernel agent-native: an AI agent can call the tool, receive the structured output_payload and execution_hash, and immediately chain to downstream tools without requiring a browser session.

§12.1: compute_capability field

Every live node in chaingraph.json carries a compute_capability field that declares how the Worker will dispatch it:

{
  "tool_id":            "art-05-eu-ai-act-credit-scoring-conformity",
  "gpu":                false,
  "compute_capability": "server"   // "server" | "browser" | "auto"
}

§12.2: GPU delegation and the compute parameter

Callers may override dispatch per-call using the compute input parameter on any ChainGraph MCP tool:

{
  "compute": "auto"    // default — server for gpu:false nodes with kernels
  "compute": "server"  // force server-side (errors if no kernel)
  "compute": "browser" // always return browser delegation URL
}

Nodes with gpu:true ignore compute and always delegate to the browser: the GPU dependency cannot be satisfied server-side. Future nodes may carry a per-node gpu_fallback flag for seeded LCG reduced-path approximation, but this is not part of v0.4.

§12.3: Kernel pattern

A kernel is a pure ESM module at repo/chaingraph/kernels/<tool-id>.kernel.mjs exporting three symbols:

// compute(pp) → { output_payload, compliance_flags }
// Pure: no DOM, no window, no network, no Date.now().
// policy_parameters is passed verbatim so the execution_hash anchors the full input.
export function compute(policy_parameters) { … }

// buildArtifact(pp, opts) → Promise<v0.4 artifact object>
// Calls compute(), then hashes with executionHash() from _hash.mjs.
export async function buildArtifact(pp, { now, parent_hashes, parent_tool_ids, chain_depth } = {}) { … }

// Static metadata for the Worker registry.
export const meta = { tool_id, tool_version, gpu: false, mandate_type };

Kernels are vendored from repo/chaingraph/kernels/ into both mcp-apps-poc/kernels/ (bundled into the Worker by wrangler/esbuild) and mcp-apps-poc/data/kernels/ (served as static assets) by running node generate.mjs before every push.

§12.4: Privacy boundary

The zero-egress contract is preserved for all compute modes. Server-side kernels are pure functions: they receive policy_parameters, run deterministic logic, and return output_payload. No policy parameters, outputs, or user data are logged, stored, or transmitted beyond the JSON-RPC response. The only telemetry written is structural metadata (tool name, latency, success/error flag, and a salted one-way hash of the caller IP: never the payload). gpu:true nodes continue to run entirely in the user's browser with zero network egress.

§12.5: v0.4 artifact schema delta

The v0.4 artifact adds two fields to the v0.3.1 envelope:

{
  "chaingraph_version": "0.4.0",           // bumped from 0.3.x
  "compute_mode":       "server",           // "server" | "browser" — new in v0.4
  …                                          // all v0.3 fields retained
}

The hash preimage definition is unchanged: execution_hash is still SHA-256(JCS({ policy_parameters, output_payload })). A v0.4 artifact is verifiable by any v0.3 verifier that ignores unknown fields.

Export Profiles new in v0.4

OpenChainGraph v0.4 adds export profiles: generated, non-canonical renderings of an already-verified artifact, produced after execution_hash is computed and excluded from the hash preimage. They exist so the cryptographic anchor stays attached at the last mile (where a human reviewer, a downstream pipeline, or a regulator actually consumes the decision) instead of breaking the provenance chain the moment someone hand-copies output_payload into a spreadsheet, board memo, or filing.

Export profiles follow the exact precedent of the OKF companion bundle (§10): a generated view, never hand-edited, never independently verifiable, fully swappable, and additive: no existing tool, kernel, or verifier changes to remain v0.4-valid.

§13.1: The chaingraph_export umbrella

Every export format is a documented sub-profile under one umbrella term, chaingraph_export:<format>:

chaingraph_export:xlsx   // analyst / board spreadsheet
chaingraph_export:pdf    // signed board / audit one-pager
chaingraph_export:csv    // pipeline-tabular sibling of xlsx
chaingraph_export:xbrl   // regulator-submission profile (taxonomy per regime)
chaingraph_export:vc     // W3C Verifiable Credentials 2.0 (base profile, all nodes; new in v0.4.1)

§13.2: Conformance rules (every export profile MUST)

1. Be generated solely from the verified artifact's output_payload (+ optionally policy_parameters): never hand-authored.
2. Embed a metadata block carrying tool_id, execution_hash, chaingraph_version, compute_mode, and (if present) audit_signature.signatures[0].keyid, plus a link/QR to the canonical JSON artifact or its verification endpoint.
3. NOT carry a new execution_hash and NOT be treated as independently verifiable: it is a view, not a fact. Verification always routes back to the canonical JSON.
4. Be optional and additive: absence of an exporter never invalidates a tool.
5. Be deterministic: same artifact + same exporter version → byte-stable output (static per-mandate_type templates, sorted rows, fixed number formats), so two parties can confirm they hold the same rendering.

§13.3: Generation: server-side (Cloudflare Worker)

Export generation runs in the Worker (the same runtime as the Compute-Binding kernels) as one canonical generator rather than N drifting client implementations. The rationale mirrors §12: agent-native, single round-trip, reproducible. The zero-egress/privacy boundary of §12.4 applies unchanged: exporters are pure functions over an artifact the caller already holds; no payload is logged, stored, or transmitted beyond the JSON-RPC response. (Strict client-side generation remains permissible for an air-gapped deployment using the published exporter spec, but the reference generator is server-side.) Exporters live at repo/chaingraph/exporters/<format>/ (parallel to kernels/), each a pure buildExport(artifact) → Uint8Array, vendored into the Worker by generate.mjs on the same push (same two-repo discipline as kernels).

§13.4: MCP surface: the export_artifact tool

A single new read-only MCP tool: not a format parameter on every tool (which would inflate all schemas), nor an out-of-band endpoint (which would split the agent-callable story). This follows MCP best practice: focused, domain-aware tools an agent can reason about, with one tool owning the render concern.

// Tool: export_artifact   (readOnlyHint: true)
{
  "artifact":       // full v0.4 artifact object (REQUIRED — stateless Worker, no cache)
  "format":         "xlsx" | "pdf" | "csv" | "xbrl" | "vc",
  "xbrl_taxonomy":  "<regime id>"   // required only when format = xbrl (§13.8)
}
// Returns:
{
  "format":      "xlsx",
  "filename":    "<tool_id>-<short_hash>.xlsx",
  "media_type":  "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
  "bytes_base64": "…",           // standard base64 (NOT url-safe) — avoids client decode bugs
  "metadata":    { "tool_id", "execution_hash", "chaingraph_version", "compute_mode" }
}

The agent flow stays end-to-end: call a compute tool → receive JSON artifact + execution_hash → call export_artifact with that artifact → receive the rendered file. Both calls are readOnlyHint:true. For large outputs (big GPU-batch CSVs), the Worker returns an MCP resource (URI-addressable, read-only) instead of an oversized inline blob. The tool rejects any (tool, format) pair not present in the node's export_capability (§13.10): a deterministic, discoverable failure.

§13.5: chaingraph_export:xlsx

Workbook convention:

Sheet "Decision"    // verdict, tool_id, mandate_type, timestamp;
                    // metadata block (execution_hash, chaingraph_version, compute_mode, keyid); QR
Sheet "Data"/…    // tabular output_payload — percentile tables, batch rows, distributions
Sheet "Provenance"  // optional: chain.parent_hashes, parent_tool_ids, compliance_flags[]

Generated with a Workers-compatible OOXML writer (pure JS/WASM, no Node fs); a minimal hand-rolled OOXML writer is acceptable given the simple, deterministic structure. Pilot tools: compute_rwa_scenarios, validate_einvoice_batch, simulate_vop_matching, run_liquidity_stress_test: all already tabular in shape.

§13.6: chaingraph_export:pdf

Board/audit one-pager: verdict headline, key output_payload fields as prose/table, execution_hash + signing keyid in the footer, and a QR encoding the verification URL. Uses a static template per mandate_type (one layout for attestation_mandate, one for compliance_mandate, etc.) so output is reproducible artifact-to-artifact: no freeform layout. Best fit: precheck_reserve_attestation, assess_ai_act_conformity, classify_dora_incident. Server-side deterministic renderer.

§13.7: chaingraph_export:csv

The pipeline-tabular sibling of xlsx: same extraction, simpler serialization (near-free once xlsx exists). For data-engineering consumers and large GPU-batch outputs (run_liquidity_stress_test 1,000×250, simulate_stablecoin_reserve 1,000×90). One CSV per logical table; a manifest row carries the metadata block. (Parquet is a future columnar option once a concrete pipeline consumer asks, not in v0.4, to avoid Arrow/Parquet Workers-runtime dependency weight.)

§13.8: chaingraph_export:xbrl (regulator-submission profile)

The strategic profile: render artifacts as XBRL/iXBRL so they are submission-ready, not merely analyst-readable. XBRL requires a taxonomy per regulatory regime: there is no single mapping. v0.4 defines the umbrella, the export_artifact interface (xbrl_taxonomy selector), and the initial mapping; each regime's concept mapping is a tracked work item.

Rule: No fabricated taxonomy concepts: every concept must trace to a published regulator element or an explicitly-OCG extension element. The lightweight default is the OCG extension taxonomy ocg-ext, published at chaingraph/xbrl/ocg-ext/ocg-ext-2026.xsd: a small, self-contained, regime-neutral XBRL 2.1 schema that produces a fully validatable instance (verify with any XBRL processor, e.g. Arelle) with no external taxonomy dependency. Mapping into a regulator taxonomy (e.g. EBA COREP for EU capital & liquidity) is optional and pull-driven: undertaken only when a real submission to that regulator is required, since it is version-coupled and dimensional. Every XBRL export records its source taxonomy + version in-context.

§13.9: Three layers, not three formats for one thing

v0.4 extends §10's "two layers" framing to three: provenance-out (JSON) → knowledge-in (OKF) → rendered-for-review (xlsx / pdf / csv / xbrl / vc). All three derive from the same verified artifact; only the JSON layer is canonical and hash-anchored.

§13.10: export_capability discovery field

Mirroring compute_capability, every live node in chaingraph.json MAY declare which export profiles it supports, so MCP clients/agents discover formats before calling export_artifact:

{
  "tool_id":            "compute_rwa_scenarios…",
  "compute_capability": "server",
  "export_capability":  ["xlsx", "csv", "xbrl:eba-corep-own-funds"]
}

Absent or [] → JSON-only (still v0.4-valid). xbrl:<taxonomy-id> entries name a specific taxonomy from §13.8. The Graph Index / DCAT surface (§7) gains a discovery signal symmetric with compute_capability. Base profiles (see §13.11 vc) are exempt: available on every node without a declaration.

§13.11: chaingraph_export:vc (W3C Verifiable Credentials profile) new in v0.4.1

Renders a verified artifact as a W3C Verifiable Credentials 2.0 credential (application/vc+json): the standards-conformant interchange shell for agents and counterparties that already speak VC. It is a base profile: available on every node regardless of export_capability, because a lossless structural re-expression of the canonical artifact always exists. Envelope → VC mapping:

{
  "@context": ["https://www.w3.org/ns/credentials/v2", "<ocg vc context>"],
  "id":       "urn:ocg:artifact:<bare-execution-hash>",   // deterministic — no UUID/clock
  "type":     ["VerifiableCredential", "OpenChainGraphCredential"],
  "issuer":   "<issued_by>",
  "validFrom", "validUntil":  // from valid_from / valid_until
  "credentialSubject": { "mandate_type", "policy_parameters", "output_payload" },
  "ocg:hashAnchor": {        // re-states the canonical hash — NOT a VC proof suite
    "type": "OpenChainGraphHashAnchor2026", "digestMethod": "sha-256",
    "executionHash", "verify_url"
  }
}

Like every §13 profile, vc is a view, not a fact: it mints no new execution_hash and adds no securing proof: verification routes back to the canonical JSON. A deployer needing a secured VC adds an enveloping JOSE/COSE or Data Integrity proof downstream (out of profile scope; §16 Proof Binding provides exactly this over the canonical artifact). Deterministic: the same artifact renders byte-identical bytes. Because export profiles are not part of the artifact envelope, the envelope and hash preimage are unchanged at v0.4.1: artifacts still emit chaingraph_version:"0.4.0"; only spec_version bumps to 0.4.1.

§13.12: Selective-disclosure export (SD-JWT, RFC 9901) new in v0.7

An implementation MAY export an artifact as an RFC 9901 SD-JWT whose claims map deterministically from the envelope, EXCEPT the disclosure salts, which MUST be freshly CSPRNG-generated per export (the one permitted nondeterminism; it is confined to the export and never touches the envelope or execution_hash). ALWAYS-DISCLOSED (non-selectively-disclosable) claims: execution_hash, chaingraph_version, spec_version, compute_capability, the §17 kernel/build identity fields, all outputs (output_payload), and timestamps. SELECTIVELY DISCLOSABLE: top-level input values only. Signature: JWS (EdDSA) under the §16 signing key.

Normative limitation (MUST be stated by presenting UIs): a redacted export is NOT re-executable and does NOT permit execution_hash recomputation; its verification yields (a) issuer-signature integrity and (b) hash-binding of each disclosed claim. The full envelope remains the artifact of record. Gate: sd-export-roundtrip.test.mjs (§15).

§13.13: xBRL-JSON export profile ocg-xbrl-json@1 new in v0.8.12

A regulatory-reporting export profile rendering a verified artifact as xBRL-JSON (OIM 1.0, REC 2021-10-13), the JSON serialization of the XBRL Open Information Model. Like every §13 profile it is a view, not a fact: generated after execution_hash, excluded from the hash preimage, mints no new hash, and MUST NOT bump chaingraph_version.

Canonical form: the document MUST set xbrl:canonicalValues: true (OIM's own canonical-lexical-value mode) AND apply JCS (RFC 8785) key ordering on top, since xBRL-JSON itself leaves member order undefined, together making the document byte-identical for byte-identical inputs. execution_hash is embedded in the document's metadata block, never inside a fact.

Taxonomy metadata is INPUT, not derived: concept QNames, dimensions, units, and decimals are supplied as taxonomy metadata (the §13.8 never-fabricate discipline: a concept is emitted only when it maps to a published taxonomy element, or an explicit ocg-ext:* element where none exists). DTS discovery, XDT validation, and formula-linkbase execution are explicitly out of scope.

Normative caveat (MUST be surfaced by presenting UIs): this is NOT a submittable wire format. FFIEC Call Report submission is XBRL 2.1 XML; EBA submission is xBRL-CSV (mandatory from 2026-03); SEC/ESEF submission is iXBRL. This profile's output is a canonical interchange form, lossless via a certified OIM processor (e.g. Arelle, Apache-2.0); an implementation MUST NOT label it "submittable" or "regulator-accepted."

Validation is external, by pointer: this spec vendors no OIM/XBRL validator (mirrors §18.1's stark-verifier delegation). Annex 1, the FFIEC Call Report mapping: concept namespace is the published FFIEC 031/041 taxonomy, item alignment keys off public-domain MDRM item codes (e.g. RCON2170 Total assets, RCON3210 Total equity capital), never a fabricated concept. Annex slots are reserved for EBA DPM 2.0 (xBRL-CSV) and future regimes; an unpopulated slot returns a "pending" error exactly as §13.8's COREP maps do.

Gate: xbrl-json-fixtures.test.mjs (§15): round-trip determinism, canonicalValues conformance, and Annex 1 structural load against the committed fixtures. Fence: this profile ships as spec text + schema + the two fixtures; the exporter implementation (exporters/xbrl-json.mjs, worker wiring) is a separate, later work unit.

Proof Binding new in v0.5

A node MAY bind authenticity to a verified artifact by attaching an OPTIONAL W3C Data Integrity proof (cryptosuite eddsa-jcs-2022, W3C Recommendation 2025-05) at audit_signature.proof. This turns the §4 execution_hash from tamper-evidence (recompute → matches inputs) into authenticated attestation (a named key vouches for the artifact): filling the §13.11 gap, where the vc view mints no securing proof. Proof Binding is OPTIONAL and holder-chosen; an artifact with no audit_signature.proof is fully v0.5-conformant.

§16.0: Home: audit_signature.proof

The proof lives at audit_signature.proof: not at artifact root and not inside the DSSE-style audit_signature.signatures[] array. The artifact root is additionalProperties:false in the frozen v0.4 schema, so a root proof would make a signed artifact fail a v0.4 verifier; audit_signature tolerates added properties, so a signed v0.5 artifact still validates under the frozen v0.4 schema. signatures[] keeps its separate DSSE/in-toto meaning (§9).

§16.1: Stock Data Integrity pipeline (whole-artifact)

The secured document is the full artifact with audit_signature.proof removed. Generation follows eddsa-jcs-2022 verbatim:

document   = artifact \ { audit_signature.proof }
hashData   = SHA-256( JCS(proofOptions) ) ‖ SHA-256( JCS(document) )   // RFC 8785 / JCS
proofValue = "z" + base58btc( Ed25519.sign(privateKey, hashData) )      // multibase

Because execution_hash sits inside the secured document, a whole-artifact signature transitively secures the §4 anchor. The JCS canonicalizer is the same kernels/_hash.mjs cgCanon used by §4: no second canonicalization path (the array-replacer forms FORBIDDEN by §4 stay forbidden). Produced by the shared kernels/_proof.mjs (browser inlines it; Worker imports it; byte-identical). Verification is reproducible offline: recompute execution_hash per §4, then verify proofValue against the verificationMethod key over the same input. The signing key SHOULD be published in the Graph Index ocg:signing_keys (§7).

§16.2: Privacy tradeoff (default-off)

A §16 proof makes a run linkable to a key, eroding the default zero-PII anonymous posture (a feature for some users). Proof Binding therefore MUST default OFF and MUST NOT be auto-applied; a tool offering it MUST surface that signing de-anonymizes the run. zero_pii_verified semantics are unchanged: inputs stay PII-free; the signer becomes known.

§16.3: Relation to §13.11

A §16 proof secures the canonical OCG artifact, not the vc re-expression (§13.11). When that artifact is exported as a VC, its ocg:hashAnchor routes a verifier back to the canonical JSON where the proof lives, so the secured artifact stays verifiable through the VC. A deployer needing a proof on the VC document itself re-runs the same eddsa-jcs-2022 pipeline over the VC (a distinct proof, outside §16 scope).

§16.4: Issuer identity: did:key vs did:web

For ephemeral / fully client-side signing a did:key suffices and is the only CONTRACT-compatible option (a private key MUST NOT ship in client HTML or storage). A stable institutional issuer SHOULD anchor to did:web over the publisher's domain with the private key held in an HSM/KMS and signing performed server-side (e.g. the §12 compute path). Both are interoperable verificationMethod values.

§16.5: Proof sets and endorsement chains new in v0.7

audit_signature.proof MAY be an array. A parallel proof set (multiple independent signers over the same artifact) follows VC Data Integrity 1.0 proof-set semantics. An ENDORSEMENT (countersignature approving a prior signature) MUST use proof-chain semantics: the endorsing proof's previousProof references the id(s) of the proof(s) it endorses, and verifiers MUST verify chained proofs in dependency order. No new cryptosuite: eddsa-jcs-2022 throughout. Gate: countersignature fixture in proof-binding.test.mjs (§15).

Kernel Identity Binding new in v0.6

A node MAY publish, and an artifact MAY record, the content digest of the exact kernel that produced it: closing the §4 gap that execution_hash proves "this output follows from these inputs by some logic" but does not pin which logic ran.

§17.0: Home: audit_signature.build_identity

The binding lives at audit_signature.build_identity (hash-excluded, like §16: keeps the frozen v0.4 root schema; an artifact without it is byte-identical to v0.5). It MUST carry a kernel_digest (a sha256:-prefixed digest produced by the shared kernels/_buildid.mjs over the kernel's canonical source bytes, UTF-8, LF-normalized, via WebCrypto SHA-256) and a buildType URI; source_ref is optional.

build_identity = {
  "kernel_digest": "sha256:…",   // SHA-256 over LF-normalized kernel source
  "buildType":     "…#WebCryptoSHA256",
  "source_ref":    "kernels/<tool_id>.kernel.mjs"  // optional
}

§17.1: Publication + three-way cross-check

A node SHOULD publish its kernel digest in the Graph Index node field compute_images[] ({ system:"sha256-source", image_id:"sha256:…", valid_from }). A verifier cross-checks three values: artifact.audit_signature.build_identity.kernel_digest == the node's compute_images[].image_id == _buildid.digest(recomputed from source). Any mismatch FAILS the binding.

Compute-Integrity Proof new in v0.6

A node MAY attach an OPTIONAL zkVM compute-integrity proof at audit_signature.compute_proof, turning the §4 hash from re-execute-to-verify (a verifier must re-run the kernel with cleartext inputs) into a succinct proof of correct execution a verifier checks without re-execution and, optionally, without seeing the inputs. This is the §17 claim made cryptographic. It is OCG's analogue of the chained-verifiable-computation goal in Trusted Compute Units (arXiv:2504.15717), but deliberately software/cryptographic only: no TEE, no hardware enclave, no blockchain anchor. An artifact with no compute_proof is fully v0.6-conformant.

§18.0: Home + object: audit_signature.compute_proof

compute_proof = {
  "type":          "ZkVmReceipt",
  "system":        "risc0",            // | "sp1" | "jolt" | … — system-agnostic
  "receiptFormat": "groth16-bn254",    // RECOMMENDED ~200-byte SNARK | "stark"
  "imageId":       "sha256:…",         // guest-program identity (ImageID / vkey)
  "seal":          "<base64>",         // proof bytes — produced OFFLINE (§18.2)
  "journal":       { "output": … }   // MUST equal artifact output_payload
}

§18.1: Verification: two paths, seal delegated

(a) §4 recompute: still valid when inputs are public; or (b) receipt verification: verify seal against imageId, valid even when inputs are withheld. Cryptographic seal-verification is DELEGATED to the named system's vetted verifier (risc0/sp1 verify), exactly as §4 delegates SHA-256 and §16 delegates Ed25519 to WebCrypto: OCG specifies the binding, it does not re-implement a proof system. A self-contained BN254 Groth16 pairing-check verifier for receiptFormat:"groth16-bn254" is a RECOMMENDED reference. OCG's gate (compute-proof.test.mjs) checks the binding: object shape, imageId ↔ Graph Index compute_images, journal ↔ output_payload, no new execution_hash, chaingraph_version stays "0.4.0".

§18.3: Confidentiality + privacy (default-off)

When the receipt is used to withhold inputs, policy_parameters MAY carry commitments/hashes in place of cleartext; then §4 recompute is unavailable to third parties (only the input-holder can re-run) and the receipt becomes the sole verification path: a tool in this mode MUST surface that. Like §16, attaching a compute_proof links the run to a published imageId, so it MUST default OFF.

§18.4: The strength-of-verifiable ladder

§17 = advisory claim of which kernel; §18 = cryptographic proof that that program produced this output; §16 = a named key vouching for the whole artifact. They compose: a §18 receipt MAY itself be covered by a §16 proof. L1 §4 hash (tamper-evidence) → L2 §16 proof (authenticated attestation) → L3 §18 receipt (succinct compute-integrity, optionally confidential).

§18.5: Deterministic guest-equivalent kernels

A §18 proof runs the kernel in a fixed zkVM guest (a pinned JS runtime), not the browser's V8. Where a rule would otherwise depend on a V8 platform API that is locale- or environment-sensitive, or whose faithful in-guest port is infeasible to prove, the kernel MUST use a deterministic, fully specified replacement applied identically on every surface (guest, browser tool, Worker) so the verdict is byte-identical everywhere and the proof binds the rule users actually see. Shipped instances: a pinned en-US number formatter in place of toLocaleString; a deterministic https-scheme plus non-empty-authority check in place of WHATWG URL parsing (faithful parsing measured near 5.4 billion guest cycles, infeasible to prove); and a shared pure-JS fdlibm port for transcendental math (Math.exp/log/sin/cos/pow), since only the four arithmetic operations and square root are IEEE bit-portable across engines. Each replacement documents its scope: it defines the rule, not an approximation of richer V8 behavior. A node whose deterministic proving cost is still prohibitive (for example tens of thousands of transcendental calls in a Monte-Carlo loop) MAY carry the replacement for cross-surface determinism yet stay compute_proof_ready:"deferred" until a larger prover exists.

§18.6: Deterministic-node proof profile (ocg-p18-deterministic)

The base standard keeps §18 OPTIONAL. An implementation MAY additionally declare conformance to the deterministic-node proof profile. Under it, every status:"live" node with gpu:false MUST either carry a compute_proof that verifies against its published imageId (§18.1) or declare compute_proof_ready:"deferred" with a stated deferral_reason; a node with neither is non-conformant to the profile. A gpu:true node is out of scope (heavy or parallel compute whose faithful in-guest proving cost is prohibitive, §18.2; it MAY still attach a proof voluntarily). A blanket §18 MUST is impossible because legitimate heavy or nondeterministic-cost nodes cannot be proven at acceptable cost, while an all-optional posture makes a proof an unreliable, and therefore unusable, trust signal. The profile is the middle path: a MUST exactly over the class where it is achievable, leaving the base standard unchanged for external implementers. Conformance is machine-checked by check-compute-proof-coverage.mjs. Its endgame, zero deferrals on gpu:false, is the state where every deterministic live node carries a real compute-integrity proof; the AINumbers reference deployment conforms with zero deferrals.

Anchor Binding new in v0.7

An artifact MAY carry portable, offline-verifiable evidence that its execution_hash was included in a transparency log or timestamp service by a point in time. Anchor evidence attaches at the OPTIONAL top-level array anchor_bindings, which, like §16 audit_signature, is attached AFTER hashing and is EXCLUDED from execution_hash scope. Each entry:

{
  "type": "rfc3161-tst" | "opentimestamps" | "c2sp-tlog-proof-v1" | "scitt-receipt-rfc9942",
  "anchored_hash": "sha256:…",        // MUST equal the artifact's execution_hash
  "log_origin":    "<TSA URL / log origin string / calendar or service identifier>",
  "proof":         "<base64 verbatim TST DER | base64 OTS proof | tlog-proof@v1 text | base64 COSE receipt>",
  // rfc3161-tst additional members (all REQUIRED for that type):
  "policy_oid", "serial", "gen_time", "signer_cert_chain_b64"
}

Verification (per type): rfc3161-tst: RFC 3161 TimeStampToken verification: messageImprint matches anchored_hash, CMS signature over TSTInfo valid, signer chains to a verifier-pinned TSA root, signing cert carries critical EKU id-kp-timeStamping, genTime sane; the DER is stored VERBATIM (never re-encoded) so openssl ts -verify remains possible independently, forever. opentimestamps: standard OTS verification (complete proofs verify against Bitcoin block headers alone). c2sp-tlog-proof-v1: the C2SP tlog-proof verification procedure (checkpoint signature against the log's public key, cosignature policy per the verifier's trust policy, Merkle inclusion proof for the leaf committing anchored_hash). scitt-receipt-rfc9942: COSE receipt verification per RFC 9942 (accepted as an evidence type for interop; OCG implementations are NOT SCITT Transparency Services and SCRAPI is out of scope). Multi-TSA redundancy across independent authorities and algorithms is RECOMMENDED per RFC 4998 (informative). A verifier MUST reject a binding whose anchored_hash differs from the artifact's recomputed execution_hash. Multiple bindings MAY coexist (several logs, plus OTS). Gate: anchor-binding.test.mjs (§15), whose rfc3161 fixture carries a REAL TimeStampToken from a public TSA verified against a pinned root.

§20.1: Merkle inclusion: batch anchoring new in v0.8

A rfc3161-tst or opentimestamps binding MAY carry an OPTIONAL merkle_inclusion member so ONE timestamp covers MANY artifacts: the anchored value is the ROOT of an RFC 6962 Merkle tree and each covered artifact's execution_hash is a LEAF. (c2sp-tlog-proof-v1 and scitt-receipt-rfc9942 already carry their own inclusion proof inside proof, so they do not use this member.)

{
  "merkle_inclusion": {
    "leaf": "<the artifact execution_hash>",
    "index": 0, "path": ["sha256:…"], "tree_size": 6, "algorithm": "rfc6962"
  }
}

When present, a verifier MUST: (1) confirm leaf equals the artifact's recomputed execution_hash; (2) reconstruct the root from leafHash(leaf) + path via the RFC 6962 inclusion procedure (the SAME leafHash/nodeHash/rootFromInclusion the c2sp/scitt verifiers use, no second Merkle implementation); and (3) require the reconstructed root to equal anchored_hash. Any mismatch FAILS the binding. Absent this member, anchored_hash == execution_hash directly (unchanged v0.7 behavior). merkle_inclusion rides OUTSIDE the hash preimage like the rest of anchor_bindings. Gate: anchor-binding.test.mjs (§15), whose offline fixture synthesizes a small RFC 6962 tree over test hashes.

§20.2: Witness cosignatures on batch anchors new in v0.8.8

A §20 binding carrying a §20.1 merkle_inclusion root (or a c2sp-tlog-proof-v1 anchor) MAY carry an OPTIONAL witness_cosignatures[] array: independent k-of-n cosignatures over the anchored Merkle root, in the C2SP tlog-checkpoint + witness-cosignature note format (a signed note of origin line, tree size, root, then one — <keyname> <base64 sig> line per witness). Suites follow the §PQC-1 reserved-extension discipline: Ed25519 now, an ML-DSA entry RESERVED, no hardcoded suite id in the envelope. A batch anchor proves a root existed at a time (§20.1); cosignatures close anchor equivocation (one root shown to verifier A, a different root to verifier B) WITHOUT the reference deployment operating a log, because the cosigners are independent third parties (existing verifiers such as sigsum-verify and Armored Witness). Verification is offline: the note origin and root must match anchored_hash and at least k valid cosignatures must verify against the pinned witness key set; fewer than k, or a cosignature over a different root, FAILS the binding. witness_cosignatures rides OUTSIDE the hash preimage like the rest of anchor_bindings, so an anchor with no cosignatures is byte-identical and fully conformant. Gate (existing, extended, no new gate): anchor-binding.test.mjs. Attribution: C2SP tlog-checkpoint + witness cosignature note format; Sigsum and Armored Witness named as conformant independent-witness mechanisms.

Post-quantum resilience of the anchor path (informative, new in v0.8.9). The anchor types do not share a post-quantum exposure profile, and the difference is worth stating rather than leaving a reader to infer it. An opentimestamps binding derives its integrity from SHA-256 Merkle aggregation committed via Bitcoin proof-of-work: there is no signature primitive anywhere in the OTS attestation path, so there is no classically-or-quantum-forgeable signature to break. Forging one requires a SHA-256 second preimage, which is not a target of Shor's algorithm and is only marginally weakened by Grover at a 256-bit output, so a store-now-forge-later adversary gains nothing against it. OTS is therefore the PQ-resilient timestamp anchor in the OCG anchor set today. An rfc3161-tst anchor (the FreeTSA / JAdES path) does carry a classical signature and inherits that scheme's exposure; the mitigation available now is the §PQC-1 hybrid proof over the artifact itself, and the eventual fix is a PQC TSA. No public PQC RFC 3161 TSA exists as of 2026-07-18 — the surveyed offerings are niche or private-cert only — so migrating the TSA path is a WATCH item, not a build. NIST IR 8547 (classical signatures deprecated 2030, disallowed 2035) is the timeline this is measured against. No field, no MUST, no gate row: this records rationale for an existing anchor set.

Chain Execution new in v0.8

Until v0.8 chain execution (run_chain / composite_execution_hash) was implementation-defined. §21 makes the existing linear contract normative (§21.1–§21.3, descriptive of shipped behavior) and adds decision gates on top (§21.4). A chain is a chaingraph.json chains[] entry: { name, title?, steps: [{ tool_id, handoff?, id?, gate? }] }. Execution is deterministic, zero-PII, zero payload logging. The reference surfaces are the Worker run_chain and the byte-identical embedded runChain; both MUST produce the identical composite_execution_hash for the same chain and inputs.

§21.1: Linear execution model

Steps run in array order. For each step by tool_id: an unknown node gets status unknown_node; a gpu:true node gpu_browser_only; a node with no kernel no_kernel_browser_only; otherwise the kernel's buildArtifact runs. policy_parameters are caller inputs[tool_id], else the vendored fixture, else {}; a kernel that throws for missing inputs yields input_required (never a silent failure). A step producing an artifact has status ok and is a RAN step. Parent threading: parent_hashes = the previous RAN step's execution_hash (or []), and chain_depth = the step's zero-based array index. Only a RAN step advances the "previous" pointer. §17/§18 attestations attach exactly as in the single-node compute path (hash-excluded).

§21.2: Composite preimage

The chain emits ONE composite artifact whose execution_hash is the §4 canonical hash over exactly { policy_parameters: composite_policy, output_payload: composite_output }, computed over the RAN steps only, via the same kernels/_hash.mjs canonicalizer (no new hash path):

composite_policy = { compute_mode: "server", chain, chain_title, step_count: <#ran>, step_tool_ids: [<ran tool_ids>] }
composite_output = { chain, steps: [ { tool_id, mandate_type, execution_hash, output_payload } … per RAN step ] }

Per-step timestamps and mandate_ids are EXCLUDED from the preimage, so the composite hash is reproducible. If no step ran, composite_execution_hash is null.

§21.3: Composite artifact

The composite artifact carries chaingraph_version:"0.4.0", compute_mode:"server", tool_id:"chaingraph/chains/<name>", chain.parent_hashes = each RAN step's execution_hash, chain.chain_depth = #ran, and the composite policy/output as its preimage halves. It re-verifies under §4 like any artifact.

§21.4: Decision gates new in v0.8

A step MAY carry an OPTIONAL string id (defaults to tool_id; MUST be unique within a GATED chain) and an OPTIONAL gate routing control after the step runs:

gate = { input: <RFC 6901 pointer into THIS step's output_payload>,
         rules: [ { op, value?, next } … ],
         default: <step id | "end"> }

op is the closed enum { eq, neq, gt, gte, lt, lte, in, present, absent }. Comparison is strict, no coercion; gt/gte/lt/lte require FINITE numbers on both sides; in tests membership in a literal array; present/absent test existence only. Rules evaluate first-match; the REQUIRED default is a total function, so an agent runs a gated chain end-to-end with no human in the loop. All targets are FORWARD-ONLY (a later array index) or the literal "end", making the chain acyclic and guaranteed-terminating. A jumped-over step gets status skipped_by_gate; a step with no gate falls through linearly.

Hash binding, CONDITIONAL-PRESENCE (only when the chain defines ≥1 gate). A chain with no gate is pure linear and its composite_execution_hash is UNCHANGED (a golden-fixture freeze gate enforces this). When the chain has ≥1 gate, and only then, three members enter the composite preimage: composite_policy.route_plan_digest (bare-hex SHA-256 over the JCS-canonical full steps[] definition, the ONE canonicalizer), composite_output.decisions[] (one record per evaluated gate: { step_id, input_pointer, observed_value, matched_rule_index, op, value, next }, recomputable by a verifier and tamper-evident), and composite_output.path_taken[] (ordered executed step ids). The evaluator is ONE pure ECMA-262 module (kernels/_gateval.mjs): no expression language, no second canonicalizer, byte-identical on every executing surface. Gates: validate-chains.mjs + gate-static.test.mjs (static), gate-semantics.test.mjs (evaluator), gate-branch-coverage.test.mjs (both-branch), gate-parity.test.mjs (surface byte-parity), linear-hash-freeze.mjs (no linear hash moves).

§21.5: Composite claim strength new in v0.8.8

A §21 chain receipt MAY carry a hash-excluded claim_strength equal to the min of its per-step claim strengths, where each step's strength reflects its evidence class: a zk-proven step (§18) is stronger than a hash-replayable step (§4), which is stronger than an asserted step. A chain mixing a §18 zk-proven step with a hash-replayable step reports the WEAKER composite faithfully, so the chain cannot claim to be stronger than its weakest link. claim_strength is DERIVED and hash-excluded, so it moves no composite_execution_hash (a receipt with and without it is byte-identical); it pairs with §24.6 per-kernel determinism classes as the per-step inputs. Gate (existing, extended, no new gate): linear-hash-freeze.mjs proves the field is hash-excluded, gate-parity.test.mjs proves Worker run_chain and embedded runChain derive the same min. Attribution: FrankenSim weakest-link design, IDEAS ONLY (unvetted "AI rider" license, no text or code copied).

Work Mandates new in v0.8.2

A Work Mandate is a signed OpenChainGraph artifact that delegates bounded authority: a principal authorizes an agent to run a defined set of nodes and chains, under stated conditions, within a validity window, with named escalation triggers. It is the "Authorize" step of the estate loop, authored once by a human and then enforced deterministically on every run. §22 makes the mandate format and the compile_work_mandate I/O contract normative (additive; spec_version 0.8.1). The escalation-record lifecycle and the escalate evaluator semantics are RESERVED here and specified in a forthcoming revision, so no reader mistakes escalation execution for shipping in this section.

This section changes NO frozen structure: chaingraph_version stays 0.4.0, the §4 hash preimage is unchanged, the v0.4 artifact envelope is untouched. mandate_type:"work_mandate" is an accepted value of the EXISTING open mandate_type string (§5, not a hard enum), so there is no envelope edit. The mandate DOCUMENT is a separate schema $def (workMandateDocument), never the artifact envelope.

§22.1: Mandate document

A Work Mandate's authority lives in its output_payload: mandate_type (the literal "work_mandate"); scope { tool_ids, chains } (REQUIRED, at least one array non-empty) naming the authorized nodes and chains; conditions (REQUIRED, MAY be empty), an array of { pointer, op, value } threshold conditions where pointer is an RFC 6901 pointer into a step's output_payload and op is from the §21.4 closed op enum; escalation_triggers (REQUIRED, MAY be empty), the same shape, whose satisfaction routes to the reserved escalation target; validity { not_before, not_after } (REQUIRED, ISO 8601); principal { id } (REQUIRED), a did:key or LEI the §16 signature verifies against; and an OPTIONAL §20 anchor over the mandate hash.

§22.2: Signature and mandate hash

A Work Mandate MUST carry a §16 eddsa-jcs-2022 Data Integrity proof at audit_signature.proof over the whole artifact. An unsigned mandate is a DRAFT and is not enforceable; the runtime (§22.5) MUST reject a mandate with no valid signature. The mandate's own §4 execution_hash IS its identifier, the mandate hash; a run that references "the mandate in force" references this hash, and folding it into the receipt (§22.5) proves which policy governed the run.

§22.3: Reserved escalation routing target

§22 RESERVES the literal string "escalate" as a decision-gate routing target, beside the existing §21.4 "end". A compiled mandate's escalation triggers become gate rules whose next is "escalate". This section reserves the NAME and its meaning ("route the run out of the automated path into the exception path") only. The evaluator semantics of "escalate", that is halting remaining steps, the skipped_by_escalation status, and the OPEN escalation record, are NOT normative here; they are specified in a forthcoming revision and implemented in its kernels/_gateval.mjs update. Until then a compiler MAY emit "escalate" targets and a static validator MUST accept "escalate" as a reserved forward target (not an unresolved step id), but no shipped evaluator executes escalation halting. "end" remains the terminal target for the fully-automated path.

§22.4: compile_work_mandate I/O contract

compile_work_mandate is a deterministic gpu:false node that turns a mandate document into a §21.4 gated-chain configuration, the write side of the loop. INPUT: the mandate document supplied as the node's policy_parameters (input_parameters.mandate = the mandate output_payload, plus a mandate_hash string); the compiler treats the mandate as data and does NOT verify the signature (that is the runtime's job). OUTPUT: output_payload.chain_config:

chain_config = { steps: [ {
    tool_id,                       // REQUIRED
    id?,                           // OPTIONAL step id (defaults to tool_id; unique in a gated chain)
    handoff?,
    gate?: { input,                // present iff this step carries ≥1 condition/trigger
             rules: [ { op, value?, next } … ],
             default }             // REQUIRED (total function, §21.4)
} … ] }

Compilation rules (v0.8.2): (1) scope.chains[0] supplies the ordered steps[] skeleton, else scope.tool_ids in array order, each becoming one step with id defaulting to tool_id. (2) One gate per checkpoint step, one input pointer per gate: since §21.4 allows one gate per step and one pointer per gate, all conditions and triggers on a step MUST share one pointer; a step with two different pointers is a multi-pointer policy that is rejected with { error: "multi_pointer_gate" }, deferred to the forthcoming decision-table artifact (spec_version 0.9, reserved). (3) Rules in fixed order: the step's escalation_triggers first, each { op, value, next: "escalate" }, then its conditions, each routing to the next scope step's id or "end". (4) default: "escalate" (management-by-exception). (5) Determinism: same mandate gives a byte-identical chain_config and hash-stable execution_hash; the compiler reads only mandate fields (no clock, RNG, or environment) and hashes over { policy_parameters, output_payload } via the ONE canonicalizer kernels/_hash.mjs (RFC 8785 / JCS).

Worked example (authoritative target for the compiler fixture). A mandate over chain loan-preflight (steps [assess_loan, record_outcome], where assess_loan emits decision.approved) with condition { "/decision/approved", eq, true } and trigger { "/decision/approved", eq, false } compiles to:

{ "steps": [
    { "tool_id": "assess_loan", "id": "assess_loan",
      "gate": { "input": "/decision/approved",
                "rules": [ { "op": "eq", "value": false, "next": "escalate" },
                           { "op": "eq", "value": true,  "next": "record_outcome" } ],
                "default": "escalate" } },
    { "tool_id": "record_outcome", "id": "record_outcome" }
] }

The trigger rule precedes the condition rule (first-match); the condition continues to record_outcome; the default escalates.

§22.5: Runtime binding

run_chain MAY accept an OPTIONAL mandate argument. When absent, run_chain behavior and every composite and step execution_hash are BYTE-IDENTICAL to pre-mandate behavior (the linear-hash-freeze invariant; mandate keys are conditional-presence, exactly the §21.4 discipline). When present, the runtime MUST, before executing any step: verify the mandate's §16 signature against principal.id (missing or invalid gives { error: "mandate_unsigned" | "mandate_bad_signature" }, no steps run); verify the execution instant is within validity (mandate_not_yet_valid / mandate_expired); and verify the run is within scope (mandate_out_of_scope). On acceptance it folds mandate_hash into EVERY step's policy_parameters and into composite_policy as a CONDITIONAL-PRESENCE key: absent for a no-mandate run (so that hash is unchanged from §21.2/§21.4), present for a governed run (so the receipt proves which policy was in force). This is enforced by the linear-hash-freeze gate plus the runtime mandate-binding gate (with and without a mandate give different composite hashes, each stable). §22.5 is the contract the runtime layer (forthcoming) MUST satisfy.

§22.6: Vocabulary alignment

Field names align with adjacent agent-authority vocabularies, aligned with but with no runtime dependency on any (Rider R2). Google AP2 mandates (donated to the FIDO Alliance): an AP2 Intent/Cart mandate is a bounded, signed grant of authority; scope + conditions + principal + signature play the same role for arbitrary compute rather than payment authority (principal maps to the AP2 issuer, the mandate hash to the AP2 mandate id). OpenID AuthZEN AARP: its subject / resource / action request maps to principal / scope / the authorized invocation, with conditions and escalation_triggers as the obligation layer AARP leaves to the policy decision point. SCITT / RFC 9942: a run's composite receipt (mandate hash folded in) is the transparency statement and a §20 anchor over it is the SCITT-style receipt, so a future registration is a re-labelling rather than a re-model.

§22.7: Normative now vs forthcoming

NORMATIVE in v0.8.2: the mandate document shape (§22.1), the signature requirement and mandate-hash identity (§22.2), the reservation of the "escalate" target name (§22.3), the compile_work_mandate I/O contract with its compilation rules, determinism, and worked example (§22.4), and the run_chain mandate-binding contract with its conditional-presence hash rule (§22.5). NORMATIVE in v0.8.2 (§22.8): the "escalate" evaluator semantics, the skipped_by_escalation runtime-halt contract, the open escalation record with its deterministic (wall-clock-excluded) record hash, and the countersigned closure contract. FORTHCOMING: the run_chain emit/halt implementation and the verify_escalation_closure utility, the exception-queue surface, and the SEP-2322 / MCP-Tasks transport binding.

§22.8: Escalation records (new in v0.8.2)

§22.8.1 Evaluator semantics. "escalate" is a TERMINAL routing target beside "end": a gate rule (or default) whose next is "escalate" routes control OUT of the chain, preserving every §21.4 invariant, differing from "end" in MEANING only (normal completion vs. leaving the automated path for the exception path). The evaluator (kernels/_gateval.mjs) returns the SAME decision record: { step_id, input_pointer, observed_value, matched_rule_index, op, value, next } with next === "escalate"; no escalation field is added, so the hashed composite_output.decisions[] is byte-identical to a non-escalating gate and no composite hash moves. Escalation is recovered by the single-source classifiers the evaluator exports, isTerminalTarget / isEscalationTarget, consulted byte-parity across the four executing surfaces (run_chain, embed, the QuickJS guest, the composer pages).

§22.8.2 Runtime semantics (contract; implemented in the runtime layer). On an escalate decision, run_chain MUST record the triggering decision and escalating step (§21.4), HALT, give every not-yet-run step the status skipped_by_escalation (DISTINCT from skipped_by_gate), and attach an OPEN escalation record. The composite hash is still over RAN steps only (§21.2).

§22.8.3 Open escalation record + DETERMINISM. The record is { mandate_hash?, decision, halted_steps, opened_at }. opened_at is wall-clock and MUST NOT enter any hash preimage. The escalation-record hash is the §4 canonical hash (kernels/_hash.mjs) over the DETERMINISTIC subset { mandate_hash?, decision, halted_steps } only (mandate_hash conditional-presence per §22.5); opened_at is hash-EXCLUDED adjacent metadata, exactly as §20 anchor bindings and §17/§18 identity are excluded. The record hash is therefore REPRODUCIBLE from the recorded deterministic fields, and the closure binds THAT hash.

§22.8.4 Closure contract. An open record CLOSES only via a countersigned closure: the escalation-record hash signed through Anchorproof create_signature_envelope (passkey / JAdES). The closure is { record_hash, decision ∈ {approve,reject}, anchor, envelope } whose signed payload IS record_hash. Verification (verify_escalation_closure, forthcoming) passes IFF Anchorproof verify_signature_envelope accepts the envelope AND the record hash recomputed from the deterministic subset equals closure.record_hash AND closure.decision echoes an approver decision.

§22.8.5 Transport-agnostic (D3). Escalation records and closures are artifacts with no transport dependency; a SEP-2322 / MCP-Tasks binding is a forthcoming worker rider. §22.8.6 Vocabulary alignment (informative). The approver decision maps to an OpenID AuthZEN AARP access decision; a countersigned closure over a record hash is a SCITT / RFC 9942 receipt-shaped statement, aligned with and with no dependency on.

§22.9: Signed failure receipts new in v0.8.8

A failed verify (a §16/§18/§20/§21.4 gate failure, or a §22 mandate rejection) MAY be emitted as a signed FAILURE receipt whose body carries an AR4SI trustworthiness-vector tier (affirming / warning / contraindicated, with the numeric AR4SI code points), shaped per IETF RATS EAR (EAT Attestation Result). It is signed with the same §16 eddsa-jcs-2022 whole-artifact proof, so the failure is portable and tamper-evident; it references the subject execution_hash (or mandate hash) and names the failing rule id. This is the failure side, complementing but never duplicating the queued OCG-VSA success side; §22 gates and ML-2 escalations MAY consume a §22.9 receipt as input evidence. Gate (existing, extended, no new gate): proof-binding.test.mjs for the signed round-trip and tamper-detection, reusing the §21.4 gate-semantics.test.mjs tier mapping where a gate failure is the source. Attribution: IETF RATS EAR / AR4SI (draft-ietf-rats-ar4si), PIN draft -10. RFC 9457 problem-details is REJECTED (an unsigned HTTP-error shape at the wrong layer).

§22.10: Offline mandate attenuation new in v0.8.8

A multi-hop work mandate MAY be delegated by Biscuit-style offline attenuation-block chaining: each hop is a signed block bound to the previous by a single-use keypair; a holder narrows scope OFFLINE by appending a caveat block, never widening; a verifier checks the whole block chain under ONE root public key. Widening re-delegation is structurally impossible (a hop can only add restrictions), which makes the §SIDECAR.2 resource-narrowing invariant concrete for multi-hop mandates. This is a CONSTRUCTION and FORMAT only: OCG defines the block-chaining and single-use-key binding and NEVER the Biscuit Datalog authorization runtime, which stays external and out of scope. Gate (existing, extended, no new gate): mandate-binding.test.mjs gains an attenuation-chain fixture (a valid narrowing chain verifies under one root key; a widening block MUST fail; a broken link MUST fail). Attribution: Eclipse Biscuit (Apache-2.0), the block/attenuation construction ONLY, never the Datalog runtime. UCAN is REJECTED (DID baggage + quadratic nested-JWT bloat); draft-prakash-aip-00 is REJECTED as a dependency.

§22.11: Exception classification and counted-resume approval new in v0.8.9

§22.8 defines what an escalation record is; §22.11 refines how a failed item is classified and how a human resolution is evidenced. A record MAY carry an OPTIONAL exception_class of exactly two values: business (the data is wrong or a business rule rejected the item — no automatic retry, the item routes to a human queue in a terminal-until-resolved state) or application (the environment failed — retry up to N, then MUST escalate). The two classes have opposite correct responses, which is why the distinction is load-bearing: retrying a business exception cannot succeed and only hides the item, while routing an application exception to a human wastes the one resource that cannot scale. A machine-readable exception_detail {type, code, message} MAY accompany it, and an application record MAY carry retry {attempt, max}; reaching attempt == max MUST become a §22.8 escalation rather than silently drop. State is tracked per item, never per run: item_state is done/failed/pending_human, and one failed item MUST NOT abort its siblings in the same batch. An escalation MAY declare a counted-resume gate resume_approval {required_events, approver_group, resume_form, timeout} — the gate stays suspended until N distinct approvals (or one cancel) arrive, the approve payload MUST validate against the resume_form JSON Schema, and on timeout with fewer than N events it MUST resolve to a §22.8 escalation, never a silent auto-approve. Every resume message and exception record emitted as an OCG artifact MUST carry a §16 eddsa-jcs-2022 proof bound to a named human, referencing the subject execution_hash and the approver identity; an unsigned resume is NOT conformant §22.11 evidence. That is what makes the approval trail portable and offline-verifiable rather than a claim held inside one vendor's queue. A §22.9 failure receipt MAY be the evidence that opens a business-class exception. Every field is hash-EXCLUDED and the frozen §22.8 envelope is untouched, so a record carrying none of them is byte-identical and fully conformant. Scope limit: OCG defines these formats and their invariants and does NOT operate a queue, runtime, approver directory, or timer. Gate (existing, extended, no new gate): mandate-binding.test.mjs for the classification, retry-to-escalation, sibling-isolation and suspend/timeout fixtures; proof-binding.test.mjs for the signed round-trip, tamper-detect, and hash-identity with and without the fields. Attribution: Robocorp work-items (Apache-2.0, patterns only), Windmill suspend/approval (AGPLv3, semantics only, never code or text), UiPath's Business/System split as convergent prior art.

Input Attestations new in v0.8.3

The §4 execution_hash proves the computation over the inputs the artifact was given; it says nothing about whether those inputs were themselves authentic. §23 lets an artifact carry portable, per-input evidence that a named input was vouched for by an external source, without changing what execution_hash means. Evidence attaches at the OPTIONAL top-level array input_attestations, which, like §16 audit_signature and §20 anchor_bindings, is attached AFTER hashing and is EXCLUDED from execution_hash scope. An artifact with zero attestations remains fully conformant; attestations never enter the preimage, so adding, removing, or re-ordering them leaves every existing execution_hash byte-identical.

Each entry is { type, pointer, proof, source_ref }. pointer is an RFC 6901 JSON Pointer evaluated against policy_parameters (naming WHICH input); an entry whose pointer does not resolve inside policy_parameters is rejected. Where a type binds a digest, that digest MUST equal the SHA-256 of the §4-canonical encoding of the resolved input value. source_ref names who vouches and is informative, never a substitute for verifying proof.

§23.1 Type phasing (D2). Three types verify NOW with shipped machinery; zktls is defined with EXTERNAL verification (no vendored verifier: vendoring a TLSNotary-class verifier would break the zero-dependency posture). vc-2.0: a W3C VC 2.0 credential binding the input by value or digest; verified via the shipped §16 / §13.11 Data Integrity (eddsa-jcs-2022) or enveloping JOSE/COSE proof, plus subject-digest equality. rfc3161-snapshot: an RFC 3161 TimeStampToken (verbatim base64 DER) whose messageImprint is the input's SHA-256, verified by the SAME §20 rfc3161-tst verifier (no second implementation). c2pa-manifest: a C2PA manifest whose hard-binding digest matches the input; verified STRUCTURALLY now (parse + claim-signature well-formedness + digest match), full signer trust-chain a link-out. zktls: reported as PRESENT with verifiable:"external": structural fields checked, the cryptographic claim neither confirmed nor refuted by OCG machinery.

§23.2 Verifier report. A verifier reports per-input status ALONGSIDE (never folded into) the execution_hash result: for each entry { pointer, type, structural: "pass"|"fail", verifiable: "verified"|"failed"|"external"|"n/a" }. The execution_hash verdict is computed INDEPENDENTLY of attestation status: a failed or absent attestation never changes it, a passing attestation never substitutes for it. §23 attests input provenance where sources support it; it does not prove computational correctness (§18), authorship (§16), kernel identity (§17), or existence-in-time (§20); these are independent, composable claims. A UI presenting attestations MUST keep the zero-attestation caveat visible.

§23.3 Frozen-envelope invariance. input_attestations is an OPTIONAL top-level property (exactly as §20 anchor_bindings), so $defs/artifact.required, the §4 preimage members, and chaingraph_version 0.4.0 are UNTOUCHED. A verifier correct for v0.7/v0.8 computes an identical execution_hash for a v0.8.3 artifact and MAY ignore input_attestations entirely. Any type whose binding would require folding attestation data INTO the preimage is out of profile.

§23.4 Freshness and consent new in v0.8.9. An input_attestations entry MAY carry an OPTIONAL freshness object: { observed_at, expires_at?, freshness_class, consent_ref?, retention_class? }, where freshness_class is realtime|intraday|daily|point-in-time|static and retention_class is declarative only (transient|case-file|regulatory-N-years). Like the rest of §23 it is hash-excluded — a freshness block never enters the execution_hash preimage. A verifier's §23.2 report gains one field per entry, freshness_status: "fresh"|"stale"|"undeclared" (stale when expires_at is past at verification time, undeclared when no freshness object is present); staleness is reporting-only and NEVER changes structural, verifiable, or the execution_hash verdict. A §21.4 decision gate MAY target a copied-forward freshness_status so a mandate can require fresh evidence.

Deterministic Compute Profile new in v0.8.4

OCG's integrity model already assumes a kernel is a pure, deterministic function of its inputs: §4 makes the output tamper-evident, §17 pins which kernel source ran, §18 proves that it ran, and §18.5 fixes the specific cross-engine hazards a real deployment hit. This section adds no new machinery. It names the determinism those layers already enforce as one citable profile, ocg-deterministic-compute, modeled on the W3C WebAssembly 3.0 Deterministic Profile (W3C Candidate Recommendation, April 2026), which conforms an execution environment by enumerating every source of nondeterminism and fixing or banning each one. An implementation that already passes the §15 gate suite already conforms; the profile's value is a name a verifier or a second implementer can point at.

§24.0 Scope. The profile governs a kernel's compute(policy_parameters) under §12, over the same class §18.6 delimits: every gpu:false, status:"live" node (gpu:true is out of scope for the same cost and parallelism reason as §18.6). It binds the compute surfaces to byte-identical output for identical input across the browser tool, the Cloudflare Worker (§12 server path), and the fixed zkVM guest (§18). As the in-browser QuickJS VM lands it runs the same C interpreter family as the §18 guest, so its output is diff-checked against the Worker rather than adding a fourth engine. Determinism here means reproducible-bit, not "same up to rounding": one differing bit is a different execution_hash.

§24.1 Enumerated nondeterminism sources. A conforming kernel MUST NOT let any of the following affect output_payload. Each binds to an existing §15 gate; the profile introduces no gate of its own. D1 Non-finite floats (NaN, ±Infinity): output MUST canonicalize under RFC 8785 / I-JSON, which forbids non-finite numbers, so a kernel returns finite output or rejects input cleanly, never a silent NaN (enforced at hash time by the §4 canonicalizer and the empty-input finite sweep). D2 Iteration order: serialization MUST NOT depend on property order; the preimage is built by the one canonical RFC 8785 (JCS) sorter, never by hand (§4 hash gates; ad-hoc canonicalization is linted out). D3 Transcendental math: only + − × ÷ √ are IEEE-754 bit-portable, so every transcendental routes through the shared pure-JS fdlibm port (§18.5c), never engine libm. D4 Wall-clock time: no clock or timer may enter the payload or preimage; time-bearing evidence (anchor genTime, escalation opened_at) is defined hash-excluded (§20, §22.8), and the guest disables Date. D5 Randomness: none may reach the payload; Math.random is stubbed, and the sole CSPRNG (§13.12 SD-JWT salts) is confined to hash-excluded disclosure material. D6 Locale / Intl: locale-sensitive formatting routes through a pinned en-US formatter verified value-for-value against V8 (§18.5a); the guest and the QuickJS VM ship no Intl at all. D7 Environment / platform APIs: where a rule would depend on an environment-sensitive V8 API, the kernel substitutes a fully specified deterministic replacement used identically on every surface (§18.5), and network, filesystem, and ambient I/O are already forbidden by the zero-fetch contract. Rows D1 through D7 are exhaustive over the escape hatches the Wasm 3.0 profile enumerates; any future source is a normative profile change (§24.2), not a silent addition.

§24.2 Freeze clause. Modeled on the RISC-V base-ISA freeze policy: a ratified kernel-semantics version is never revised. Once a profile version fixes the meaning of D1 through D7 that meaning is immutable for that version; a change that could alter any conforming kernel's output_payload (for example re-baselining the shared libm) MUST ship as a new profile version ocg-deterministic-compute@<n>, never an in-place edit. This is what lets execution_hash be a durable identifier: a receipt minted under @1 verifies bit-for-bit forever, because @1's semantics can never move under it. A version bump is additive (a new named profile beside the old, as §11 profiles compose); it never mutates the frozen v0.4 envelope and never bumps chaingraph_version (stays "0.4.0").

§24.3 Conformance. An implementation MAY declare ocg-deterministic-compute@1 for its gpu:false live kernel set. The declaration asserts exactly that D1 through D7 hold, which, because each binds to a gate already in §15, is decided by the existing gate suite: an implementation green on §4, §12, §18.5/§18.6, and §21.4 parity is conforming. The profile adds a name and an enumeration, not a new obligation, and deliberately introduces no §15 row of its own (the §15 meta-rule is satisfied because every requirement cites an existing wired gate). This mirrors §18.6. The AINumbers reference deployment conforms: its gpu:false live set is green on every cited gate.

§24.4 Prior art (informative). The enumerate-and-close method is the W3C WebAssembly 3.0 Deterministic Profile. The never-revise-a-ratified-version rule is the RISC-V frozen-base-ISA policy. The precedent for proving a deterministic JS/Wasm-class guest inside a zkVM is Cartesi (a RISC-V zkVM running a full deterministic guest); OCG differs by proving a single pinned kernel per receipt rather than a whole machine image, and by carrying the proof as an OPTIONAL §18 attachment rather than a consensus artifact. A deeper lineage of a frozen, total, deterministic instruction semantics as the base of a permanent record (Nock, and Kelvin versioning counting down to a frozen zero) is noted only as motivation; OCG cites the ratified engineering standards above as its normative models.

§24.5 Profile version ocg-deterministic-compute@2: WebCrypto subset split (new in v0.8.6). @1 stated D7 at a granularity a literal reader can over-read as banning all of WebCrypto, conflating two subsets D5 and D7 already treat differently. @2 is a new profile version (per the §24.2 freeze clause, a new named profile alongside @1, never an in-place edit) that keeps D1 through D6 unchanged and enumerates the split inside D7. Allowed as fully-specified deterministic replacements: crypto.subtle.digest (SHA-256/384), importKey, and verify, all pure functions of their inputs, so they MUST be byte-identical across the browser tool, the Cloudflare Worker, and the in-browser QuickJS VM (a surface that ships no WebCrypto, like the §18 guest, simply does not host the crypto-using kernels). Banned as D5 randomness: crypto.getRandomValues, generateKey, and sign (fresh key) MUST throw. A kernel that reaches for them fails, never silently degrades an output_payload. @2 is additive: it moves no execution_hash (all six previously-VM-unrunnable kernels emit the same bytes the Worker already produces), the frozen v0.4 envelope and §4 preimage are UNTOUCHED, chaingraph_version stays "0.4.0", and only spec_version bumps to 0.8.6. The reference deployment re-declares its gpu:false live set as @2-conforming; @1 receipts verify under @1 forever.

§24.6 Per-kernel determinism-class declaration (new in v0.8.8). A kernel entry in chaingraph.json metadata MAY declare a determinism class: bit-exact (byte-identical across the browser tool, the Cloudflare Worker, and the QuickJS VM, the §24 default for gpu:false live kernels), replayable (same output for the same inputs but not cross-surface byte-identical), seeded-stochastic (§24.6.2, draws from a declared pseudo-random generator, bit-identical on replay from the declared seed), or estimated (stochastic / model-output whose replay bounds are not bit-exact). The declaration is TESTED, not merely asserted: the existing §4 parity and finite gates are RE-BOUND per class, so a bit-exact kernel MUST pass the cross-surface byte-identity check while an estimated kernel is exempt from byte-identity but MUST still pass finite-output and idempotency-within-tolerance. A kernel whose declared class does not match its measured behavior MUST fail. It refines §24's global profile to per-kernel granularity, complementing rather than replacing it, and the declared class is hash-excluded metadata that moves no execution_hash. Gate (existing, extended, no new gate and no new §15 row): determinism-replay.test.mjs and kernel-contract.test.mjs read the declared class and assert the class-appropriate property; golden-parity.test.mjs enforces cross-surface identity for bit-exact. Attribution: FrankenSim determinism-class idea, IDEAS ONLY (same license caveat as §21.5), modeled alongside the W3C WebAssembly Deterministic Profile already cited in §24.

§24.6.1 quantization_parity sub-declaration (new in v0.8.8, ZKML-GUEST-1-BUILD-SPEC.md §ZG-3). A bit-exact kernel that performs pure-integer inference over a statically quantized model MAY attach a hash-excluded top-level quantization_parity object declaring the float-reference-vs-quantized agreement rate the quantization achieved over a committed, frozen held-out test-vector set: quantization method, bit width, scale/zero_point, granularity, reference-model and test-vector digests, vector count, and a top1-match agreement figure. Field names align ONNX QuantizeLinear and the HuggingFace quantization_config convention. The declaration is metadata about the offline quantization step, never a claim compute() makes: the kernel's integer arithmetic stays 100% deterministic and the float figures are recorded, never evaluated, inside compute(). Same doctrine as §24.6: TESTED, not merely asserted. Gate (existing infrastructure plus one new script, extends §24.6, no new §15 row): quantization-parity.test.mjs re-runs the kernel over the committed test-vector set, reproduces every row's own recorded quantized prediction (kernel-fidelity check), independently recomputes the agreement rate, and fails on drift between the declared and recomputed value. No new hash, no chaingraph_version bump, no envelope change; a kernel with no quantization_parity block is unaffected and fully conformant.

§24.6.2 seeded-stochastic determinism class (new in v0.8.8). A kernel whose output depends on pseudo-random draws MAY declare the class seeded-stochastic instead of estimated. The class is a STRONGER claim than estimated and carries a replay obligation: the kernel MUST record, in the receipt, the prng_algorithm (a named, integer-only generator; the reference deployment uses xoshiro256** seeded through splitmix64), the integer seed, and the draw_count actually consumed; and a replay of the kernel at the SAME policy_parameters and the SAME declared seed MUST reproduce a bit-identical output_payload, hence a byte-identical execution_hash. Floating-point draws are permitted only where the generator's integer state is the seeded quantity and the float derivation is itself deterministic. A kernel that cannot meet bit-identical replay MUST declare estimated, not seeded-stochastic: under-claiming is always conformant (§11), and the weaker class is the conservative default while a kernel's replay behavior is unproven. Same §24.6 doctrine, TESTED, not merely asserted, and this class earns a gate of its own because its claim, replay determinism, is not what the §4 parity and finite gates already measure. Gate (new script, new §15 row): seed-replay.test.mjs re-runs every kernel declaring the class at its own declared seed and requires a byte-identical execution_hash; re-runs it at a tampered seed and requires the hash to CHANGE, which is what proves the seed is load-bearing rather than a decorative field; and exercises both paths unconditionally against a committed reference vector, so replay and tamper-detect stay proven in an estate with zero adopters. No envelope change, no new hash, no chaingraph_version bump. At v0.8.8 the class is specified and not yet adopted: no live kernel declares it, and the Monte Carlo VaR node art-371 carries the prng_algorithm, seed and draw_count fields already but continues to declare estimated, a sound under-claim (§11), because migrating it would move that node's execution_hash and is therefore a kernel-versioning event rather than a spec change.

Normative reference — the profile substrate (normative, new in v0.8.9). §24 opens by naming the W3C WebAssembly 3.0 Deterministic Profile (pinned at Candidate Recommendation, April 2026) as the method this profile is modeled on. This paragraph makes it a normative reference for the substrate as well, which strengthens an existing claim rather than adding one: where a conforming compute binding's engine is a WebAssembly module, that module MUST be executable under the Deterministic Profile — it MUST NOT use relaxed-SIMD instructions, MUST NOT declare or import shared memory or threads, and MUST NOT observe non-deterministic NaN bit patterns. A module meeting those constraints is bit-reproducible across conformant engines by the referenced profile's construction, not merely measured-equal across the surfaces we happen to run; the D1–D7 enumeration in §24.1 remains the OCG-side statement of the same closure and is unchanged. The reference deployment's shipped quickjs-ng guest wasm is the reference module and already meets these constraints; it is asserted profile-clean by a build-time CI check over the shipped binary — a tooling assertion on our own engine, deliberately not a §15 conformance-gate row, because §15 gates run over OCG artifacts that third-party implementers can reproduce and a check on our vendored binary is not reproducible by them. The RISC-V zkVM guest freeze clause (§24.2) is the parallel determinism substrate for the proving tier; the two are cited together and neither is required of the other. No field, no envelope change, no new §15 row.

Private-Input Profile new in v0.8.5

§18.3 already permits a receipt to be used in an input-hiding mode: policy_parameters may carry a commitment in place of cleartext, §4 recompute becomes unavailable to third parties, and the receipt is the sole verification path. That paragraph states the mode; it does not pin the declaration (which input is private, under which commitment) or the commitment construction. §25 closes that gap: it names a profile, ocg-private-input@1, that makes input-hiding machine-declared and machine-checkable, so a high-value node (sanctions screen, RBC action-level, capital-ratio) can carry it as a first-class, gated claim. It adds no new integrity machinery: the commitment binds through the §4 preimage and the §18 journal that already exist. It adds only a declaration, a named hiding commitment scheme, and a verifier contract.

§25.0 Declaration object. An artifact MAY carry a top-level private_inputs[] array, a map telling a verifier which policy_parameters locations hold commitments rather than cleartext, and under which scheme. Like §16 audit_signature, §20 anchor_bindings, and §23 input_attestations, it is attached and EXCLUDED from execution_hash scope: an artifact with zero entries is byte-identical to a plain v0.8.4 artifact and fully conformant. The binding force does not come from the array; it comes from the commitment sitting inside policy_parameters (§25.2). Each entry carries a pointer (RFC 6901, into policy_parameters, naming WHICH input is private), a commitment (sha256:-prefixed), and a commitment_scheme.

§25.1 Commitment scheme sha256-salted@1 (the crux). A bare SHA-256(cgCanon(input)) is NOT admissible: for low-entropy inputs (booleans, small integers, a list-membership flag, a modest enumerated set) an attacker precomputes the digest of every possible value and recovers the plaintext by table lookup, defeating hiding. The commitment MUST be salted with a high-entropy secret held by the prover: commitment = "sha256:" + hex(SHA-256(salt ‖ cgCanon(input_value))), where salt is a fresh ≥256-bit CSPRNG value and cgCanon is the one §4 canonicalizer. This is simultaneously hiding (a 256-bit secret salt makes precomputation over even a two-element input space infeasible; the standard hash-based commitment, not a bare digest), deterministic given (input, salt) (the same pair yields the same commitment bit-for-bit, reproducible on every §24 surface because SHA-256 and cgCanon are already bit-portable there), and risc0-private-input-bindable (the guest reads both salt and input_value over the zkVM private-input channel, recomputes the commitment in-guest, and commits the commitment, never the salt and never the plaintext, to the journal). The salt MUST be fresh per (artifact, private input) and never reused, and MUST NEVER appear in the artifact (not in policy_parameters, output_payload, the §4 preimage, private_inputs[], or the §18 journal). It is disclosure material held only in the prover's private witness and an optional out-of-band package, exactly as §13.12 SD-JWT salts and §24 D5 CSPRNG material are excluded from the hash, and it lets an authorized verifier holding (salt, input_value) recompute and confirm the commitment, while a public verifier holds neither and relies solely on the proof.

§25.2 Plaintext-exclusion invariant (the profile's defining MUST). For every private_inputs[] entry, the value that pointer resolves to inside policy_parameters MUST BE the entry's commitment string (the sha256: digest) and MUST NOT be the plaintext. The plaintext NEVER appears anywhere in policy_parameters or any §4 preimage. So the §4 execution_hash binds the commitment not the value, the §18 journal (§25.3) binds that same commitment, and there is no location from which a third party can recover the plaintext. A verifier that finds a pointed value which is not the declared commitment MUST FAIL the artifact.

§25.3 Proving and journal binding. A conforming artifact MUST carry a §18 compute_proof (groth16-bn254 recommended). The guest named by imageId reads each private input_value and its salt over the private-input channel (never committed), recomputes each commitment = SHA-256(salt ‖ cgCanon(input_value)) in-guest and commits every declared commitment to the journal, and computes and commits output_payload. The journal thus exposes only the public commitments and the public result, never the salt or plaintext. Proving stays off-band (§18.2): the browser tool, the Worker, and CI only verify, never prove. This is the risc0 private-input pipeline the flagship kernels build against.

§25.4 Verification via validate_private_inputs. A verifier checks, without ever seeing the plaintext: (1) structural, meaning private_inputs[] well-formed, each pointer valid RFC 6901 and resolving into policy_parameters, each commitment a sha256: digest, each commitment_scheme known; (2) plaintext-exclusion (§25.2), the value at each pointer equals its commitment; (3) proof binds commitment, meaning a §18 compute_proof is present, its journal commits every declared commitment, seal verifies against imageId via the §18.1 BN254 Groth16 reference verifier, and imageId is in the node's Graph Index compute_images; (4) output binding, the journal's committed output equals output_payload (§18.0). A public verifier stops here, hiding intact. An authorized verifier additionally takes (salt, input_value) from the disclosure package, recomputes the commitment, asserts equality, and MAY re-run the kernel to reproduce output_payload.

§25.5 Composition with §23 Input Attestations. Hiding and attesting are orthogonal and stack. A §23 input_attestation MAY point at the same policy_parameters pointer to vouch for the committed input. Because §23 evaluates its digest binding against the resolved value, which under §25.2 IS the commitment, the existing §23 rule works unchanged: the attestation vouches for the commitment (a vc-2.0 subject binding the sha256: commitment, or an rfc3161-snapshot whose messageImprint is the commitment), so a public verifier confirms the committed input was vouched for without seeing the plaintext, and an authorized verifier ties the attestation to the cleartext through the disclosure package. Neither section changes to admit the other; the claims are independent and composable.

§25.6 Frozen-envelope invariance. private_inputs is an OPTIONAL top-level property (exactly as §20 anchor_bindings and §23 input_attestations), so $defs/artifact.required, the §4 preimage members, and chaingraph_version 0.4.0 are UNTOUCHED. A verifier correct for v0.8.4 computes an identical execution_hash for a v0.8.5 artifact and MAY ignore private_inputs entirely. The commitment lives in policy_parameters.input_parameters, an already-open object, so seating a sha256: string where a plaintext would otherwise sit is not a schema or envelope change. Any construction that would fold salt or plaintext INTO the preimage is out of profile.

§25.7 Conformance. An implementation MAY declare ocg-private-input@1 for a node whose sensitive input is committed under this profile. Conformance is machine-checked by validate-private-inputs.test.mjs (§15): structural shape, plaintext-exclusion, commitment-scheme validity, and the journal-commits-the-commitment binding, layered on the §18 pairing check compute-proof.test.mjs already runs. The §24.2 freeze discipline applies to the commitment construction: sha256-salted@1's meaning is immutable; a different construction ships as ocg-private-input@<n>, never an in-place edit, so a private-input artifact minted under @1 re-verifies bit-for-bit forever. Like §18, the profile defaults OFF: a node MUST surface that it withholds an input (§18.3) and MUST NOT auto-apply commitment mode.

Control Plane Profile ocg-control-plane@1 new in v0.9-draft

§26.1 Purpose and scope. Defines the artifact vocabulary for connected, operated workflows: executions involving external data retrieval, durable local state, scheduling, human review, or agent delegation, run by the artifact producer on infrastructure it controls (the AINumbers Helm Local Hub). It is a superset layered beside a conformant OCG artifact, not a replacement: a control-plane deployment produces ordinary OCG artifacts for its deterministic compute steps and additionally emits the objects defined here. A verifier ignorant of this profile remains fully correct for the core artifact. Nothing here makes AINumbers an operator of any log, registry, or authority; every durable journal is producer-local, its integrity claims derived from internal hash-chaining plus anchoring to external §20 authorities.

§26.2 Envelope. Every signed object in this profile is an in-toto Statement v1 carried in a DSSE envelope, with subject[] digests of the bound artifacts, a predicateType naming the object kind (§26.4), Ed25519 signing (SHOULD additionally ML-DSA-44, RFC 9964 JOSE identifiers), and JCS-canonical payload JSON before signing. Verifiers accept an envelope as verified when at least one trusted signature family verifies.

§26.3 Workflow manifest binding. A control-plane execution MUST record workflow_manifest_digest, the SHA-256 of the JCS-canonical workflow manifest (trigger, connectors, compute nodes, gates, actions, per-node kernel digests, connector contract digests, environment overlays by reference only, never secret values). Every §26.4 object pertaining to a run carries run_id and workflow_manifest_digest.

§26.4 Object kinds. Ten kinds, schemas SSOT in the Helm repo and mirrored here by fixture: connector_attestation and execution_state are REQUIRED-producible; policy_decision, review_task, review_decision, override, agent_delegation (mirroring the RFC 8693 exchange-chain sub/act shape), external_action_intent, external_action_receipt, and disclosure_receipt are reserved in @1: schema normative, production OPTIONAL until Helm Phase 2+, but a @1 verifier MUST parse and verify any it encounters.

§26.5 Journal and checkpoints. The producer-local journal is append-only, each entry carrying a monotonic journal_seq, stream_id, entry_digest, a per-stream running hash, and the record-keeping fields period_start, period_end, reference_db_version, triggering_input_digest, and humans_involved[] (may be empty, must be present), named to satisfy EU AI Act Art. 12(2)/(3) logging minima directly. Signed checkpoints summarize per-stream state periodically and at run completion, anchorable per §20; unknown anchor types are reported as unrecognized, never as failures.

§26.6 Trust labels. Every claim on a verification surface or in an evidence bundle carries exactly one of hash_verified, kernel_verified, connector_asserted (no claim about payload truth), human_attested, or external_ack_captured. Surfaces MUST NOT collapse these into an undifferentiated "verified" indicator or present any label as establishing source-data truth or regulatory acceptance.

§26.7 Evidence bundles. A self-contained, offline-verifiable archive: a signed bundle manifest listing every included object by digest and trust label, the objects themselves, covering checkpoints, and anchor proofs, with a mandatory redaction profile (no secrets, no raw credential material, no payload above the export's disclosure level). A conformant verifier evaluates a bundle with zero network access; anchor freshness checks are optional and clearly separated.

§26.8 Conformance. A producer conforms iff every emitted object validates against its schema, every envelope verifies (§26.2), running hashes and checkpoints verify for every exported journal segment, and the gate suite's control-plane fixtures pass including tampered negative fixtures (an envelope, a journal segment, and a bundle each proven to fail when altered). A verifier conforms iff it accepts the golden fixtures, rejects every tampered fixture, and reports trust labels per §26.6. The profile is entirely additive: §4 preimage members and chaingraph_version "0.4.0" are UNTOUCHED, no existing execution_hash changes, and a verifier correct for v0.8.12 MAY ignore §26 entirely. §26 is the gap §27 (Human Accountability) deliberately left open.

Human Accountability new in v0.8.12

The §4 hash proves what computed; §16 and §18 prove that it computed correctly; §22 proves who was authorized to run it. None of them records which named human took responsibility for the result, the preparer, reviewer and approver act that a bank examiner, an auditor, or a court actually asks for. §27 adds that layer as a first-class, signed, machine-checkable artifact type without touching any existing hash, envelope, or gate. It follows the standards-precedent verdict: the C2PA to CAWG identity split (assertions about content are separate from the content), in-toto's integer threshold for dual control, SCITT's statements about statements (a receipt about a receipt), and the ZCAP over-abstraction failure, so §27 defines banking-concrete record types rather than a generic workflow-authorization calculus. §26 is reserved for the control-plane profile; §27 deliberately leaves the gap.

§27.0 Additivity and scope (the defining constraint). Every construct here is attached after hashing and EXCLUDED from every existing execution_hash preimage, exactly as §20 anchor_bindings, §23 input_attestations, and §25 private_inputs are. An approval record is a NEW artifact ABOUT an existing sealed artifact (SCITT-style), never a mutation of it: minting, revising, or discarding approval records leaves the subject artifact's execution_hash byte-identical, $defs/artifact.required UNTOUCHED, and chaingraph_version at "0.4.0". A verifier correct for v0.8.11 validates every existing artifact unchanged and MAY ignore §27 entirely. Scope is banking-concrete record types only (preparer, reviewer, approver, submitter over a reporting artifact); §27 defines no generic workflow-engine, no delegation calculus, no policy DSL. It is a FORMAT for evidencing human acts, never a runtime, a queue, an approver directory, or a timer.

§27.1 Roles. §27 defines a closed set of accountability roles: preparer (assembles the reporting artifact), reviewer (checks it), approver or attestor (accepts responsibility, the legally-effective sign-off), submitter (transmits it), and the OPTIONAL model_owner, compliance_officer, and examiner (READ-ONLY: an examiner binding grants inspection, never approval authority). A role binding is a signed record that ties one §9 identity (did:key or LEI) to one role for one subject; its §16 eddsa-jcs-2022 proof MUST verify against that identity. An identity MAY hold more than one role, but §27.3 distinctness is by identity, so one human cannot satisfy a dual-control threshold alone by wearing two role hats.

§27.2 Approval records (SCITT-style statements about statements). An approval record is a conformant OCG artifact whose mandate_type is the accepted envelope value "human_accountability_record" and whose output_payload matches $defs/humanAccountabilityRecord. Its payload carries record_type (role_binding, approval, rejection, override, annotation), role, subject_hash (the sha256:-prefixed execution_hash of the artifact acted upon, the SCITT reference), the acting identity, an optional decision, a reason_code, and a timestamp. The record is itself a first-class artifact with its own §4 execution_hash and MUST carry a §16 whole-artifact proof bound to the named human (an unsigned approval record is NOT conformant §27 evidence, exactly the §22.11 rule). Because it only references subject_hash and never contains the subject's preimage, it has zero impact on the subject's hash: the accountability trail is portable, tamper-evident, and offline-verifiable rather than a row locked inside one vendor's queue.

§27.3 Dual control and thresholds (in-toto integer threshold). A gate MAY require N distinct role-bound identities to have signed approval records over the SAME subject_hash before it is satisfied. This is the in-toto threshold construction: an integer threshold: N on the required role, satisfied when at least N distinct identities (counted by identity.id, NEVER by key, so a single human rotating keys or signing twice counts once) have each emitted an approval record naming that role and subject. dual_control(2) is the N=2 case (the FDIC GENIUS CEO and CFO certification is its first production use). A threshold gate over fewer than N distinct approvers is UNSATISFIED and MUST NOT auto-pass.

§27.4 Gate-policy vocabulary (wired to §21.4). §27 defines a closed gate-policy enum, the $defs/haGatePolicy value applied to a §21.4 decision gate as an OPTIONAL precondition: auto_pass, review_required (at least one reviewer approval), dual_control (the §27.3 threshold), escalate (route to the §22.3 reserved target), hold, reject, and emergency_override (§27.5). A gate carrying a policy is satisfied ONLY when the named approval records exist at the stated threshold over the gate's subject; absent the required records, the gate does NOT fall through to its §21.4 default, because the human precondition is a hard predicate evaluated before the routing rules. This composes with §21.4 without changing its evaluator: the policy is a precondition annotation consumed by the accountability layer, the §21.4 _gateval.mjs routing math is untouched, and a chain with no HA policy evaluates byte-identically to today.

§27.5 Override and waiver (time-boxed §22.10 attenuation). An emergency_override is NOT an unconditional bypass. It is a time-boxed §22.10 attenuated mandate paired with a mandatory evidence bundle carrying at minimum a reason_code, an explicit scope (which gate or subject it covers, narrowing only, never widening, per §22.10 and §SIDECAR.2), an expiry, the authorizing identity, and an immutable link to the overridden artifact's subject_hash. The override is itself a signed record_type:"override" approval record. On expiry the override lapses and the underlying gate policy REVERTS: an expired override MUST be treated as absent, so the gate returns to review_required, dual_control, or hold as originally specified. A timeout MUST NEVER resolve to a silent permanent auto-pass.

§27.6 Evidence bundle (§13.12 SD-JWT export). The evidence bundle is a profile object, $defs/haEvidenceBundle, aggregating the trail for one subject: input-hash lineage, kernel version (§12 and §17 build identity), policy version, the subject_hash, the §16/§18/§20 verification result, exception rationale, annotations, the reviewer and approver identities with their signed approval-record hashes, timestamps (with optional §20 anchor bindings), and a submission-receipt slot populated only after a real transmission, never fabricated. The bundle is exportable via §13, and specifically via §13.12 SD-JWT selective disclosure, so an examiner receives exactly the fields their remit requires and no others: approver identities and the verdict are always-disclosed, while selectively-disclosable input values follow §13.12 (disclosure salts the sole permitted nondeterminism, never touching any execution_hash). A redacted bundle is NOT re-executable (§13.12's limitation); it evidences the human trail, not a recomputation.

§27.7 Separation of concerns (four distinct artifact types). §27 keeps four routinely-conflated things structurally separate, each its own artifact type: calculation or validation (a §4/§18 compute result, what the numbers are); recommendation (a machine or model suggestion, what could be decided); human judgment (a reviewer or annotation record, a person's assessment); and legally-effective sign-off (an approver or attestor approval record, a person accepting responsibility). An approval record is evidence OF a human act, NOT a claim of regulator acceptance: §27 produces the accountable-signature artifact a filing requires, and explicitly does not assert that the artifact is regulator-submittable or that the computation substitutes for the human's judgment (the §0 no-filing-claims and §18.3 evidence-not-unsupervised-automation doctrine, made concrete for the sign-off layer).

§27.8 Agent-parity clause. An agent MAY create review tasks and MAY submit approval records, but ONLY under a §22 mandate whose scope explicitly grants the corresponding §27.1 role to that agent's identity. An agent MUST NOT satisfy a review_required or dual_control gate absent an explicit human-role mandate: the default posture is that these gates require a named human, and an agent-signed approval record counts toward a threshold only when a human principal has, in a signed mandate, delegated that exact role to the agent within a validity window. Counted-resume (§22.11) is the mechanism for human approval events and is referenced here, not duplicated: a §27 dual_control threshold and a §22.11 resume_approval.required_events are the same integer-threshold discipline viewed from the accountability side. This closes the obvious failure mode: an autonomous agent MUST NOT quietly become both preparer and approver of its own output.

§27.9 Conformance. An implementation MAY declare human-accountability support for a node or chain; the declaration asserts §27.0 through §27.8 hold for that surface. Conformance is machine-checked by validate-ha-records.test.mjs (§15): the approval-record shape ($defs/humanAccountabilityRecord, closed record_type, role, and gate-policy enums, subject_hash a valid sha256ref); the additivity invariant (an approval record's presence leaves the subject's execution_hash byte-identical, and a subject with zero HA records is byte-identical to a plain v0.8.11 artifact); threshold distinctness (dual_control at N counts distinct identities, so a repeated identity satisfies only N=1 while two distinct identities satisfy N=2); override expiry (an expired override reverts the gate policy, never a silent permanent pass); and the signed-named-human requirement (an unsigned approval record is rejected, layered on the §16 proof-binding.test.mjs round-trip). Like §18 and §25, the layer defaults OFF: a node MUST NOT synthesize accountability records, and absence of §27 records is fully conformant and carries no meaning. Backward compatible and purely additive: no existing artifact, hash, gate, or golden vector moves. Attribution: the identity split follows C2PA and CAWG, the integer threshold follows in-toto, the statement-about-statement framing follows IETF SCITT, and ZCAP-LD is cited as the anti-pattern the §27.0 scope discipline avoids; no text or code is copied.

For a worked walkthrough of a preparer to reviewer to dual-control approval trail, see the Human Accountability explainer.

Conformance Gates

The standard is enforced by executable gates, not by prose. SPEC.md §15, in the normative single source of truth this page renders, carries a rule-to-gate matrix: every normative rule MUST name at least one on-disk gate script that checks it, and a meta-gate parses that matrix and fails if any rule lacks a wired gate. A rule with no live gate is, by definition, not part of the standard.

The practical consequence is that conformance is a decidable property, not a matter of interpretation. An implementation conforms if and only if it validates against the published JSON schema and passes the gate suite. "v0.4-compliant" means exactly one thing: passes the SPEC.md §15 gate suite.

The suite spans strict schema validation of the artifact envelope and Graph Index node object (schema-validate.mjs), a single version of record across every public surface (spec-version-consistency.mjs), the rule-to-gate meta check itself (spec-gate-coverage.mjs), surface and catalog parity (surface-parity.mjs, catalog-parity.mjs), canonicalization lints against the §4 forbidden constructions, kernel determinism checks, and sign-and-verify round trips for the §16, §17, and §18 attestation layers. After every deployment, a sweep re-verifies that each live node still recomputes a valid execution_hash and a smoke test performs a real MCP handshake against the live endpoint.

The full matrix and gate list live in SPEC.md §15 in the public standard repository. For the reasoning behind conformance-by-construction, see Section 9 of the white paper; for a gentler introduction to the whole standard, see the interactive explainer.

Changelog

v0.8.12: 2026-07-23 — spec-text pass

v0.8.10: 2026-07-19 — spec-text pass

v0.8.9: 2026-07-18 — spec-text pass

v0.8.7 → v0.8.8: 2026-07-18

v0.8.6 → v0.8.7: 2026-07-10

v0.8.5 → v0.8.6: 2026-07-09

v0.8.3 → v0.8.4: 2026-07-09

v0.8.2 → v0.8.3: 2026-07-09

v0.8.0 → v0.8.2: 2026-07-06

v0.7.0 → v0.8.0: 2026-07-04

v0.6.1 → v0.7.0: 2026-07-02

v0.6.0 → v0.6.1: 2026-07-02

v0.5.0 → v0.6.0: 2026-06-27

v0.4.1 → v0.5.0: 2026-06-25

v0.3.1 → v0.4.0: 2026-06-19

Maintenance: 2026-06-18 (no version change)

v0.3 → v0.3.1: 2026-06-18

v0.2 → v0.3: 2026-06-18

v0.1 → v0.2: 2026-06-15

v0.1: 2026-06-12 — initial release