What the signature covers. What it does not.

Coverage.

The Ed25519 signature is over the canonical attestation envelope. The envelope commits to the following, and to nothing else.

Covered by the signature

• The canonical input record (inputHash), including the fact model.
• The canonical result payload (outputHash), excluding the attestation field.
• The resolved engine manifest (manifestHash): engine identity, public key, key id and source-file list.
• The engine, catalogue, methodology and rubric versions, and the scoredAt timestamp.

Not covered by the signature

• The whole exported bundle. The signature is over the canonical attestation envelope, not over every file in an export.
• The report header. The organisation name, sector, system name and the rendered audience layer are platform display fields read at render time; they can change after signing, and such changes are audit-logged on the platform rather than committed by the signature.
• Any rendered report layer or narrative. A verifier establishing what was scored relies on the signed input and output hashes, not on the report as displayed.

Read a report header alongside the signed input and output. The header is not proof that the displayed name was cryptographically committed.

The envelope.

A signed record commits to the attestation envelope, the signed result, the exact input that was hashed and the resolved manifest. Which of these artefacts are supplied, to whom and under what arrangement requires an approved output-access arrangement and is set in the engagement terms. The fields below are the envelope.

Example envelope · illustrative values

{
  "attestationVersion": "1.2",
  "engineVersion":      "2.0.6",
  "engineHash":         "17594a80a72888a18e8b2c40b6e2fddaf56989f0bb417bc884111f8260355e50",
  "transformVersion":   "N/A",
  "catalogueVersion":   "1.0",
  "methodologyVersion": "1.3.0",
  "rubricVersion":      "1.3.0",
  "keyId":              "2026-05-02-d7e5468e",
  "scoredAt":           "2026-05-14T09:47:12.334Z",
  "inputHash":          "47a2e19c41d4...cd8b103e4f8d",
  "outputHash":         "91f4c02a6800...a6d0d4e7ad91",
  "manifestHash":       "36b45cbe3e7cc74368febfb01db81bb23c792d1c4884e0cff0983e533edc1c12",
  "signature":          "M4Gb2ZqAfD...pLQX7w=="
}

attestationVersion

The attestation envelope schema version. Current production format: 1.2.

engineVersion

The AGDA™ engine semver. Pinned at the assessment.

engineHash

Engine hash recorded in the resolved manifest and committed by the attestation envelope.

transformVersion

Transform identity for the assessed output. N/A for the core SEDI engine.

catalogueVersion

Failure-mode catalogue version used by the assessment.

methodologyVersion

Methodology version stamped on the result and bound into the attestation.

rubricVersion

Rubric version stamped on the result and bound into the attestation.

keyId

Date-stamped Ed25519 key identifier matched to the public key in the manifest registry.

scoredAt

ISO-8601 UTC timestamp. The moment of attestation.

inputHash

SHA-256 of the canonical input record. Includes the fact model.

outputHash

SHA-256 of the canonical AGDA™ result payload, excluding the attestation field.

manifestHash

SHA-256 of the resolved engine manifest, binding key, catalogue and engine identity together.

signature

Base64 Ed25519 signature over the canonical attestation envelope, excluding the signature field.

How to verify.

A single command. A pinned key ID. A local verifier the supervised entity does not control.

Example run · illustrative output

$ agda-verify --key-id 2026-05-02-d7e5468e --bundle ./bundle.json
[verify] result:
  attestation present: ✓ yes
  manifest found:      ✓ yes
  manifest integrity:  ✓ yes
  signature valid:     ✓ yes
  output integrity:    ✓ yes
  input integrity:     ✓ yes
  revocation checked:  ✓ yes
  revoked:             ✓ no

  ✓ ATTESTATION VALID

The transcript above shows what a successful check prints. Neither the verifier nor any record is published here.

The verifier ships as the agda-verify package command: a self-contained Node.js CLI for Node.js 18+. It checks signature validity, manifest integrity, output integrity, input integrity when input is present, and revocation status when registry entries are available. It uses compiled JavaScript, public keys, manifest data and registry data from the customer distribution, and never contacts Intervene infrastructure.

Public keys, registry and trust.

The verifier checks the Ed25519 signature against the public key recorded in the engine manifest whose hash the envelope commits to, and confirms that manifest is present in the append-only registry supplied with the verifier. Revocations are honoured only when they carry a valid registry signature. Historical public keys remain in the registry so historical attestations can still be checked.

The check cannot establish that the registry copy you hold is the one Intervene published. That rests on how you obtained the verifier distribution and its registry.

Key material

public-keys/. Ed25519 public keys only.

Registry

engine-registry.jsonl. Append-only engine manifests and signed revocation entries.

Rotation

Keys may rotate for scheduled rotation, suspected compromise or engine-version retirement.

Revocation

Signed revocation entries in the registry or bundle. The verifier honours only revocations with a valid registry signature.

What a successful check establishes. And what it does not.

A successful check establishes that the input and output records match the signed commitments associated with the stated engine version, and that neither has changed since signing. It does not independently establish that the engine was executed or that its computation was correct; that would require an engine replay, which is a separate activity.

Not established by verification

• That the engine was executed, or that its computation was correct. The check compares hashes and a signature; it does not rerun the engine.
• That the underlying evidence is true or complete.
• That the assessment method is empirically valid. AGDA™ is not validated against real-world outcomes.
• That a regulator accepts the conclusion, or that any obligation is met.
• That intervention will work in a future event.
• That no revocation exists beyond those present in the registry supplied with the verifier.
• The confidentiality of the record. Signing provides integrity and authenticity, not encryption.

A signature check and an engine replay are separate activities. Signature verification does not rerun the assessment engine. Repeatable computation is a separate property: with fixed inputs and fixed engine and assessment versions, the engine produces the same computed result. Scenario definition, evidence grading and interpretation remain Intervene's judgement.