# Governance Interoperability Note

Status: **DOCUMENTED**. This note describes a vendor-neutral interface
for exchanging references between AI-governance systems and Decision
Receipts. It does not implement, endorse, or partner with any specific
vendor.

## Position

Governance systems define **what should happen**. Signatrust records
**cryptographic evidence about what was recorded as having happened**.
The two roles are complementary, not overlapping. Any UI or spec text
must preserve that distinction.

## The vendor-neutral evidence interface

A Decision Receipt may reference governance artefacts by identifier and,
crucially, by hash — so that the reference remains verifiable even if
the governance system disappears.

### Fields (already available today)

- `decision.policies: string[]` — free-form policy identifiers
  meaningful to the issuer.

### Fields introduced in the alignment pass

- `policy_bindings: PolicyBinding[]` — pins a receipt to a specific
  historical policy document by hash
  (`POLICY_BINDING_SPEC.md`).

### Fields recommended (DOCUMENTED, additive)

For governance-integrated deployments, receipts MAY carry a
`governance_refs` object inside `metadata` (customer-controlled), so no
schema bump is required:

```jsonc
"metadata": {
  "governance_refs": {
    "framework_ids":   ["nist-ai-rmf", "iso-42001"],
    "control_ids":     ["MG-3.1", "MEA-5.2"],
    "policy_ids":      ["hospital-triage-protocol"],
    "workflow_id":     "triage-v3",
    "approval_id":     "AW-2026-08-1234",
    "rule_set_hash":   "sha256:af…"
  }
}
```

### Semantics

| Field | Meaning |
|-------|---------|
| `framework_ids` | Governance frameworks whose controls the customer maps to this decision. Purely referential. |
| `control_ids`   | Specific control identifiers within those frameworks. |
| `policy_ids`    | Issuer's own policy identifiers. Pair with `policy_bindings[]` to pin content. |
| `workflow_id`   | The workflow / process id inside the governance platform. |
| `approval_id`   | If the workflow required a human approval, its identifier in the governance platform. |
| `rule_set_hash` | `sha256:<hex>` of the rule set that the governance platform reports as having been executed. Pairs with the platform's own attestation of that hash. |

None of these fields is interpreted by Signatrust. They are stored as
`metadata` (customer-controlled) and appear in the signed body verbatim.
A governance platform can independently attest to what a given
`control_id` means and what its execution produced — that attestation is
its own responsibility, not Signatrust's.

## Mapping model

The interoperability model is a three-layer mapping, executed in the
customer's environment:

```
Governance intent                ->  Execution evidence          ->  Receipt verification
(policy / control / rule-set        (workflow-manager records        (Signatrust receipt with
 defined by governance platform)     that the rule set ran,           policy_bindings + hashes;
                                     with hashes of inputs/outputs)   verifier checks integrity)
```

Signatrust owns only the right-hand column. The left and middle columns
are the governance system's responsibility.

## Boundary rules

- Signatrust does **not** decide whether a receipt satisfies a control.
- Signatrust does **not** attest that a rule set was correctly designed.
- Signatrust does **not** attest that a governance platform ran what it
  claims to have run — unless the platform itself supplies an
  attestation (see below).
- Verifying a receipt does not, by itself, satisfy any regulatory
  obligation.

## Attestation from a governance platform

If a governance platform wants to add cryptographic evidence that a
control was executed, it may do so by producing its **own** attestation
receipt (see `RECEIPT_TAXONOMY_RESEARCH_NOTE.md` §Attestation Receipt)
that references the Decision Receipt id and includes the platform's own
Ed25519 signature. This is a normal use of the Attestation Receipt
pattern; no new protocol is required.

Semantically:

- Decision Receipt says: "the issuer recorded that decision D was
  produced under policy P and rule set R at time T".
- Attestation Receipt (produced by the governance platform) says: "the
  governance platform confirms that its recorded execution of R
  matches hash H, and links to Decision Receipt STR-…".

A verifier can then check both signatures, without either system
trusting the other.

## Anti-pattern

Do not embed the governance platform's own execution logs inside
`metadata`. That defeats data minimisation and pushes long-term
verifiability onto Signatrust for content that Signatrust does not
control. Reference by id and by hash, not by inline copy.

## Non-goals

- No governance-platform-specific SDK.
- No "compliance dashboard" claiming that a set of receipts satisfies
  any specific framework.
- No mapping of receipts to controls maintained inside Signatrust;
  mappings are the governance platform's artefact.
- No pre-negotiated integration with any specific vendor.

## What this delivers

- A stable, additive way to carry vendor-neutral governance references
  inside a receipt.
- A boundary rule set that stops governance and evidence roles from
  drifting into each other.
- A clear pattern (Attestation Receipt) for governance platforms to
  contribute their own cryptographic evidence without asking Signatrust
  to certify their execution.