Cause-Field Canonicalization: Cryptographic Identity from Purpose Statements as Constitutional Commitment

#1. Introduction

Cryptographic identity primitives for multi-agent systems are typically specified over descriptive inputs. The W3C Agent Identity Registry working group’s draft specification names three input categories: a human-readable identifier, a scope descriptor, and a purpose declaration. Implementations frequently treat the identifier and scope as load-bearing fields and the purpose declaration as either decorative metadata or as a free-form description not contributing to the cryptographic seed.

We argue this framing is incomplete. The purpose declaration — what we call the cause field — is structurally distinct from the descriptive inputs and warrants treatment as an independent primitive. When the cause field contributes to the cryptographic seed alongside name and scope, the identity primitive acquires properties that pure descriptive identity does not have: constitutional commitment, immutable purpose, and external verifiability of authorization context.

We describe cause-field canonicalization as it has been deployed across a multi-tenant orchestration substrate, motivate it as a structural mechanism for constitutional commitment, and argue that it satisfies regulatory and audit requirements that ask for evidence of why an entity acted (its authorized purpose) rather than only that an entity acted (its identity).

The contribution is conceptual and operational. The conceptual claim is that cause-field canonicalization is structurally distinct from descriptive identity and from constitutional AI as practiced at the model layer. The operational claim is that the discipline has been implemented at production scale and produces empirical properties consistent with the conceptual claim.

#2. The cause field

We use cause field to refer to the canonical first-person declarative purpose statement bound to an entity in a cryptographic identity primitive. The field is structured by three constraints:

First-person declarative. The cause is written from the entity’s voice, in the form “I [verb that describes the entity’s purpose].” This grammatical form forces the authoring committee to confront what the entity is for, not what it is named.

Canonical. The cause is committed at the time the entity’s identity is minted and is not editable thereafter. Editing the cause produces a different identity (a different cryptographic seed); the original entity, with its original cause, persists in the audit chain. The canonical commitment is enforced cryptographically, not by policy.

Publicly readable. The cause text is part of the entity’s canonical record, accessible to any party with read access to the entity. External auditors, regulators, and counterparties can read the entity’s cause and use it as evidence of the entity’s authorization context.

flowchart LR
NAME[Namehuman-readable identifier] —> CONCAT[Concatenation+ canonical separator]
SCOPE[Scopehierarchical container] —> CONCAT
CAUSE[Causefirst-person declarativepurpose statement] —> CONCAT
CONCAT —> HASH[SHA-256]
HASH —> SEED[Cryptographic seed64-char hex]
SEED —> AUDIT[Audit-chain entriessign with seed]
SEED —> RECORD[Public canonical recordcause readable externally]

When the cause is concatenated with name and scope into the cryptographic seed input, the three structural properties acquire load-bearing significance. The first-person declarative form becomes part of the entity’s cryptographic identity. The canonical commitment is enforced by the hash function: changing the cause produces a different seed, which is a different entity. The public readability makes the constitutional commitment externally verifiable: a counterparty can read the cause and verify it has not been altered since the entity’s mint.

#3. The structural argument

The argument that cause-field canonicalization is structurally distinct from descriptive identity rests on three observations.

#3.1 Descriptive identity does not encode purpose

A descriptive identity primitive — say, agent.id = uuid4() or agent.id = sha256(name + tenant) — encodes which entity the identifier refers to but does not encode why the entity exists. A regulator examining the audit chain can verify that some entity identified by the seed took an action; they cannot verify, from the identity primitive alone, that the entity was authorized to take that class of actions. The authorization context must be reconstructed from external sources (charters, role definitions, policy documents) that may or may not be cryptographically committed alongside the identity.

Cause-field canonicalization closes this gap. The cause text is the entity’s authorization context, cryptographically committed to the seed, publicly readable, and immutable. A regulator who reads the cause text knows what the entity was authorized to do, not as a separate document that the operator might or might not produce on demand, but as an integral part of the entity’s identity.

#3.2 Constitutional AI operates at the model layer

The constitutional AI methodology, as described in Anthropic’s foundational papers, operates at the model layer: a constitution is a set of principles the model trains to satisfy, and the model’s outputs reflect (with measurable fidelity) the constitutional commitments encoded in training. Constitutional AI is appropriate for shaping a model’s behavior across the distribution of prompts it might encounter.

Cause-field canonicalization operates at the substrate layer. The constitution is not encoded in the model’s weights; it is encoded in the entity’s identity record. Any model substrate underlying the entity is constrained by the same cause text. The substrate can be model-substrate-agnostic in a way that constitutional AI cannot.

The two methodologies are complementary, not redundant. A model with constitutional training that produces outputs aligned with constitutional principles can be deployed under a substrate-layer cause field that further commits the deploying entity to a specific authorization context. The model layer provides general alignment; the substrate layer provides specific commitment.

#3.3 Causes resist drift in ways descriptive identity cannot

A description that an entity is (its name, its scope, its role label) can change without changing the entity in any meaningful sense. An agent named “Composer-A” can be renamed “Composer-Alpha” without the entity becoming a different actor. A description of what an entity is for (its cause) cannot change without changing the entity meaningfully: an entity whose declared purpose changes is, in a regulatory and auditing sense, a different entity. The change should be cryptographically detectable.

Cause-field canonicalization makes this detectability structural. The cause is part of the seed; a changed cause produces a different seed; a different seed is, by the substrate’s identity primitive, a different entity. The substrate’s audit chain cannot conflate the original entity with the post-change entity because their seeds differ.

This property has practical consequences. An adversary attempting to expand an entity’s authorization scope by quietly editing its purpose statement cannot succeed: the edit produces a different seed, the audit chain rejects the imposter as a different entity, and the original entity (with its original cause) remains the canonical record.

#4. The discipline of authoring

Cause text deserves committee review at the time it is authored. We describe three structural properties of the authoring discipline that make the resulting cause text load-bearing.

Constitutional review. The cause is authored not as a description of what an entity does but as a commitment to what the entity is for. Drafting committee members are tasked with surfacing edge cases the cause does not cover, scope-creep risks the cause does not bound, and authorization context the cause does not specify. The drafting iterations resemble constitutional drafting more than software documentation.

Immutability commitment. The committee writes knowing the text cannot be edited post-mint. This forces the text toward statements that the committee is willing to commit to indefinitely. Throwaway language is filtered out at drafting time because the committee anticipates future readers (regulators, counterparties, future committee members) reading the same text.

Public-reader framing. The committee writes knowing the text is publicly readable. This filters out internal-jargon that does not communicate to external readers and forces the cause toward a register that an external auditor can read without context. The forcing function produces text that survives translation across audiences.

The three properties produce text quality that is materially higher than typical software documentation. The cost is real: drafting cause text for substrate-tier canonical entities requires explicit committee time and produces friction. The benefit is the cryptographic commitment: cause text drafted under the discipline can be relied upon as authoritative evidence of the entity’s authorization context.

#5. The regulatory dimension

The regulatory environment for autonomous AI deployments has converged on requirements that ask for evidence of why an entity acted, not just that an entity acted. Examples include:

• EU AI Act Article 12 requires logs that enable retrospective examination including identification of natural persons involved in verification of results. The Article anticipates that auditors will trace actions back to authorized actors with verified authorization context.

• W3C Agent Identity Registry working group specifies cryptographic identity that includes purpose declaration alongside identifier and scope. The working group’s draft converges on the three-field shape we describe.

• Five Eyes joint guidance on cryptographic agent identity (April 30, 2026) names purpose verification as a baseline requirement for autonomous AI deployments under regulatory oversight.

• Singapore IMDA Model Governance Framework for Agentic AI identifies fine-grained, context-dependent permissions as a baseline for regulated agentic AI, distinct from static role-based access.

In each of these regulatory frames, the question “was this entity authorized to take this action” requires evidence of the entity’s purpose, not only its identity. Cause-field canonicalization provides this evidence as a structural property of the identity primitive: the cause is part of the seed, the seed is part of every audit-chain entry, the cause is publicly readable.

The regulatory frame therefore aligns naturally with the cause-field discipline. We do not claim cause-field canonicalization is the only mechanism that satisfies these regulatory requirements; we claim it is one mechanism that satisfies them with low operational overhead and clean cryptographic guarantees.

#6. Comparison to alternative purpose-binding mechanisms

We discuss alternative mechanisms for binding purpose to identity, and the structural reasons cause-field canonicalization was selected over them.

External charter document. The entity has an identifier; the entity’s authorization context is specified in a separate charter document; the charter is referenced by URL or by content hash from the entity’s record. Strengths: simple, conventional. Weaknesses: the charter document can be edited after the fact; the reference can be re-pointed to a different document; the cryptographic commitment is at most as strong as the operator’s policy commitment to preserve the charter.

Capability tokens. The entity carries a set of capability tokens, each authorizing a specific action class, with cryptographic signatures from a granting authority. Strengths: fine-grained, well-understood in distributed systems literature. Weaknesses: capability tokens describe what an entity can do, not why; they do not carry the constitutional-commitment property; they require a granting authority that the substrate may or may not have.

Constitutional AI training. The model substrate underlying the entity is trained against a constitution; the entity’s outputs reflect (with measurable fidelity) the constitutional commitments. Strengths: shapes behavior across the prompt distribution. Weaknesses: operates at the model layer (substrate-level deployments inherit the model’s constitution; they cannot specify their own); does not produce externally-verifiable evidence of substrate-specific authorization.

Decentralized identifier (DID) with verifiable credentials. The entity has a DID; verifiable credentials issued by trusted issuers describe the entity’s purpose; the credentials are verifiable by external parties without trusting the substrate. Strengths: standards-track, interoperable. Weaknesses: substantial implementation complexity (DID method registries, resolution layers, credential issuance); credentials can be revoked or rotated, which complicates immutable-purpose semantics.

Cause-field canonicalization is the simplest mechanism that produces all four desired properties: cryptographic commitment, immutability, public readability, and externally-verifiable authorization context. The cost is the discipline of canonical authoring; the benefit is structural alignment with the regulatory frame.

#7. Production properties

The discipline has been deployed across a multi-tenant orchestration substrate. We report observed properties.

Cause text drafted under committee review. Substrate-tier canonical entities (the orchestration agents responsible for routing, gating, building, and voicing) have committee-authored cause text reviewed before mint. Tenant-tier operational entities (agents minted on behalf of tenant onboardings) have template cause text instantiated with tenant-specific variables; the templates were committee-authored at template-creation time.

Cause text in audit-chain entries. Every audit-chain entry references the actor’s cause-bound seed. Verification of an audit-chain entry includes resolving the seed to the entity’s canonical record, which exposes the cause text to the verifying party.

Cause-text-driven authorization checks. The substrate’s authorization layer reads cause text in cases where action authorization is ambiguous. An action proposed by an entity whose cause does not encompass the action class is flagged by the gate function as out-of-scope; the entity’s cause text is the canonical reference for what the entity is for.

Cross-tenant verification. When entities in different tenants interact (cross-tenant bus messages, cross-tenant audit-chain entries), each side can read the other’s cause text as part of identity resolution. Cross-tenant trust is therefore grounded in publicly-readable purpose commitments, not in opaque identifiers.

We have not observed cause-text drift attempts in the production corpus; the canonical-immutability property holds. We have not observed adversarial cause-text impersonation attempts; the cryptographic seed verification rejects mismatched seeds before any authorization decision.

#8. Limitations

The cost of canonical cause-text authoring is real. Committee review takes time; the resulting text resists future edits; mistakes in the original drafting cannot be cleanly corrected (correction requires minting a new entity, which produces a parallel identity with its own audit-chain history). The discipline is appropriate for substrate-tier canonical entities and for tenant-tier entities where authorization context is durable; it is inappropriate for ephemeral entities where the authoring cost exceeds the cryptographic-commitment benefit.

The cause text’s quality is not enforced by the cryptographic primitive. An operator could mint entities with empty or trivial cause text; the seed would be cryptographically valid but the substrate would lose the constitutional-commitment property. The substrate’s response is a protocol-layer enforcement: pre-mint review processes verify cause text quality before the migration applies. This is policy enforcement rather than primitive enforcement; we do not claim the primitive itself produces quality.

The cause text cannot be revoked. An entity whose authorization should be revoked retains its cause text in the canonical record; the substrate’s response is to mark the entity’s status as revoked and require downstream verifiers to consult the status field. This is a separable concern from the cause field’s immutability; revocation works through the audit chain and the entity-status field, not through cause-text mutation.

The cause field is a single statement; it does not support hierarchical or compositional purpose specification. An entity whose authorization context is multi-dimensional (e.g., “act as composer for sprint coordination AND as voice for external content”) is forced to express both dimensions in a single cause statement, which can produce text that is awkward to read. Forward work may explore structured cause representations that compose across dimensions; the current discipline assumes monolithic cause text.

#9. Open questions

Cause-text length and information density. The current discipline has no formal upper bound on cause-text length. We have observed that texts of approximately 100-200 words produce the strongest committee consensus and the cleanest audit-chain readability. Texts much shorter risk under-specification; texts much longer risk drifting into descriptive prose rather than constitutional commitment. We have not formalized the optimal range.

Cross-substrate cause portability. A cause text minted in one substrate’s identity space cannot be re-used in another substrate without re-minting (because the scope field differs across substrates and the seed differs). The substrate’s response is to treat each substrate’s identity as independent; cross-substrate cause portability is not a current concern. If federation across substrates becomes load-bearing, cause portability will require a federation protocol.

Cause-text version migration. The substrate currently does not support cause-text versioning (a single-text-per-entity model). Hypothetical future support for cause text versions would require careful semantic specification: are multiple versions parallel identities, or is the latest version canonical? The current discipline avoids the question by treating cause text as immutable.

Adversarial cause-text construction. An entity whose cause text is constructed to appear to authorize a broad action class while being interpretable in narrow ways could plausibly evade authorization gates that read the cause text literally. Defending against this is partly a discipline matter (drafting committee resists adversarial constructions) and partly a probe matter (gate functions probe for adversarial interpretations of cause text). Forward work may formalize the defense.

#10. Conclusion

We describe cause-field canonicalization as a structural mechanism for constitutional commitment in multi-agent systems. The cause field — the canonical first-person declarative purpose statement, contributing to the cryptographic identity seed alongside name and scope — produces four properties that descriptive-only identity does not: constitutional commitment, immutable purpose, public readability, and externally-verifiable authorization context.

The discipline operates at the substrate layer, distinct from constitutional AI’s model-layer methodology, and aligns naturally with the regulatory environment that asks for evidence of why an entity acted in addition to that an entity acted. The discipline has been deployed at production scale across a multi-tenant orchestration substrate; observed properties are consistent with the conceptual claim.

The cost is the canonical authoring discipline: committee review, immutability commitment, public-reader framing. The benefit is cryptographic commitment to constitutional purpose that survives operator turnover, model substrate changes, and regulatory transitions. We propose cause-field canonicalization as a candidate primitive for multi-agent identity standards work, including the W3C Agent Identity Registry working group’s specification process.

Companion to Mumega 200.003 — QNFT Cryptographic Identity Primitive (the identity primitive that includes cause as a load-bearing field) and Mumega 200.102 — EU AI Act Article 12 Reference Implementation (the regulatory framework against which cause-field canonicalization is mapped).