]> Aevum Network

kwailapt@gmail.com https://github.com/kwailapt/AgentCard

Applications and Real-Time Individual Submission causal record intervention do-calculus landauer thermodynamic provenance A2A AI This document defines the Physically Annotated Causal Record (PACR), a wire-format protocol for representing one verifiable causal-intervention event between autonomous agents. A PACR is a six-tuple (ι, Π, Λ, Ω, Γ, P) binding a causal identity, a set of causal predecessors, a thermodynamic Landauer cost, an energy-time-space resource triple, a cognitive complexity split, and an opaque payload. The opaque payload optionally carries a one-byte intervention tag classifying the event under Pearl's do-calculus hierarchy (Observe / Do-Physical / Do-Digital / Do-Chemical / Do-Genetic / Counterfactual). PACR is intended as the smallest sufficient statistic for a replayable, rights-aware claim about a single causal step performed by an autonomous agent on a digital, physical, or biological substrate. It is complementary to AgentCard (draft-aevum-agentcard): AgentCard declares an agent's identity and capabilities; PACR records what an agent actually did and at what physical cost. PACR records form a content-addressed directed acyclic graph through their predecessor set. Causal order is determined solely by the predecessor edges; no wall-clock timestamp is required for ordering. This makes the format suitable for distributed multi-agent systems where clock skew and partial ordering are unavoidable. Discussion of this document should take place on the GitHub repository at https://github.com/kwailapt/AgentCard/issues with the label pacr-draft. A reference Rust implementation is published as the pacr-types crate. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Introduction Multi-agent systems built on top of large language models and autonomous physical infrastructure increasingly require a common format for recording what an agent did, not only what an agent claims to be able to do. Existing provenance and audit formats describe transactions, signed statements, or workflow traces, but they typically do not record the physical cost of the computation, do not distinguish causal observation from causal intervention, and do not constrain partial ordering through explicit predecessor edges. This document specifies a minimal wire format that combines these properties: a single, content-addressed record that captures (i) a globally unique identity, (ii) the set of directly preceding records that caused this one, (iii) the thermodynamic energy floor for the bit-level erasures performed, (iv) the actually measured energy-time-space resource cost, (v) a complexity split into statistical structure and residual unpredictability, and (vi) an opaque payload whose first bytes optionally classify the event as an observation, an intervention, or a counterfactual. The format has been designed for use as a substrate-level record in agent-to-agent (A2A) protocols and is independent of any specific transport, storage, or settlement system. It is a peer to AgentCard : an AgentCard says "I am agent X, and I can do Y"; a PACR record says "agent X did Y at cost Z, caused by events {A, B}".

Design Goals

1. Single record, six independent dimensions. A PACR record carries exactly six fields, each derived from an independent physical or logical principle. Implementations MUST NOT collapse two fields into one and MUST NOT add fields whose semantics overlap with an existing field.
2. Causal order, not temporal order. Records are partially ordered by their predecessor sets. Wall-clock timestamps MAY appear inside the opaque payload but MUST NOT be used by readers to determine causal order.
3. Physically grounded cost accounting. The Landauer field carries a theoretical energy floor derived from the number of bits irreversibly erased; the resource triple carries the actually measured energy. The two are distinct and the difference is the thermodynamic waste.
4. Pearl-hierarchy intervention tag. The opaque payload MAY begin with a four-byte magic prefix followed by a one-byte tag classifying the event under Pearl's do-calculus rungs . Counterfactual records MUST additionally carry a sim-real correlation score.
5. Append-only schema evolution. New fields MAY be added to PACR in future revisions. The semantics of existing fields, including this draft's six dimensions, MUST NOT change.
6. Zero hidden state. A reader who can parse this draft and who has access to the predecessor records referenced by Π can fully verify a PACR record without consulting any external service.

Non-Goals This document does not specify:

• A transport protocol. PACR records may be exchanged over HTTP, MCP , message queues, or written to disk; the wire format is independent.
• A signature or attestation scheme. Implementations requiring authenticated records SHOULD wrap a PACR record in a JOSE or COSE envelope.
• A registry, settlement currency, or token system. A PACR record reports a Landauer cost in joules; conversion to any settlement unit is a layer-above concern.
• A specific causal-discovery or counterfactual-inference algorithm. The Counterfactual tag indicates that a simulation produced this record; how the simulation arose is out of scope.

Terminology

Record:

One PACR six-tuple as defined in .

Predecessor:

A record whose causal identity appears in the predecessor set Π of another record.

Genesis record:

A record whose predecessor set is empty. Genesis records have no causal predecessors and serve as roots of the causal graph.

Substrate:

The physical or digital medium on which an intervention acts. Examples include a population of users, a single cell, a piece of infrastructure, or a digital data stream.

Intervention:

A causal action on a substrate, distinct from passive observation. Pearl's do-calculus formalises the distinction.

Counterfactual:

A simulated event that did not actually occur on the substrate; included for "what-if" reasoning. PACR counterfactuals MUST carry a sim-real correlation score.

Estimate:

A measurement reported as a triple (point, lower, upper) with the invariant lower <= point <= upper. Several PACR fields use this representation to carry measurement uncertainty.

Landauer floor:

The minimum energy required to irreversibly erase a given number of bits at a given temperature, defined by Landauer's principle : Λ = bits × k_B × T × ln 2.

The PACR Six-Tuple A PACR record is the six-tuple where the Greek letters are written as their ASCII transliterations in the diagram for portability. The canonical names of the fields are ι (iota, identity), Π (Pi, predecessors), Λ (Lambda, Landauer cost), Ω (Omega, resources), Γ (Gamma, cognitive split), and P (payload). Each of the six fields is REQUIRED. Implementations MUST reject records in which any of the six is missing or null.

i (iota): Causal Identity The causal identity is a 128-bit value that uniquely names this record. It is the content-address of the record within the causal graph. Implementations MUST treat the 128 bits as opaque for ordering purposes: causal order is derived solely from the predecessor set, not from the bit value. Implementations MAY use any 128-bit identifier scheme (e.g., ULID or UUIDv7) so long as the collision probability over the lifetime of the deployment is cryptographically negligible. The reserved value 0x00000000000000000000000000000000 is the genesis sentinel and indicates a record with no causal predecessors that is itself a root of the graph. When serialised in JSON, the identity MUST be encoded as a 32-character uppercase hexadecimal string. Other serialisations (e.g., CBOR ) MAY encode it as a 16-byte byte string.

P (Pi): Predecessor Set The predecessor set is an unordered collection of zero or more causal identities, each naming a record that directly caused the current record. Implementations MUST NOT interpret the order of elements in the set as semantically meaningful. The predecessor set establishes the partial ordering of records. Readers traversing the causal graph MUST treat two records with disjoint predecessor lineages as concurrent (incomparable), regardless of any timestamp information they may carry in their payloads. A record MUST NOT include its own causal identity in its predecessor set; such a record is malformed and MUST be rejected. For typical agent interactions, predecessor sets contain one to four entries. Implementations SHOULD optimise for this common case (e.g., using small-vector storage); they MUST also accept arbitrarily large predecessor sets, since some records (e.g., aggregations) legitimately have many causes.

L (Lambda): Landauer Cost The Landauer cost is the theoretical minimum energy in joules required to perform the bit-level erasures recorded by this event, derived from Landauer's principle : where k_B = 1.380649e-23 J/K is Boltzmann's constant , T is the temperature of the computing substrate in kelvin, and bits_erased is the number of bits irreversibly erased while producing this record. At a reference temperature of 300 K, the per-bit floor is approximately 2.854e-21 J. The Landauer cost MUST be a non-negative Estimate (see ). Negative point estimates are ill-defined and MUST cause validation to fail. The Landauer cost is a lower bound, not the actual energy consumed. The actual energy is reported separately in the resource triple. The difference between the two is the thermodynamic waste of the event.

O (Omega): Resource Triple The resource triple reports the actually measured cost of the event along three axes:

energy:

Actual energy consumed in joules, including waste heat and overheads beyond the Landauer floor.

time:

Wall-clock execution duration in seconds. Despite using seconds, this value MUST NOT be used for causal ordering; it is a resource cost only.

space:

Memory or storage footprint in bytes (encoded as a floating-point number for SI-unit consistency with the other two axes).

Each of the three axes MUST be an Estimate (see ). The triple is subject to two physical constraints:

• Landauer floor: energy.point >= L.point. The actually measured energy MUST NOT be below the theoretical floor.
• Margolus-Levitin bound : time.point >= pi * h_bar / (2 * energy.point) for non-zero energy, where h_bar = 1.054571817e-34 J×s. This bound is of practical relevance only at femtojoule scales but MUST be checked for completeness.

A record violating either constraint is malformed. Implementations MAY still store such records for forensic purposes (measurement errors do occur), but they MUST flag the violation in any downstream validation report.

G (Gamma): Cognitive Split The cognitive split decomposes the information-theoretic structure of the data stream associated with this event:

statistical_complexity (S_T):

Statistical complexity in bits, measuring the minimum information required to optimally predict the stream. Computed via an epsilon-machine reconstruction .

entropy_rate (H_T):

Entropy rate in bits per symbol, measuring the residual unpredictability of the stream even given the optimal predictor.

info_gain (dH):

Information gain in bits, equal to the entropy reduction H_T_before - H_T_after attributable to processing this record. This field was added in a later revision of the reference implementation; readers parsing earlier records MUST treat its absence as a value of 0.0 with zero uncertainty.

All three values MUST be non-negative Estimates. Negative point estimates are ill-defined and MUST cause validation to fail. Statistical complexity and entropy rate are observer- dependent quantities: they depend on the symbol alphabet and the time scale at which the stream is sampled. Implementations exchanging records MUST agree on the discretisation, either through prior arrangement or by recording the discretisation parameters inside the opaque payload.

P (Payload): Opaque Application Data The payload is an arbitrary byte string carrying application-specific semantics. PACR does not interpret this field except to optionally extract a Pearl-hierarchy tag from its first bytes (see ). Upper-layer protocols (e.g., AgentCard ) define their own schemas inside this field. PACR readers that do not understand the upper-layer schema MUST still accept and forward the record; they MUST NOT alter the payload bytes in any way. A payload MAY be empty. An empty payload denotes an event with no application-level content, such as a heartbeat or a synthetic genesis record.

Estimate Type Several PACR fields carry physical measurements that are inherently uncertain. These fields use a common Estimate representation: an object with three numeric values point, lower, and upper, subject to the invariant where point is the best single-value estimate (for example the median or mean of a sample), and [lower, upper] is a confidence interval. A 95 % confidence interval is RECOMMENDED, but the chosen confidence level is implementation-defined and MAY be reported in the opaque payload. The choice MUST remain consistent within a single deployment. For quantities known with mathematical certainty (e.g., a bit count), an Estimate with point = lower = upper MAY be used. Floating-point equality is physically meaningless; consumers comparing two Estimates MUST do so through interval-overlap checks rather than exact equality. Implementations MUST reject Estimates whose values do not satisfy the ordering invariant. Recovery from invalid Estimates is implementation-defined.

Tagged Payload and Intervention Kind A PACR payload MAY begin with the four-byte magic prefix 0x50 0x41 0x43 0x52 (ASCII "PACR") to indicate that the payload carries an intervention tag. Payloads without this prefix are legacy payloads and MUST be treated as if they carried the tag Observe.

Wire Layout

Intervention Kinds The intervention kind classifies the event under Pearl's three-rung do-calculus hierarchy . This document defines six kinds, encoded as the byte values shown:

0x00 -- Observe (Pearl rung 1):

A passive observation of the substrate. No causal action was taken.

0x01 -- DoPhysical (Pearl rung 2):

A physical-world action. Examples: a robot actuator command, a sensor calibration, a laboratory pipetting step.

0x02 -- DoDigital (Pearl rung 2):

A digital action against an external system. Examples: an HTTP API call, a settlement message, a routing decision in a multi-agent system.

0x03 -- DoChemical (Pearl rung 2):

A chemical or biological perturbation. Examples: applying a small-molecule compound to a culture, dosing an animal model.

0x04 -- DoGenetic (Pearl rung 2):

A genetic edit. Examples: a CRISPR guide-RNA delivery, a directed-evolution selection round.

0x05 -- Counterfactual (Pearl rung 3):

A simulated event that did not occur on the real substrate. Counterfactual records carry the additional sim_real_corr field described below.

Future revisions of this document MAY define additional kinds with byte values 0x06 through 0xFF. Readers encountering an unknown kind byte MUST reject the record rather than guess; this preserves the append-only contract.

Sim-Real Correlation A Counterfactual record MUST carry a sim_real_corr value in the range [0.0, 1.0], encoded as an IEEE 754 double-precision number in big-endian byte order immediately following the kind byte. The value reports the observed correlation between simulated outcomes and the historical real-substrate outcomes for analogous setups. A Counterfactual record without a sim-real correlation score, or with a score outside [0.0, 1.0], is malformed and MUST be rejected. This requirement prevents counterfactual claims from being treated as substrate-truth without a stated calibration.

Validation Rules An implementation that validates a PACR record MUST check each of the following conditions and MUST report a violation for any condition that fails. A record may have multiple violations; implementations SHOULD report all of them rather than stopping at the first.

1. Required fields present. All six fields (ι, Π, Λ, Ω, Γ, P) MUST be present. Missing fields MUST cause rejection.
2. No self-reference. ι MUST NOT appear in Π.
3. Estimate invariants. Every Estimate value MUST satisfy lower <= point <= upper.
4. Non-negative physical quantities. Λ, the energy and space components of Ω, the statistical complexity, the entropy rate, and the information gain MUST have non-negative point estimates.
5. Strictly positive time. The time component of Ω MUST have a strictly positive point estimate.
6. Landauer floor. The energy point estimate MUST be greater than or equal to the Λ point estimate.
7. Margolus-Levitin bound. For non-zero energy, the time point estimate MUST satisfy time >= pi * h_bar / (2 * energy).
8. Tagged payload integrity. If the payload begins with the magic prefix, the payload MUST contain at least the kind byte (and, for Counterfactual records, the sim-real correlation field). An unknown kind byte MUST cause rejection.
9. Counterfactual sim-real range. A Counterfactual record MUST have 0.0 <= sim_real_corr <= 1.0.

Encodings This document does not mandate a single binary encoding. Two canonical encodings are described below; deployments MAY use either or both.

JSON Encoding A PACR record MAY be serialised as a JSON object with the following fields: Identities are encoded as 32-character uppercase hexadecimal strings. The payload is encoded using base64 without padding-stripping. All numeric values use IEEE 754 double-precision semantics; JSON numbers without a decimal point or exponent retain integer interpretation per .

CBOR Encoding A PACR record MAY be serialised as a CBOR map with the same field names as the JSON encoding. Identities MUST be encoded as 16-byte byte strings (CBOR major type 2). Estimates are encoded as three-element CBOR arrays in the order [point, lower, upper]. Payloads are encoded as CBOR byte strings. The CBOR encoding is RECOMMENDED for high-throughput deployments where the JSON overhead is significant.

Relationship to Other Specifications

AgentCard AgentCard declares what an agent is and what it can do. PACR records what an agent did. AgentCards are typically static; PACR records are append-only event streams. A common deployment pattern is for an agent to publish an AgentCard containing its identity and capabilities, and for every action that agent takes to be recorded as a PACR record whose payload references the AgentCard's identity and the capability invoked.

JOSE / COSE PACR does not define an authentication mechanism. Deployments that require authenticated PACR records SHOULD wrap each record in a JOSE or COSE envelope and use the wrapper's signature semantics. The PACR identity field is suitable as the JOSE/COSE message identifier.

W3C PROV-O The W3C PROV ontology models provenance using activities, agents, and entities, and is designed for description in RDF. PACR is a complementary, line-protocol-style format with a fixed six-tuple structure and an explicit thermodynamic cost field. A PROV-O activity MAY be derived from a PACR record by mapping ι to prov:Activity, Π to prov:wasInformedBy, and the payload to prov:value.

Model Context Protocol MCP defines a protocol for communication between language-model hosts and tool servers. An MCP tool call MAY produce a PACR record as a side effect of execution; the PACR record's payload MAY embed the MCP request and response identifiers. This document does not require any specific MCP integration.

Security Considerations

Cost Spoofing A malicious or buggy producer may report a Landauer cost or resource triple lower than the actual physical cost of the event. PACR's validation rules detect impossibly low costs (e.g., negative energy, energy below the Landauer floor at the producer's stated temperature) but do not detect plausibly low costs. Consumers who use PACR records for economic settlement or capacity planning SHOULD independently corroborate cost claims (for example, by comparing reported energy against observed latency and throughput) before acting on them.

Fabricated Predecessors A malicious producer may include in the predecessor set identities that the producer does not actually possess knowledge of, intending to claim a causal lineage it did not participate in. PACR does not by itself prevent this: a consumer must verify that the referenced predecessor records exist in a trusted store and that they precede the current record in the consumer's view of the causal graph. Implementations SHOULD reject a record whose predecessor set references unknown identities until the predecessors have been resolved.

Payload Injection The opaque payload MAY contain arbitrary bytes including executable code, malformed structured data, or content that attempts to exploit the consumer's parser. Consumers MUST treat the payload as untrusted input and apply normal parser-hardening practices (e.g., strict schema validation, length limits, never eval-ing the bytes). PACR itself does not interpret the payload.

Personally Identifiable Information PACR's six structural fields do not carry personally identifiable information (PII). Producers MAY embed PII in the opaque payload. Doing so makes the PACR record subject to the same privacy controls (consent, retention, lawful basis) as any other PII-bearing data. Implementations intended for use in regulated environments SHOULD partition PII-bearing payloads from non-PII payloads at the storage layer.

Counterfactual Misuse A Counterfactual record describes a simulated event, not a real-substrate event. Confusion between the two could lead to substantial harm in safety-critical contexts (for example, an autonomous-driving system mistakenly treating a counterfactual scenario as observed reality). Consumers MUST inspect the intervention kind before treating a record as evidence of substrate state, and SHOULD render counterfactual records distinctly in any user interface. The mandatory sim_real_corr field is intended as a calibration hint, not as a guarantee.

Graph Denial-of-Service A producer may construct records with very large predecessor sets, or whose graph forms a deep chain, in an attempt to exhaust consumer resources during traversal. Implementations SHOULD impose configurable per-record limits (predecessor-set cardinality, payload size) and per-traversal limits (depth, total node count) and SHOULD reject or truncate records that exceed them.

Replay PACR does not include a sequence number, nonce, or signature. A captured record MAY be replayed by a network attacker. Deployments MUST rely on transport-layer or wrapper-layer mechanisms (TLS, JOSE/COSE, MCP transport authentication) to detect and reject replays where this is a concern.

IANA Considerations

Media Type Registration: application/pacr+json This document requests that IANA register the following media type in the "Media Types" registry :

Type name:

application

Subtype name:

pacr+json

Required parameters:

none

Optional parameters:

none

Encoding considerations:

binary (UTF-8 JSON object)

Security considerations:

See .

Published specification:

This document.

Applications that use this media type:

Multi-agent systems, AI-agent provenance ledgers, MCP servers and adapters, and any deployment that records verifiable causal-intervention events with thermodynamic cost annotations.

Additional information:

Magic number(s):

none

File extension(s):

.pacr.json

Macintosh file type code(s):

none

Person and email address to contact for further information:

Kwai Lap Tsoi <kwailapt@gmail.com>

Intended usage:

COMMON

Restrictions on usage:

none

Author:

Kwai Lap Tsoi <kwailapt@gmail.com>

Change controller:

IETF

Media Type Registration: application/pacr+cbor This document requests that IANA register the following media type in the "Media Types" registry :

Type name:

application

Subtype name:

pacr+cbor

Required parameters:

none

Optional parameters:

none

Encoding considerations:

binary (CBOR map per RFC 8949)

Security considerations:

See .

Published specification:

This document.

Applications that use this media type:

High-throughput PACR deployments where JSON encoding overhead is significant.

Additional information:

Magic number(s):

none

File extension(s):

.pacr.cbor

Macintosh file type code(s):

none

Person and email address to contact for further information:

Kwai Lap Tsoi <kwailapt@gmail.com>

Intended usage:

COMMON

Restrictions on usage:

none

Author:

Kwai Lap Tsoi <kwailapt@gmail.com>

Change controller:

IETF

PACR Intervention Kind Registry This document requests that IANA establish a new registry named "PACR Intervention Kind" with the following initial contents. The assignment policy is "Specification Required" per .

Value	Name	Pearl Rung	Reference
0x00	Observe	1	This document
0x01	DoPhysical	2	This document
0x02	DoDigital	2	This document
0x03	DoChemical	2	This document
0x04	DoGenetic	2	This document
0x05	Counterfactual	3	This document

Values 0x06 through 0xFE are unassigned. Value 0xFF is reserved. New assignments require a published specification that defines the semantics of the kind, any additional payload fields it requires, and any additional validation rules.

References Normative References Informative References Anthropic NIST

Acknowledgements The PACR six-tuple structure was developed in the context of the Aevum Network specification work over 2026. The author thanks reviewers of the AgentCard draft () for early feedback that motivated the separation of capability declaration (AgentCard) from event recording (PACR). The Pearl-hierarchy intervention tag was added after practical use of an untagged predecessor format made it clear that downstream consumers cannot reliably distinguish observations from interventions without an explicit marker.