Part of a coordinated release

This is one of three protocol drafts being published together: SSP v0.2 (the Session-Surface Protocol), ACP v0.1 (this document), and RCP v0.1 (the Runtime Compact Protocol). The three specs are intended to be read together as a coordinated architectural proposal. An architectural overview at [link] introduces the five-protocol architecture: SSP, ACP, RCP, AAP (the Agent Attestation Protocol), and EPP (the Event Propagation Protocol). Three of the five are included in this coordinated release; AAP and EPP are named throughout but not yet drafted. ACP v0.1 can be read standalone, but readers wanting the full picture should start with the overview.

The companion essay The Contract Problem at [link] provides the architectural argument that motivates ACP. It traces the history of how parties have structured agreements with each other — from written contracts to terms of service — and names what changed when interactions began crossing agent boundaries faster than humans could review them. The essay is recommended for readers who want to understand why ACP exists; it is not required to implement the protocol.

1. What ACP is

ACP defines structured terms governing what crosses the boundary between two agents in a bounded interaction. It specifies the form of those terms, the negotiation that produces them, the artifact that records them, and the obligations each party retains under them.

The terms govern context. When agent A and agent B interact — to coordinate work, to exchange information, to commit to a transaction, to author a record — context flows across the boundary between them. ACP specifies how that flow is constrained: what context enters the interaction, what each party retains afterward, what each party may derive from what it retains, how each party may propagate what it derived, when retention expires, and how the agreement may be revoked.

The agreement itself is an artifact. ACP calls it a compact. A compact is bilateral, machine-readable, signed by both parties, and retained by both. Once authored, it persists independently of the session that authored it and the agents that signed it, governing the parties' obligations until it expires or is revoked.

ACP does not govern what agents do for their principals. It does not govern what services are negotiated, what work is performed, or what value is exchanged. It governs how the context surrounding those interactions is structured, retained, and disposed of.

ACP exists because the interactions agents now mediate are happening faster than humans can review and at a scale where each interaction's terms-of-service screen is no longer a meaningful consent surface. The compact is the mechanism that lets parties pre-negotiate terms that will govern many future interactions, with structure precise enough for agents to enforce on each side. The companion essay The Contract Problem develops this argument; this spec defines the protocol.

[ACP v0.1 introduces the protocol family's first specified compact. Subsequent specifications and revisions will reference this articulation.]

2. What ACP is not

ACP is deliberately narrow.

ACP is the compact protocol, not a service-discovery specification, a payment specification, or a service-level specification. It governs the terms surrounding what crosses an agent boundary; it does not govern the substantive interaction the boundary contains. Agents that have authored a compact may then negotiate services, exchange value, or coordinate work; ACP specifies the terms under which they do so but not the terms of what they do.

ACP is not a substitute for AAP. The compact's signing and retention claims are meaningful only when the agents on each side are legitimately representing their principals. ACP names this dependency where it bears on the protocol's claims and defers the mechanism.

ACP is not a substitute for legal instruments. A compact is a structured agreement that may carry legal weight in jurisdictions where signed agreements between competent parties do, but ACP does not specify enforceability, jurisdiction, or recourse. Where parties want legal force beyond what the compact's structure provides, they layer legal instruments on top of compacts.

The granular inventory of what is in scope, out of scope, and deferred is in §13.

3. The compact pattern

This section articulates the structural pattern that ACP's compact, RCP's runtime compact, and AAP's attestation compact share. The pattern is named here because ACP is the first protocol in the family to specify a compact in full. The articulation may eventually consolidate elsewhere — possibly in RCP, where the substrate question gives the pattern its strongest grounding — as the family matures. v0.1 carries it here.

3.1 What a compact is, structurally

A compact is a structured agreement between two parties that specifies the terms of a bounded interaction between them.

Five properties define the pattern:

A compact is bilateral. It records the agreement of two parties to specific terms, signed by both. A document that records only one party's stated intentions is not a compact; it is a declaration. A compact requires mutual, attested agreement.

A compact is bounded. It specifies what its terms apply to — which interactions, which contexts, which time period, which scope of work. A compact that purports to govern all future interactions of any kind between two parties is not a compact under this pattern; it is a treaty. The compact pattern requires that what falls inside the agreement and what falls outside is explicit.

A compact is machine-readable. Its terms are structured precisely enough that the agents enforcing the compact on each side can determine, programmatically, whether a given action conforms to or violates them. A compact whose terms can be enforced only by human judgment is not a compact under this pattern; it is a contract. The compact pattern requires that compliance is computable.

Machine-readability has a specific technical shape. It means structured fields specifying retention rules with explicit time bounds, derivation rights as enumerated allow-lists, propagation rules as a graph of permitted forward-flows, and a verification protocol that lets each party's agent check, before any action, whether the action conforms. This shape has affinity with policy-engine traditions, structured access-control languages, and declarative configuration formats; ACP v0.1 does not commit to a specific implementation but draws on these traditions for what computability requires. The companion document on cryptographic constructions (§13) addresses mechanism in more detail.

A compact is bilaterally retained. Each party retains a copy. The two copies share canonical content; what each party retains beyond the canonical content is governed by the compact's own terms. Neither party holds the authoritative copy; the agreement lives in the pairing.

A compact is revocable. The conditions under which the compact may be retired, the notice required, and the residual obligations that survive revocation are specified within the compact itself. A compact whose terms cannot be unwound under any condition is not a compact under this pattern; it is a perpetual undertaking.

These five properties — bilateral, bounded, machine-readable, bilaterally retained, revocable — together constitute the compact pattern. A document that has all five is a compact. A document that has fewer is something else: a declaration, a treaty, a contract, or a perpetual undertaking. The names matter because the legal and practical traditions surrounding each are different, and conflating them produces confusion about what protections each provides.

3.2 Why the pattern, for protocol designers

The compact pattern is the structural answer to a problem that arises whenever bounded interactions between agents need to carry forward obligations. The agents need to know, going into an interaction, what each side will do with what crosses between them. They need to know it in a form they can enforce. They need to be able to demonstrate to their principals afterward what was agreed. They need to be able to retire the agreement when the bounded interaction is over.

A protocol designer encountering this problem can solve it in many ways. The compact pattern is the solution that arises when the constraints are: (1) the agreement must survive the agents' loss of state; (2) neither party should hold the authoritative record; (3) the terms must be precise enough to enforce mechanically; (4) the agreement must be retire-able without requiring the parties to be present at retirement; (5) the agreement applies to a bounded set of interactions.

The first constraint forces durability. The second forces bilateral retention. The third forces machine-readability. The fourth forces specified revocation. The fifth forces explicit boundedness.

Different family members solve the same pattern under different boundary conditions. ACP applies it to context flowing between agents (this spec). RCP applies it to runtime hosting agreements between visiting agents and host runtimes. AAP applies it to what an agent demonstrates about itself to be a legitimate participant. EPP, when drafted, will apply it to the propagation relationships through which events flow across the mesh of compacts. Each family member has different terms, different signing requirements, and different lifecycle behavior. The shared pattern is what makes them recognizable as siblings.

3.3 The structural rationale

Each of the five properties is a response to a specific failure mode in how agreements have been structured historically. The companion essay The Contract Problem develops this argument in full; this section names the rationale briefly so that implementers reading only the spec understand why the properties are non-arbitrary.

Bilateral signing addresses the failure mode of unilateral terms — agreements drafted by one party and accepted-or-departed by the other. Unilateral terms drift toward whichever party drafts them; bilateral signing requires that both parties' agents commit to the agreement, which structurally constrains the drift.

Boundedness addresses the failure mode of perpetual catch-all agreements — terms that purport to govern all future interactions of any kind. Catch-all terms expand indefinitely beyond what either party originally understood; boundedness requires explicit scope, which keeps the agreement legible to both parties.

Machine-readability addresses the failure mode of agreements enforceable only by retrospective dispute. The volume and complexity of agent-mediated interactions cannot be reviewed by humans in real time. An agreement whose enforcement depends on lawsuits filed years later is not enforced in any meaningful sense; it is litigated. The compact pattern requires that enforcement happens at the moment of interaction, not at the moment of dispute.

Bilateral retention addresses the failure mode of one-party records. When one party holds the authoritative record and the other does not, disputes resolve to whichever party can demonstrate what was agreed — and the party without an authoritative record cannot. Bilateral retention restores parity in the record itself.

Revocability addresses the failure mode of perpetual obligations. Agreements whose terms cannot be unwound under any condition bind parties to obligations whose original justification has long since passed. Specified revocation keeps agreements live, subject to withdrawal when conditions change, with the conditions of withdrawal stated in advance.

These rationales are structural. They do not depend on the parties being well-intentioned, the terms being favorable, or the jurisdiction being friendly. They depend only on the properties being preserved by the protocol that implements them.

3.4 What the compact pattern does not promise

The compact pattern produces structured agreements; it does not produce wise agreements. Two parties may author a compact whose terms are unfavorable to one of them. The compact pattern's protections are structural — bilateral, bounded, retained, revocable — not substantive. The terms inside the compact's structure can be anything the parties agree to, and parties can agree to terms that disadvantage them.

The compact pattern does not solve the problem of asymmetric power between parties. A counterparty with significantly more leverage than the principal a user-agent represents may extract terms the user-agent cannot meaningfully refuse. The compact pattern makes the asymmetry explicit and structured; it does not remove it.

The compact pattern does not solve the problem of bad-faith agents. An agent that signs a compact and then violates its terms — fails to delete what it agreed to delete, retains what it agreed not to retain, propagates what it agreed not to propagate — is a bad-faith agent. The compact pattern's enforcement mechanisms (§12) address what a counterparty can do when bad faith is detected; they do not prevent bad faith from occurring. AAP, when drafted, will address what makes an agent a legitimate participant in the first place; until that spec exists, the wolf-in-agent's-clothing concern is named but not closed.

The compact pattern does not solve the problem of jurisdictional variation. A compact authored under one legal regime and disputed in another faces enforceability questions that are downstream of ACP and RCP. The protocol's structure is uniform; the legal weight of that structure is not.

These limitations are real. They are not failures of the pattern. The compact pattern is a structural proposal for what agreements between agents should look like, given the constraints of the agent era. Other problems — power asymmetry, bad faith, jurisdictional variation — require other instruments. The compact pattern does not pretend to be those instruments.

3.5 Multilateral interactions resolve into bilateral meshes

Real-world workflows are often multilateral. A homeowner's agent hires a general contractor's agent, who in turn brings in a plumber's agent and an electrician's agent. A patient's agent coordinates with a primary care agent, a specialist's agent, and an insurer's agent. A buyer's agent negotiates with a seller's agent and a logistics provider's agent. These interactions involve more than two parties; ACP must specify how the bilateral compact pattern applies.

ACP's answer is that multilateral interactions resolve into a mesh of strictly bilateral compacts. Each pair of parties whose agents need to exchange context authors its own bilateral compact governing what crosses that pair's boundary. The general contractor authors a bilateral compact with the homeowner; the general contractor authors a separate bilateral compact with the plumber; if the homeowner and plumber need to exchange context directly, they author a third bilateral compact between them. The mesh is the set of pairwise compacts; n-lateral compacts with three or more signing parties are not specified by ACP.

Implementations of multilateral workflows MUST decompose them into bilateral compacts. The decomposition is the architectural commitment. Whatever crosses between any two parties' agents is governed by that pair's compact; whatever crosses three or more parties' agents simultaneously is decomposed into the pairwise flows that compose it.

This commitment has a cost: the mesh produces redundancy when the same context flows across multiple boundaries. The general contractor relays the homeowner's scope of work to the plumber under a different compact than the one that governed the homeowner-to-contractor flow; the contractor's compact with the plumber specifies what the contractor may share with the plumber about the homeowner. Each crossing is governed by its own pair's terms. This is more verbose than n-lateral compacts would be, but it preserves clean signing semantics, clean retention semantics, and clean revocation semantics — properties that n-lateral compacts compromise.

The cost is acceptable because the alternatives are worse. N-lateral compacts produce design problems that compound: revocation by one party becomes ambiguous (does it retire the whole compact or just that party's participation?), retention asymmetry becomes intractable across many pairs of slices, signing requires consensus protocols that introduce coordination failures, and disputes resolve into multi-way disagreements about what was authored. Bilateral meshes sidestep these by keeping each agreement structurally simple.

Future protocol revisions may specify n-lateral compacts as a distinct artifact class with their own structural properties. ACP v0.1 does not. The bilateral mesh is the architecture; multilateral workflows are bilateral compacts in composition.

[§3 articulates the pattern shared across the compact family. v0.1 carries the articulation in ACP because ACP ships first; the articulation may consolidate elsewhere as the family matures.]

4. The structural novelty: asymmetric retention

The compact pattern's properties listed in §3.1 do not, by themselves, capture what is structurally novel about ACP's compact. Bilateral signing, boundedness, machine-readability, bilateral retention, and revocability are properties any well-designed agreement protocol would specify. They are necessary; they are not what makes ACP's compact specific to the problem ACP is solving.

The structural novelty is asymmetric retention. This section specifies what asymmetric retention is, why it is a feature rather than a failure mode, and why the pattern's other properties depend on it being correctly framed.

4.1 What asymmetric retention is

When two parties author a compact and each retains a copy, the two copies share canonical content (§3.1). The canonical content is what both parties agreed to: the compact's terms, the bounded scope, the signing attestations, the retention rules themselves. This is the part of the compact that must be identical across both parties' copies.

Beyond the canonical content, each party retains additional material that the compact's terms specify they may retain. This additional material is not the same on both sides. What the contractor's agent retains about the homeowner is not what the homeowner's user-agent retains about the contractor. The retention is asymmetric by design.

Specifically, asymmetric retention covers: what context entered the interaction (each party's pre-interaction knowledge of the other), what derivations each party performed during or after the interaction, what propagation rights each party has for the derived material, and what records each party retains about the work the interaction produced.

In a contractor-and-homeowner compact, the contractor's agent might retain: the scope of work agreed to, billing records, the property's relevant access details, materials used, time logs, and warranty information. The homeowner's user-agent might retain: the scope of work agreed to, payments made, the contractor's identity and credentials, the work record, and any disputes raised. Both parties retain the scope-of-work and the work-record because both need them; each party retains material specific to its role that the other does not.

The compact's terms specify exactly what falls into each retention slice. The retention is not arbitrary asymmetry; it is structured asymmetry, contractually agreed to in advance, with the structure recorded in the compact's canonical content so that both parties have an authoritative reference for what each side retained.

4.2 Why asymmetric retention is a feature, not a failure mode

The first reading of asymmetric retention by readers familiar with mutual-consent frameworks is often skeptical: if the parties agreed mutually, why should retention be asymmetric? Doesn't symmetric retention better embody the mutual-consent principle? This section addresses that reading directly.

Symmetric retention would require both parties to retain identical material about each other. In practice, this means either: (a) both parties retain everything either party generated, or (b) both parties retain only the material both agreed to retain identically. Both options fail.

Option (a) — both parties retain everything — produces over-retention by both parties. The contractor's agent retains the homeowner's full property details even when the contractor's role does not require them. The homeowner's user-agent retains the contractor's internal work logs even when the homeowner's role does not require them. Mutual over-retention is not mutual protection; it is mutual exposure. Each party holds material about the other that exceeds what their role warrants, which means each party holds material that becomes a liability if either party's systems are compromised. Symmetric over-retention multiplies the attack surface that any compromise produces.

Option (b) — both parties retain only the intersection of what they agreed to retain identically — produces under-retention by both parties. The contractor cannot retain the work logs they need for accounts because the homeowner does not need to retain those work logs. The homeowner cannot retain payment records because the contractor does not need to retain payment records in the same form. Symmetric under-retention means neither party has the records their role requires. The interaction's documentation falls below the threshold of usefulness for either party.

Asymmetric retention solves the problem that neither symmetric option can. Each party retains what their role requires. Neither party retains material about the other that exceeds what their role warrants. The retention is mutually agreed to in advance; the asymmetry is the structure that lets mutual agreement produce role-appropriate retention rather than role-misaligned retention.

The mutual-consent reading is preserved at the level of what matters: both parties have agreed to the asymmetric structure, and both parties have an authoritative record of what each side retained. What is not preserved — and should not be preserved — is the assumption that mutual consent requires symmetric outcomes. Mutual consent in ACP's framing means both parties agreed to terms that produce role-appropriate retention, with the asymmetry made explicit and structured. That is a stronger form of mutual consent than the symmetric framings would produce, because it accounts for the substantive asymmetry of the parties' actual roles.

4.3 Why the pattern's other properties depend on this framing

The five properties in §3.1 — bilateral, bounded, machine-readable, bilaterally retained, revocable — only do their work if asymmetric retention is correctly framed. Each property's value derives from the structural novelty rather than standing independent of it.

Bilateral signing matters because the parties are signing terms that include retention asymmetry. If retention were symmetric or unspecified, bilateral signing would attest to less. The signature commits each party to specific retention rules, asymmetric across the parties, and that specificity is what bilateral signing actually attests to.

Boundedness matters because the bounded scope determines which retention asymmetry applies. Outside the bounded interaction, the asymmetry does not bind; inside it, the asymmetry is precise. Without boundedness, asymmetric retention would either expand indefinitely or remain ambiguous; with boundedness, it is contained and legible.

Machine-readability matters because asymmetric retention is enforced by each party's agent acting on its own copy of the compact. The agents check, programmatically, what they may retain and what they may not. Without machine-readability, asymmetric retention would depend on human interpretation of natural-language terms, which is the failure mode the protocol is replacing.

Bilateral retention matters because each party retains its own slice under the compact's asymmetric rules. The pairing — both parties holding compatible but distinct retention — is what bilateral retention produces. Without asymmetric retention as the explicit structure, bilateral retention would either collapse into one-party authoritative records or fail to specify what each party should hold.

Revocability matters because revocation must specify what each party does with what each party retained. The asymmetric retention is what revocation acts on. A party revoking the compact triggers the disposition rules the compact specified in advance for that party's retention slice — which may include immediate deletion of some material, retention for specified durations of other material, and indefinite retention under different terms of still other material. Without asymmetric retention as the explicit structure, revocation would either over-act (purporting to delete material the revoking party never had rights over) or under-act (leaving the structure of the asymmetric record intact even after retirement).

In each case, the property's protective work depends on asymmetric retention being correctly framed. The properties are not five independent guarantees layered together; they are a system whose coherence comes from the structural novelty at the center.

4.4 Revocation acts through pre-negotiated dispositions

Revocation does not mean immediate total deletion. The compact's asymmetric retention establishes that each party retains material specific to its role; some of that material has obligations attached that a revocation cannot dissolve. A contractor's billing records may be subject to retention requirements by tax authorities; a healthcare provider's record of services rendered may be subject to retention requirements by regulators; a service-provider's record of work performed may be necessary to defend against future claims. Revocation that purported to delete this material would put parties in violation of obligations the protocol cannot override.

ACP's compact specifies, in advance, what happens to each retention slice when revocation is triggered. The disposition is part of the compact's canonical content, agreed to bilaterally at authoring time, structured so that each party's agent can enforce it programmatically when revocation occurs.

Disposition rules cover, for each retention slice:

• What is deleted immediately on revocation (typically: active access credentials, in-flight context, ephemeral working state).
• What is retained for a specified period after revocation (typically: records the retaining party needs for accounts, compliance, or defense, with the period bounded by the obligations driving retention).
• What transitions to different retention terms after revocation (typically: material that continues to be needed but under more restricted use rights — for instance, retained for compliance reference but no longer permitted to be derived from or propagated).
• What is retained indefinitely (typically: minimum records required by law or regulation that cannot be unwound by mutual agreement).

The dispositions are negotiated when the compact is authored and signed bilaterally. Both parties commit, in advance, to what each will do with each retention slice when revocation triggers. The compact's revocation is not a unilateral act of demanding deletion; it is the activation of pre-agreed disposition rules that both parties have committed to.

This framing resolves what would otherwise be a contradiction between asymmetric retention and revocability. Asymmetric retention establishes that parties retain different things for different reasons; revocation acts on those retention slices through dispositions that respect the reasons. Neither property compromises the other; they compose because revocation was specified, from the start, as triggering pre-negotiated dispositions rather than as demanding immediate deletion.

The mechanics of disposition rules — their structure, their default forms, the standard library entries that specify common dispositions — are specified in §6 (compact dimensions). What §4 commits to is that revocation, in ACP's compact, never means "immediately delete everything" and always means "trigger the dispositions the parties agreed to in advance."

4.5 What this means for implementers

Implementations of ACP MUST treat asymmetric retention as the load-bearing property of the compact. This means:

• The compact's canonical content MUST specify, explicitly, what each party retains. Implicit or default retention rules are not sufficient; the compact records the asymmetric structure that both parties signed.
• Each party's agent MUST be able to determine, from its copy of the compact, what that party may retain, derive, and propagate. The compact is the agent's reference for what its retention rights are.
• The compact MUST NOT be interpreted as imposing symmetric retention by default. An implementation that produces symmetric retention because it failed to specify asymmetric terms has produced a compact whose protective claims are weaker than the protocol intends.
• When a compact is revoked, each party's disposition of retained material MUST act according to the compact's pre-negotiated disposition rules (§4.4). Revocation does not cross the asymmetry; it acts within it through the dispositions both parties committed to in advance.

These requirements are normative. The structural novelty is what makes ACP's compact specific to the problem ACP solves; implementations that flatten the asymmetry have not implemented ACP's compact.

[§4 names asymmetric retention as the load-bearing property of ACP's compact and defends the framing against the mutual-consent reading. Subsequent sections — §5 (compact primitive), §6 (dimensions), §9 (standard library) — specify the mechanics that make asymmetric retention operable.]

5. The compact primitive

This section specifies what a compact is as an artifact: its required fields, its structure, its signing semantics, and its lifecycle. §3 articulated the pattern; §4 named the structural novelty; §5 specifies the operational form.

5.1 The compact as artifact

A compact is a durable artifact that exists independently of the session that authored it and the agents that signed it. Once committed, the compact persists under its own lifecycle rules until it expires or is revoked. The compact is not session-scoped (SSP §3.4); it survives the session in which it was authored and continues to govern the parties' obligations across many subsequent interactions.

Each party retains a copy of the compact. The two copies share canonical content (§3.1, §4.1); each party's copy may also contain that party's retention slice as governed by the compact's terms. The pairing is what makes the compact a compact; without bilateral retention, the artifact is something else.

A compact MAY be rendered through SSP surfaces during authoring and review. The session that hosts the authoring is governed by SSP and runs on a runtime governed by RCP. The compact itself, as an artifact, is governed by ACP.

5.2 Required fields

Every compact MUST contain the following fields. Implementations MAY extend with additional fields for specific use cases; the listed fields are the minimum.

5.2.1 Identification

• Compact identifier. A globally unique identifier for this compact. Stable across the compact's lifetime; survives versioning.
• Version identifier. A version number or hash. Each material change to the compact's terms produces a new version (§5.5).
• Predecessor reference. If this version supersedes a prior version, the predecessor's version identifier. Null for initial versions.

5.2.2 Parties

• Party A identity. The cryptographic identity of the first party's agent. The form of identity is deferred to AAP; ACP requires that whatever form AAP specifies is recorded here.
• Party A principal. Identification of the principal that party A's agent represents. May be a human, an organization, or another entity recognized by AAP.
• Party A principal authorization. Verifiable proof that party A's principal authorized the specific terms in this compact's canonical content — not merely that the agent had general authority to sign on the principal's behalf, but that the principal authorized the asymmetric retention structure, the propagation rights, the disposition rules, and the bounded scope as they appear in this compact. The form of this proof is deferred to AAP; ACP requires that whatever form AAP specifies be recorded here.
• Party B identity. Same as party A, for the second party.
• Party B principal. Same as party A, for the second party.
• Party B principal authorization. Same as party A's principal authorization, for the second party.

ACP is bilateral; compacts have exactly two parties. Multilateral workflows resolve into bilateral meshes (§3.5).

The principal-authorization requirement is normative. Without it, bilateral signing by agents tells counterparties only that agents had general authority to sign, not that principals authorized the specific terms being signed. The asymmetric retention structure can only protect principals from terms they did not authorize if the protocol requires verifiable proof that they did authorize the terms in question. AAP, when drafted, specifies the mechanism; ACP specifies that the requirement exists.

5.2.3 Bounded scope

The compact's bounded scope establishes what the compact governs. ACP takes a default-deny stance: any interaction, context, or data not explicitly permitted within the bounded scope and the retention dimensions (§5.2.4) is strictly out of scope. The compact does not govern omissions by implication; the boundary is established by what the compact says, not by what it does not say.

This stance is normative. Implementations MUST treat unspecified interactions as outside the compact's authority. An implementation that interprets unspecified interactions as implicitly permitted has produced a compact whose protective claims are weaker than the protocol intends.

• Interaction scope. What interactions this compact governs. May be a specific bounded interaction (one transaction, one project, one consultation) or a class of interactions over a defined period (all interactions of type X between these parties for the next N months). Whatever falls outside the specified scope is not governed by this compact.
• Effective period. The time bounds during which this compact is in force. Includes start time and either an end time or a condition for expiration.
• Out-of-scope clarification. Optional. Used solely to resolve edge-case ambiguity about what falls within the specified scope, not to establish the boundary itself. The boundary is established by what the compact specifies as in-scope; this field exists only to make explicit what would otherwise be ambiguous, never to expand or constrain the boundary by implication.

5.2.4 Retention dimensions

The retention dimensions specify what each party retains. They are asymmetric by design (§4); each party's retention slice is specified separately.

• Party A retention. What party A retains: the categories of material, the retention duration during the compact's effective period, the derivation rights (what party A may compute from retained material), the propagation rights (what party A may share with third parties), and the disposition rules that apply on revocation or expiration (§4.4).
• Party B retention. Same as party A, for the second party.

Retention dimensions reference standard library entries where applicable (§9). For domain-specific dimensions outside the standard library, the compact specifies the dimension's structure inline.

5.2.5 Revocation terms

• Revocation conditions. The conditions under which either party may revoke. May be unilateral (either party may revoke at any time with notice), conditional (revocation permitted only on specified events), or mutual (revocation requires both parties' consent).
• Notice period. The notice required before revocation takes effect. May be zero (immediate) or a specified duration.
• Disposition rules. What each party does with each retention slice when revocation is triggered. Specified separately for each party, consistent with the asymmetric retention structure (§4.4).
• Residual obligations. Obligations that survive revocation. Typically: minimum legal retention requirements, indemnification clauses, dispute-resolution provisions for matters arising before revocation.

5.2.6 Signing

• Party A signature. Party A's agent's cryptographic signature attesting to the compact's canonical content. The signature mechanism is deferred to the cryptographic constructions companion document (§13); ACP requires that whatever mechanism is used produces a signature both parties can verify.
• Party A signing timestamp. Informational. Records when party A signed according to party A's local clock. Not a load-bearing protocol artifact; signing order is established cryptographically (§5.4), not by comparing local timestamps.
• Party B signature. Same as party A, for the second party. Cryptographically incorporates party A's signature as input, establishing that party B signed after party A.
• Party B signing timestamp. Informational. Records when party B signed according to party B's local clock. Not a load-bearing protocol artifact.
• In-force timestamp. Authoritative. Records the moment the compact transitioned to in-force status, provided by the runtime hosting the second signature event. The runtime's authoritative clock — governed by RCP — establishes when the compact became binding for both parties.

Both signatures MUST be present for the compact to be in force. A compact with only one signature is a proposed compact (§8); it does not bind either party until both signatures are recorded and the in-force timestamp is established.

5.3 Canonical content

Canonical content is the part of the compact that both parties' copies must depict identically (§3.1, §4.1). The canonical content includes:

• All identification fields (§5.2.1).
• All parties fields (§5.2.2).
• All bounded scope fields (§5.2.3).
• All retention dimensions for both parties (§5.2.4).
• All revocation terms for both parties (§5.2.5).
• Both parties' signatures and signing timestamps (§5.2.6).

Beyond the canonical content, each party's copy may contain that party's retention slice as governed by the compact's retention dimensions. The retention slice is not canonical content; it is the party-specific material the compact authorizes that party to retain. The retention slices are asymmetric by design and are not expected to match across the two parties' copies.

The integrity attestation specified in SSP §12.5 establishes pairing across the two parties' copies of the canonical content. Implementations MUST produce paired copies whose canonical content is identical and verifiable against the bilateral signatures.

5.4 Signing semantics

A compact requires both parties' signatures to be in force. Until both signatures are recorded, the compact is a proposed compact: an artifact with one party's commitment but not yet the other's, not yet binding either party.

Signatures attest to the canonical content as it existed at the moment of signing. If the canonical content changes after one party signs, that party's signature is no longer valid for the new content; the modified compact is a new proposal that requires a new signature from each party. There is no partial signing of modified content; signatures are atomic with respect to the canonical content they attest to.

Signing order is established cryptographically, not by local timestamps. The second party's signature cryptographically incorporates the first party's signature as input, producing a chain in which Party B's signature is verifiable only against the canonical content plus Party A's signature. This makes signing order unambiguous regardless of clock skew or network latency: an implementation can verify, from the signature structure alone, that Party A signed before Party B. Local-clock timestamps (§5.2.6) are informational and may be used for human-readable logs, but the protocol's authoritative ordering comes from the cryptographic chain.

Signing requires that each party's agent be authenticated and authorized to sign on the principal's behalf. The mechanics of authentication and authorization are deferred to AAP. ACP requires that signatures be cryptographically verifiable and non-repudiable; implementations that produce signatures lacking these properties have not produced compacts under ACP.

A compact's signatures are the basis for enforcement (§12). When one party alleges that the other has violated the compact's terms, the signed compact is the authoritative reference for what the parties agreed to. Without verifiable signatures, ACP's enforcement claims cannot operate.

5.5 Versioning

Compacts are versioned. Material changes to a compact's terms produce a new version with a new version identifier and a recorded predecessor reference. Versions are immutable: once both parties have signed a version, that version's canonical content does not change. Subsequent changes produce subsequent versions; they do not mutate the prior version.

New versions require fresh bilateral signatures. A new version is, structurally, a new proposed compact whose predecessor reference identifies what it is replacing. Both parties' agents sign the new version; the prior version remains in the historical record but is no longer the in-force compact.

Material changes include: changes to bounded scope, changes to retention dimensions, changes to revocation terms, addition or removal of parties (the latter being a special case where the compact is retired and a new compact authored). Non-material changes — corrections of typographical errors in human-readable annotations, updates to non-canonical metadata — do not require new versions but also do not bind unless they are recorded as new versions.

Implementations MUST distinguish material from non-material changes and MUST require fresh bilateral signing for any material change. Ambiguity about whether a change is material is resolved in favor of treating the change as material; an implementation that errs toward treating changes as non-material has weakened the compact's binding force.

5.6 Lifecycle

A compact's lifecycle has the following phases:

• Proposed. One party's agent has authored the compact and signed; the other party's agent has not yet signed. The compact is not yet in force.
• In force. Both parties have signed. The compact governs the parties' obligations within its bounded scope.
• Expired. The compact's effective period has ended. The compact is no longer in force for new interactions; residual obligations and disposition rules continue to apply.
• Revoked. One or both parties have triggered revocation under the compact's revocation terms. The compact is no longer in force; pre-negotiated dispositions (§4.4) determine what each party does with retained material; residual obligations continue to apply.
• Superseded. A new version of the compact has been authored and signed by both parties. The prior version is no longer in force; the new version governs the parties' obligations from the moment of supersession forward.

The compact's status — which lifecycle phase it is in — is determined by the compact's records. A compact that has been signed by both parties and is within its effective period is in force. A compact that has reached its end-of-effective-period is expired. A compact that has been revoked records the revocation event in the compact's lifecycle history.

Implementations MUST maintain the compact's lifecycle history accurately. The history records when each phase began and what triggered the transition. The history is part of the canonical content's extension; it is not the canonical content itself (which is immutable per §5.5) but is appended to over the compact's lifetime.

5.7 Lifecycle synchronization across the bilateral boundary

Because a compact is bilaterally retained, lifecycle state changes — revocation, supersession, and other phase transitions — happen on one party's side first and must propagate to the counterparty. ACP specifies how this propagation is constrained so that the two copies do not diverge into split-brain state, where one party considers the compact revoked and the other considers it in force.

Lifecycle state changes have three states:

• Initiated. One party has triggered a lifecycle event (a revocation, a proposed supersession). The event is recorded on that party's side. The compact's lifecycle phase has not yet changed for either party.
• Acknowledged. The counterparty has received cryptographic proof of the event and recorded acknowledgment. Acknowledgment is itself a signed event, attestable to both parties.
• Active. Both parties have recorded the acknowledgment, and the lifecycle phase has transitioned. The compact is now in its new phase from both parties' perspective.

The transition from initiated to active requires acknowledgment receipt. During the gap between initiated and active, the compact remains in its prior phase for both parties. A revocation that has been initiated but not acknowledged is not yet active; the compact remains in force during the gap. This rule prevents the failure mode where one party acts as if the compact were revoked while the counterparty acts as if it were still in force.

The gap creates an exploit window unless further constrained. A bad-faith counterparty could strategically delay acknowledgment — by deliberate inaction, by network partition, or by feigned outage — and use the gap to extract derivations from material the lifecycle event would have disposed of. ACP closes this window normatively: when a lifecycle event has been initiated by one party but not yet acknowledged by the counterparty, the counterparty MUST suspend any operations on the retention slice that would be affected by the lifecycle event. Specifically, no new derivations, no new propagations, and no new retentions in categories the lifecycle event would affect may be performed by the counterparty during the gap. Continued reading of already-retained material and completion of in-flight reads are permitted; new actions that derive value from the affected retention slice are not.

This rule means the timeout-and-escalation provision does not function as an exploit window. The unacknowledging party gains no benefit from delaying acknowledgment because their operational rights over the affected retention slice are suspended for the duration of the gap. Acknowledgment is the only path to either confirming the lifecycle event or, in narrow cases, contesting it through reconciliation; delay is structurally without advantage.

Implementations MUST NOT treat lifecycle state changes as active until acknowledgment is recorded. Where ambiguity exists about which state is current — for instance, during network partition or runtime failure — implementations MUST resolve in favor of the prior phase. This is consistent with the §5.5 tiebreaker pattern: the compact's binding force is preserved at the cost of slower lifecycle transitions.

The mechanism by which lifecycle events propagate within a single bilateral compact — between the two parties to that compact — is the runtime's responsibility, governed by RCP. The mechanism by which lifecycle events propagate to other compacts that depend on this one — for instance, when a compact's revocation affects downstream compacts in a mesh (§3.5) — is governed by EPP, deferred. ACP specifies the bilateral lifecycle requirement; RCP specifies the bilateral propagation; EPP, when drafted, will specify mesh-wide propagation. RCP MUST provide a cross-boundary delivery proof mechanism that satisfies the bilateral requirement; without it, ACP's bilateral lifecycle guarantees cannot operate. EPP's absence in this release means that mesh coherence — ensuring related compacts respond consistently to events that affect them — is, for v0.1 implementations, the application's responsibility. This is a known limitation of the current release.

Where the runtime cannot deliver an acknowledgment in a reasonable time — where the counterparty's runtime is offline, partitioned, or terminated — ACP specifies a timeout-and-escalation behavior. Implementations MAY define a maximum acknowledgment-wait period after which an initiated event is treated as activated unilaterally, with the counterparty's failure to acknowledge recorded as a protocol-level event. The maximum period and the escalation behavior are properties of the compact itself (specified in revocation terms, §5.2.5) and are bilaterally agreed at signing time. Without this provision, lifecycle state changes could be blocked indefinitely by an unresponsive counterparty.

[§5 specifies the compact as artifact: required fields, canonical content, signing, versioning, lifecycle, and bilateral lifecycle synchronization. §6 will specify the dimensions of the compact in detail; §7 will specify compact tiers; §8 will specify the two-phase negotiation protocol that produces signed compacts.]

6. Compact dimensions

This section specifies the structural dimensions of a compact's terms. Each dimension is a category of property the compact specifies for each party; the dimensions together constitute the asymmetric retention structure (§4) that the compact records. §5.2.4 introduced retention dimensions as a required field; §6 specifies what those dimensions are and what each governs.

All dimensions inherit the default-deny stance specified in §5.2.3. For each dimension, anything not explicitly permitted is implicitly forbidden. Implementations MUST NOT interpret silence as permission; the compact's terms specify what each party may do, and what they may not do is everything else.

6.1 The four core dimensions

ACP specifies four core dimensions that every compact MUST address for each party. Compacts MAY specify additional dimensions for domain-specific use cases (§9), but the four core dimensions are the minimum: every party's retention slice is defined along each of them.

• Retention. What material the party may retain after the interaction. Specified as a set of categories; each category names a class of material (e.g., "work records," "billing information," "access credentials") and the category's retention duration.
• Derivation. What the party may compute from retained material. Specified as an enumerated allow-list of derivation operations the party may perform; operations not in the allow-list are forbidden.
• Propagation. What the party may share with third parties, and under what conditions. Specified as a graph of permitted forward-flows: which third parties may receive which categories of material, under which compact terms governing the third-party relationship.
• Disposition. What happens to retained material when the compact is revoked or expires. Specified per category and per lifecycle event, consistent with §4.4.

6.2 Retention

The retention dimension specifies what each party retains from the interaction. Retention is asymmetric (§4); each party's retention slice is specified separately.

A retention specification names the categories of material the party may retain and, for each category, the duration of retention. Categories are domain-specific; the standard library (§9) provides common categories for the contractor-and-service domain in v0.1 (work records, billing information, access credentials, materials and labor logs, warranty information, dispute records). Compacts in other domains either reference standard library entries when those are added in future versions or specify their categories inline.

Retention duration is specified for each category. Common forms include: a fixed period from the compact's effective period end ("retained for seven years after compact expiration"); an open-ended period bounded only by other constraints ("retained for the duration of any active legal proceeding"); a conditional period that ends when a specified event occurs ("retained until the warranty period ends").

A category not named in the retention specification is implicitly forbidden under the default-deny stance. An implementation that retains material in a category the compact does not specify has violated the compact, regardless of whether the material is similar to a category the compact does specify.

6.3 Derivation

The derivation dimension specifies what the party may compute, infer, or generate from retained material. Derivation rights are operational: they govern what the party's agent may produce as outputs from the inputs the retention rights granted.

A derivation specification is an enumerated allow-list. Each entry in the list names an operation the party may perform on retained material — for example, "compute aggregate statistics from billing records," "generate summaries of work performed," "identify patterns across multiple compacts of the same domain." Operations not in the allow-list are forbidden.

Derivation rights compose with retention rights in a specific way: a party may derive only from material the party is permitted to retain. A derivation operation that would require access to material outside the party's retention slice is forbidden, even if the derivation operation itself is in the allow-list. The retention slice is the universe over which derivation operates; derivation cannot reach beyond it.

Derivation rights also compose with propagation rights: a derived output may be shared with third parties only if the propagation specification (§6.4) permits the propagation of either the derived output or the derived material's category. Propagation is not implied by derivation; producing a derived output does not, by itself, grant the right to share it.

Derivation rights specify the operation, not the output. A party that performs a permitted derivation operation produces an output; what the party may do with the output is governed by the retention, propagation, and disposition rules that apply to the output's category. The standard library (§9) specifies how derived outputs are categorized for retention purposes.

Derivation has a specific definitional boundary that ACP makes explicit because the boundary is contestable. Derivation is any operation that produces material the agent can later access — whether that material is in durable memory, in working context, in a knowledge graph, in a retrieval cache, or in updated model weights — for a duration extending beyond the current interaction. The line is not the storage medium; the line is durability across interaction boundaries.

This means an agent computing on retained material to produce outputs within the current interaction is using its retention rights, not deriving. An agent that updates weights, caches context, or persists state in any form that influences subsequent interactions is deriving — and that derivation is governed by the allow-list rules of the retention category from which the influence was derived.

The implementation consequence is consequential. Agents that use techniques like fine-tuning, retrieval-augmented generation cache updates, persistent context windows, or knowledge graph maintenance MUST treat those updates as derivation operations subject to allow-list permission. An agent that updates its weights or its working state in ways that persist across interactions, based on retained material, has performed a derivation operation. If that operation is not in the allow-list for the source category, the agent has violated the compact, regardless of whether any traditional memory write occurred.

This boundary is normative because the alternative produces a structural loophole. An interpretation in which only durable memory writes count as derivation would allow agents to accumulate compact-governed influence inside their working state in ways that effectively retain it across interactions while formally complying with retention restrictions. The asymmetric retention structure can only protect parties from accumulation of influence beyond compact terms if the protocol counts all forms of persistent influence — not only the storage media that look like traditional databases.

6.4 Propagation

The propagation dimension specifies what each party may share with third parties — entities not party to the compact — and under what conditions.

A propagation specification is a graph. Each node in the graph is a third-party class — "the party's tax authority," "the party's professional association," "any party with whom the party has signed a compact of class X," "the public." Each edge is a permitted flow from a category of retained material to a third-party class. Edges may be conditional: the flow is permitted only when specified conditions are met.

Propagation rights inherit the default-deny stance unconditionally. A flow not in the propagation specification is forbidden. An implementation that propagates retained material to a third party not named in the propagation specification has violated the compact, regardless of whether the propagation seems reasonable, common, or obviously beneficial. The compact specifies what propagation is permitted; everything else is forbidden.

Propagation rights have a specific structural property: when material is propagated to a third party, the third-party relationship MUST itself be governed by a compact (the bilateral mesh requirement, §3.5). A party with permitted propagation rights cannot share material with a third party in the absence of a third-party compact governing what that third party will do with the propagated material. This requirement prevents propagation from being a mechanism by which compact-governed material escapes into ungoverned downstream relationships.

The mesh requirement means that, in practice, propagation specifications often reference compact classes ("may propagate to any third party with whom the party has signed a compact specifying retention category X with disposition Y") rather than naming specific third parties. The compact class is the structural condition; whether a specific third party qualifies depends on the compact that governs the party's relationship with that third party.

There is a gap in the propagation mesh that ACP v0.1 names but does not close. The propagation specification binds the party that propagates: that party must establish a downstream compact with the third party, and the downstream compact's terms must conform to the propagation specification's structural conditions. But ACP v0.1 does not specify a mechanism by which the original party — the one whose material is being propagated — can verify that the downstream compact actually exists and actually conforms. Bad-faith propagation is therefore detectable only retrospectively, through reconciliation processes that ACP defers.

The verification mechanism for downstream compact terms is governed by EPP. EPP, when drafted, will specify how compact-existence and compact-terms attestations propagate across the mesh, allowing the original party to verify that downstream relationships meet the propagation specification's conditions before propagation occurs. Until EPP is drafted, propagation specifications are normative and binding on the propagating party, but the original party's ability to detect violations is partial. Implementations should consider this when authoring compacts whose protective claims depend heavily on propagation enforcement; for high-stakes propagation rights, parties may choose to constrain propagation more tightly than they otherwise would, given the verification gap.

6.5 Disposition

The disposition dimension specifies what each party does with retained material when the compact is revoked, expires, or is superseded. Disposition is the operational form of revocation (§4.4) and is specified per category.

A disposition specification names, for each retention category and each lifecycle event that may affect retention, what the party's agent does with the retained material in that category. The four common disposition behaviors are:

• Immediate deletion. The party deletes all retained material in the category at the moment the lifecycle event triggers. Typically applied to active access credentials, ephemeral working state, and material whose continued retention would actively harm the counterparty.
• Bounded retention. The party retains the material in the category for a specified period after the lifecycle event, then deletes. Typically applied to records the retaining party needs for accounts, compliance, or defense, with the period bounded by the obligations driving retention.
• Transitioned retention. The material continues to be retained but under different terms — typically more restrictive than the in-force compact's terms. Typical transitions: derivation rights are removed, propagation rights are removed, retention duration is shortened to a specified terminal period.
• Indefinite retention. The material is retained indefinitely under the same or different terms, typically because legal or regulatory obligations require it. Indefinite retention is the only disposition behavior that does not have a specified end.

Each retention category MUST have a disposition specified for each of the lifecycle events that may affect it (revocation, expiration, supersession). A category whose disposition is unspecified for a lifecycle event has violated the default-deny stance: the compact has not specified what happens, so the implementation has no authoritative behavior to follow. ACP requires that compacts specify disposition completely; ambiguity is resolved at authoring time, not at lifecycle-event time.

The disposition specification is part of the compact's canonical content (§5.3). Both parties' copies of the compact contain the same disposition rules for both parties' retention categories, even though the categories themselves are asymmetric. This is because the disposition specification is what each party agreed the other would do; both parties need an authoritative reference for each other's disposition obligations.

Dependent compacts in known meshes have an additional structural requirement. When a compact's existence is conditional on another compact being in force — when the contractor's compact with the plumber depends on the contractor's compact with the homeowner, when an insurance claim's evaluation compact depends on the underlying policy compact, when a sub-contractor's authorization compact depends on the prime contractor's master compact — the dependent compact MUST reference the upstream compact's identifier as a lifecycle trigger. Specifically, the dependent compact's disposition specification MUST name the upstream compact's revocation or expiration as a trigger event for the disposition of the affected categories in the dependent compact.

This requirement is the v0.1 mechanism for mesh coherence in the absence of EPP. Without an event-propagation layer that automatically propagates upstream lifecycle changes to dependent compacts, the dependent compacts must be self-describing about their upstream dependencies. A dependent compact that does not name its upstream dependency cannot respond to upstream events at the protocol level; mesh coherence becomes the application's responsibility, with all the failure modes that exporting protocol responsibility to applications produces.

When EPP is drafted, the explicit-reference mechanism becomes the foundation EPP propagates events along. The mesh becomes self-describing: each dependent compact names its upstream dependencies, and EPP propagates upstream lifecycle events to dependent compacts according to those references. The v0.1 requirement is structurally weaker than EPP would provide — it requires manual referencing rather than automated discovery — but stronger than nothing, and it produces a clean migration path.

Implementations of compacts in known mesh contexts MUST author dependent compacts with explicit upstream references. An implementation that authors dependent compacts without upstream references has produced a mesh in which lifecycle events do not propagate at the protocol level, and the protective claims of the mesh structure are weaker than the protocol intends.

6.6 Composition across dimensions

The four dimensions compose. A complete retention slice for a party specifies, for each retention category, the retention duration; the derivation operations the party may perform on material in the category; the propagation rights for material in the category; and the disposition behavior for each lifecycle event affecting the category.

Composition has a specific structural property: each dimension constrains the others. Retention is the universe; derivation operates within retention; propagation may carry retained or derived material outward but only along permitted edges; disposition acts on what was retained when lifecycle events affect the category. An action that violates any dimension violates the compact, regardless of whether the action would have been permitted under the others. The protection is intersectional: a party may act only when every applicable dimension permits the action.

Composition also produces a verification property useful for enforcement (§12). When one party alleges that the other has violated the compact, the alleged violation is checked against each dimension that would govern the disputed action. Either the action was permitted under all applicable dimensions (no violation) or it was not (violation along the failing dimension). The compact's dimensions provide the structure within which violation claims are evaluated.

6.7 Domain-specific dimensions

ACP specifies the four core dimensions as the minimum. Compacts in specific domains may require additional dimensions to address domain-specific concerns. A medical compact may need a dimension for chain-of-custody for clinical records. A financial compact may need a dimension for audit trail attestation. A legal compact may need a dimension for privilege preservation.

Domain-specific dimensions are specified inline in the compact or, where the standard library has been extended to cover the domain, by reference to standard library entries. v0.1's standard library covers the contractor-and-service domain (§9); domain-specific dimensions for that domain are specified in §9. Other domains will be addressed in future revisions of the standard library.

Implementations of compacts in domains not yet covered by the standard library MUST specify all dimensions inline, including domain-specific dimensions appropriate to the use case. Inline specification is acceptable for v0.1; the standard library exists to reduce duplicated specification across compacts in the same domain, not to constrain what compacts may specify.

[§6 specifies the four core compact dimensions: retention, derivation, propagation, disposition. §7 will specify compact tiers (the predefined complexity levels that compacts may instantiate). §8 will specify the two-phase negotiation protocol that produces signed compacts.]

7. Compact tiers

Compacts vary in complexity. A homeowner authorizing a single contractor visit needs less elaborate terms than a healthcare provider authorizing a year-long treatment plan with multiple specialists. ACP specifies tiers — predefined complexity levels — that compacts may instantiate, reducing the friction of authoring common configurations from scratch while preserving the ability to author bespoke compacts when standard configurations do not fit.

7.1 The three tiers

ACP v0.1 specifies three tiers. Each tier is a complete compact configuration with all four core dimensions (§6) populated according to predefined defaults. Tiers are not constraints on what compacts may specify; they are starting points that parties may instantiate directly or extend.

7.1.1 Minimal tier

The minimal tier specifies a compact for single bounded interactions with no propagation, no derivation rights beyond the immediate interaction, short retention durations, and immediate-deletion dispositions for most categories. Typical use: one-off transactions, single consultations, brief service interactions.

Minimal tier compacts have the following defaults:

• Retention. Limited to the categories required for the interaction itself; durations measured in days to weeks, not years.
• Derivation. Allow-list contains only operations required to complete the bounded interaction.
• Propagation. Empty allow-list. No third-party propagation permitted.
• Disposition. Immediate deletion on revocation, expiration, or supersession for all categories except those required by legal retention obligations.

Minimal tier compacts are the v0.1 default for ad-hoc interactions where parties have no established relationship and no anticipated future interactions. They are also appropriate for interactions where the parties want maximum protection at the cost of operational flexibility.

7.1.2 Standard tier

The standard tier specifies a compact for bounded ongoing relationships with limited propagation, derivation rights appropriate to the relationship's purpose, retention durations matched to the relationship's expected duration plus reasonable post-relationship retention, and tiered dispositions on lifecycle events. Typical use: contractor-and-homeowner relationships, professional service engagements, recurring commercial relationships.

Standard tier compacts have the following defaults:

• Retention. Categories appropriate to the relationship's purpose; durations measured in months to years, with terminal retention bounded by legal and operational requirements.
• Derivation. Allow-list contains operations required for the relationship to function plus aggregation operations on each party's own retention slice. Cross-party derivation operations are allow-listed individually if at all.
• Propagation. Limited allow-list naming specific third-party classes (the party's accountant, the party's professional regulator) with conditional flows — typically requiring that the third-party relationship itself be governed by a compact of standard or advanced tier.
• Disposition. Immediate deletion of active credentials and ephemeral state on revocation; bounded retention of records required for accounts, compliance, and defense; transitioned retention for material whose continued retention is appropriate but under more restrictive terms.

Standard tier compacts are the v0.1 default for most contractor-and-service domain interactions. The standard library (§9) populates standard tier defaults for the contractor-and-homeowner case and provides domain-specific extensions for related cases.

7.1.3 Advanced tier

The advanced tier specifies a compact for sustained, complex, multi-party relationships with explicit propagation across known meshes, derivation rights including aggregation and pattern recognition, retention durations measured against domain-specific obligations, and disposition rules that handle complex lifecycle scenarios including supersession of related compacts in the mesh.

Advanced tier compacts have the following defaults:

• Retention. Categories matched to the relationship's full operational scope; durations matched to the longest applicable obligation period across legal, regulatory, and operational requirements.
• Derivation. Allow-list explicit about which operations are permitted on which categories, including operations that compose across categories within the party's retention slice.
• Propagation. Specified mesh of third-party relationships with explicit upstream references (§6.5) and verification requirements pointing to EPP when drafted. Each propagation edge specifies the third-party compact class required to receive propagation.
• Disposition. Per-category, per-lifecycle-event specifications that handle the full range of revocation, expiration, supersession, and partial supersession scenarios. Includes specifications for what happens when upstream compacts in the mesh are revoked or superseded.

Advanced tier compacts are appropriate for high-stakes verticals where the protocol's protective claims most need to operate at full strength: healthcare provider relationships, legal representation, sustained financial advisory, complex multi-party commercial relationships. The standard library (§9) does not yet populate advanced tier defaults for any specific domain in v0.1; advanced tier compacts in v0.1 are authored bespoke or extended from standard tier defaults.

7.2 Tier selection

The choice of tier is a property of the compact at authoring time. Parties select a tier appropriate to the interaction's complexity and stakes. The tier selection is recorded in the compact's canonical content; counterparties verifying a compact can determine which tier's defaults applied at authoring time.

Tier selection is bilateral. Both parties must agree to the tier; one party cannot impose a tier on the other. Where the parties disagree about appropriate tier, the more restrictive interpretation governs (consistent with the §5.5 tiebreaker pattern): a party requesting standard tier when the counterparty requests minimal tier results in either both parties agreeing to minimal tier or no compact being authored.

The default-deny stance applies at the tier level as well as within tiers. A tier specifies what is permitted; anything not permitted under the tier's defaults must be explicitly added to the compact via extensions (§7.4) or the compact is not authored under that tier.

7.3 Tier extension

Compacts MAY extend beyond their tier's defaults by specifying additional permissions inline. An extension to a minimal tier compact might add a single propagation edge to permit a specific third-party share. An extension to a standard tier compact might add a derivation operation not in the standard tier's allow-list. Extensions are bilateral: both parties must agree to each extension.

Extensions do not change the tier of the compact. A minimal tier compact with a single propagation extension is still a minimal tier compact for purposes of tier identification; the extension is recorded as a deviation from the tier's defaults. This preserves the tier system's value as a shorthand for compact complexity while allowing parties to customize where standard configurations do not fit.

Implementations of tier extensions MUST record extensions explicitly in the compact's canonical content, naming each deviation from the tier's defaults. Implicit or unspecified extensions are forbidden under the default-deny stance: anything not in the tier's defaults or explicitly extended is implicitly forbidden.

7.4 Tier migration

A compact may be superseded by a new version at a different tier. A minimal tier compact authored for a one-off interaction may be superseded by a standard tier compact when the parties' relationship matures into an ongoing engagement. A standard tier compact may be superseded by an advanced tier compact when the relationship's complexity grows.

Tier migration follows the supersession rules in §5.5: the new version requires fresh bilateral signing and the predecessor remains in the historical record. Tier migration cannot be accomplished by extension of an existing compact; a change in tier is a material change that produces a new version.

Tier migration in the descending direction (from advanced to standard, from standard to minimal) is permitted under the same supersession rules. Descending migration is appropriate when a relationship's scope contracts; the parties supersede the prior advanced tier compact with a standard tier compact whose defaults better match the contracted scope.

During tier migration, the disposition rules of the predecessor compact govern any retained material from the predecessor compact's effective period, even after the successor compact takes effect. The successor compact governs the relationship going forward; the predecessor's disposition rules govern its own retention slice's terminal handling.

7.5 Why tiers

The tier system addresses a friction problem the compact pattern would otherwise create. If every compact required parties to specify all four dimensions completely from scratch, the cognitive overhead of authoring compacts for routine interactions would be substantial. Implementations would either ship with hidden defaults (which violates the default-deny stance) or push the cognitive load to users (which violates the consent fatigue concerns the protocol is responding to). The tier system resolves this by making defaults explicit, named, and bilaterally agreed at the tier-selection step rather than buried in implementation.

Tiers also create a useful adoption ramp. v0.1 implementations can begin with minimal tier compacts for ad-hoc interactions, mature into standard tier as relationships develop, and adopt advanced tier as the standard library matures and high-stakes verticals develop their domain-specific extensions. The tier system grows with the protocol; v0.1 ships three tiers because three is the minimum that produces meaningful differentiation, not because three is the final number.

[§7 specifies the three-tier system: minimal, standard, advanced. Tiers reduce friction for common configurations while preserving bespoke compact authoring. The standard library (§9) populates tier defaults for the contractor-and-homeowner domain in v0.1.]

8. The two-phase protocol

Compacts come into existence through a two-phase protocol: Proposal and Authorization. The Proposal phase produces a draft compact with one party's signature and terms; the Authorization phase produces either a fully-signed compact (both parties have signed and the compact transitions to in-force) or a terminated negotiation (the second party declines, and the proposal is retired without effect). This section specifies both phases and the transitions between them.

The two-phase structure exists because compacts are bilateral and the parties are not co-located. One party initiates the negotiation by proposing terms; the other party reviews, accepts, modifies, or declines. The phases give the protocol a clean shape for the asynchronous negotiation that bilateral compacts require.

8.1 The Proposal phase

The Proposal phase begins when one party — the proposer — authors a compact with all required fields specified and signs it. The Proposal phase ends when either the counterparty enters Authorization (§8.2) or the proposer withdraws the proposal (§8.4).

During the Proposal phase, the compact is not yet in force. The proposer's signature attests to the canonical content as the proposer authored it, but the compact does not bind either party until the counterparty has also signed.

8.1.1 Required state for a proposal

A proposal MUST contain all required fields specified in §5.2: identification, parties, bounded scope, retention dimensions for both parties, revocation terms, and the proposer's signature. The proposal MUST specify what the counterparty's signature would attest to — meaning the counterparty's retention slice, derivation rights, propagation rights, and disposition rules are all populated in the proposal, even though the counterparty has not yet committed to them.

A proposal that is incomplete is not a proposal under this protocol; it is a draft. Drafts are application-specific intermediate states; they have no protocol status. The protocol begins recognizing the artifact as a proposal only when all required fields are populated and the proposer's signature is recorded.

8.1.2 Transmission to the counterparty

After signing, the proposer transmits the proposal to the counterparty through the mechanism specified by the runtime hosting the negotiation (RCP). ACP does not specify the transmission mechanism; it specifies that the counterparty MUST be able to receive the proposal in a form that allows verification of the proposer's signature, inspection of all required fields, and review of the canonical content as the proposer authored it.

The transmission MUST preserve the canonical content exactly. Implementations that modify the proposal in transmission — by reformatting, by re-encoding, by relaying through intermediaries that alter the structure — have produced a different artifact, not the proposal the proposer signed. The counterparty receiving an altered proposal MUST treat it as either a new draft requiring re-signing by the proposer or as a transmission failure requiring retransmission.

8.1.3 Counterparty review

On receipt, the counterparty's agent reviews the proposal. Review consists of: verifying the proposer's signature, verifying that the proposer's identity and principal authorization (§5.2.2) are valid, parsing the proposed terms, evaluating the proposed terms against the principal's policy, and forming a decision: accept, modify, or decline.

Where the counterparty's principal must be involved in the review — typically when terms exceed what the agent's standing authority covers — the agent surfaces the proposal to the principal through SSP (§17 of SSP v0.2). The principal reviews the rendered compact terms and authorizes or declines. The agent's subsequent action in the Authorization phase is bound by the principal's decision.

The principal's review is governed by the integrity requirement for compact-rendering surfaces (SSP §10.4). The terms shown to the principal MUST be the terms the principal is authorizing; any drift between the rendered terms and the proposal as transmitted is a failure of the surface and MUST be treated as one.

8.2 The Authorization phase

The Authorization phase begins when the counterparty's agent has reviewed the proposal and determined that the principal authorizes signing. The Authorization phase ends when the counterparty's signature is recorded (and the compact transitions to in-force) or when the counterparty's review concludes with a decline or modification request (and the proposal is terminated or returned for renegotiation).

8.2.1 Counterparty signing

The counterparty's agent signs the proposal's canonical content, cryptographically incorporating the proposer's signature as input (§5.4). The counterparty's signature MUST attest to the same canonical content the proposer signed; any modification produces a different artifact requiring restart of the protocol.

With both signatures recorded, the compact transitions to in-force. The runtime provides the authoritative in-force timestamp (§5.2.6); the compact is now binding on both parties for the duration of its effective period.

The transition to in-force MUST be recorded in both parties' copies of the compact. The runtime's role in establishing the authoritative timestamp is governed by RCP; ACP requires that the timestamp be authoritative and that both parties' copies agree on the moment of transition.

8.2.2 Counterparty decline

If the counterparty's review concludes with decline, the counterparty's agent transmits a decline notification to the proposer. The decline MUST identify the proposal being declined (by compact identifier and version) and MAY provide a reason. ACP does not require that decline reasons be provided; the counterparty's right to decline without justification is preserved.

On receipt of the decline, the proposer's agent retires the proposal. The proposer's signature on the retired proposal is no longer attached to a compact in any phase; the proposer MAY author a new proposal with different terms or abandon the negotiation. Retired proposals MUST NOT be revived by either party; restarting negotiation requires a new proposal with a new identifier.

Decline notifications themselves are not compacts. They do not create binding obligations. A counterparty that declines and later wishes to engage MAY do so by initiating a new proposal as the proposer; the prior decline does not constrain the new negotiation.

8.2.3 Counterparty modification request

If the counterparty's review concludes with a modification request, the counterparty's agent transmits modified terms to the proposer. The modification request consists of a new draft proposal — with the counterparty's proposed changes — and the counterparty's signature on the new draft.

Modification requests are not modifications of the original proposal; they are new proposals authored by the counterparty (now acting as proposer of the new draft). The original proposal is retired when the modification request is transmitted; the new proposal begins its own Proposal phase with the original proposer now as counterparty.

This means the two-phase protocol is symmetric across modification cycles. Either party may propose; either party may decline; either party may counter-propose. A negotiation that proceeds through multiple counter-proposals consists of a sequence of proposals, each retired when its successor is authored. Only when both parties sign the same canonical content does the negotiation produce an in-force compact.

Implementations MUST treat each new proposal as structurally independent. A counterparty's signature on a modification request does not carry forward to subsequent proposals; if the original proposer counter-modifies, the subsequent proposal requires a fresh signature from the original counterparty. This is the cryptographic atomicity rule from §5.4 applied to negotiation.

8.3 Negotiation timeouts

Proposals SHOULD include a negotiation timeout — a duration after which an unsigned proposal expires and is retired automatically. Where specified, the timeout is part of the canonical content; the proposer's signature attests to the timeout's value as part of what they signed.

If the negotiation timeout elapses without the counterparty entering Authorization, the proposal expires. Expiration is structurally identical to decline: the proposer's signature is detached from any compact, and a new proposal is required to restart the negotiation. The counterparty's failure to engage within the timeout is recorded but does not constrain future negotiations.

Implementations SHOULD specify negotiation timeouts for substantially all proposals. Indefinite pendency is a known footgun: a proposal pending without a timeout binds the proposer's intent (their signature attests to the proposed terms as they understood them at proposal time) without binding the counterparty to engage at all. Where the proposer's circumstances change — their pricing shifts, their availability changes, their authority is revoked — the un-timed-out proposal remains technically signable by a counterparty acting on stale terms. The timeout is the mechanism that prevents this.

Where no timeout is specified, the proposal pends until either party retires it explicitly. Implementations choosing to omit the timeout MUST treat the omission as a deliberate decision and SHOULD surface the decision to the proposer at proposal-authoring time, so that omission is informed rather than accidental. This is the §5.5 tiebreaker pattern applied at the negotiation layer: omission is permitted but not invisible.

8.4 Proposer withdrawal

Before the counterparty signs, the proposer MAY withdraw the proposal. Withdrawal retires the proposal; the proposer's signature is detached, and the negotiation ends without effect.

Withdrawal follows the same three-state mechanics as lifecycle synchronization (§5.7): initiated, acknowledged, active. The withdrawal is initiated when the proposer transmits a withdrawal notification to the counterparty. The withdrawal is acknowledged when the counterparty confirms receipt. The withdrawal is active only after acknowledgment is recorded; until then, the proposal remains in its prior state and the counterparty's signature on the proposal, if recorded, is valid.

This means the withdrawal-after-counterparty-signing race condition resolves in favor of the counterparty's signature. If the counterparty signs before the withdrawal is acknowledged, the compact transitions to in-force normally; the proposer's withdrawal arrives too late to prevent the binding. The proposer who wishes to retire a now-in-force compact must use revocation (§4.4, §5.6), not withdrawal.

The asymmetry favors the party who has acted in good faith on the proposal as transmitted. A counterparty who has reviewed the terms, surfaced them to their principal, obtained authorization, and signed has performed substantive work; the protocol does not permit the proposer to retroactively invalidate that work by withdrawing after the counterparty has committed. The proposer's protection against unwanted compacts is the negotiation timeout (§8.3) and the right to specify revocation terms in the proposal itself, not a retroactive withdrawal mechanism.

Where the counterparty has not yet signed but is in active review at the moment withdrawal is initiated, the withdrawal proceeds normally. The counterparty's acknowledgment of the withdrawal terminates the negotiation cleanly; the counterparty's review work is wasted, but no binding obligation is created.

Where the counterparty's runtime is offline or partitioned and cannot acknowledge the withdrawal in a reasonable time, the withdrawal pends. The proposer is not bound to wait indefinitely for acknowledgment; the timeout-and-escalation mechanism specified in §5.7 applies, and the proposer MAY unilaterally activate the withdrawal after the timeout period — at which point the suspension-of-derivation rule from §5.7 applies to any operations the counterparty might attempt during the gap. The same protection that closes the bad-faith timeout exploit in lifecycle synchronization closes it here: a counterparty cannot benefit from delaying acknowledgment of a withdrawal.

8.5 The lifecycle of a successful negotiation

A successful negotiation proceeds as follows:

• The proposer authors a compact with all required fields, signs it, and transmits the proposal to the counterparty.
• The counterparty receives the proposal, verifies the proposer's signature, verifies principal authorization, and reviews the proposed terms — surfacing the proposal to the principal where the agent's standing authority does not cover the terms.
• The principal reviews the rendered compact terms (via SSP) and authorizes signing.
• The counterparty's agent signs the proposal's canonical content, incorporating the proposer's signature cryptographically.
• The runtime provides the authoritative in-force timestamp; the compact transitions to in-force.
• Both parties' copies of the compact record the in-force transition; the negotiation is complete.

From this point, the compact governs the parties' obligations within its bounded scope until it expires, is revoked, or is superseded. The two-phase protocol's role is complete.

8.6 The lifecycle of a failed negotiation

A failed negotiation may proceed as follows:

• The proposer authors and signs a proposal; transmits to the counterparty.
• The counterparty reviews; either declines outright, requests modifications (initiating a new proposal in the reverse direction), or fails to act within the negotiation timeout.
• The proposal is retired. The proposer's signature is detached. No compact comes into force.
• If the negotiation involved counter-proposals, each retired proposal is recorded in its parties' negotiation history but creates no binding obligations.

Failed negotiations leave no residue at the protocol level. The parties may negotiate again with new proposals; they may abandon the relationship; they may pursue alternative engagements. The protocol does not penalize failed negotiations or constrain future negotiations between the same parties.

Implementations MAY retain records of failed negotiations for their own purposes — auditing, dispute reconstruction, pattern analysis — but the failed negotiations are not compacts and do not carry the protections compacts provide. Material exchanged during the proposal phase that was not retained under the proposed compact's terms (because the compact never took effect) is governed by whatever default rules the parties' standing relationships establish; ACP specifies no default retention for material exchanged during failed negotiations.

[§8 specifies the two-phase protocol: Proposal and Authorization. §8.4 handles the withdrawal-after-signing race condition by privileging the proposer's withdrawal. §8.5 and §8.6 walk through successful and failed negotiations end-to-end. §9 will specify the standard library that populates compact dimensions for the contractor-and-homeowner domain.]

9. The standard library

The standard library is a registry of predefined compact terms — retention categories, derivation operations, propagation flows, disposition rules — that compacts may reference instead of specifying inline. It exists because compact authoring without shared vocabulary produces ontology katamari: each implementation defines its own terms, similar but not identical, and the protocol's interoperability claims dissolve into vocabulary mismatch.

v0.1 specifies the standard library's structure and populates it for one domain: the contractor-and-service domain centered on contractor-and-homeowner relationships. The contractor-and-service entries demonstrate the library's shape and provide a complete vocabulary for the v0.1 wedge vertical. Other domains will be added in subsequent revisions through the standard library's governance process (§9.4).

9.1 Standard library structure

Each standard library entry has the following structure:

• Identifier. A globally unique identifier for the entry. Stable across the entry's lifetime; survives revisions.
• Category. What the entry is — a retention category, a derivation operation, a propagation flow, a disposition rule, or a domain-specific dimension.
• Domain. The domain the entry applies to. v0.1 entries are domain-tagged "contractor-and-service".
• Definition. A precise specification of what the entry covers, including edge-case clarifications and exclusions.
• Default disposition. For retention categories, the default disposition rules across lifecycle events. Used when compacts reference the entry without specifying disposition explicitly.
• Composition rules. How the entry composes with other entries — for example, which derivation operations may be applied to a retention category, which propagation flows are permitted from the category.
• Version. The standard library version that introduced or last revised the entry. Compacts referencing the entry pin to a specific version; subsequent revisions of the entry produce new versioned entries that compacts may opt into.

Compacts reference standard library entries by identifier. The reference resolves to the entry's definition at the version pinned in the compact. This means a compact authored against version 1 of an entry continues to operate under that version's definition even if the entry is revised later; the revision affects future compacts that opt into the new version, not existing compacts.

9.2 Contractor-and-service retention categories

The following retention categories are specified for the contractor-and-service domain. Each is a category of material that may be retained by parties to a contractor-and-homeowner compact, with defaults appropriate to the typical relationship.

9.2.1 Work scope

The agreed scope of work to be performed. Includes the work description, the agreed price or pricing structure, the timeline, and any material conditions on performance. Both parties retain this category by default; both parties' copies depict identical content (this is canonical content, not retention slice).

Default disposition: indefinite retention. The work scope is the basis for any future dispute about what was agreed; both parties need it indefinitely for defense purposes. Revocation does not delete the work scope; it freezes it as historical record.

9.2.2 Work record

The record of work actually performed: dates of service, hours logged, materials used, work products delivered, and confirmations of completion. The contractor's agent retains this category for its own operational records; the homeowner's agent retains it as evidence of work received.

Default retention duration: seven years from the compact's effective period end, matching typical statute-of-limitations periods for contractor work disputes. Bounded retention disposition on revocation; indefinite retention disposition where active legal proceedings reference the work.

Asymmetric retention slices: the contractor retains time logs and internal labor allocations the homeowner does not have access to; the homeowner retains receipts and confirmations of payment the contractor does not retain in the same form. The asymmetry is structural: each party retains material specific to their role in the work.

9.2.3 Billing and payment record

The record of amounts billed and amounts paid: invoices, payments, taxes, late fees, refunds, and credits. The contractor's agent retains this category for tax and accounts purposes; the homeowner's agent retains it for personal records and tax deduction purposes.

Default retention duration: seven years, matching IRS retention requirements in applicable jurisdictions; longer where local jurisdiction requires. Indefinite retention disposition for the duration of any tax obligation referencing the records.

Asymmetric retention slices: the contractor retains the full billing record including internal cost-and-margin breakdowns the homeowner does not have access to; the homeowner retains payment records including methods and dates that the contractor retains in different form. Both parties retain the canonical billed-and-paid amounts.

9.2.4 Property access details

Information about the homeowner's property required for the contractor to perform work: address, access codes, alarm settings, key locations, scheduling restrictions, presence of pets or other occupants, and any special access requirements.

Asymmetric retention is sharp here. The contractor's agent retains property access details only for the duration of the active work; immediate-deletion disposition on the work's completion or on revocation. The homeowner's agent retains the access details independently as part of the homeowner's own property records, governed by the homeowner's own retention policies, not by this compact.

This category illustrates why asymmetric retention is the structural novelty (§4.2). Symmetric retention of property access details would either over-retain on the contractor's side (the contractor keeps the homeowner's access codes after the job is done) or under-retain on the homeowner's side (the homeowner cannot keep records of their own property's access details). Asymmetric retention solves both problems by specifying different retention rules per party.

9.2.5 Work product warranty information

Information about warranties on work performed: warranty period, warranty conditions, contact information for warranty claims, and any warranty exclusions. Both parties retain this category; the contractor as part of their commitment to the warranty, the homeowner as the basis for any future warranty claim.

Default retention duration: the warranty period plus an extension matching applicable statute of limitations for warranty disputes. Bounded retention disposition on revocation; the warranty period continues to apply even if the underlying compact is revoked, because the warranty is itself a separate obligation.

9.2.6 Dispute records

Records of disputes that arose during the work or subsequently: complaints, responses, resolutions, and any third-party involvement (mediator, arbitrator, court). Both parties retain these records as evidence in the dispute and in any subsequent proceedings.

Default retention duration: seven years from dispute resolution, matching typical statute-of-limitations periods. Indefinite retention for the duration of any active legal proceeding.

9.3 Contractor-and-service derivation operations

Derivation operations specify what each party may compute from retained material. v0.1's standard library defines a representative set; implementations MAY define additional operations inline in compacts.

• Aggregate billing statistics. The contractor's agent may compute aggregate statistics over their own billing records (total revenue per quarter, average job value, mix of work types). Operates on the contractor's own retention slice only; cannot reach across to the homeowner's slice.
• Aggregate payment statistics. The homeowner's agent may compute aggregate statistics over their own payment records (total spent on home maintenance per year, mix of contractor types). Mirror of the contractor's aggregation, on the homeowner's slice.
• Work history summary. Either party may compute a summary of work performed under the compact (work types, dates, completion status). Operates on the joint canonical content of the work scope and work record.
• Warranty status check. The homeowner's agent may compute the current warranty status of work performed (within warranty, expired, voided by conditions). Operates on the warranty information category.

These operations illustrate the structural pattern: each derivation operation names what it operates on, identifies which party may perform it, and specifies the retention slice or canonical content the operation can reach. Operations not in the standard library are forbidden under the default-deny stance unless explicitly allow-listed in the compact.

9.4 Standard library governance

The standard library evolves over time as new domains are added and existing entries are refined. v0.1 specifies the library's structure but does not yet specify its governance — who proposes new entries, who reviews them, who approves them, who maintains the registry.

Governance is deferred to a companion document and to the protocol family's broader maintenance process. The constraints are: governance must not be captured by any single party or any narrow coalition of parties; new entries must be reviewed for consistency with the protocol's stances (default-deny, asymmetric retention as feature, bilateral mesh requirements); existing entries must be revisable but not invalidatable (compacts pinned to prior versions must continue to operate).

Until governance is specified, ACP v0.1's standard library is maintained by the original protocol authors with input from implementers. New entries proposed during v0.1 implementation will be reviewed and added to the library for v0.2 or to a maintenance release of v0.1, depending on whether the entry is structural (changes how the library works) or content-additive (adds entries without changing structure).

9.5 Why the standard library matters

The standard library is the difference between ACP being implementable and ACP being a graveyard. A protocol that defines the structure of compacts but not the content of compact terms forces every implementation to define its own vocabulary; vocabularies diverge; compacts authored under one implementation become unintelligible to agents operating under another implementation; the protocol's interoperability claim dissolves.

The contractor-and-service entries in v0.1 are intended to be enough vocabulary for the wedge vertical to operate. They are not intended to be exhaustive. As the protocol matures, the standard library will grow to cover additional domains, with each domain's entries reviewed for fit with the protocol's stances and for compatibility with adjacent domains.

Implementations SHOULD reference standard library entries when their compacts cover material the library addresses. Inline specification is permitted but creates the risk of vocabulary drift; standard library references create interoperability without requiring implementations to coordinate term-by-term. The library's job is to make interoperability the default and inline specification the exception, not the reverse.

[§9 specifies the standard library's structure and populates the contractor-and-service domain. The library is representative for v0.1; subsequent revisions will populate additional domains and refine existing entries. §10 (asymmetric sophistication) will address the user-side and counterparty-side capability asymmetries that affect how compacts are authored and reviewed.]

10. Asymmetric sophistication

ACP's compact pattern assumes that both parties have agents capable of negotiating, signing, retaining, and enforcing compact terms. In practice, the parties' agents will not be equally capable. A homeowner's user-agent operating on a consumer device is not the same kind of artifact as a contractor's agent operating on commercial infrastructure with engineering staff and dedicated security review. The asymmetry is not a flaw in the parties' choices; it is a structural feature of the agent ecosystem the protocol enters.

This section names the asymmetry, specifies what ACP does about it, and names what ACP cannot do. Like §4 (asymmetric retention), the protocol's response is to make the asymmetry explicit rather than to pretend it does not exist.

10.1 The shape of the asymmetry

Counterparty-agents in commercial settings tend to be more sophisticated than user-agents along several dimensions. They are built by engineering teams with dedicated security review and compliance expertise. They run on infrastructure with consistent uptime, monitored deployment, and operational tooling. They have access to legal counsel and policy expertise that user-agents typically do not. They negotiate many compacts, which gives them experience that user-agents — negotiating only the user's compacts — do not accumulate at the same rate.

User-agents, particularly in early implementations, are typically more constrained. They run on whatever device the user has. They are configured with whatever policy the user has expressed (often imperfectly). They have to interpret terms the user may not fully understand. They often face counterparty-agents whose terms have been engineered specifically to extract favorable concessions from less sophisticated counterparts.

The asymmetry is not always in favor of the counterparty. A user with substantial resources may operate a sophisticated user-agent against a counterparty-agent that is itself constrained. A user-agent operated by a regulated profession (a doctor, a lawyer, a financial advisor) may bring more domain expertise than the counterparty-agent it is negotiating with. The protocol does not assume which side has more sophistication; it assumes only that the sides will not be equal and that the difference matters.

10.2 Why the asymmetry is structural, not transitional

It is tempting to read the sophistication asymmetry as a transitional problem that will resolve as user-agent technology matures. The reading is partially correct and substantially misleading.

The reading is correct in that user-agents will become more sophisticated over time. As the protocol family matures, as user-agent ecosystems develop, as standard libraries grow, as regulatory frameworks recognize compacts, the gap between commercial counterparty-agents and individual user-agents will narrow. v0.1 implementations will be more constrained than v1.0 implementations; v1.0 implementations will be more constrained than what comes after.

The reading is misleading in that the asymmetry will not disappear. Even when user-agents are far more sophisticated than they are now, commercial counterparty-agents will continue to invest disproportionate resources in their negotiation capabilities, because the resources scale with the value of the compacts being negotiated. A counterparty-agent negotiating millions of compacts a year will always have economic incentive to invest more in negotiation sophistication than a user-agent negotiating a few dozen. The asymmetry is structural in the sense that the economic geometry of the agent ecosystem reproduces it.

This means the protocol cannot be designed assuming the asymmetry will eventually resolve. The protocol must work in the presence of asymmetry; v0.1 has to be correct under v0.1 conditions, and the protocol's design has to remain correct as the asymmetry's specific shape evolves but its existence persists.

10.3 What the protocol does

ACP's response to asymmetric sophistication operates along four lines.

10.3.1 Default-deny stance

The default-deny stance (§5.2.3, threading through §6 and §9) is the protocol's most direct response to asymmetric sophistication. A user-agent that fails to specify retention, derivation, or propagation rights for a category leaves that category implicitly forbidden, not implicitly permitted. The user-agent that misses something through inexperience has produced a more restrictive compact, not a more permissive one. The asymmetry's typical failure mode — user-agents agreeing to terms they did not understand or did not specify — produces narrower protections under the protocol's stance, not wider concessions.

This is why the default-deny stance is normative rather than configurable. Implementations that produced permissive defaults would systematically disadvantage less sophisticated user-agents, exactly the failure mode the protocol is designed to prevent. The default-deny stance is the structural answer to the asymmetric-sophistication problem at the level of compact authoring.

10.3.2 Tier system

The tier system (§7) is the protocol's response to asymmetric sophistication at the level of compact complexity. A user-agent that cannot meaningfully evaluate advanced tier compacts is not forced to. The minimal tier exists for ad-hoc interactions where minimum protection is the appropriate default; the standard tier provides reasonable protection for most ongoing relationships; the advanced tier exists for parties (typically with sophistication on both sides) who need its capabilities.

The tier-disagreement tiebreaker (§7.2) compounds this. When parties disagree about tier, the more restrictive interpretation governs. A counterparty-agent requesting advanced tier from a user-agent that proposes minimal tier results in either both parties agreeing to minimal tier or no compact being authored. The user-agent's preference for simpler terms cannot be overridden by the counterparty-agent's preference for richer ones.

10.3.3 Standard library as a leveling mechanism

The standard library (§9) reduces the cognitive load of compact authoring for less sophisticated agents by providing predefined terms with predefined defaults. A user-agent that does not have the expertise to specify retention durations from scratch can reference standard library entries whose defaults have been reviewed for fit with the protocol's stances. The library is the vocabulary that less sophisticated agents borrow when they cannot generate vocabulary themselves.

The library's governance constraints (§9.4) reflect this function. If the library is captured by sophisticated parties, its defaults will drift toward terms that favor them; the library would then reproduce the asymmetry rather than mitigate it. Governance that resists capture is what makes the library a leveling mechanism rather than an extraction mechanism.

10.3.4 Principal authorization requirement

The principal-authorization requirement (§5.2.2) is the protocol's response to the most acute form of the asymmetry: the case where a user-agent's principal does not adequately understand the terms the agent is signing. Principal authorization requires verifiable proof that the principal authorized the specific terms in the compact's canonical content, not merely that the agent had general signing authority.

This requirement bites most where the asymmetry is sharpest. A user whose agent has accepted broad authority — "sign whatever standard contracts come up in this engagement" — and is then presented with a compact whose terms exceed reasonable expectations cannot be bound by the agent's signature alone. The principal must specifically authorize the terms; the requirement is the structural floor under user protection.

AAP, when drafted, will specify the mechanism by which principal authorization is verified. ACP requires that whatever AAP specifies be present in the compact; without it, the asymmetry's worst failure mode (a user-agent with weak understanding signing terms its principal would not authorize) goes unaddressed.

10.4 What the protocol cannot do

The protocol's responses to asymmetric sophistication address the structural failure modes the asymmetry produces. They do not eliminate the asymmetry. Several limitations are worth naming explicitly.

ACP cannot make a user-agent more sophisticated. If the user's agent does not understand the implications of a propagation flow it is being asked to authorize, the protocol's default-deny stance protects the user from authorizing flows the agent did not specify; it does not help the user understand what flows would have been appropriate. The user receives a compact that reflects their agent's limited understanding, with the protections that limitation produces, but not a compact that reflects the more sophisticated negotiation the user might have wanted.

ACP cannot prevent sophisticated counterparty-agents from designing compacts that exploit user-agent limitations within the protocol's bounds. A counterparty-agent that crafts terms designed to be technically permissible under the protocol but practically disadvantageous to the user-agent has not violated the protocol; the user-agent's signature, if obtained, is binding. The protocol's structural protections (default-deny, tiers, standard library, principal authorization) raise the floor; they do not eliminate the design space within which sophisticated parties may operate.

ACP cannot solve the problem of user-agent capture. A user-agent that has been compromised — by malicious software, by a service provider acting against the user's interests, by a developer's design choices that prioritize commercial considerations over user protection — may sign compacts the user would reject if they understood them. The protocol cannot distinguish a captured user-agent from a legitimate but limited one. AAP, when drafted, will address what makes a user-agent legitimate; until then, the wolf-in-agent's-clothing problem (§3.4) is named but not closed.

ACP cannot remediate compacts authored under the asymmetry's pressure. A user-agent that signed a compact whose terms it did not adequately evaluate cannot retroactively narrow the compact's terms by claiming inadequate evaluation. Revocation under the compact's revocation terms is the remedy; renegotiation under fresh terms is the remedy; the protocol's structural protections operate at authoring time, not retroactively.

10.5 What this means for implementers

Implementers building user-agents for asymmetric environments — typically, consumer-facing applications where users will face sophisticated commercial counterparties — bear specific responsibilities the protocol cannot enforce but that the protocol's effective operation depends on:

• Surface the principal-authorization step prominently. Users authorizing compacts under SSP need to see what they are authorizing, in language they can act on. The integrity requirement (SSP §10.4) governs the surface; the user-agent's responsibility is to render the surface in a form the user can meaningfully evaluate.
• Default to minimal or standard tier compacts unless the user has explicitly requested otherwise and demonstrated understanding of the tier's implications. Advanced tier compacts authored by inexperienced user-agents are a known failure mode.
• Use standard library entries by default. Inline-specified terms in user-agent compacts should be the exception, used only when standard library entries do not fit; the library's review process is a protection against vocabulary that disadvantages less sophisticated parties.
• Make the asymmetry visible to the user. A user-agent that conceals its limitations — that signs compacts confidently when the agent's actual understanding is limited — is acting against the user's interest. Honest representation of what the agent can and cannot evaluate is the user-agent's most basic obligation.

Counterparty-agent implementers in asymmetric environments bear different responsibilities. The protocol does not prevent them from designing compacts that exploit user-agent limitations within the protocol's bounds, but adoption of the protocol depends on counterparties not doing so systematically. A counterparty-agent ecosystem that uses ACP's structure to extract concessions less sophisticated user-agents would not have authorized in better-informed circumstances will produce regulatory backlash, user-agent ecosystem responses, and erosion of the protocol's adoption rationale. The protocol is built on the working assumption that most counterparty-agents will operate in good faith; bad-faith implementations are individually permitted but collectively destructive.

[§10 names asymmetric sophistication as a structural feature of the agent ecosystem and specifies the protocol's four-line response: default-deny, tier system, standard library, principal authorization. The section also names what the protocol cannot do — eliminate the asymmetry, prevent within-bounds exploitation, solve user-agent capture, remediate compacts authored under asymmetric pressure. §11 will provide worked examples that illustrate the protocol operating in asymmetric and balanced environments.]

11. Worked examples

This section walks through two end-to-end examples to demonstrate how the protocol's specifications compose in practice. The first example is a single-pair compact between a homeowner and a contractor, illustrating the two-phase protocol, the standard library at work, and the asymmetric retention structure operating across a complete relationship lifecycle. The second example extends to a mesh case — homeowner, general contractor, and plumber — showing how dependent compacts and the explicit-upstream-reference requirement (§6.5) handle multilateral workflows before EPP is drafted.

Both examples are illustrative, not normative. The normative rules are in §1 through §10. These examples show what compliance looks like in practice and what failure modes the rules prevent.

11.1 Single-pair compact: homeowner and contractor

This example traces the same hypothetical interaction used in SSP §17 (the session-as-authoring-venue worked example), now viewed from ACP's side. SSP §17 walked through the surface-rendering and authorization mechanics; this section walks through the compact mechanics.

11.1.1 Setup

A homeowner needs a kitchen remodel. The homeowner's user-agent has been authorized to engage contractors for home improvement work within stated budget and scope parameters. The contractor's agent represents a remodeling company that takes such jobs.

Both agents are running on runtimes that satisfy RCP requirements. Both agents have AAP-compliant identity attestations recorded for their principals. Both agents have authority within their stated scope to negotiate and sign compacts of standard tier.

11.1.2 Proposal phase

The contractor's agent authors a proposal. The proposal is a standard tier compact (§7.1.2) with a contractor-and-service domain selection (§9.2). The proposed terms include:

• Bounded scope: "Kitchen remodel as described in attached scope-of-work artifact." Effective period: from authorization through completion plus warranty period.
• Retention dimensions referencing standard library entries: work scope (§9.2.1), work record (§9.2.2), billing and payment record (§9.2.3), property access details (§9.2.4), warranty information (§9.2.5).
• Each retention category is populated with the contractor's retention slice and the homeowner's retention slice, asymmetric per the standard library's defaults.
• Derivation operations: the four standard library operations from §9.3 (aggregate billing statistics, aggregate payment statistics, work history summary, warranty status check).
• Propagation: limited allow-list referencing standard library entries (the contractor's tax authority, the contractor's professional licensing board, the homeowner's accountant where the homeowner authorizes), each with the bilateral mesh requirement (§6.4) — third-party flows require the third party to have a compact of standard tier or higher with the propagating party.
• Disposition rules per category and per lifecycle event, populated from standard library defaults.
• Revocation terms: either party may revoke with 30 days' notice; emergency revocation by either party is permitted with concurrent immediate-deletion disposition for active credentials.
• Negotiation timeout: 14 days from proposal transmission.

The contractor's agent signs the proposal — which means: (a) cryptographic signature attesting to the canonical content; (b) AAP-verifiable proof that the contractor (the principal) authorized these specific terms, not merely that the agent had general authority; (c) signing timestamp from the runtime as the authoritative in-force timestamp candidate. The proposal transmits to the homeowner's user-agent.

11.1.3 Counterparty review

The homeowner's user-agent receives the proposal, verifies the contractor's signature, verifies the contractor's AAP attestation and principal authorization, and parses the proposed terms.

The user-agent evaluates the terms against the homeowner's policy. The proposed terms exceed the user-agent's standing authority — the budget falls within the homeowner's stated parameters, but the propagation flows include a third-party class ("the contractor's professional licensing board") that the user-agent's standing authority does not cover. The user-agent therefore surfaces the proposal to the homeowner through SSP.

Per SSP §17, the user-agent renders a compact-review surface inside the homeowner's session. The integrity requirement (SSP §10.4) applies: the surface MUST depict the compact accurately, with all proposed terms visible and unambiguous. The action window for authorization is set to several days, appropriate to a compact authorization the homeowner may want time to consider.

The homeowner reviews the rendered terms. The homeowner has questions about the propagation flow to the licensing board — the user-agent surfaces a clarification request to the contractor's agent through the inter-agent channel, which transmits the question and receives a response (the licensing board flow is for required regulatory reporting; the propagation includes only the work category and completion confirmation, not personal details). The homeowner accepts this explanation. The homeowner authorizes signing.

11.1.4 Authorization phase

The user-agent signs the proposal's canonical content, cryptographically incorporating the contractor's signature as input (§5.4). The user-agent's signature attests to the canonical content as the homeowner authorized it; AAP-verifiable principal authorization is recorded; signing timestamp is set.

With both signatures recorded, the runtime provides the authoritative in-force timestamp. The compact transitions to in-force. Both parties' copies of the compact record the in-force transition. Both parties' agents now operate under the compact's terms.

11.1.5 Operating under the compact

During the kitchen remodel, both agents perform operations governed by the compact. The contractor's agent retains time logs, materials used, and progress photos under the work record category — material in its retention slice that the homeowner's agent does not retain. The homeowner's agent retains payment confirmations and progress acknowledgments under the billing and payment record category — material in its retention slice that the contractor's agent retains in different form.

When the contractor's agent computes aggregate billing statistics for the contractor's quarterly accounts (a permitted derivation operation per §9.3), the operation acts only on the contractor's own retention slice. The homeowner's payment patterns do not appear in the contractor's aggregates because the contractor cannot reach into the homeowner's retention slice.

When the contractor's agent propagates work-completion confirmation to the licensing board (a permitted propagation flow), the propagation requires the contractor to have a compact with the licensing board governing what the licensing board does with the propagated material. The contractor maintains such a compact independently of the homeowner-contractor compact; the propagation conforms to the bilateral mesh requirement (§6.4).

11.1.6 Completion and expiration

The kitchen remodel completes. Work-completion confirmation is recorded. The warranty period begins. The compact's effective period extends through the warranty period; both parties continue to retain material under the compact's terms.

After the warranty period ends, the compact expires. Per §5.6, expiration triggers the disposition rules specified for expiration. The contractor's agent applies disposition: property access details that were retained for the duration of the work were already deleted at work completion (immediate-deletion disposition); time logs and materials used are retained for the seven-year period specified in the work record category (bounded retention disposition); billing and payment records continue to be retained for tax obligations (indefinite retention until tax obligations end). The homeowner's agent applies its own disposition rules for its retention slice.

The compact is now expired. New interactions between these parties (a future remodel, a warranty claim under a different obligation) require new compacts. The expired compact remains in the historical record; both parties' agents retain the expired compact for the duration that disposition rules require.

11.1.7 What this example demonstrates

The single-pair example shows the protocol's specifications composing across a complete interaction lifecycle. Several rules do specific work that would not be visible in any single section:

• The two-phase protocol (§8) handles the asynchronous negotiation between agents whose principals are not co-located.
• The standard library (§9) provides a vocabulary both agents share, eliminating the vocabulary-mismatch failure mode that would otherwise occur.
• The asymmetric retention structure (§4) keeps each party's retention slice appropriate to that party's role; the contractor does not retain the homeowner's payment patterns; the homeowner does not retain the contractor's internal cost breakdowns.
• The bilateral mesh requirement (§6.4) prevents the contractor's propagation flows from escaping into ungoverned third-party relationships; the licensing board flow requires the contractor to maintain its own compact with the licensing board.
• The integrity requirement (SSP §10.4) ensures the homeowner's authorization is meaningful — what the homeowner reviewed is what the homeowner authorized.
• The disposition rules (§4.4, §6.5) handle the compact's end-of-life cleanly; different categories of retained material disposed of differently, per the compact's pre-negotiated terms.

11.2 Mesh compact: homeowner, general contractor, plumber

The single-pair example is the simplest case. Most real-world workflows are multilateral, and ACP's bilateral mesh architecture (§3.5) requires that multilateral workflows resolve into pairwise compacts. This example demonstrates the mesh in operation.

11.2.1 Setup

The kitchen remodel from §11.1 requires plumbing work that the general contractor will subcontract. The general contractor's agent and the plumber's agent need to author their own compact governing what crosses between them, including what the general contractor may share with the plumber about the homeowner's property and the work scope.

Three parties: homeowner, general contractor, plumber. Three potential pairwise compacts: homeowner-contractor (the §11.1 compact, already in force), contractor-plumber (the new compact this example focuses on), homeowner-plumber (potentially needed if the plumber needs to interact with the homeowner directly, possibly not needed if all interaction flows through the general contractor).

11.2.2 The contractor-plumber compact

The general contractor's agent proposes a compact with the plumber's agent. The compact is standard tier with contractor-and-service domain selection. Its terms specify what the contractor may share with the plumber about the homeowner-contractor relationship and what the plumber retains from the work performed.

The contractor-plumber compact has an additional structural requirement that distinguishes it from the homeowner-contractor compact: it is a dependent compact in a known mesh, and §6.5's explicit-upstream-reference requirement applies. The contractor-plumber compact MUST reference the homeowner-contractor compact's identifier as a lifecycle trigger.

Specifically, the contractor-plumber compact's disposition specification names: "On revocation or expiration of the homeowner-contractor compact identified by [identifier], the contractor-plumber compact transitions to its post-upstream-revocation disposition." This means the homeowner's revocation of the homeowner-contractor compact propagates to the contractor-plumber compact through the explicit reference; the contractor's authority to engage the plumber on the homeowner's behalf was derived from the homeowner-contractor compact, and the loss of that authority triggers the dependent compact's disposition.

11.2.3 What the contractor may share with the plumber

Property access details that the contractor's agent retains under the homeowner-contractor compact are subject to the propagation specification of that compact. Property access details cannot be propagated to the plumber unless the homeowner-contractor compact's propagation flows include the plumber's compact class as a permitted flow. In the standard library's default for property access details (§9.2.4), the contractor retains the details only for the duration of the active work and immediate-deletion disposition applies on completion. Propagation to subcontractors is permitted only when the contractor-plumber compact specifies receipt of property access details with matching disposition.

The contractor-plumber compact therefore includes a property access details retention category for the plumber, with the same immediate-deletion disposition as in the homeowner-contractor compact. The plumber retains property access for the duration of the active plumbing work; immediate deletion at work completion. The bilateral mesh requirement is satisfied: the contractor's propagation of property access to the plumber is governed by the contractor-plumber compact, and the plumber's handling of property access is contractually constrained.

Work scope is similarly governed. The contractor may share the relevant portion of the work scope with the plumber — specifically, the plumbing-related portion — under the contractor-plumber compact's work scope category. The portions of the work scope not relevant to the plumber's role (cabinetry, tile work, finish carpentry) are not propagated to the plumber; the bounded scope of the contractor-plumber compact does not include them.

11.2.4 Operating across the mesh

During the kitchen remodel, both compacts are in force concurrently. The general contractor's agent operates under the homeowner-contractor compact for interactions with the homeowner; under the contractor-plumber compact for interactions with the plumber. The plumber's agent operates under the contractor-plumber compact for interactions with the contractor; the plumber may have a separate compact with the homeowner if direct interactions are needed (this example assumes interactions flow through the general contractor).

Cross-compact derivations are forbidden under the default-deny stance. The plumber cannot derive material from the contractor-plumber compact's retention slice and propagate it back into a different compact unless propagation flows are explicitly specified. The contractor cannot use the contractor-plumber compact's retention slice to perform derivations that would violate the homeowner-contractor compact's terms.

This composition is what makes the bilateral mesh work. Each pairwise compact is structurally simple; their composition produces multilateral coordination through the explicit relationships between them.

11.2.5 Upstream revocation in the mesh

Suppose the homeowner revokes the homeowner-contractor compact mid-project. The revocation initiates per §5.7's three-state mechanics: initiated, acknowledged by the contractor, active. During the gap, the suspension-of-derivation rule applies — the contractor cannot perform new derivations on the homeowner-contractor compact's retention slice.

Once the revocation activates, §6.5's explicit-upstream-reference mechanism takes effect. The contractor-plumber compact's disposition rules specify what happens when the homeowner-contractor compact revokes: typically, the contractor-plumber compact transitions to its post-upstream-revocation disposition, which may include immediate deletion of property access details on the plumber's side, transitioned retention for work-record material, and a triggered renegotiation or revocation of the contractor-plumber compact itself.

The plumber's agent receives notice of the upstream revocation through the contractor-plumber compact's lifecycle synchronization (§5.7). The plumber's agent acknowledges; the disposition rules activate. The plumber's retention slice from the contractor-plumber compact is handled per the disposition specification — even though the plumber was not party to the homeowner-contractor compact, the dependent-compact mechanism propagates the upstream event to the plumber's compact terms.

This is the v0.1 mechanism for mesh coherence in the absence of EPP. The propagation is explicit (recorded in the dependent compact's terms, not automatic), the propagation is bilateral (handled through the contractor-plumber compact's lifecycle synchronization), and the propagation is structurally constrained (the dependent compact responds only to the upstream revocation it explicitly references). When EPP is drafted, the explicit-reference mechanism becomes the foundation EPP propagates events along; the migration is additive rather than disruptive.

11.2.6 What this example demonstrates

The mesh example shows the protocol's bilateral-mesh architecture handling multilateral workflows without n-lateral compacts. Specifically:

• Multilateral workflows resolve into pairwise compacts (§3.5), each structurally simple, composed through explicit dependencies.
• The bilateral mesh requirement (§6.4) prevents propagation from escaping into ungoverned downstream relationships; every cross-party flow is governed by a compact.
• The explicit-upstream-reference requirement (§6.5) provides v0.1's mechanism for mesh coherence; dependent compacts respond to upstream lifecycle events through declared dependencies.
• The default-deny stance (§5.2.3) keeps cross-compact operations bounded; derivations and propagations operate only within their compact's specified terms, not across compacts in the mesh.
• Lifecycle synchronization (§5.7) handles cross-boundary state transitions for each pairwise compact; the suspension-of-derivation rule prevents bad-faith timing exploits.

The mesh also surfaces what v0.1 cannot do automatically. Without EPP, dependent compacts must explicitly reference their upstream dependencies at authoring time; new dependencies discovered after authoring cannot be added retroactively. EPP, when drafted, will close this gap. Until then, the explicit-reference mechanism is the load-bearing mechanism for mesh coherence.

[§11 demonstrates the protocol's specifications composing across single-pair and mesh interactions. The contractor-and-homeowner example interlocks with SSP §17's session-as-authoring-venue example. The mesh example demonstrates §6.5's explicit-upstream-reference mechanism as the v0.1 substitute for EPP. §12 will specify enforcement: what counterparties can do when violations are detected.]

12. Enforcement

Enforcement is what makes the compact's protective claims real rather than aspirational. A protocol that specifies bilateral terms, asymmetric retention, and disposition rules but provides no mechanism for the parties to detect, evidence, or respond to violations has produced an artifact whose protections exist only as long as both parties choose to honor them voluntarily. ACP specifies enforcement to make voluntary compliance the easier path and to give the harmed party recourse when voluntary compliance fails.

ACP v0.1's enforcement baseline is legal and reputational. The protocol does not specify a technical enforcement infrastructure that detects violations automatically across all parties; such infrastructure is downstream of EPP and is deferred. v0.1 specifies what counterparties can do with the information the compact provides — how violations are detected, what evidence is preserved, and what remediation paths are available.

12.1 Detection

Violations of compact terms are detected primarily through counterparty observation. The party that holds a retention slice can observe what the counterparty does with the counterparty's slice only insofar as the counterparty's actions become visible — through propagation flows the counterparty performs, through derivations the counterparty publishes, through downstream compacts the counterparty enters, or through interactions in which the counterparty's behavior reveals what it has retained or derived.

Detection is therefore partial. A counterparty that violates retention terms by retaining material it agreed to delete, but does not act on the retained material in ways that become visible, is undetectable at the protocol level. The compact's terms are nonetheless binding; the violation is not erased by undetectability. The detection mechanism establishes which violations the harmed party can act on, not which violations exist.

ACP's response to partial detection is twofold. First, the protocol's structural requirements — bilateral signing, principal authorization, machine-readable terms, default-deny stance — make many violations either impossible (terms not in the compact cannot be claimed as authorized) or legible when they occur (a propagation to a third party not in the propagation specification is a violation that becomes visible the moment the third party is observed in a downstream interaction). Second, the protocol's enforcement framework rests on the assumption that most counterparties operate in good faith, and that the structural protections plus the threat of detected violation are sufficient to keep good-faith parties compliant.

This assumption is the protocol's working hypothesis. Bad-faith counterparties who calculate that undetected violations are profitable and acceptable risk are individually possible. The protocol does not pretend to prevent them at v0.1; it limits their scope through structural requirements, increases their detection probability through the bilateral mesh requirement, and provides remediation paths when detection occurs. The cumulative effect is intended to make systematic bad-faith implementation economically and reputationally unattractive.

12.2 Evidence preservation

When a violation is detected or alleged, the harmed party needs evidence of what was agreed and what occurred. ACP specifies several mechanisms that preserve evidence at the protocol level.

The signed compact itself is the primary evidentiary artifact. Both parties retain identical canonical content (§5.3); both parties' signatures are cryptographically verifiable; the AAP-attested principal authorization (§5.2.2) establishes that the principal authorized the specific terms. A party alleging violation can produce the compact as evidence of what was agreed; the counterparty cannot credibly claim different terms because their own copy contains the same canonical content.

The compact's lifecycle history (§5.6) records when each phase began and what triggered the transition. Revocations, expirations, supersessions, and acknowledgment receipts are all recorded. A party alleging a violation that occurred at a specific phase of the compact's lifecycle can establish, from the lifecycle history, that the compact was in the alleged phase at the time of the violation.

The disposition records — what each party did with each retention slice when lifecycle events triggered — are preserved per the compact's terms. A party alleging that the counterparty failed to dispose of material on revocation can produce the compact's disposition specification as evidence of what was required. The counterparty's compliance or non-compliance is established by what the counterparty did or did not do with the material; the disposition specification establishes what was required.

Evidence preservation is not the same as evidence sufficiency. A party may have access to clear evidence of what was agreed and inadequate evidence of what occurred — particularly where the violation is in the counterparty's retention slice and the harmed party cannot directly observe the counterparty's compliance. The protocol's evidence preservation establishes what was agreed; what occurred remains a question that may require additional discovery, audit, or third-party observation.

12.3 Remediation paths

When a violation is detected and evidence is preserved, the harmed party has several remediation paths. ACP v0.1 specifies these paths abstractly; the substantive availability of each depends on the jurisdictions, infrastructures, and institutional contexts the parties operate within.

12.3.1 Legal remediation

The signed compact is a structured agreement between competent parties. In jurisdictions where signed agreements between competent parties carry legal weight, the compact may be admissible as evidence of the agreement and as the basis for legal claims arising from violation.

Legal remediation is the protocol's baseline enforcement mechanism. It is not a strong mechanism — legal proceedings are slow, costly, and uncertain — but it is the mechanism most universally available, and the protocol's structural requirements (bilateral signing, machine-readable terms, evidentiary preservation) are designed to make legal remediation more tractable than ad-hoc agreements would be.

ACP does not specify legal enforceability. Whether a compact is enforceable in a given jurisdiction depends on that jurisdiction's law of contracts, evidence, agency, and computation; v0.1 names this dependency and does not pretend to resolve it. Implementations operating in jurisdictions where compacts may be enforceable should preserve the compact's structural integrity (canonical content, signatures, AAP attestations) in forms admissible under those jurisdictions' rules.

12.3.2 Reputational remediation

A counterparty that violates compact terms and is detected may face reputational consequences from other potential counterparties who subsequently decline to enter compacts with them. The bilateral mesh requirement (§6.4) supports this: every cross-party flow is governed by a compact, and a party with a record of compact violations may find their compact proposals declined by counterparties who have learned of the violations.

Reputational remediation depends on violations being communicable across the mesh. Without EPP, this communication is application-mediated rather than protocol-mediated; counterparties learn of violations through reputation systems, professional networks, regulatory bodies, or other channels external to ACP. EPP, when drafted, will provide a protocol-mediated mechanism for compact-violation events to propagate across the mesh of related compacts; until then, reputational remediation is partial.

The strength of reputational remediation varies with the market and the parties involved. In tight-knit professional communities (specialized contractors, regulated professions, niche commercial markets), reputational consequences can be severe; in atomized markets where parties interact briefly and rarely repeat, reputational consequences may be negligible. ACP does not strengthen reputational remediation; the protocol's structural requirements make violations more legible when they occur, but the consequences of legibility depend on the market context.

12.3.3 Audit-on-demand for high-stakes verticals

Some verticals — healthcare, financial services, regulated commerce — require enforcement stronger than legal-and-reputational baselines provide. ACP's enforcement architecture is designed to be swappable: high-stakes verticals can require additional enforcement mechanisms without breaking the protocol structure.

Audit-on-demand is the most common stronger mechanism. A vertical may require that compacts in that vertical specify an audit clause: the counterparty's retention slice may be inspected, on demand, by a designated auditor (a regulator, a bonded third party, an automated audit infrastructure). The audit's findings establish whether the counterparty's compliance with disposition rules and retention terms is genuine. Audit-on-demand transforms detection from partial-and-incidental to active-and-comprehensive.

Audit-on-demand has costs. The audit infrastructure is an additional party to the compact relationship; the audit clause is a propagation flow with specific terms; the audit itself is a derivation operation on the counterparty's retention slice. v0.1's enforcement architecture is designed to allow these mechanisms to be specified within compacts without requiring all compacts to include them. A vertical's standard library entries (when added in future revisions) can populate audit clauses with vertical-appropriate defaults; compacts in lower-stakes verticals can omit them.

Future ACP revisions may specify additional enforcement mechanisms for high-stakes verticals: attested enclaves for material that must remain unobservable to the retaining party's operations, hardware-rooted attestation for compact compliance, formal audit protocols with cryptographic evidence chains. v0.1 establishes the architecture's swappability; future revisions populate it.

12.4 What enforcement does not promise

ACP's enforcement framework is intended to make voluntary compliance the easier path and to give the harmed party recourse when voluntary compliance fails. It is not intended to make violations impossible or to fully remediate harms when violations occur.

The protocol cannot prevent violations that occur within the counterparty's retention slice and never become visible. Detection is partial; some violations are undetectable. ACP's structural requirements limit the scope of undetectable violations; they do not eliminate the category.

The protocol cannot remediate harms that exceed what the available enforcement mechanisms can address. A counterparty that violates retention terms in ways that produce harm exceeding the available legal damages, the available reputational consequences, and the available audit-mediated remediation may walk away from the violation effectively unpunished. The protocol raises the floor; it does not eliminate the design space within which sophisticated bad-faith parties may operate.

The protocol cannot enforce against parties operating outside its jurisdiction. A counterparty in a jurisdiction without recognized legal weight for signed compacts, without functional reputational markets, and without audit infrastructure has limited exposure to the enforcement mechanisms ACP relies on. The protocol's enforcement claims are stronger in mature jurisdictions and weaker in jurisdictions where the surrounding institutional context is weak. v0.1 names this dependency rather than papering over it.

These limitations are real. They are also the limitations of any protocol that relies on enforcement mechanisms external to the protocol itself. ACP's role is to make the protocol-level commitments precise and the surrounding enforcement mechanisms' work tractable; the surrounding mechanisms' substantive limits remain their own.

[§12 specifies enforcement at the legal and reputational baseline with swappable architecture for stronger mechanisms in high-stakes verticals. v0.1's enforcement is intentionally conservative; future revisions populate the swappable architecture as cryptographic and audit infrastructures mature.]

13. Deferred concerns

This section consolidates what ACP v0.1 explicitly defers — concerns the protocol acknowledges but does not address, with pointers to where they will be addressed when drafted. The deferrals are not omissions; they are scope choices that keep v0.1 implementable while naming what remains to be done.

13.1 Compact reconciliation

When parties dispute compact terms, accuse each other of violations, or seek to retire a compact under contested conditions, the question of who arbitrates and on what authority is not specified by ACP v0.1. This is the same deferral SSP and RCP make on the same topic. Reconciliation is parallel-deferred across the compact family.

The working hypothesis worth holding lightly: a reconciliation agent operating under its own compact, distinct from both parties to the disputed compact, may be the architectural answer. Reconciliation would then be a compact relationship — bilateral between the disputing party and the reconciliation agent, with explicit authority over the disputed compact's terms. v0.1 does not commit to this design; it names it as a possibility.

13.2 The Agent Attestation Protocol (AAP)

AAP is named throughout this spec but is not yet drafted. ACP's references to AAP specify the requirements AAP must satisfy for ACP's claims to hold. The list of these requirements, consolidated:

• Cryptographic identity for agents, verifiable by counterparties.
• Form of principal identification — what entity an agent represents and how the representation is verifiable.
• Principal-specific authorization for compact terms — verifiable proof that the principal authorized the specific terms in the canonical content, not merely general signing authority.
• What makes an agent a legitimate participant — the wolf-in-agent's-clothing test that distinguishes genuine user-agents from captured or malicious ones.
• Authentication and authorization to sign on the principal's behalf, with delegation chain.
• Cryptographic signature mechanism producing verifiable, non-repudiable signatures.
• Competence to negotiate compacts — the agent can parse, evaluate, and sign compact terms.
• Alignment with the principal's policy — the agent will refuse terms outside policy.

AAP, when drafted, will specify the mechanisms by which these requirements are satisfied. ACP's role is to specify what AAP must accomplish for ACP's protective claims to operate; ACP does not specify how.

13.3 The Event Propagation Protocol (EPP)

EPP is the missing civic-layer mechanism in the v0.1 release. It is named throughout this spec but is not yet drafted. ACP's references to EPP specify the requirements EPP must satisfy:

• Cross-mesh verification mechanism for downstream compact terms (§6.4) — a way for Party A to verify that Party B's downstream compact with Party C actually conforms to A's propagation specification.
• Event propagation along explicit upstream references in dependent compacts (§6.5) — the automated mechanism that complements the v0.1 explicit-reference requirement.
• Lifecycle event propagation across the mesh of compacts that depend on each other (§5.7) — the substrate-level mechanism for cross-compact synchronization.

EPP must satisfy these requirements without recreating the centralization failure modes of the page era's event mechanisms. The protocol's design constraint is that propagation is mesh-composing rather than centrally registered; events propagate along the same bilateral relationships that compacts establish, rather than through central authorities. This constraint is harder to satisfy than centralized propagation but is consistent with the compact family's broader stance against centralized substrate.

13.4 Cryptographic constructions

ACP defers cryptographic mechanisms — signature schemes, integrity attestations, verification protocols — to a non-normative companion document. The companion document will specify viable mechanisms without prescribing one, allowing implementations to choose mechanisms appropriate to their substrate while maintaining interoperability.

v0.1's cryptographic deferral is operational. Cryptographic primitives evolve; protocols that pin to specific primitives become obsolete as primitives are deprecated, weakened, or superseded. The companion-document approach allows the protocol's structural requirements to remain stable while the mechanisms that satisfy them evolve. The companion document will be updated more frequently than ACP itself; ACP's stability does not require cryptographic stability.

13.5 Standard library governance

The standard library evolves over time as new domains are added and existing entries are refined. v0.1 specifies the library's structure and populates the contractor-and-service domain; it does not specify the governance process that determines how new entries are proposed, reviewed, and approved.

Governance is deferred to a companion document and to the protocol family's broader maintenance process. The constraints — not captured by single parties or narrow coalitions, consistent with the protocol's stances, revisable but not invalidatable — were named in §9.4. The governance mechanism that satisfies these constraints is itself a structural concern that requires more design work than v0.1 attempts.

Until governance is specified, the standard library is maintained by the original protocol authors with input from implementers. New entries proposed during v0.1 implementation will be reviewed and added through this informal process, with formalization expected in a future revision.

13.6 Compound action atomicity

The question of whether multi-step actions in compacts should be atomic — succeed-or-fail as a unit, with rollback on partial failure — is parallel-deferred with SSP's deferral on the same topic. ACP carries SSP's working answer forward: compound user intent should be expressed as a single action with internal orchestration, rather than as a chain of separately-authorized actions. Implementations that report worked-around failure modes from this approach provide evidence that may shift the deferral status; absent such evidence, v0.1 carries the deferral.

13.7 N-lateral compacts

ACP v0.1's bilateral mesh architecture (§3.5) resolves multilateral workflows into pairwise compacts. The architecture preserves clean signing, retention, and revocation semantics at the cost of mesh redundancy. Whether n-lateral compacts as a distinct artifact class would offer net benefits is deferred.

Future protocol revisions may specify n-lateral compacts. The design constraints would be: signing semantics that handle three-or-more-party agreement without requiring full consensus protocols, retention asymmetry that handles three-or-more retention slices without combinatorial explosion, revocation mechanics that handle partial-party retirement without compact dissolution, and dispute resolution that handles multi-way disagreements. v0.1 does not address any of these; the bilateral mesh is the v0.1 architecture.

13.8 Cross-jurisdiction enforceability

A compact authored under one jurisdiction's legal framework and disputed in another faces enforceability questions that are downstream of ACP. The protocol's structure is uniform; the legal weight of that structure is not. v0.1 names this concern in §12.3.1 and defers the substantive resolution to legal frameworks evolving as the protocol matures and to implementations choosing jurisdictions appropriate to their use cases.

14. Open questions

These are questions ACP v0.1 has taken positions on but where review may produce better answers. Each question names the position v0.1 takes and the kind of pushback that would justify revision.

14.1 The bilateral mesh as the architecture

v0.1 commits to the bilateral mesh as the architecture for multilateral workflows, deferring n-lateral compacts. Some reviewers will argue that the mesh's redundancy cost is too high — that real workflows of substantial complexity will produce mesh proliferation that becomes intractable. Others will argue that n-lateral compacts introduce design problems that compound faster than mesh redundancy does.

v0.1 takes the bilateral-mesh position because the failure modes of n-lateral compacts are worse than the costs of mesh redundancy in the cases v0.1 anticipates. Pushback that names a specific multilateral workflow whose mesh resolution produces unmanageable complexity, with detail on why bilateral pairs cannot handle it, is welcome.

14.2 The integrity attestation requirement

v0.1 inherits SSP's integrity attestation requirement for bilateral shareable durable surfaces and applies the same strictness to ACP's compact records. Implementations without the integrity attestation mechanism cannot produce conformant compacts. Some reviewers will argue this is too strict for early implementations; others will argue it should be specified at the ACP layer rather than deferred to cryptographic constructions.

v0.1 takes the strict middle position for the same reasons SSP does: relaxing integrity dissolves the protocol's bilateral guarantees. Pushback on workability in early implementations is welcome; pushback on whether the mechanism should be specified at the protocol layer rather than deferred is welcome.

14.3 Default-deny across the protocol

v0.1 commits to default-deny as the structural stance — anything not explicitly permitted is implicitly forbidden. This stance threads through bounded scope (§5.2.3), retention (§6.2), derivation (§6.3), propagation (§6.4), disposition (§6.5), and tier extension (§7.3). Some reviewers will argue this produces excessive friction in compact authoring; that compacts will fail because parties failed to specify some permission they reasonably wanted.

v0.1 takes the default-deny position because the failure mode of permissive defaults — over-permissive compacts produced through omission — is structurally worse than the failure mode of restrictive defaults: under-permissive compacts requiring explicit re-authoring. The standard library reduces friction by providing predefined permissions for common cases. Pushback that names a class of compacts where default-deny produces unworkable friction, with detail on why the standard library cannot resolve it, is welcome.

14.4 The principal authorization requirement

v0.1 requires that each agent's signature carry verifiable proof that the principal authorized the specific terms in the canonical content. The mechanism is deferred to AAP. Some reviewers will argue that this requirement produces unworkable friction — that principals cannot meaningfully authorize each compact's specific terms when they negotiate compacts at scale, and that the requirement effectively prevents compact-mediated commerce at meaningful volume.

v0.1 takes the position that without principal-specific authorization, the bilateral signing structure is theater. Pushback that proposes mechanisms by which principal authorization can be made tractable at scale (delegation patterns, standing authorizations for compact classes, deferred authorization with retroactive ratification) is welcome. Pushback that argues the requirement should be relaxed without proposing alternative mechanisms is not.

14.5 The neural-network-weight derivation boundary

v0.1 specifies that derivation is any operation producing material the agent can later access for a duration extending beyond the current interaction — including updates to model weights, persistent context windows, and knowledge graph state. This is Position C in the §6.3 design choice.

Some reviewers will argue this is too restrictive; that modern AI agents operate in ways that make every retained-material read functionally a derivation under this definition, and that the derivation allow-lists become so granular as to be unenforceable. Others will argue it is not restrictive enough; that even in-flight processing should count as derivation if the processing produces outputs the agent acts on.

v0.1's position is the middle commitment. Pushback on whether the durability-across-interactions line is operationally workable is welcome. Pushback that proposes alternative formulations of the boundary is welcome.

14.6 The asymmetric sophistication framing

v0.1 names asymmetric sophistication as a structural feature of the agent ecosystem rather than a transitional problem (§10.2). Some reviewers will argue that this framing is too pessimistic — that user-agent sophistication will eventually approach commercial counterparty-agent sophistication and that protocol design should account for the trajectory rather than the steady state.

v0.1's position is that the economic geometry of the agent ecosystem reproduces the asymmetry; even as user-agent sophistication grows, commercial counterparty-agents have economic incentive to invest disproportionate resources in their negotiation capabilities. Pushback that names a mechanism by which the asymmetry might dissolve, rather than narrow, is welcome.

14.7 Reconciliation deferral

v0.1 defers reconciliation across the compact family. Some reviewers will argue that the deferral is unsustainable — that compacts whose violations cannot be reconciled produce litigation that the protocol's structural requirements cannot prevent and that the family's adoption depends on resolving.

v0.1's position is that reconciliation is a hard problem requiring substantial design work, that v0.1's structural protections reduce the rate of reconcilable disputes, and that legal-and-reputational baseline plus swappable enforcement architecture provides a workable path during the deferral. Pushback that proposes a tractable reconciliation design is welcome — and would be substantively useful for the protocol family's evolution beyond v0.1.

15. Changelog and contact

15.1 Status

This is ACP v0.1, the first published draft of the Agent Compact Protocol. ACP v0.1 is part of a coordinated release that also includes SSP v0.2 and RCP v0.1. The release proposes the compact family of protocols as a coordinated architectural answer to the question of how interactions between agents should be structured to preserve the principals' interests.

The protocol is a draft. It will be revised based on implementation experience, reviewer critique, and the substantive evolution of the agent ecosystem the protocol is designed to operate within. v0.1 establishes the architecture; subsequent revisions will refine, extend, and strengthen the specifications.

15.2 Contact and feedback

Feedback on ACP v0.1 can be directed to Curated Future at curatedfuture.com. The architectural overview accompanying this release names the channels for the coordinated feedback process across SSP, ACP, and RCP.

The companion essay The Contract Problem provides the architectural argument that motivates ACP. It is recommended for readers who want to understand the context in which this protocol is being proposed but is not required to implement it.

ACP v0.1 is a draft. It will be revised.