Appendix A: Worked Example

This appendix is informative. It illustrates how the layers and patterns defined in the normative core may be realized in practice. It does not endorse or require any particular implementation. Chain operators and protocol stewards are encouraged to publish authoritative profiles in their own documentation.

This appendix walks a single transaction scenario through each of the four trust levels in sequence. At each level the seller's legal-context.json adds a new field, the buyer's policy adds a new constraint, and the transaction flow gains a new evidentiary property. The example uses generic HTTP carriers and vendor-neutral placeholders; specific protocols, chains, and signing schemes are not named.

Scenario

A procurement agent acting on behalf of an enterprise buyer at acme.example.com transacts with an API service at api.service.example.com. The same buyer-seller pair is used at every level. As the level rises, so does the complexity of the transaction:

• At Level 1, the agent purchases a single low-value API call.
• At Level 2, the agent enrolls in a recurring API plan; the integrity guarantee matters because the relationship spans multiple charges.
• At Level 3, the agent commits to an annual minimum spend; the commitment justifies a signed acceptance record.
• At Level 4, the buyer requires an institutional dispute path and a returns process; the seller integrates with a third-party recourse provider.

Level 1 — Discoverable Terms

What the seller publishes. At https://api.service.example.com/.well-known/legal-context.json:

{
  "terms": "https://api.service.example.com/legal/api-terms-v3.md"
}

The terms document at the URL is a markdown file describing the service's terms of use, fees, and acceptable-use policy.

What the buyer declares. The procurement agent's principal has declared a buyer policy that for low-value, single-call transactions requires only:

minimum_level: 1
acceptable_jurisdictions: [USA, EU, UK]
required_format: [markdown, plain, json]
single_call_cap_usd: 10.00

The transaction flow.

1. The agent fetches legal-context.json from the service's well-known URL.
2. The agent fetches the terms document at the URL given in terms.
3. The agent's policy engine evaluates the document's stated jurisdiction against the policy. The terms specify the service operates under U.S. law; the policy permits.
4. The agent fetches the resource and pays. The transaction completes.
5. The agent retains a local copy of the terms document for its own records.

What's gained. The seller has published its terms at a known location. The buyer has discovered them and proceeded — implicit acceptance, consistent with browsewrap doctrine. There is no integrity guarantee: the seller could change the document tomorrow and the buyer would have no proof of what was in force today, except its own saved copy.

Level 2 — Adding Provable Integrity

What the seller publishes. The seller adds atrHash:

{
  "terms": "https://api.service.example.com/legal/api-terms-v3.md",
  "atrHash": "0x7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069"
}

The terms document at the URL is byte-stable: serving any other content would produce a different SHA-256 hash and break the published reference.

What the buyer declares. For the recurring API plan, the buyer's policy raises the minimum level and adds a hash-verification requirement:

minimum_level: 2
acceptable_jurisdictions: [USA, EU, UK]
required_format: [markdown, plain, json]
verify_hash_before_paying: true
recurring_plan_cap_usd_per_month: 5000.00

The transaction flow.

1. The agent fetches legal-context.json.
2. The agent fetches the terms document.
3. The agent computes SHA-256 of the document and compares to the published atrHash. They match.
4. The agent's policy engine evaluates the structured fields and permits the transaction.
5. The agent enrolls in the recurring plan. The seller's enrollment proposal includes atrHash so the agent can re-verify at the transaction moment.
6. The agent verifies once more, then accepts the proposal.
7. The seller's receipt includes atrHash. The agent retains the document and the receipt locally.

What's gained. The seller cannot retroactively claim a different document was in force; the buyer cannot later claim different terms were offered. Both parties hold the same authoritative record of what was on offer at the moment of commitment. The asymmetry that favored the party with better records in Level 1 is gone — the cryptographic record is bilateral.

Level 3 — Adding Signed Acceptance

What the seller publishes. The seller advertises acceptanceRequired:

{
  "terms": "https://api.service.example.com/legal/enterprise-terms-v3.md",
  "atrHash": "0x9b2a4d6f8e3c1a0b5f8e1c4d7a2f9b3e6c0a5d8f2b7e4c1a6d9f3e0c5a8b2d7e",
  "acceptanceRequired": true
}

What the buyer declares. The buyer's policy now governs an annual-minimum-spend commitment. It adds signing thresholds and a human-in-the-loop gate:

minimum_level: 3
acceptable_jurisdictions: [USA, EU, UK]
required_format: [markdown, plain, json]
verify_hash_before_paying: true
sign_only_below_usd: 10000.00
require_human_approval_above_usd: 10000.00
allowed_signing_keys: [agent-key-2026-A]

The transaction flow.

1. The agent fetches legal-context.json. The acceptanceRequired: true field signals that the seller will not transact without explicit acceptance.
2. The agent fetches the terms document and verifies atrHash.
3. The agent evaluates the proposed annual commitment ($25,000) against the policy. The amount exceeds sign_only_below_usd, so the policy engine escalates to human review.
4. A human at acme.example.com reviews the terms document, the proposed commitment, and the dispute clauses. The human approves.
5. The agent produces a signed acceptance record over atrHash, the agreement parameters, and a timestamp, using the configured signing key. The signature is sent to the seller as part of the enrollment proposal.
6. The seller verifies the signature, records it, and confirms enrollment. The seller's receipt includes atrHash, the agent's signature, and the seller's confirmation.
7. The agent retains the document, the signature, and the receipt.

What's gained. The record now binds both parties explicitly. The buyer's signature is attributable, timestamped, and bound to a specific atrHash. The seller cannot retroactively claim different terms; the buyer cannot later claim it did not consent. The human in the loop ensured the agent's signing key was invoked under contemporaneous human authorization for a commitment of this size.

Level 4 — Adding Recourse Hooks

What the seller publishes. The seller adds dispute resolution, returns, and a contact block:

{
  "terms": "https://api.service.example.com/legal/enterprise-terms-v3.md",
  "atrHash": "0x9b2a4d6f8e3c1a0b5f8e1c4d7a2f9b3e6c0a5d8f2b7e4c1a6d9f3e0c5a8b2d7e",
  "acceptanceRequired": true,
  "disputeResolution": {
    "method": "AAA Commercial Arbitration Rules",
    "jurisdiction": "New York, USA",
    "contact": "disputes@service.example.com",
    "clauseId": "sha256:0x4f1e8a3c...",
    "source": "https://adr.example.org/clauses/commercial-arbitration",
    "catalog": "https://adr.example.org/.well-known/dispute-services.json"
  },
  "returns": "https://api.service.example.com/api/returns",
  "contact": {
    "legal": "legal@service.example.com",
    "technical": "support@service.example.com"
  },
  "api": "https://api.service.example.com/legal-context/v1"
}

What the buyer declares. The buyer's policy now requires an explicit recourse path:

minimum_level: 4
acceptable_jurisdictions: [USA, EU, UK]
acceptable_dispute_methods:
  - AAA Commercial Arbitration Rules
  - ICC Rules
  - JAMS Streamlined Arbitration Rules
require_returns_process: true
require_legal_contact: true
require_human_approval_above_usd: 10000.00

The transaction flow. The flow is the same as Level 3, with two additional checks before signing:

1. The policy engine evaluates disputeResolution.method against the whitelist. "AAA Commercial Arbitration Rules" is permitted.
2. The policy engine confirms a returns URL is present and a contact.legal is present.

After enrollment, the agent retains the top-level api endpoint and the returns URL in its records, alongside the signed acceptance and the terms document.

What's gained. If a dispute arises later, the buyer's evidence package is complete: the signed terms document with verifiable atrHash, the seller's confirmation, the dispute resolution clause (verifiable via clauseId), and the contact information for filing. The buyer's recourse is institutional rather than ad hoc — the dispute resolution body is named, the jurisdiction is named, the filing path is published.

The Cumulative Evidence Record

After a Level 4 transaction, the parties hold:

No single artifact is sufficient on its own. Together they form an evidentiary record that is independently verifiable by either party and by any institutional dispute forum that adjudicates the agreement. This cumulative record is the bilateral evidentiary chain that LCP's layered model produces.