System boundaries & non-goals

Digital Action Receipts are intentionally constrained. This page states what DARs do — and what they explicitly do not do. The purpose is clarity: receipts remain neutral artifacts that record occurrence and support integrity verification later, independent of representation or explanation.

If a capability is not listed as “in scope,” assume it is out of scope. DARs should remain useful even when teams, vendors, and systems change.

In scope

The minimum commitments that define the primitive.

Scope
Record occurrence at the moment of action

When a digital system takes a Digital Action, a Digital Action Receipt may be generated contemporaneously with that action.

Scope
Return a receipt identifier and integrity information

A receipt provides a stable reference identifier and integrity information sufficient to support later verification.

Scope
Append-only behavior

Receipts are stored in an append-only record sequence in which previously stored receipts are not modified or removed.

Scope
Verification of integrity only

Verification confirms whether a receipt has been altered (integrity confirmed vs mismatch detected) — nothing more.

Scope rule: DARs record that an action occurred and allow later verification of integrity. They do not assert why it occurred, whether it was correct, or whether it was permitted.

Explicit non-goals

These are intentionally excluded to preserve neutrality and avoid turning receipts into a monitoring or enforcement product.

Non-goals
DARs do not validate correctness

A receipt does not prove that an action was correct, appropriate, compliant, or desirable. It records occurrence only.

DARs do not explain intent or reasoning

Receipts do not provide explanation, rationale, model reasoning, decision justification, or human intent interpretation.

DARs do not enforce policy

Receipts do not permit/deny actions, apply rules, trigger approvals, or function as an authorization layer.

DARs are not monitoring, analytics, or dashboards

DARs do not provide dashboards, alerting, behavioral scoring, performance monitoring, or surveillance.

DARs do not replace existing operational records

DARs coexist with logs, metrics, audits, and system records. They provide an independent reference artifact, not a replacement.

A useful test: if a feature sounds like control, judgment, monitoring, or compliance claims, it is out of scope.

Boundary of responsibility

The boundary is deliberate: the originating system is responsible for deciding and acting; the receipt system is responsible for recording occurrence and verifying integrity later.

Originating system
Decides and acts
  • Defines policies, rules, workflows, and models.
  • Determines whether and how an action occurs.
  • Maintains operational records (logs, audits, case records).
Receipt layer
Records and verifies
  • Generates a receipt at the moment of action.
  • Stores receipts in an append-only record sequence.
  • Supports integrity verification by reference.
Allowed: occurrence Allowed: reference identifier Allowed: integrity verification Excluded: correctness Excluded: intent Excluded: enforcement Excluded: monitoring

What “verification” means here

Verification is intentionally narrow. It is the ability to confirm that a receipt has not been altered since issuance.

Verification
Integrity-only outcome
  • Integrity confirmed: the receipt matches the stored record.
  • Mismatch detected: the receipt or associated integrity information does not match.
Verification does not confirm correctness, compliance, authorization, intent, business meaning, or “truth” beyond integrity of the artifact.

Optional extension boundary

Event-triggered receipts are a separate extension pattern. It introduces an event-triggering system that determines when to trigger receipt generation, while the receipt service remains responsible for generating the receipt independently.

Extension
Event-triggering system

Observes signals/state over time, determines when a receipt-worthy event has occurred, and emits a trigger signal at a trigger moment.

Core
Receipt service

Generates the Digital Action Receipt when invoked. It does not perform event detection or decide when to trigger.

Separation rule: the event-triggering system determines when to invoke receipt generation. The receipt service determines how to generate the receipt (independently).