# PoC, Legal Context Protocol, and Pathways — Standards Interoperability Brief

**For:** AAIS Proof-of-Control project committee and interoperability working group  
**Assumes:** Working familiarity with PoC architecture v0.1.0 (May 2026)  
**Introduces:** Legal Context Protocol (LCP), optional Pathways orchestration, and their relationship to PoC  
**Date:** June 2026

---

## How to use this brief

If you already live inside the PoC draft — binary threshold, verification spectrum, domains, tiers, trust taxonomy — you do not need a recap of why the Verifiability Gap matters. This document answers the next questions the committee is likely to face as agentic commerce matures:

1. **What is the Legal Context Protocol**, and why will PoC adopters encounter it?  
2. **How does PoC relate to LCP** — complement, overlap, or collision?  
3. **Where does Pathways fit** (if at all) for LCP implementers and for PoC WD 1.0?  
4. **What is still only proposed** for WD 1.0 versus what v0.1.0 already defines?

Sections 1–8 stand alone: no prior materials required. **Section 9** lists WD 1.0 extension ideas that appear in the GitHub repository associated with this work — they are **not** part of v0.1.0 unless the committee adopts them. **Section 10** explains that repository for readers who arrive via GitHub.

---

## 1. PoC v0.1.0 — what the draft already defines

The May 2026 architecture working draft establishes:

| Element | Status in v0.1.0 |
|---------|------------------|
| Binary conformance threshold | Defined — PoC property present or absent |
| Verification spectrum (Stages 1–3) | Defined |
| Five evidence domains (Privacy, Portability, **Authorization**, Security, Identity) | Defined in **v0.1.0-rev** |
| Core PoC evidence (what the system did) | Defined in **v0.1.0-rev** — not a separate domain (replaces base Verifiability domain) |
| Sixth domain (Provenance) | Flagged proposed / TBD in the draft itself |
| Conformance tiers (Self-Declared, Third-Party Assessed, Continuously Monitored) | Tier **labels** defined |
| Trust-assumption disclosure (six categories) | Defined |
| Verification vs validation boundary | Defined — cryptography verifies boundary compliance, not intent or output correctness |
| Insurance-first adoption thesis | Strategic framing in draft |

**Still open in v0.1.0** (gaps the committee is already debating, not resolved in the May draft):

- Operational meaning of Tier 3 “Continuously Monitored” (beyond the name)  
- Evidence interoperability (schemas, event types, verifier APIs)  
- Scoped conformance statements when only some domains apply  
- Mutable and self-modifying systems — lifecycle evidence for model updates  
- Whether and how to normative Provenance as a sixth domain  

Section 9 catalogs **additional** extension ideas submitted through the GitHub repository. Treat those separately from the draft text above.

---

## 2. Introducing the Legal Context Protocol (LCP)

**Stewards:** American Arbitration Association–ICDR and Integra Ledger  
**Specification:** v1.4-draft (pre-announcement), Apache 2.0  
**Site:** [legalcontextprotocol.org](https://legalcontextprotocol.org/)

### 2.1 The problem LCP addresses

Payment, checkout, and identity protocols (ACP, UCP, AP2, x402, Visa TAP, Mastercard Agent Pay) handle value transfer and authorization. They **defer** a different problem: **what legal terms governed the transaction**, and **how to prove which terms version applied** when an agent acted without a human click-through.

Human e-commerce grew up around browser consent and terms-of-service pages. Agent-to-agent commerce breaks that pattern: agents negotiate and pay autonomously; payment records alone do not carry immutable legal terms.

### 2.2 Mechanism

One well-known URL per domain:

```
https://{any-domain}/.well-known/legal-context.json
```

Minimum discovery file (illustrative):

```json
{
  "terms": "https://example.com/terms/v3.json",
  "atrHash": "0x7f83b1657ff1fc53b92dc18148a1d65d...",
  "acceptanceRequired": true
}
```

| Field | Role |
|-------|------|
| `terms` | URL to a standalone, downloadable terms artifact (PDF, JSON, Markdown, etc.) |
| `atrHash` | SHA-256 Agreement Terms Reference — proves exact terms at transaction time |
| `acceptanceRequired` | Whether explicit acceptance is required before proceeding |

Cross-stakeholder agreement to date: store the ATR hash **with the payment record** so disputes have one source of truth about governing terms.

### 2.3 Four levels of trust

Stake-proportional — none required, each independently useful:

| Level | Name | What it adds |
|-------|------|--------------|
| 1 | Informational | Agent finds terms; proceeding may imply consent |
| 2 | Provable | ATR hash proves terms content and immutability |
| 3 | Signed | Digital signature binds a party to specific terms |
| 4 | Integrated | Hooks to dispute resolution, escrow, compliance, private terms |

### 2.4 Scope discipline (“separation of concerns”)

LCP stewards are explicit: LCP makes legal terms **discoverable and permanent**. It does **not** solve AI hallucination, agent authority, contract performance, or output correctness. That narrow scope mirrors PoC’s verification-not-validation boundary from the opposite direction.

---

## 3. Where PoC and LCP sit in the stack

| Layer | Role | Examples |
|-------|------|----------|
| Commerce | Payments, checkout, carts | ACP, UCP, AP2, x402, Visa TAP |
| Legal (LCP) | Terms discoverability, ATR hash, acceptance | `.well-known/legal-context.json` |
| Identity | Agent PKI, delegation, authorization | Visa TAP, Mastercard Agent Pay |
| Control (PoC) | Runtime evidence of boundaries and actions | TEE, ZK, consensus timestamps |
| Orchestration (optional) | Multi-step auditable agent workflows | Pathways (Section 6) |

PoC and LCP occupy **different rows**. They meet at transaction boundaries and in dispute evidence packages; neither subsumes the other.

---

## 4. PoC and LCP — how they relate

### 4.1 Two different questions

| Dimension | PoC | LCP |
|-----------|-----|-----|
| Core question | Did the AI stay within declared control boundaries at runtime? | What legal terms governed the transaction, and which version applied? |
| Primary evidence | Contemporaneous runtime cryptographic evidence | Terms document + ATR hash (+ optional signature) bound to payment |
| Binary threshold | Yes — per scoped conformance statement | No — four trust levels |
| Moment of truth | Execution | Agreement / payment |
| Explicit non-claims | Output correctness; whether boundaries were wise | Agent authority; AI quality; performance |

**Plain language:** LCP answers *what did we agree to?* PoC answers *what did the AI do?* A PoC-conformant deployment can still operate under catastrophic terms. An LCP-compliant transaction can still involve an AI that violated its boundaries.

### 4.2 One transaction, four phases

**Pre-transaction (LCP-primary):** Agent fetches legal-context.json, retrieves terms, verifies ATR hash, parses machine-readable clauses if present, escalates per `acceptanceRequired`.

**Transaction (LCP + commerce):** Payment executes; ATR hash stored with payment record; optional signed acceptance at Level 3.

**Execution (PoC-primary):** Agent operates within declared boundaries; PoC mechanism produces contemporaneous evidence (not operator-narrated logs).

**Post-incident (both):** Contract disputes lean on LCP terms immutability; control disputes lean on PoC runtime evidence; insurance claims may need **both** — coverage scope from terms hash, moral hazard from control evidence.

### 4.3 Domain crosswalk (PoC v0.1.0 draft)

| PoC domain | Relationship to LCP |
|------------|---------------------|
| Identity | Adjacent. PoC proves runtime delegation; LCP does not prove authority to accept terms. |
| Privacy | Partial overlap. LCP terms may state constraints; PoC Privacy proves runtime enforcement. |
| Verifiability / Authorization | Strong complement. ATR hash = verifiable terms; PoC **core evidence** = verifiable actions; **Authorization domain** = permissions and delegation. |
| Security | Mostly orthogonal. Runtime attestation vs optional LCP signatures / Integra hooks. |
| Portability | Weak link. Cross-vendor control vs `.well-known` discoverability pattern. |
| Provenance (TBD in draft) | Conceptual overlap on lineage — different objects (model/context vs terms artifact). |

### 4.4 Trust architecture comparison

**PoC (v0.1.0):** Tiers measure assessment rigor; six-category trust-assumption taxonomy compares Stage 3 mechanisms without picking TEE vs ZK vs consensus.

**LCP:** Four levels measure terms-evidence strength; Level 4 adds dispute infrastructure without requiring blockchain at base layer.

**Shared pattern:** Stake-proportional assurance. **Shared risk:** Marketing conflation — “LCP” does not mean “PoC,” “legally safe,” or “AI behaved correctly.”

### 4.5 Insurance and disputes

| Evidence | Source | Typical use |
|----------|--------|-------------|
| Terms immutability | LCP atrHash in payment record | Coverage scope, exclusions |
| Runtime boundary compliance | PoC Stage 3 evidence | Control quality, moral hazard |
| Assessment rigor | PoC Tier 2/3 | Premium tier |
| Residual trust profile | PoC trust taxonomy (v0.1.0) | Differentiation within conformant set |
| Dispute path | LCP Level 4 (optional) | Claims handling |

Neither standard alone supports full actuarial modeling of agentic AI liability. Together they separate **contractual context** from **operational control**.

### 4.6 Composable evidence package (illustrative)

Separate hash domains; link by transaction ID:

```json
{
  "transaction_id": "...",
  "legal_context": {
    "lcp_discovery_url": "https://supplier.example/.well-known/legal-context.json",
    "terms_url": "https://supplier.example/terms/v3.json",
    "atr_hash": "sha256:..."
  },
  "proof_of_control": {
    "conformance_statement_ref": "poc-registry:...",
    "domains_covered": ["Identity", "Authorization", "Security"],
    "tier": 2,
    "runtime_evidence_ref": "..."
  }
}
```

**Guardrail:** Do not merge atrHash, PoC evidence digests, or unrelated seal hashes into one composite hash.

### 4.7 Gaps neither standard solves alone

- Agent authority to bind a principal (formation, ratification)  
- Cross-jurisdiction terms selection  
- Emergent multi-agent causation  
- Performance vs compliance (terms honored but deliverable failed)  

---

## 5. Committee recommendations — PoC and LCP

**P0 — Non-normative PoC–LCP crosswalk appendix in WD 1.0.** Prevents procurement category confusion.

**P0 — Separate evidence object types** for terms hash vs runtime control evidence.

**P1 — Liaison with AAA/LCP stewards** on shared verify/validate vocabulary.

**P1 — Linked fields** between LCP atrHash and any future PoC Evidence Object schema (not merged objects).

**P2 — Insurance working group scenario** requiring both atrHash and PoC evidence in a single claim narrative.

**Do not:** Expand PoC into agreement formation (LCP’s center of gravity); require LCP for PoC conformance; imply LCP Level 2 satisfies PoC binary threshold.

---

## 6. Pathways and LCP — optional orchestration layer

*For readers focused on PoC: Pathways is a separate orchestration architecture. It is not part of PoC v0.1.0 and not required for LCP. It matters here because LCP defines **what** must be discoverable, not **how** agents operationalize multi-step terms workflows.*

### 6.1 What Pathways is

Pathways is a **versioned orchestration model** for multi-step agent work:

- **Template** — named recipe (`Domain.Subdomain.Action@version`) with steps and contracts  
- **Run** — one execution with step-level audit (agent, model, inputs, outputs, timing)  
- **Composable sub-runs** — workflows that call workflows  

Pathways is neither a legal-terms protocol nor a runtime control standard. It is machinery for **repeatable, auditable agent procedures** — including procedures that implement LCP.

### 6.2 Why LCP implementers may want orchestration

LCP does not specify how an agent should:

- Fetch terms across many counterparty domains  
- Compare terms versions over time  
- Escalate when `acceptanceRequired` conflicts with delegation limits  
- Normalize PDF vs JSON terms  
- Record who fetched what, when, with which model  
- Bind atrHash across heterogeneous payment protocols  
- Assemble dispute packets for neutrals  

Those are orchestration problems. Pathways (or any equivalent workflow engine) is one way to encode them as reusable templates with audit trails.

### 6.3 Illustrative template family (non-normative)

| Template (illustrative) | Purpose |
|-------------------------|---------|
| `Legal.Commerce.DiscoverTerms@v1` | Fetch and validate legal-context.json |
| `Legal.Commerce.VerifyATRHash@v1` | Download terms, verify hash |
| `Legal.Commerce.ParseTermsJSON@v1` | Extract governing law, dispute clauses |
| `Legal.Commerce.BindTermsToPayment@v1` | Include hash in payment record |
| `Legal.Commerce.EscalateForAcceptance@v1` | Human gate when required |
| `Legal.Commerce.AssembleDisputePacket@v1` | Export terms + fetch provenance + payment ref |

Each run produces an auditable record: which model parsed which terms version at what time — useful to AAA neutrals, but **not** a substitute for LCP Level 3 signatures or PoC Stage 3 runtime evidence.

### 6.4 Honest boundaries

Pathways does not make terms enforceable, replace atrHash, prove agent authority, or automatically produce PoC-conformant runtime evidence.

**For the PoC committee:** Pathways × LCP is a **separate track** from Pathways × PoC Provenance (Section 9). PoC should not normatively mandate Pathways for conformance; LCP implementers may still adopt it voluntarily.

---

## 7. Three-way composition

When all three exist in one deployment:

- **LCP** — what terms governed the transaction  
- **Pathways** (optional) — how agents processed those terms (auditable workflow)  
- **PoC** — whether runtime behavior stayed within control boundaries  

Recommended dispute evidence order:

1. LCP atrHash + terms document (contractual baseline)  
2. Orchestration audit trail, if any (diligence: who read what, when)  
3. PoC runtime evidence (operational behavior vs boundaries)  

---

## 8. Maturity snapshot

| Standard | Maturity (June 2026) |
|----------|----------------------|
| PoC v0.1.0 | Working draft; substantial proto-standard content |
| LCP v1.4-draft | Pre-announcement; discovery schema clear; full normative spec emerging |
| Pathways v1.1.0 | Published architecture + RIS; engine features partially shipped |
| PoC × LCP linkage | Conceptually clear; not yet standardized |
| Pathways × LCP | Architecturally coherent; no normative Legal.Commerce.* family yet |

---

## 9. Proposed WD 1.0 extensions (not in v0.1.0)

The following are **recommendations under discussion** for Working Draft 1.0. They are **not** part of the May 2026 architecture text unless the committee adopts them. Several originate from contributors who used the GitHub repository (Section 10) to submit structured feedback; they are listed here so readers can distinguish **draft content** from **proposals**.

### 9.1 Provenance and evidence interoperability

| Proposal | Summary |
|----------|---------|
| Normative Provenance domain | Elevate sixth domain from TBD to required WD 1.0 decision |
| Provenance reference implementation | Use existing orchestration provenance patterns rather than parallel schema invention |
| PoC Evidence Object (canonical JSON) | Assessor interoperability; optional link fields to LCP atrHash |
| Model-update provenance record | Who authorized change, what changed, when active — for dynamic deployments |

### 9.2 Self-modifying and dynamic AI

| Proposal | Summary |
|----------|---------|
| Model State Identity (MSID) | Bind actions to exact model state, not deployment label alone |
| Dynamism classification | Explicit bands; assurance decreases as dynamism increases |
| “Model Updated” lifecycle stage | Contemporaneous evidence at update time |
| Scoped conformance statements | “PoC-conformant for {domains} at {tier} for {stages} under {trust profile}” |

### 9.3 Tier 3 and structured disclosure

| Proposal | Summary |
|----------|---------|
| Operational Tier 3 requirements | Cadence, drift detection, evidence SLAs, incident hooks |
| Structured trust manifest | Machine-readable layer on v0.1.0’s six-category taxonomy |

### 9.4 What remains v0.1.0 (not proposals)

Verifiability Gap framing; binary threshold; verification spectrum; five core domains; Provenance flagged TBD **in the draft**; tier labels; six-category trust taxonomy; verification-not-validation; insurance adoption thesis; SOC 2 complementarity.

---

## 10. About the GitHub repository

Readers who find this brief through GitHub are looking at a **Proof-of-Control feedback repository** — not the AAIS PoC standard itself, and not the LCP specification.

### 10.1 What the repository is

A **signed collaboration bundle**: a self-contained snapshot of structured feedback on PoC architecture v0.1.0, delivered as verifiable files rather than email or slides. The repo root points to an authoritative dated folder:

```
collaboration/20260602-160000/
```

That folder holds executive summaries, architecture review PDFs, optional Pathways alignment material, and machine-readable indexes. A companion index at the bundle root (`companion-bundle-index.md`) is the usual entry point for humans; agents may start from `START_COLLABORATION_HANDOFF.prompt.md` at the repository root.

### 10.2 Integrity verification

Anyone can verify byte integrity offline:

```bash
python3 tools/collaboration-bundle/sign_bundle.py verify collaboration/20260602-160000
```

Expected result: `verify: OK` — meaning files match a SHA-256 manifest and an Ed25519 signature over the bundle root hash. Cryptographic verify proves **integrity**, not that the committee endorses the feedback.

### 10.3 How this brief relates to the repository

| This brief (Sections 1–8) | Repository contents |
|---------------------------|---------------------|
| Standalone interoperability analysis for PoC + LCP (+ optional Pathways) | Full architecture review, strategic reports, origin exports, hypotheses, Pathways templates |
| No dependency on bundle structure | Bundle **is** the delivery format for deeper feedback |
| Section 9 summarizes WD 1.0 **proposals** found in the repo | Detailed rationale, schemas, and experiments live in repo artifacts |

If you need depth beyond this brief — comprehensive gap analysis, Pathways–Provenance mapping, pre-registered experiments — open the bundle index inside `collaboration/20260602-160000/`. If you only need PoC–LCP positioning for WD 1.0, Sections 1–8 suffice.

### 10.4 What the repository is not

- Not an AAIS normative standard publication  
- Not the LCP specification (see [legalcontextprotocol.org](https://legalcontextprotocol.org/))  
- Not proof that proposed Section 9 items are adopted  
- Not a live system — origin exports are static; no external API access required to read  

---

## Closing note for the committee

PoC and LCP will appear together in procurement, insurance, and dispute conversations long before either standard reaches final form. The committee’s highest-leverage near-term action is a **clear, public story**: PoC proves runtime control; LCP proves terms context; link them in evidence packages without merging hash domains or scope claims.

Assign a small interoperability tiger team to draft the PoC–LCP crosswalk for WD 1.0 and open a liaison channel with AAA LCP stewards. Evaluate Section 9 proposals on merit — separately from what v0.1.0 already defines.

---

*Standalone brief. For repository layout and verification, see Section 10.*