Core principles
Principles, invariants, and non-goals
DAR is intentionally narrow: preserve durable evidence at the boundary of digital action. This page states the invariants that must hold for DAR to remain neutral infrastructure.
Invariants
The following properties are non-negotiable. If these are weakened, DAR collapses into monitoring, a compliance product, or an opinionated platform — and loses neutrality.
Invariant 1 — Execution-time issuance
Receipts are issued at the point an action is executed (or a decision is committed), not after analysis.
Invariant 2 — Append-only history
Receipts are never edited or deleted. Corrections and remediation produce new receipts.
Invariant 3 — Tamper-evidence & verifiability
Any alteration of a receipt, its signature, or its ordering must be detectable through verification.
Invariant 4 — Minimal, portable semantics
Receipts contain the minimum facts required to attest the action. Domain meaning remains external.
Invariant 5 — Neutrality by design
DAR preserves facts. It does not interpret correctness, intent, risk, or compliance.
Invariant 6 — Evidence by reference
Receipts are shareable as references. Consumers can verify without tight coupling or shared databases.
If a feature requires DAR to “decide,” “flag,” “score,” “monitor,” or “alert,” it is likely outside scope. If a feature preserves a verifiable fact at execution time, it is likely in scope.
Non-goals
These non-goals protect DAR’s neutrality and reduce liability. They are intentional exclusions, not missing features.
No monitoring or surveillance
DAR is not a telemetry platform. It does not continuously observe behavior or infer intent.
No compliance determinations
DAR does not declare compliance or non-compliance. It provides evidence that others may evaluate.
No risk scoring or fraud detection
DAR does not score users, sessions, or actions. Any scoring is downstream and external.
No “truth arbitration”
DAR does not adjudicate disputes. It offers verifiable records to anchor adjudication.
No log replacement mandate
DAR complements existing logs; it does not require replacing observability stacks or SIEM systems.
No business-rule enforcement
DAR can reference policies/guardrails, but does not enforce them. Enforcement is external.
Systems that interpret, flag, or enforce become accountable for outcomes. DAR’s purpose is to remain a neutral evidence layer: durable facts at the action boundary, usable across domains and regimes.
Responsibility boundaries
DAR’s boundary is the issuance and verification of receipts. This section clarifies what DAR is responsible for versus what remains external.
DAR is responsible for
Issuing receipts at execution time; preserving append-only history; enabling verification; providing query-by-reference; ensuring tamper-evidence for stored receipts (within the system’s integrity guarantees).
DAR is not responsible for
Determining correctness; detecting fraud; enforcing policies; validating business intent; proving identity beyond stated references; resolving disputes; or ensuring a customer’s systems generate semantically accurate events.
“We provide verifiable receipts of the actions executed by configured systems at time T. We do not interpret intent, determine compliance, or adjudicate disputes.”
Security considerations
DAR’s integrity depends on issuance, storage, and verification controls. Security guidance here is intentionally high-level and implementation-agnostic.
Key management
Receipt integrity mechanisms depend on key custody. Rotation should produce verifiable continuity, not history loss.
Least-privilege issuance
Only authorized issuers should be able to issue or append receipts for a given namespace or tenant.
Redaction avoidance
Prefer references and hashes over raw sensitive content. Receipts should minimize privacy and disclosure risk.
Verification independence
Verification should be possible without trusting a single vendor narrative. “Verify, don’t assume.”
Receipts should be designed as evidence primitives, not data lakes. Prefer stable references, coarse context tags, and optional hashed fields over sensitive payload storage.
Extensibility model
DAR is a core primitive. Higher-level expressions (profiles, packages, or domain-specific conventions) should layer on top, without changing the core invariants.
Profiles (recommended)
Domain conventions that reuse DAR unchanged (e.g., Agent Action Receipts / AAR, workflow approvals, security boundary receipts).
Packages (optional)
Bundles that assemble receipts into exportable artifacts (e.g., audit packets) without turning DAR into a dashboard.
Terms & normative language
This document uses “MUST / SHOULD / MAY” in the standards sense: MUST indicates a required property for DAR invariants; SHOULD indicates a recommended default for neutrality; MAY indicates optional extensions.