1.2.0-rc.1 / Specification
Specification
The authoritative composition, capability classes and exact contract versions.
Edition: 1.2.0-rc.1 — 21 September 2026. Status: implementation candidate. This document, its numbered requirement register, linked current contract annexes and exact schemas form the candidate specification. The composition below preserves the exact policy, service and package versions. The release record states current status and supersedes earlier operational status notes; the release audit retains the executed reference evidence.
Odexa means Originator Data exchange for Agents. It defines how an originator publishes terms, appoints a service, records explicit agreements and receives qualified evidence of participating exchanges. It supports independent operation and optional providers. No Foundation account, central registry, third-party service, payment account or blockchain is required for static policy publication or the direct free path.
1. Reading and normative precedence
The words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY express requirements of the explicitly selected capability/profile. A requirement does not prove that a reference implementation has passed it. Implementation validation is recorded separately in the evidence map and validation report.
The following rules apply to this specification:
- This specification governs profile selection, dependencies, terminology, version boundaries and the status of referenced material. Section 9 consolidates the normative requirements, rendered from the requirement register; the checked render and register must agree.
- The normative modules in section 2 govern their stated current contracts. Closed schema definitions specify structural fields and types; module prose specifies cross-message, authority, time, lifecycle and evidence semantics. Both must hold. A structural positive is not necessarily a semantic positive.
- Reference validators and tests provide executable evidence. They do not silently override contradictory normative prose or excuse a missing requirement. A conflict between prose, schema and executed behavior is a release defect to resolve before publication.
- Statements labelled history, original results, subsequent integration, remaining work, implementation status, example or review are informative status/evidence. Their historical counts and proposed work do not redefine the wire contract or override the current release status.
docs/BASELINE-*,docs/WIRE-PROFILE.md,schema/draft-2 envelopes, historical reports andresearch/incomplete/are historical or research material. Their explicit versions remain valid for those historical profiles. They are not alternate draft-3 contracts.
Unversioned semantics reused from earlier code—canonical URLs, strict JSON, identity, representation metadata and policy vocabulary—apply only where the current module explicitly reuses them. A current message MUST NOT be validated by replacing its version or payment fields and treating that altered object as the original signed payload.
2. Normative module inventory
The following documents and schemas define this candidate. Their linked machine definitions contain the exact field inventories; a summary here never adds an optional field to a closed envelope.
The free service, gateway reporting, managed duties, ledger, catalog and executor guides describe reference implementation boundaries and trusted adapter responsibilities. They do not create an additional interoperable wire profile through a Python or JavaScript API alone.
Paid archives use the explicit contracts above. The normative provider handover procedure composes the existing closed contracts and has real two-provider free/paid transition evidence. It adds no new wire envelope or transparent agreement transfer. The normative observation coverage contract uses an origin-declared registry and explicit known-report denominators; it does not assert complete origin-wide traffic capture. No importer may infer a shape from a filename. Every selected capability must meet its complete dependencies. The closed structural inventory lists every declared object field without replacing nested constraints or semantic correlations.
3. Versions and explicit selection
| Layer | Exact current identity | Selection rule |
|---|---|---|
| Native policy | 1.2.0-draft.1 |
Validate the published policy against its own version and policy contract |
| Current service/authority/asset envelopes | 1.2.0-draft.3 |
Validate the selected message family; the version alone does not identify a capability |
| Fixed quote | fixed-quote-v1 |
Exact payment profile/record type, accepted quote and separate payer mandate |
| Continuing storage | storage_sessions_v1 |
Explicit reporting_profile in request, offer, signed assent and receipt; event_profile in selected client events |
| Observation coverage | observation_coverage_v1 |
Same-origin policy-bound registry; independently authenticated intakes and trusted expected-observation journal |
| Native asset publication | asset_evidence_v1 |
Explicit manifest/bundle profile and scoped publication authority |
| Ordinary free archive | odexa-free-evidence-snapshot-1 |
Explicit importer/exporter selection |
| Storage free archive | odexa-storage-free-evidence-snapshot-1 |
Selected storage agreement and exact copy-parent closure |
| Asset free archive | odexa-assets-free-evidence-snapshot-1 |
Ordinary free agreement plus independently anchored asset closure |
| Asset/storage free archive | odexa-assets-storage-free-evidence-snapshot-1 |
Both selected storage and independently anchored asset closure |
| Ordinary paid archive | odexa-paid-evidence-snapshot-1 |
Fixed quote, independently pinned payer mandate, provider proof and audit replay |
| Storage paid archive | odexa-storage-paid-evidence-snapshot-1 |
Paid archive plus signed storage selection and exact parent closure |
| Asset paid archive | odexa-assets-paid-evidence-snapshot-1 |
Paid archive plus independently anchored asset closure |
| Asset/storage paid archive | odexa-assets-storage-paid-evidence-snapshot-1 |
Paid replay and both selected storage/asset closures |
| Historical local service/CLI | 1.2.0-draft.2 |
Historical quickstart and envelope definitions only |
| Python development distribution | 0.0.0.dev3 |
Package identity, not a protocol compatibility claim |
An implementation MUST reject an unselected/unknown profile and unknown fields where its schema is closed. It MUST NOT silently downgrade a selected paid/storage/asset message to an ordinary free message. Compatibility is explicit; changing a package version, CMS page or “latest” link cannot change the immutable identity or exact bytes of retained terms, receipts or asset versions. Upgrade and migration instructions define the supported transition and rollback boundaries.
Before publication the final release inventory MUST list each actual wire/profile version. A release can compose a frozen policy core and a later service profile; it must disclose that composition rather than globally replacing version strings. Existing immutable draft-2 downloads remain available.
4. Trust and discovery
The originator publishes native policy at its canonical HTTPS origin’s /odexa.json, for example https://example.com/odexa.json. An origin that implements an appointed service publishes current service authority at that same origin’s /odexa-service.json. A static policy deployment does not need to advertise an unimplemented service. These are this draft’s origin-controlled publication conventions. They are not claims of registered well-known endpoints or public adoption.
The informative website discovery guide shows optional robots.txt comments and a concise /llms.txt pointing to the actual same-origin policy and documentation. These are supplemental signposts: /odexa.json remains authoritative and credential-free. The hints do not override crawl rules, appoint a provider, accept an agreement or supply permission. They add no wire requirement or standard robots directive.
Clients acquire authoritative documents through bounded verified HTTPS under the acquisition contract. Discovery uses no agent or provider credential. The trusted transport constrains origin, path, redirects, response type/size, TLS and observation time. Retained history prevents rollback to a locally superseded observation. Current authority is checked at the operation boundaries specified by the module, including before sending credentials/context and before committing an authority-dependent result.
An appointed service is restricted by origin-owned capability, resource/action/purpose scope, lifetime, key use, exact endpoint and delegation. An external provider needs an explicit delegation. Same-origin operation can use a null delegation when allowed. No service can appoint its own replacement or derive contracting/payment/publication authority merely from being named as a measurement provider.
Operational authority is not resource permission. A signed object is not automatically current, a registered key is not automatically authorised for every role, and a bundle’s carried keys are not independent trust anchors. Known compromised material, retired historical keys and currently active operation keys have distinct treatment under the history/verification contracts.
4.1 Publication and acquisition boundaries
| Resource | Exact location / owner | Meaning |
|---|---|---|
| Native policy | Origin /odexa.json |
Scoped terms; no agent credential |
| Current service authority | Origin /odexa-service.json |
Appointed capabilities, operators, routes, keys and delegations; no provider may replace the origin’s authority |
| Optional observation registry | Origin /odexa-observation.json |
Exact-policy-bound observation declaration, not operational authority |
| Retained agreement contexts | Exact URLs/digests in the offer, constrained to the origin or selected provider’s tenant context route | Original policy, origin authority and human terms |
| Native asset publication | Exact origin-qualified version_id |
Original scoped publisher JWS; not an access credential |
| Portable asset/evidence bundle | Explicitly configured source or selected export API | No universal discovery route is introduced by fixture URLs |
Under AUTH-02–AUTH-04, current observation time begins before acquisition. Current authority has no more than five seconds of observation age at the specified decision/commit. The reference acquisition adapter imposes one total budget of at most five seconds, pins a vetted resolved address, verifies TLS hostname/chain, sends revalidation headers and accepts no redirect, stale cache response or compressed/ambiguous current JSON. Authority declares Cache-Control: no-store; policy is revalidated on every acquisition. Its exact HTTP framing, media/charset and address-policy rules are in the acquisition annex. A deployment’s destination allowlist and egress policy remain separate from TLS identity.
Current observations and a protected local commit are not a globally atomic publisher transaction. Previously admitted in-flight delivery can finish at the declared gateway boundary. Retained history detects only observations made by that installation, not unknown prior compromise or a privileged local rollback. Origin history’s revoked-material memory is origin-scoped. Asset/evidence verification additionally evaluates known compromised material in the independently trusted context required by the selected closed bundle; this is a refusal to rely on that evidence, not a global key blacklist or a new remote revocation mechanism.
5. Agreements, access and optional payment
The common current service binding is exactly protocol_version, origin, service_id, issuer, delegation_id. It remains fixed for an accepted agreement. The signer is established independently by its authorised key and signature role; the issuer field in an agent request names the selected service, not the requester.
A direct or delegated free exchange uses exact payment:{required:false} and requires no quote, payer mandate or payment-provider request. The agent verifies the offer’s exact policy/authority/human-terms bytes, scope, obligations and selected identity before signing explicit assent. The service authenticates the client/principal, commits the original receipt and preserves the accepted access/use windows. Exact retries return the original recorded result; changed payloads under the same identity conflict.
A receipt records acceptance and is not a bearer credential. Protected access uses a separately issued scoped, expiring token and current authenticated introspection. A gateway durably distinguishes admission, actual attempted transport and the terminal observed outcome. Failed or unresolved transport cannot be replaced with an invented completed delivery.
Paid selection adds the exact accepted quote with distinct resource-licence and provider-service items, bounded integer minor-unit amounts and an exact total. Assent produces a pending-payment receipt. Separately authenticated payer authorisation binds the exact quote once. Read-only payment checks authenticate the appointed verifier and bind the check, agreement, mandate, amount and accepted resource scope. They do not initiate a debit.
Pending, failed, confirmed and reversed payment assertions are separate from pending/active/revoked/expired access. Late financial facts cannot extend an expired use/access window or resurrect terminal access. Original assent/receipt bytes remain unchanged as status advances. The statement “confirmed” is the authenticated provider’s assertion, not independently observed bank settlement.
Revocation stops future access under the accepted revocation rule. It does not silently rewrite historical agreement terms or prove local/remote deletion. Existing use and retention duties remain governed by their exact accepted terms. A new provider, URL, key or credential does not inherit an old token’s authority by resemblance.
5.1 Current HTTP exchange
The following paths are relative to the exact appointed tenant base_url. They describe the current reference interoperability profile; trusted local provisioning is not a public registration endpoint. JSON bodies use their exact selected free/paid/storage shape. Signed bodies and responses use application/jose. Unsigned JSON uses application/json; human terms use text/plain. Roles are separately provisioned; the reference authenticates them with scoped HTTP Basic over verified HTTPS.
| Method and path | Requesting role / body | Successful result |
|---|---|---|
POST offers |
Agent / selected offer request | 201, exact unsigned offer; paid request additionally names payer_id |
POST agreements |
Agent / exact signed acceptance | 201 for first durable receipt, 200 for exact accepted-payload retry; original receipt JWS |
POST tokens |
Owning agent / token request | Newly issued opaque token; same current authorization on every request |
POST introspect |
Gateway / exact request UUID, token and retrieval scope | Exact admission or explicit token/scope denial; no echoed bearer |
GET agreements/{id}/receipt |
Authorized owner/gateway/admin | Original historical receipt JWS |
GET agreements/{id}/status |
Authorized reader | Newly signed, currently authorized status; a historical receipt is not this result |
POST agreements/{id}/revoke |
Owner/admin / bound revoke command | Original signed result for exact command retry |
POST events |
Agent/gateway / selected signed report | Original signed collector intake with retained exact report bytes |
GET contexts/{sha256hex} |
Public, credential-free | Exact immutable context body at its pinned media type |
POST agreements/{id}/payment-mandate |
Separate payer / mandate JWS | 201 for first retained mandate, 200 for identical payer/payload retry |
POST agreements/{id}/payment-check |
Owner/admin / B plus agreement_id, check_id |
Payment/access state; no debit or bearer token |
POST verify on the separately appointed verifier base |
Authorized verification caller / exact payment check | Original payment-status JWS |
The reference dispatcher uses bounded JSON errors {error:<code>} with non-success HTTP status. Invalid/unauthenticated/forbidden/conflicting/unavailable requests do not fabricate an allowed admission or payment. The caller checks HTTP status and the selected successful contract together. Authority acquisition failure is service unavailability, not evidence that an arbitrary bearer itself is invalid. Immutable historical retries can preserve old receipts/intakes during outage without creating new authority. Introspection request IDs are consumed once; an admission is not replayable authorization.
5.2 Signatures and distinct actors
ES256 is the selected signature algorithm: a closed protected header names alg, kid and exact typ, and the compact JWS retains original UTF-8 payload bytes. A valid signature alone does not establish an authorized identity or role. Origin-pinned service keys, separately provisioned agent/gateway keys and separately provisioned payer keys have different trust sources.
| Exact JWS type | Authorized signer / meaning |
|---|---|
odexa-acceptance+jws |
Authenticated agent for the accepted principal; explicit exact-offer assent |
odexa-receipt+jws |
Appointed agreement service; immutable acceptance evidence |
odexa-status+jws |
Appointed agreement service; qualified current lifecycle statement |
odexa-event+jws |
Authenticated reporter in its permitted agent/gateway/service namespace |
odexa-event-record+jws |
Appointed collector; receipt/authentication of original report, not truth of downstream use |
odexa-payment-mandate+jws |
Independently authorized payer; exact-quote-once authority |
odexa-payment-status+jws |
Separately appointed payment verifier; provider financial assertion |
odexa-asset-manifest+jws |
Scoped origin-authorized publisher; immutable version and declared derivation evidence |
odexa-evidence-export+jws |
Appointed exporter; closed retained-source inventory, not a new licence |
No global signature registry is expanded for legacy profiles. Profiles explicitly select any additional type. Offers and quotes are retained exact unsigned documents whose digests enter signed assent/receipts; token/introspection responses use authenticated HTTPS, not a newly invented signature type. Internal operation/request digests use the specified sorted-key compact UTF-8 encoding with array order preserved. That internal encoding is not a replacement for original signed bytes or a claim of a general JSON canonicalization standard.
5.3 Time, money and state limits
Offer lifetimes are 1–600 seconds and fit all relevant origin/key/delegation ceilings; the current reference offers 60 seconds only when that full interval fits. Accepted access/use durations are positive and at most 31,536,000 seconds, with access no longer than use. Tokens last at most 300 seconds and no longer than accepted access. UTC windows use their stated inclusive start and exclusive expiry; a new assertion is not accepted at the expiry boundary. New payment response freshness has its separate inclusive 60-second bound, checked again at commit.
Paid amounts are canonical unsigned decimal strings of at most 18 digits, with scale 0–9, no floating arithmetic and exact total below 10^18. At least one resource-license line is explicit, even at zero; all-zero agreements bypass payment. Supported currency/scale and provider-status mapping are adapter responsibilities, not a claimed live currency or settlement registry.
| Current financial state | Allowed next authenticated states |
|---|---|
pending |
pending, failed, confirmed, reversed |
failed |
pending, failed, confirmed, reversed |
confirmed |
confirmed, reversed |
reversed |
reversed |
Access separately follows pending_payment → active only with otherwise valid current authorization, and can become revoked or expired. Terminal access stays terminal. Free receipts initially record active but still are not access credentials. Quote expiry blocks new assent, not later evidence of timely authorized payment. Exact old check replay is read-only; changed bytes/sequence/reference under retained identities conflict. The bounded payment reference retains 256 checks and fails closed at capacity rather than discarding history or initiating another charge.
6. Assets, duties and qualified evidence
An asset’s origin-qualified identity, immutable version, representation and manifest-payload digest are separate from a mutable retrieval URL. Publisher-signed derivation links require complete independently anchored dependencies for verification; extract/transform declarations are not proof of the computation or of unlisted-source absence. Encoded and decoded representation bytes remain separate measurements.
An originator may publish static policy without an agreement or payment service. A native signed asset manifest additionally requires an origin-authorized publication descriptor/key; that descriptor can appoint the origin itself for static publication without running a transaction API. Publication expresses the stated policy/evidence; it neither blocks an uncooperative crawler nor records every use. Protected delivery requires an implemented enforcement boundary. The coverage module makes declared observation boundaries and known expected-report denominators explicit. Its static/manifest-only mode has unknown traffic; its report-only mode distinguishes client claims and collector receipts from protected delivery. No complete origin-wide capture claim is inferred.
Client use assertions, gateway observations and collector receipt of a report MUST remain distinct. Signature verification establishes attribution/integrity within the stated trust assumptions; it does not prove downstream LLM use, client honesty, remote receipt, physical erasure or global completeness. Local matching bytes MUST NOT be promoted into proof of end-client delivery.
Managed clients MUST execute applicable supported duties or decline the use. They must not announce unsupported obligations and then ignore them. The reference supports bounded reversible retrieval/storage, retention, attribution and reporting adapters; it does not claim arbitrary training, transformation or redistribution execution. Continuing custody uses an explicitly selected session profile; a completed write and later custody checkpoints are different operations. Copies preserve original acquisition/retention deadlines, and absent/late/uncertain observations remain visible.
Portable evidence preserves original bytes, signatures, identities, contexts, dependencies and source qualifications. An independently verified archive is inert. It contains no live credentials, transfers no authority and reactivates no access. Closure of a declared retained source selection is not proof that an exporter recorded or disclosed every event.
7. Capability declarations and dependencies
The following are documentation/conformance class names, not new wire fields. Implementations must name the exact profiles/operations and version they support. The reference distribution must retain a complete standalone free path even though individual third-party implementations may support only declared classes. No subset earns an unrestricted “Odexa compliant” claim.
| Class | Required dependencies and boundary |
|---|---|
| Policy publisher/evaluator | Native policy, canonical scope and deterministic duties; no service account required |
| Authority publisher/resolver | Native policy plus service/delegation/key contract; acquisition/history for current operation decisions |
| Direct free agreement service | Free contract, authenticated client/principal, authority, durable receipt/retry/status/revocation; same-origin supported |
| Delegated agreement service | Explicit external appointment plus its selected free or paid agreement contract; credential isolation and withdrawal checks |
| Fixed-quote agreement adapter | Exact paid offer/assent/receipt and quote; separate payer authorisation and appointed verifier; reference free mode remains independently available |
| Payment verifier | Fixed-quote read-only check/response, scoped current authority and payment-status key; no implicit debit or licence grant |
| Publisher gateway | Selected agreement’s authenticated introspection, current authority, exact scope, durable admission and qualified transport outcome |
| Event collector | Selected event profile, reporter authentication, exact report/intake bytes, retry identity and origin authority; source categories remain separate |
| Asset publisher/verifier | Scoped publication, immutable identity, representations, exact derivation closure and independent origin pins |
| Managed agent | Authenticated accepted context plus every duty of its claimed supported action/profile; explicit refusal of unsupported use |
| Evidence verifier/archive | Exact selected ordinary/storage/asset/paid archive contract, independent trust and complete required dependencies; inert import |
| Measurement processor | Authenticated source/context, declared boundaries/denominators, deterministic conflict/omission treatment; no unobserved-use assertion |
Combination claims must meet all dependencies. A provider claiming storage and asset-aware paid portability must implement that selected combined archive; it cannot rely on an ordinary free-archive result. The conformance evidence map identifies component evidence. Current validation and release status distinguish the executed checks from release status and deployment limits.
8. Stewardship, implementation and release
The Odexa Foundation has a wider fair/open-web and originator-value mission. Its council and formal protocol governance are developing. The Foundation site and documentation are non-commercial, implementation-neutral protocol resources. Providers may implement governance, measurement and payment services independently; none has a privileged schema field or trust root. Product availability and pricing claims belong to each provider and require their own evidence.
Documentation is licensed under CC BY 4.0; schemas, examples and reference code under Apache 2.0, with the exclusions in LICENSE.md. Licence approval is not release approval, external certification or a claim of adoption.
The integrated contracts, reproducible installation, separate client checks and four-perspective findings/dispositions are recorded in the release audit. RC1 preserves that reviewed implementation. Its implementation-candidate status does not constitute external certification or approval of a production deployment. The release record identifies the current security contact and distinguishes the immutable package from later website deployment checks.
Installed reference tooling (informative)
Current installation and configuration packages the ordinary draft-3 direct/delegated free and optional fixed-quote reference under odexa-current. The legacy command stays separately versioned. The current operator client uses the Python semantic implementation, so its installed flow checks do not substitute for independent Node interoperability. These local configuration/CLI interfaces add no wire profile and change no signed type. The separate security inventory records deployment limits, dependencies and the owner-monitored private reporting route.
The independent paid Node client supplies separate semantic and actual wire evidence for ordinary fixed-quote operation. Its fixture configuration and local journal are not new wire profiles or portable evidence exports. It retains explicit execution and trust limits. The independent asset client supplies native complete-graph semantics, original-publication HTTPS and persistent-trust evidence. Neither client claims universal conformance; their bounded results are included in current validation.
9. Normative requirement register
This register consolidates the cross-message requirements of this edition. Each requirement includes the exact closed schema and semantic rules in its linked contract. The explicit evidence map names individual executed methods; it does not certify universal coverage or supply release approval.
CORE-01 — all
An implementation MUST validate the selected closed envelope, strict UTF-8 JSON, lexical unsigned safe integers, canonical identifiers and exact calendar timestamps; unknown profiles or fields MUST NOT be silently downgraded.
CORE-02 — all
Signed payloads, offers, contexts and retained evidence MUST preserve exact original bytes and their digests; reserialization MUST NOT substitute for the signed or accepted bytes.
POL-01 — policy
Publishers and evaluators MUST use the native policy contract, canonical origin/path/query scope and explicit action-purpose vocabulary; a selected resource MUST NOT implicitly grant another action or purpose.
POL-02 — policy
Evaluation MUST include every overlapping resource and every requested action-purpose pair, applying prohibit, no_grant, unsupported, require_agreement, then permit precedence without treating duty support as completion.
POL-03 — policy
Applicable duties MUST accumulate deterministically, deduplicating attribution and taking the strictest retention/report deadlines; rule order MUST NOT change the decision.
AUTH-01 — authority
Origin authority MUST bind the selected service, issuer, capability, exact endpoint, key use, scope and lifetime. External operation MUST use one explicit current delegation; partial grants MUST NOT be unioned or subdelegated.
AUTH-02 — authority
Current authority MUST come from bounded verified origin acquisition with revalidation, canonical publication routes, exact bytes and no stale fallback or redirect; discovery MUST transmit no agent/provider credential.
AUTH-03 — authority
An acquisition observation MUST begin before retrieval and remain within the permitted freshness budget at use; expired, unavailable, cached or superseded authority MUST NOT authorize sending context or committing a result.
AUTH-04 — authority
Credentials MUST be restricted to their appointed HTTPS origin and tenant route. A trusted pre-send guard MUST run after connection/TLS delay, and authority-dependent mutations MUST recheck current trust after lock waits and before commit.
AUTH-05 — authority
Retained history MUST reject revision rollback, changed bytes under one revision, policy-lineage reset and immutable service/key identity redefinition, while keeping historical documents separate from current authorization.
AUTH-06 — authority
New operations MUST use active keys. Retirement, compromise and withdrawal MUST retain their documented distinctions; locally observed revoked material MUST NOT regain authority under a replacement key ID for that origin.
FREE-01 — free
The reference distribution MUST support a complete direct free exchange without a commercial platform, payer, payment configuration or payment-provider call; delegated free exchange MUST retain the same free contract under explicit appointment.
FREE-02 — free
An offer and its exact policy/authority/human-terms contexts MUST preserve the requested scope, cumulative duties and permitted lifetime; authenticated explicit assent MUST bind the exact offer, nonce, service, client and authorized principal.
FREE-03 — free
Acceptance MUST atomically consume one offer and preserve one original receipt. Exact decoded-payload retries MUST recover the original result across restart; changed payloads under the same retry identity MUST conflict.
FREE-04 — free
A receipt MUST remain immutable evidence with access_credential:false and exactly accepted access/use windows; neither receipt possession nor an original-receipt retry MUST create fresh access.
FREE-05 — free, gateway
Protected access MUST require a separately issued, bounded token and authenticated introspection matching agreement, principal, exact resource, method, actions and purposes. Both active and permitted MUST be true; a denial MUST contain no admission.
FREE-06 — free
Status/revocation MUST bind the exact agreement and current authorized signer. State versions and original signed command retries MUST remain durable; future-access revocation MUST NOT rewrite past accepted use terms or revive terminal access.
GW-01 — gateway
A gateway MUST record admission before sending protected bytes, constrain the actual request including cached bodies, and distinguish admission, attempted transport, completed/failed transport and unresolved interruption.
GW-02 — gateway
The terminal observed outcome and original signed outbox record MUST commit together; retries MUST preserve the exact event and original collector acknowledgement. Failure or crash MUST NOT invent completion.
REPORT-01 — collector, gateway
Reported client use, observed gateway transport and service-recorded transitions MUST remain distinct. Authenticated roles and admission correlation MUST prevent source, reporter, scope or delivery-ID promotion.
REPORT-02 — collector
An intake MUST retain exact report bytes/digest, the original verified reporter signature where present, authenticated identity, source qualification and collector authority. Retry/conflict handling MUST use exact reporter/event/payload identities.
PAY-01 — paid
A fixed quote MUST distinguish resource-license and provider-service payees/items, use bounded canonical integer minor-unit strings and exact positive sums. An all-zero agreement MUST use the free path without a payer/verifier.
PAY-02 — paid
A paid offer MUST bind exact quote bytes and explicit paid selection; its original receipt MUST be pending_payment, payment_required:true and access_credential:false with exactly accepted windows. Free and paid envelopes MUST NOT be interchanged.
PAY-03 — paid
Spending authority MUST require a separately authenticated payer and exact-quote mandate binding every amount, currency, payer, payee and agreement. Agent assent/credentials MUST NOT substitute for payer authority.
PAY-04 — paid
A read-only payment check MUST authenticate the origin-appointed verifier and original signature and bind check, request, offer, quote, mandate, amount and accepted scope before financial state changes. A provider response MUST NOT nominate its own authority.
PAY-05 — paid
Provider states and sequences MUST follow the documented pending/failed/confirmed/reversed transition graph and fixed transaction binding. Verification MUST NOT initiate or retry a debit; exact historical check replay MUST return current state without reapplying the old transition.
PAY-06 — paid
Financial state MUST remain separate from access state. Pending/failed payments MUST deny access; reversal MUST revoke future access, and later confirmation or replay MUST NOT revive expired/revoked access or rewrite original receipts.
PAY-07 — paid
Receipt, accepted payment binding, provider evidence and access transition MUST use one durable transaction with live post-lock and pre-commit authority/deadline guards; failures MUST roll back the attempted transition.
ASSET-01 — asset
Asset/version/representation references MUST bind immutable version IDs and exact signed payload digests, with independently authorized scoped publication signatures; a mutable resource URL MUST NOT substitute for version identity.
ASSET-02 — asset
Every included publisher MUST have independently acquired current origin knowledge and exact retained historical pins. Bundled keys/documents MUST NOT bootstrap trust; known revoked material and rebound immutable key identity MUST be rejected.
ASSET-03 — asset
A verified derivation graph MUST close every declared parent with exact qualified references, source chronology and copy equivalence. Missing, duplicate, extra, cyclic, substituted or over-limit dependencies MUST fail rather than be truncated.
ASSET-04 — asset, measurement
Encoded bytes, decoded representations, ranges, metadata and observation source MUST remain distinct. Local matches or signed claims MUST NOT establish remote receipt, actual downstream use or verified derivation computation.
ASSET-05 — asset
Retained version pins and exact original publications MUST survive restart; an authorized signer MUST NOT redefine an existing version, and late verification failure MUST NOT partially retain a new catalog bundle.
STORE-01 — storage
Continuing storage MUST be explicitly selected in request, offer, signed assent and receipt, and in its signed event profile. Ordinary messages MUST reject or decline unselected storage fields rather than infer/downgrade selection.
STORE-02 — storage
Completed store actions and continuing custody sessions MUST remain separate; copy references MUST close exact authenticated parent writes and preserve original acquisition and the earliest accepted retention/use deadline.
STORE-03 — storage, measurement
Checkpoint deadlines MUST use original scheduled times. Exact retries MUST NOT add actions/checkpoints; late, absent, conflicting or failed-cleanup observations MUST remain visible and MUST NOT invent cessation or backfill coverage.
AGENT-01 — agent
A managed agent MUST execute every supported applicable duty for its claimed operation, retain durable exact report intent and decline unsupported or irreversible/model uses outside its declared executor profile.
EVID-01 — archive
An evidence export/import MUST select its exact free/paid/storage/asset profile and close the signed inventory of original artifacts, authority, reporter and payer trust, related evidence and selected dependencies. Unknown or omitted dependencies MUST fail.
EVID-02 — archive
An archive MUST independently recompute the retained agreement/status/admission and paid audit timeline using exact proofs; an exporter signature MUST NOT rescue missing, reordered, changed or invented lifecycle evidence.
EVID-03 — archive
Combined paid/storage/asset claims MUST validate all selected dependencies together, retaining the separate payer mandate, provider proofs, copy parents and complete native asset graph. Ordinary free-archive validation MUST NOT stand in for a selected combination.
EVID-04 — archive
Import MUST be inert, idempotent and separate from live operational state. Exports MUST contain no live credential or token; imported records MUST NOT transfer authority, reactivate access or claim total capture beyond the selected retained source.
MIG-01 — handover
Provider handover MUST be origin-controlled and preserve original issuer, signatures, accepted terms and evidence. The supported transition MUST create fresh credentials/agreements and, when paid, a fresh quote/mandate; outage MUST NOT silently restore the withdrawn provider.
MIG-02 — handover
A limited reporting tail MUST appoint only the collector scope still needed for original accepted duties; it MUST NOT restore old agreement, token, payment or publication authority. Key rotation MUST preserve historical evidence while blocking new use of retired keys.
METRIC-01 — measurement
An observation registry MUST be a separately acquired origin declaration bound to exact native policy, named scopes/profiles/intervals and monotonic history. Static publication MUST remain possible without a service/payment account.
METRIC-02 — measurement
Origin declarations, authenticated intakes and trusted expected-observation journals MUST remain distinct. Completeness ratios MUST use explicit known cohorts; unknown traffic and empty denominators MUST NOT become zero use or a whole-origin capture percentage.
METRIC-03 — measurement
Overlaps, retries and conflicts MUST NOT inflate observations or shrink known expected denominators. Missing, late, pending and unresolved reports MUST remain separate, with exact agreement/profile/source boundaries and as-of time.
REF-01 — reference_distribution
The installed reference MUST expose a reproducible standalone free setup and explicit optional synthetic payment configuration, with private credentials, TLS verification, scoped routes, restart and separately trusted archive verification. Synthetic state MUST NOT be represented as real settlement.