# Integration pilot ## 1. Acceptance scope Each pilot has a defined predicate, network and asset scope, evidence sources, freshness window, consumer, and value-at-risk limit. ## 2. Evidence coverage Anonymized or synthetic fixtures cover the normal case, altered instructions, mismatched outcomes, and unavailable evidence. Existing platform controls provide the comparison baseline. ## 3. Independent verification The pilot runs alongside existing controls without releasing funds or signing orders. The platform’s independent consumer verifies each report and records ACCEPT, REJECT, or REVIEW under its own policy. ## 4. Evaluation metrics Evaluation covers integration effort, predicate coverage, false acceptance, false rejection, indeterminate rate, latency, and reconciliation effort. Usage and revenue reporting distinguish independent demand from subsidies and demonstrations; transferred value is not protocol revenue. ## 5. Service fit Service fit depends on repeated use, reliable evidence collection, and measurable reduction in operational work. Commercial scope follows the profiles the platform can independently evaluate. ## Scope controls A profile stays outside deployment when its evidence cannot establish the required predicate or its report could mislead the consumer. Revisions change the explicit profile and its tests, not the meaning of an already issued report. Public case studies, partner names, and logos require the partner's explicit permission. ## Additional source and payment conformance cases Test duplicate names and duplicate field/pattern signatures, unsupported fields or regex semantics, incorrect inscription content, mismatched source hashes, incomplete registry history, wrong network and source reorganization. Test nonce-only/known-source claims, post-source commitments, changed ordering or weights, request-ID/context grinding, retries and withheld outcomes. For native NAT, test the wrong deployment/ticker/network/recipient, a UNAT-only transfer, a created but unexecuted transfer inscription, partial/late/overpayment, stale or lagging observations, conflicting indexes, insufficient confirmations, duplicate event crediting, concurrent reservations, caller mismatch, refund replay and reorganization after credit use. Exercise the same request independently through the USDC rail. A synthetic policy test is not a real-funds settlement test. ## Commercial activation and implementation status NAT and USDC are both required for the initial commercial-launch acceptance test. Public documentation, source code and policy fixtures are not live payment endpoints. The static payment-policy resource lists required launch methods with `enabled: false`, no recipient and no live endpoint until each rail passes end-to-end settlement, accounting, failure/reorganization, security and owner-approval gates. Do not advertise a USDC-only release as the completed initial payment scope. No token has been issued, no source element is announced, and no mainnet inscription, customer charge, treasury swap or wallet authorization is performed by this release. Production service availability remains separate from website publication. No Trac partnership, hosted SLA or independent cryptographic audit is implied. [1] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/digital-elements/.element-registry [2] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/src/index/updater/inscription_updater/tap/ops/dmt_element.rs [3] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/nat-use-cases/usdnat-method-1-live [4] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/non-arbitrary-tokens-nats/nat-token-transfer [5] https://docs.x402.org/core-concepts/network-and-token-support [6] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/README.md [7] https://arxiv.org/abs/1605.04559