In Practice

The architecture described in this documentation is not theoretical. This scenario walks through a single transaction — from identity establishment through dispute resolution — to show how each layer of trust in depth operates in practice and what would be missing without it.

The transaction is straightforward. The dispute is commonplace. What is not commonplace is the infrastructure that makes the dispute resolvable.

The Participants

• Maria Santos — VP of Procurement at Meridian Health Systems, a Delaware-incorporated hospital network operating 14 facilities across the Mid-Atlantic region
• ShopAssist — Maria's AI procurement agent, built on Google ADK, authorized to source, negotiate, and purchase medical equipment on Meridian's behalf
• MedTech Precision GmbH — a German medical device manufacturer based in Munich, UCP-compatible, Stripe-verified
• Mastercard — VI Issuer and payment network
• Stripe — Payment service provider, processes the transaction
• AAA — American Arbitration Association, administers disputes under the AAA Commercial Rules
• Integra — Legal context layer providing identity attestations, agreement anchoring, and dispute resolution infrastructure

---

Phase 1: Identity Establishment

Before any transaction occurs, each participant establishes verifiable identity at the appropriate assurance level. This is the foundation on which everything else depends. Without it, every subsequent phase — negotiation, payment, agreement, dispute resolution — operates in a vacuum.

Maria Santos (Tier 1 — Human Identity)

Maria completes a ZK mDL verification — a zero-knowledge proof derived from her state-issued mobile driver's license. The verification proves she is a real, identifiable human without exposing her address, date of birth, or license number. Only the fact of verification is recorded — not the underlying data.

The result is a cross-record EAS attestation anchored on-chain: Tier 1 human identity, verified. This attestation is not scoped to a single transaction or a single protocol. It persists across interactions, across platforms, and across time. When Maria authorizes an agent six months from now, the same human identity anchor applies.

This matters because the alternative — no human identity verification — means that any software process, anywhere, could claim to be acting on behalf of "Maria Santos" with no way to verify or challenge that claim.

Meridian Health Systems (Tier 2 — Entity Identity, High Assurance)

Meridian's entity identity flows through the GLEIF vLEI chain. The chain has four links:

1. GLEIF (Global Legal Entity Identifier Foundation) serves as the root of trust
2. A Qualified Vetting Institution (QVI) is accredited by GLEIF to issue credentials
3. Meridian's Legal Entity Identifier is issued by the QVI, binding the LEI to the legal entity
4. Maria's Official Organizational Role (OOR) — VP of Procurement, authorized signatory — is attested within that LEI

This produces a Tier 2 EAS attestation with high assurance. The vLEI chain is cryptographically verifiable end-to-end: from GLEIF root of trust to Maria's specific authority within Meridian. Any counterparty can verify not just that Meridian is a real organization, but that Maria specifically holds the VP of Procurement role with signing authority.

MedTech Precision GmbH (Tier 2 — Entity Identity, Low Assurance)

MedTech establishes entity identity through its UCP business profile with DNS verification — proving control of the medtechprecision.de domain. This produces a Tier 2 EAS attestation, but at low assurance.

DNS verification proves domain control. It does not prove corporate formation, authorized representatives, regulatory standing, or that the entity behind the domain is the German medical device manufacturer it claims to be. A sophisticated attacker could register a similar domain, set up a UCP-compatible storefront, and pass DNS verification without being a legitimate manufacturer.

The assurance gap is visible immediately. Meridian has high-assurance entity verification through vLEI — a chain that traces from a global standards body through a regulated vetting institution to a specific human with a specific role. MedTech has low-assurance verification through DNS alone — proof of domain control, nothing more.

The trust in depth framework does not hide this asymmetry. It makes it explicit and auditable. Any party evaluating this transaction can see that the buyer's identity chain is significantly stronger than the seller's. This asymmetry does not prevent the transaction — it informs it. A procurement team might accept DNS-level assurance for a $500 supply order. For a $185,000 medical device, the visible gap is a signal worth considering.

ShopAssist (Tier 4 — Agent Authorization)

Maria creates a VI L2 credential for ShopAssist with specific constraints:

• Counterparty: MedTech Precision GmbH only
• Product: Model 7500 MRI Scanner (3.0 Tesla) only
• Maximum value: $250,000
• Expiration: 30 days

The L2 credential is notarially attested and recorded as a Tier 4 EAS attestation. ShopAssist now carries verifiable, bounded authority — not general-purpose procurement capability, but a specific mandate for a specific purchase from a specific vendor within a specific value limit within a specific time window.

The constraints are not advisory. They are cryptographically bound to the agent's credential. If ShopAssist attempted to negotiate with a different vendor, purchase a different model, or exceed the value cap, the constraint violation would be detectable at every layer of the stack.

Note the completeness of the identity chain at this point, before any transaction has occurred:

Every participant has an identity attestation. Every attestation records what was proven and at what assurance level. The asymmetry between Meridian's high-assurance entity identity and MedTech's low-assurance entity identity is visible to anyone inspecting the transaction before it occurs.

---

Phase 2: The Commerce Transaction

Discovery and Negotiation

ShopAssist discovers MedTech through its UCP /.well-known/ucp manifest and initiates a procurement workflow. Six negotiation interactions follow, each hash-anchored via the Communication Resolver:

1. Catalog search — ShopAssist queries MedTech's product catalog for MRI equipment
2. Product listing — MedTech returns available models, including Model 5000 (1.5T, $95K) and Model 7500 (3.0T, $189.5K)
3. Pricing inquiry — ShopAssist requests volume pricing for Model 7500
4. Quote — MedTech quotes $189,500 for one Model 7500, delivered within 8 weeks
5. Counter-offer — ShopAssist offers $182,000, citing Meridian's multi-facility purchasing history
6. Acceptance — MedTech accepts $185,000 for one Model 7500 (3.0 Tesla), 8-week delivery

Every interaction is recorded. Every record is independently verifiable. The Communication Resolver does not store the full content of each exchange — it stores cryptographic hashes that prove what was communicated, when, and between which parties. The full content is stored off-chain, but the hashes on-chain mean that neither party can later alter what was said without the alteration being detectable.

This is a critical distinction from email, phone calls, or even typical API logs. In a traditional dispute, negotiation records are whatever each party's system captured — and those records are under each party's control. Communication Resolver records are anchored by neither party. They are independently verifiable by anyone with access to the record.

Checkout and Payment

UCP checkout proceeds with a merchant_authorization JWS — a JSON Web Signature created and signed by MedTech — covering the agreed terms: Model 7500, $185,000, 8-week delivery. This is not Meridian's record of what was agreed. It is MedTech's own cryptographic commitment to the transaction terms.

The merchant_authorization is the single most important piece of evidence in this entire transaction. It is MedTech's own signature on a document that specifies Model 7500. It cannot be repudiated. It cannot be claimed to be a forgery. It is a cryptographic commitment by MedTech to deliver a specific product at a specific price.

Two VI L3 credentials are created from Maria's L2:

• L3a — Payment mandate to Mastercard, authorizing $185,000
• L3b — Checkout mandate to MedTech, specifying Model 7500

Each L3 credential inherits the constraints of the L2 that produced it. The delegation chain — from Maria (L1 human identity) to ShopAssist (L2 agent authorization) to the specific checkout and payment actions (L3a, L3b) — is unbroken and verifiable at every link.

Payment is delegated through Stripe via ACP's delegate_payment mechanism. $185,000 is authorized and settled.

The Commerce Resolver tracks the transaction against ShopAssist's authorization bounds: $185,000 of $250,000 maximum utilized (74%). If ShopAssist attempted a second purchase that would exceed the $250,000 cap, the Commerce Resolver would flag the constraint violation before payment authorization. The cumulative tracking is automatic — not dependent on Maria monitoring her agent's spending in real time.

---

Phase 3: Agreement Anchoring

With the transaction complete, the full agreement is anchored on-chain.

An IntegraRecordV1 is registered with a contentHash binding to all transaction artifacts — the negotiation records, the merchant authorization, the VI credential chain, the payment confirmation, and the delivery terms. The contentHash is a cryptographic fingerprint of the complete agreement. If any artifact is altered after the fact, the hash will not match.

Five resolvers are attached to the record:

Three agreement tokens are reserved and claimed by the parties — Meridian (buyer), MedTech (seller), and the agreement itself (neutral). The agreement is now bound: immutable, independently verifiable, connected to a specific dispute resolution forum, and tied to identified parties through verified credential chains.

The entire agreement — from identity through negotiation through payment through anchoring — is now a single, coherent, verifiable record. Not a collection of emails, invoices, and phone call notes scattered across two companies' internal systems. A unified record that no single party controls and no single party can alter.

---

Phase 4: The Problem

Seven weeks later, a crate arrives at Meridian's receiving dock.

Inside is an MRI scanner. But it is a Model 5000 — a 1.5 Tesla unit with a list price of $95,000 — not the Model 7500 (3.0 Tesla, $185,000) that was ordered, negotiated, agreed to, and paid for.

The difference is not cosmetic. A 1.5 Tesla MRI and a 3.0 Tesla MRI are fundamentally different diagnostic instruments. The 3.0T unit provides higher resolution imaging essential for neurological and musculoskeletal diagnostics. Meridian's radiologists specified the 3.0T unit because their diagnostic workflows require it. The 1.5T unit cannot serve the same clinical purpose.

MedTech claims they shipped what was ordered. Their internal order management system shows the line item as "MRI Scanner" without a model number. From MedTech's perspective, there is no discrepancy — their system recorded "MRI Scanner," and they shipped an MRI scanner. Whether this is genuine confusion, a data entry error, or something more deliberate is unknowable from MedTech's internal records alone.

Without Trust in Depth

Without the trust in depth infrastructure, this dispute would reduce to a familiar pattern: one party's word against the other's.

MedTech's internal system says "MRI Scanner." Meridian says they ordered a specific model. MedTech controls their own records. Meridian has emails and chat logs that may or may not be complete, may or may not be admissible, and are stored on systems Meridian controls.

The available remedies would be:

• Credit card chargeback — limited to 120 days from the transaction, limited to the payment amount, governed by card network rules that are not designed for specification disputes on complex equipment. A chargeback analyst evaluating "did the merchant deliver what was ordered?" has no mechanism for determining what was ordered beyond each party's own records.
• Litigation — a Delaware company suing a German manufacturer. Cross-border litigation is slow (12-24 months typical), expensive ($50K-$200K in legal fees for a case of this complexity), and jurisdictionally uncertain. Which court has jurisdiction? Which country's law applies? These threshold questions could consume months of legal argument before the merits are even reached.

With Trust in Depth

With trust in depth, every layer of the original transaction is independently verifiable. The evidence is not reconstructed from each party's internal systems. It is anchored on infrastructure that neither party controls.

---

Phase 5: Dispute Resolution

Initiation

Maria initiates a dispute on the AAAResolverV1 attached to the agreement record. The resolver transitions to INITIATED. The dispute is linked directly to the agreement record — all transaction artifacts, identity attestations, and communication records are immediately accessible to the dispute process.

Filing

An AAA Provider Agent reviews the filing, confirms the dispute falls within the scope of the AAAResolverV1, binds the case, and transitions the resolver to FILED. MedTech receives formal notice with a 30-day response deadline.

The filing is not a letter to a P.O. box. It is an on-chain state transition on a resolver that MedTech agreed to when the agreement was anchored. MedTech's participation in the dispute process is not optional — it is a term of the agreement they entered.

Evidence

Both parties submit evidence through the resolver's structured evidence mechanism.

Maria's evidence:

• VI credential chain — The L2 credential specifies Model 7500 explicitly. ShopAssist never had authority to purchase any other model. The L3b checkout mandate specifies Model 7500. The delegation chain from Maria to ShopAssist to checkout is unbroken and cryptographically verifiable. This proves not just what was ordered, but that the agent was authorized to order only that specific product.

• Communication Resolver records — The six negotiation interactions show MedTech listing Model 7500 at $189,500, MedTech quoting Model 7500 at $189,500, MedTech accepting $185,000 for Model 7500. Each interaction is hash-anchored and independently verifiable. The records cannot have been altered after the fact — the on-chain hashes would not match.

• UCP merchant authorization — MedTech's own JWS-signed checkout authorization specifying Model 7500 at $185,000. This is not Maria's claim about what MedTech agreed to. It is MedTech's own cryptographic signature on the agreed terms. MedTech signed a document that says "Model 7500." They cannot credibly claim they committed to anything else.

• Delivery receipt — Serial number on the delivered unit corresponds to a Model 5000 (1.5 Tesla), as confirmed against the manufacturer's own serial number registry.

• Manufacturer specifications — Model 5000 and Model 7500 are distinct products with different field strengths, different imaging capabilities, different physical dimensions, and different price points. There is no reasonable interpretation under which they are interchangeable.

MedTech's evidence:

• Internal order system — Shows "MRI Scanner" without model number.
• Shipping manifest — Shows one MRI scanner shipped to Meridian Health Systems.

The evidentiary asymmetry is stark. Maria's evidence is cryptographically anchored, independently verifiable, and includes MedTech's own signed commitment to a specific product. MedTech's evidence consists of their own internal system — which they control, and which shows incomplete information — and a shipping document that confirms only that some MRI scanner was shipped.

Award

The arbitrator — operating under AAA Commercial Rules with full access to the on-chain evidence — issues an award:

MedTech Precision GmbH shall deliver one Model 7500 (3.0 Tesla) MRI scanner to Meridian Health Systems within 45 days of this award, or provide a full refund of $185,000 plus $15,000 in consequential damages for the disruption to Meridian's diagnostic scheduling caused by the delivery of non-conforming equipment.

The award is based on the weight of evidence that no traditional dispute mechanism could have produced. The merchant_authorization alone — MedTech's own cryptographic signature on the specification — would likely have been dispositive. Combined with the Communication Resolver records, the VI credential chain, and the delivery receipt, the case is unambiguous.

Compliance

The AAAResolverV1 tracks compliance with per-requirement deadlines. The award is not a suggestion. It is not a recommendation. It is an enforceable arbitration award under the New York Convention on the Recognition and Enforcement of Foreign Arbitral Awards — recognized and enforceable in over 170 countries, including Germany.

If MedTech does not comply, Meridian can enforce the award in German courts under the Convention. The enforcement proceeding is streamlined — the court does not retry the merits, it enforces the award. This is the institutional infrastructure that makes the dispute resolution meaningful, not just procedural.

The entire dispute — from initiation through award — proceeds through a defined lifecycle:

Every state transition is recorded on-chain. The lifecycle is auditable by both parties. Neither party can claim they were not given the opportunity to respond.

---

Phase 6: What Every Layer Proved

---

The Lesson

Remove any single layer and the outcome changes.

Without human identity verification, MedTech could argue the purchase was initiated by an unauthorized bot — software with no connection to any accountable person. Without entity attestation, MedTech could argue Maria had no authority to bind Meridian to a $185,000 commitment — that she was a rogue employee or an impersonator. Without agent authorization constraints, MedTech could argue ShopAssist exceeded its mandate — that it was authorized only for general inquiries, not purchases.

Without the Communication Resolver, there would be no independent record of the negotiation — just each party's own logs, which each party controls. Without MedTech's own merchant authorization signature, they could plausibly deny agreeing to Model 7500 — their internal system, after all, shows only "MRI Scanner." Without the Commerce Resolver, there would be no verifiable record of cumulative agent spend or whether the transaction fell within authorized bounds.

Without the AAAResolverV1, the only recourse would be a credit card chargeback — limited to 120 days, limited to the payment amount, incapable of ordering specific performance or consequential damages, and fundamentally not designed to analyze equipment specifications. Without AAA's institutional authority, any dispute outcome — however well-reasoned — would carry no legal weight. An AI panel analyzing evidence and producing a recommendation is not an arbitration award. It is not enforceable under the New York Convention. It is not recognized by any court.

Every layer was necessary. No single layer was sufficient.

This is trust in depth in practice. Not a theoretical framework, but a concrete architecture where each layer contributes something that no other layer provides, and the composition of all layers creates an outcome that none could achieve alone.