Decision Receipts

Decision receipts are the governed provenance records for important operational decisions. A receipt answers what decision happened, what source-owner record produced it, what governed subject was affected, who acted or approved, what evidence or authority refs supported it, and what integrity posture exists.

Receipts are owned by Governance Trace. They bind source-owner records through sanitized references; they do not replace the source modules that own the underlying work.

What A Receipt Contains

A receipt can include:

the source module, source resource, subject resource, version refs, and action key;
decision kind, outcome, decided timestamp, requester, actor, reviewer, and approver refs;
risk acceptance, review approval, workflow gate, or source-owner authority refs;
evidence, source graph, citation, audit, drift, follow-up, and integrity refs;
AI run, suggestion, dossier, action application, or agent refs when an AI-enabled owner exposes safe lineage;
a canonical content hash over the sanitized receipt metadata.

Receipts do not store raw source text, OCR text, prompts, model outputs, embeddings, vectors, provider payloads, storage keys, object paths, bearer tokens, webhook signing secrets, private keys, or connector credentials.

User Journey

Open Governance -> Decision receipts.
Filter by receipt status, decision kind, outcome, source module, subject, approver, or integrity state.
Select a receipt to review the decision, actor refs, source and subject refs, authority state, evidence state, integrity state, and sanitized snapshots.
Use the embedded Governance Trace panel to inspect exact source, subject, evidence, authority, and support links.
Use work-management, posture, and audit-package surfaces for follow-up or export behavior where those owner modules are enabled.

Current Source Owners

The first source-owner handoffs cover stable V1 owners:

Risk Acceptance decisions such as approve, reject, renew, revoke, expire, and supersede.
Review Approval reviewer and approver decisions.
Source Graph edge and citation review decisions.
Regulated Content handoff decisions when a handoff is accepted, completed, rejected, blocked, or marked reference-only.
Impact Analysis review decisions when a review is approved, rejected, changes-requested, or blocked.
Stakeholder Consultation disposition decisions when a comment disposition is accepted, rejected, deferred, triaged, or closed.
AI run execution, suggestion review, suggestion application, decision dossier review, watcher conversion, and controlled agent action decisions when the AI feature is enabled.
Monitoring/reporting report-run decisions when runs are generated, reviewed, exported, stale, or blocked.
Continuous Assurance snapshot decisions when snapshots are approved, published, superseded, or retired.

Integrity And Signing States

hash_only means the receipt has a deterministic content hash over sanitized receipt metadata. It is useful for internal consistency checks, but it is not the same as a signed receipt.

signed is shown only when the receipt is backed by persisted audit-ledger checkpoint signature evidence. Signing is separate from encryption BYOK: a customer-managed encryption key does not by itself sign decision receipts.

external_anchor is shown only when the signed checkpoint also has completed, verifier-checkable anchor evidence. Pending, failed, disabled, and not-configured anchor states remain visible as those exact states and are not collapsed into a completed anchor.

not_configured, provider-not-configured, deployment-dependent, anchor_pending, anchor_failed_retryable, anchor_failed_terminal, anchor_disabled, and evidence-required mean the product surface exists but the tenant or deployment still needs setup, a retry, or evidence before stronger claims can be made.

Novantra does not use this page to claim legal validity, public-blockchain anchoring, certification, or framework conformance. Those require separate evidence and contractual scope.

Cloud, On-Prem, And No-AI

Cloud and on-prem deployments expose the same receipt behavior for enabled source owners. Deployment differences appear as capability states, provider configuration, or evidence refs.

No-AI deployments can still use non-AI receipts for risk acceptance, review approval, source graph, and other non-AI owners. AI lineage fields appear as not applicable or unavailable rather than importing optional AI runtime behavior.