Technical Note: LAKEer and UCP Architecture.

Three protocols, one transaction

A common mistake when teams first scope agentic commerce is treating UCP, AP2, and MCP as competing standards. They're composable, they answer different questions, and a single transaction typically uses all three:

The property of UCP that matters most here: capabilities are declared in a standardized JSON profile at /.well-known/ucp, and they can be standard (defined by the specification) or vendor-defined extensions. In practice, vendors advertise their own versioned capabilities within their own namespace, allowing agents to discover them alongside standard UCP capabilities.

LAKEer's verification is declared as exactly that: a vendor capability that extends dev.ucp.shopping.catalog, opt-in per merchant, discovered when the agent retrieves the merchant's UCP profile. A merchant who hasn't onboarded simply doesn't list it — the capability never enters the negotiated intersection, and agents fall back to catalog-only behavior. Nothing breaks.

Phase one: enrichment happens offline

Before any live query touches LAKEer, the merchant's documents go through a continuous offline pipeline — datasheets, warranty terms, supplier agreements, price schedules, compliance and shipping documents. A nine-stage ingestion process parses them (OCR where needed), chunks and embeds them, resolves entities across documents, and builds a knowledge graph.

The extraction isn't free-form. It's guided by GoodRelations — the OWL ontology behind Schema.org's product markup — so what lands in the graph is typed structure: gr:Offering linking product, price, warranty, and seller; gr:PriceSpecification carrying currency, tier conditions, and eligibility; gr:WarrantyPromise with scope and duration; gr:QualitativeValue encoding compatibility and substitutability as traversable relationships rather than "compatible: true" strings.

Before anything publishes, extracted data passes through ClaimGuard — our multi-stage verification pipeline — for cross-document validation, price-variance QA, and ontology-level consistency checks (every price specification must carry a currency and value; every warranty promise must carry scope and duration). Only then does the verified data flow back into the merchant's own enriched catalog feed. This pipeline runs on batches, continuously. It is never in the path of a live transaction.

Discovery: the manifest is the integration

At session initialization, a UCP agent fetches the merchant's manifest and finds the extension declared alongside core capabilities:

The following manifest is an illustrative example showing how a merchant could expose a verification extension alongside standard UCP capabilities. It is not intended to reproduce the complete UCP profile schema verbatim.

GET /.well-known/ucp

{
  "ucp": {
    "version": "2026-04-08",
    "services": {
      "dev.ucp.shopping": [
        { "version": "2026-04-08",
          "spec": "https://ucp.dev/2026-04-08/specification/overview",
          "schema": "https://ucp.dev/2026-04-08/services/shopping/rest.openapi.json",
          "transport": "rest",
          "endpoint": "https://merchant.com/ucp/v1" }
      ],
      "ai.daax.shopping": [
        { "version": "2026-04-08",
          "spec": "https://daax.ai/ucp/specification/verification",
          "schema": "https://daax.ai/ucp/services/verification/mcp.openrpc.json",
          "transport": "mcp",
          "endpoint": "https://lakeer.{merchant-id}.daax.ai/mcp/v1" }
      ]
    },
    "capabilities": {
      "dev.ucp.shopping.catalog": [
        { "version": "2026-04-08",
          "spec": "https://ucp.dev/2026-04-08/specification/catalog",
          "schema": "https://ucp.dev/2026-04-08/schemas/shopping/catalog.json" }
      ],
      "ai.daax.shopping.verification": [
        { "version": "2026-04-08",
          "spec": "https://daax.ai/ucp/specification/verification",
          "schema": "https://daax.ai/ucp/schemas/shopping/verification.json",
          "extends": "dev.ucp.shopping.catalog" }
      ]
    }
  }
}

The agent opens an MCP session (JSON-RPC 2.0) to the stable per-tenant endpoint declared in services, calls tools/list, and caches the one tool LAKEer exposes. UCP leaves the authentication mechanism to the parties — API keys, OAuth 2.0, mTLS, or RFC 9421 HTTP Message Signatures — and requires that the authenticated principal be checked against the profile named in the UCP-Agent header. By the time a shopper types a question, the session is warm.

Phase two: the runtime query path

A shopper asks: "Find me a compatible charging dock for ProBook X4, under $100." The UCP app parses intent and queries the merchant's catalog capability first — basic keyword search over the enriched feed, returning candidates with flat attributes. Fast, cheap, and fully functional on its own. But "compatible" isn't a flat attribute. So the app selects candidates and calls the extension:

{
  "jsonrpc": "2.0",
  "id": "ucp-req-001",
  "method": "tools/call",
  "params": {
    "name": "lakeer_ecommerce_verify",
    "arguments": {
      "meta": {
        "ucp-agent": {
          "profile": "https://agent.example/profiles/shopping-agent.json"
        }
      },
      "product_id": "PD-200",
      "claims": ["compatibility", "warranty", "pricing"]
    }
  }
}

Inside LAKEer, the query fans out across six retrieval channels combined with Reciprocal Rank Fusion — HNSW vector similarity, BM25 keyword, Personalized PageRank graph traversal, semantic unit, table, and entity channels. Multi-channel retrieval is what lets a constraint like "under $100" filter a numeric field consistently across every ingested document instead of surfacing whichever single document ranks highest textually, and what lets a shopper's plain-English phrasing resolve to the vocabulary the source documents actually use. The graph is then traversed over its typed relationships, and ClaimGuard verifies each claim against source documents — decomposing the draft into individual assertions, then testing each for eligibility, factuality, and citation binding before assigning a verdict.

The response is structured verification, not a paragraph of prose:

{
  "jsonrpc": "2.0",
  "id": "ucp-req-001",
  "result": {
    "structuredContent": {
      "ucp": {
        "version": "2026-04-08",
        "capabilities": {
          "ai.daax.shopping.verification": [{ "version": "2026-04-08" }]
        }
      },
      "verified": true,
      "claim_breakdown": [
        { "claim": "compatibility", "status": "verified",
          "detail": "Compatible with ProBook X4 (Gen-2)",
          "source_doc": "vendor_spec_2026_Q1.pdf", "paragraph": 42 },
        { "claim": "warranty", "status": "verified",
          "detail": "2-year limited" },
        { "claim": "pricing", "status": "verified",
          "detail": "$89.00, Enterprise A tier" }
      ],
      "lakeer_verification_id": "lakeer-vid-2026-07-20-abc123"
    }
  }
}

Three fields do most of the work. verified is a strict aggregate — true only if every claim passed. There is deliberately no scalar confidence score: a single number tells an agent that something in the answer is questionable without telling it what, which is exactly the decision the breakdown exists to support. claim_breakdown enables per-claim decisions: if compatibility fails but warranty and pricing hold, the app can say exactly that, and merchant policy decides whether checkout is blocked or allowed with a warning. And lakeer_verification_id attaches to the order metadata at checkout, so every agent-committed purchase carries a durable record of what was checked, against which documents — the audit trail compliance teams ask about first.

The app merges catalog results with verified claims and answers the shopper: "ProDock 200 — ✓ verified compatible with ProBook X4, 2-year warranty, $89.00." On confirmation, UCP's standard checkout takes over — cart, price validation, AP2 tokenized payment — and LAKEer's involvement is already finished. It did its work before commitment, which is the only place verification is worth anything.

When verification can't verify

A verification layer earns trust by how it fails, not how it succeeds. Three behaviors matter. If the documents don't contain the answer, ClaimGuard declines rather than inventing one — and the integration is specified to surface that as a legitimate "no grounded answer," not an error. If two sources disagree — a spec sheet and a price list that don't reconcile — LAKEer surfaces both sources and the conflict rather than silently picking one, and the product is flagged for merchant review. And if LAKEer itself is slow or down, the agent falls back to catalog-only results for that turn: shoppers see products without verification badges, and basic commerce is untouched.

That last behavior is a deployment-model decision, not an accident. We call it enrichment-plus-supplement: each merchant runs a dedicated per-tenant LAKEer instance that enriches the catalog offline and supplements the live path for complex claims — and is deliberately kept out of the critical path for basic search, cart, and checkout. The alternative — LAKEer as the sole backend for all product search — is architecturally possible and deliberately not where anyone should start, because it converts a verification outage into a storefront outage. Under this model, if the trust layer degrades, the site still sells.

On accuracy: ClaimGuard's verification pipeline is the same architecture behind LAKEer's FACTS Grounding result — 77.7% accuracy at 92% eligibility, measured on the 860-example public split, against Gemini 2.5 Pro at 74.3% overall when we ran the evaluation in November 2025. That comparison is not strictly like-for-like: the official leaderboard averages the public and private splits, and DeepMind has since released Grounding v2 with an expanded example set and improved judge models. We've written about the result and its methodology separately. The point here is narrower — the grounding architecture agents rely on at query time is the one that was benchmarked, not a lighter-weight proxy of it.

What this means if you're building on UCP

The integration surface is intentionally small: one manifest entry, one MCP tool, one request/response schema. Your agent code needs no LAKEer-specific error handling — transport failures surface as JSON-RPC errors and business outcomes (including "no grounded answer" and "contradiction detected") arrive as successful results, the same two-layer error model the standard UCP catalog binding already uses. Verification calls default to LAKEer's grounded mode, where answers derive only from verbatim source text and explicitly extracted entities — the strict-traceability setting appropriate for anything feeding a purchase decision.

See how this comes together on the Unified Commerce Platform page, or start free with LAKEer.