blun-king-cli 9.1.597 → 9.1.600

package/standard-skills/translate-native/docs/WEBSITE_LOCALIZATION_API.md

@@ -48,12 +48,24 @@ native-Unicode JSON before signing and are never mutated.
 
 Successful responses require canonical bounded JSON, an allowed status code,
 the exact response schema, and the originating request, event, and site
-bindings. Capability responses additionally recompute both advertised hashes
-and verify the exact ordered operation names, methods, paths, request schemas,
-response schemas, and enabled booleans. Rehashing a substituted endpoint is
-therefore insufficient. Stable server failures retain their content-free error
-code and derive retryability from HTTP status; redirects and invalid bindings
-fail closed.
+bindings. Capability responses additionally recompute both advertised hashes,
+verify the exact ordered operation names, methods, paths, request schemas,
+response schemas, and enabled booleans, and compare the complete v5 capability
+shape, commercial profile, 24 locale bindings, and commercial rendering
+registry with the installed canonical contract. Rehashing a substituted
+endpoint or registry is therefore insufficient.
+
+Production hosts can also pass constructor-fixed
+`capabilities_sha256` and `commercial_rendering_registry_sha256` deployment
+pins. Each must be a lowercase 64-character SHA-256 digest; malformed
+configuration is rejected before transport. A valid response that does not
+match either configured pin fails after the single HTTP attempt with the
+distinct, non-retryable `capabilities_pin_mismatch` or
+`commercial_rendering_registry_pin_mismatch` code. Rotate a pin only as an
+explicit deployment change after installing and validating the corresponding
+client contract. Stable server failures retain their content-free error code
+and derive retryability from HTTP status; redirects and invalid bindings fail
+closed.
 
 ### Durable change dispatch
 
@@ -214,6 +226,34 @@ never enter the runtime representation or stable failure codes. A deployment
 may therefore choose its own secret manager and supervisor without weakening
 the provider-neutral contract.
 
+Set `capability_preflight=True` for a pinned production startup. It is
+mandatory whenever `http_authenticator` exposes the runtime over HTTP. The
+runtime then requires both constructor-fixed client pins described above and performs
+one signed capability request after all in-memory configuration and existing
+path checks, but before creating any database file. Missing pins, a network or
+contract failure, and either pin mismatch leave all three paths absent and
+return only a stable content-free failure code. `capability_binding()` reports
+the two verified public digests or the explicit `not_configured` state. Every
+later runtime transition rechecks that the client still exposes the exact
+verified pair before reading or writing persistent state or making another
+network request. This startup proof is deliberately not a hidden retry or a
+claim that the remote service will remain available indefinitely; supervisors
+must construct a new pinned runtime after an approved contract deployment.
+
+Pinned startup also writes an independent canonical binding row into the
+change, removal, and lifecycle databases. Each row binds the database role,
+complete capability digest, commercial rendering-registry digest, and a
+derived binding digest. Existing rows are validated before the service may add
+or alter any queue schema. A restart may reuse only the same exact binding;
+swapped database files and another capability generation block with stable
+content-free errors. An unbound database can be adopted only when every
+existing source queue is empty. This permits a safe first pinned deployment
+without allowing pending legacy work to cross the policy boundary. If a crash
+leaves only part of an otherwise matching empty set unbound, the next startup
+converges the missing binding. `capability_binding()` uses its v2 response to
+report all three verified database roles, and every later state transition
+revalidates the canonical rows before queue access.
+
 ### Durable terminal notification callback
 
 Polling remains sufficient, but a deployment can pass `terminal_notifier` and
@@ -260,11 +300,13 @@ polling contract and does not create notification state.
 For a remote backend, pass an
 `HTTPTerminalNotifierAdapter` from
 `integrations/website_localization_cms_terminal_notification_http.py` as the
-`terminal_notifier`. It sends the canonical notification object itself as the
-request body to one configured HTTPS URL. Loopback HTTP is available only by
-explicit test/development opt-in. Redirects are never followed, and the adapter
-performs exactly one transport attempt; the durable notification outbox alone
-decides whether and when to retry.
+`terminal_notifier`. Construct it with the exact deployment-approved receiver
+capability SHA-256 as well as its endpoint and authentication callback. It
+sends the canonical notification object itself as the request body to one
+configured HTTPS URL. Loopback HTTP is available only by explicit
+test/development opt-in. Redirects are never followed, and the adapter performs
+exactly one transport attempt; the durable notification outbox alone decides
+whether and when to retry.
 
 Each request reserves these exact transport headers:
 
@@ -272,7 +314,8 @@ Each request reserves these exact transport headers:
 - `Accept: application/json`;
 - `Idempotency-Key: <notification_id>`;
 - `X-Localization-Terminal-Notification-Id: <notification_id>`;
-- `X-Localization-Terminal-Notification-Sha256: <body_sha256>`.
+- `X-Localization-Terminal-Notification-Sha256: <body_sha256>`;
+- `X-Localization-Capabilities-SHA256: <receiver_capabilities_sha256>`.
 
 The host-supplied authentication callback receives a fresh copy of this
 content-free request before any network access:
@@ -286,7 +329,8 @@ content-free request before any network access:
   "notification_id": "terminal-<sha256>",
   "event_id": "cms-event-184",
   "site_id": "public-site",
-  "body_sha256": "<sha256 of exact canonical request bytes>"
+  "body_sha256": "<sha256 of exact canonical request bytes>",
+  "capabilities_sha256": "<receiver_capabilities_sha256>"
 }
 ```
 
@@ -300,6 +344,22 @@ failures are retryable by the outbox. Other statuses and malformed or
 cross-bound successful responses are permanent protocol failures. Response
 bodies and private exceptions are never copied into durable error state.
 
+When terminal-status observation is enabled, the source service derives the
+receiver's exact `expected_capabilities_sha256` from the full terminal receiver
+client. A custom notifier/status-reader pair must instead provide the same
+digest explicitly as `terminal_receiver_capabilities_sha256`; missing or
+conflicting pins block configuration before the processing-monitor schema is
+created. The source service rechecks an exposed client pin before status,
+health, or worker progress, while every returned receiver status must carry the
+same exact capability SHA-256.
+
+The terminal-processing monitor stores this expected digest in its v2 metadata
+and returns it in content-free health. Restarts may therefore reuse durable
+monitoring work only under the same receiver contract. An empty v1 monitor is
+upgraded transactionally. A v1 monitor containing unbound work is deliberately
+not assigned a guessed generation and remains fail-closed; operators must
+resolve that legacy work with independently verified deployment evidence.
+
 #### Reference terminal-notification receiver
 
 `integrations/website_localization_cms_terminal_notification_receiver.py`
@@ -409,9 +469,9 @@ If the configured join timeout expires, close fails while durable state remains
 open; the supervisor must resolve or terminate the stuck callback before trying
 again. Construct the hosted runtime after every process fork.
 
-#### Terminal-receiver status, health, readiness, and capabilities
+#### Terminal-receiver status, health, readiness, capabilities, and OpenAPI
 
-The durable runtime also serves four authenticated, content-free control routes
+The durable runtime also serves five authenticated, content-free control routes
 on the same exact HTTPS origin:
 
 | Method | Path | Required scope | Purpose |
@@ -420,6 +480,7 @@ on the same exact HTTPS origin:
 | `GET` | `/v1/localization/terminal-notifications/health` | `terminal-notification-health:read` | Inspect aggregate runtime, worker, and durable inbox health |
 | `GET` | `/v1/localization/terminal-notifications/readiness` | `terminal-notification-readiness:read` | Check the managed worker and verified inbox |
 | `GET` | `/v1/localization/terminal-notifications/capabilities` | `terminal-notification-capabilities:read` | Discover the exact active receiver contract |
+| `GET` | `/v1/localization/terminal-notifications/openapi` | `terminal-notification-openapi:read` | Read the capability-bound OpenAPI 3.1 profile |
 
 Status accepts only canonical UTF-8 JSON and requires
 `X-Localization-Terminal-Status-SHA256` to equal the exact body hash:
@@ -458,19 +519,35 @@ inspection, and the read does not claim, retry, complete, or otherwise mutate
 processing state.
 
 Discovery is also strictly `GET`, body-free, query-free, and separately scoped.
-Its `blun.cms-terminal-receiver-capabilities-response.v1` envelope contains a
-`blun.cms-terminal-receiver-capabilities.v1` contract and canonical SHA-256.
+Its `blun.cms-terminal-receiver-capabilities-response.v3` envelope contains a
+`blun.cms-terminal-receiver-capabilities.v3` contract and canonical SHA-256.
 The digest covers all active operations, including the runtime's configured
 notification intake path, plus methods, scopes, request and response schemas,
 required fields, success statuses, transport limits, processing states, and
 terminal outcomes. It contains no site, endpoint origin, notification,
 credential, website text, provider response, or private error detail. The
 contract includes the health operation's exact method, path, distinct scope,
-schema, fields, and success status.
+schema, fields, and success status. Every non-discovery operation also names
+the required `X-Localization-Capabilities-SHA256` precondition header; the
+contract semantics require its exact active digest.
+
+The separately scoped OpenAPI route returns
+`blun.cms-terminal-receiver-openapi-response.v1`. Its canonical OpenAPI 3.1
+document covers all six receiver operations, including a custom notification
+intake path, and recursively closes the notification, acknowledgement, status,
+health, readiness, capability, and error shapes. It declares the exact required
+idempotency, notification-identity, payload-hash, and status-hash headers. Both
+the envelope and document carry the active capability SHA-256; the envelope
+also carries the canonical document SHA-256. Servers are deliberately omitted
+because the deployment owns the HTTPS origin.
 
 The capability request authenticates the exact empty-body hash before the
 contract is built. It never reads the inbox, checks worker readiness, claims a
-lease, or calls a handler. A custom intake path that collides with any control
+lease, or calls a handler. Every other route includes the supplied capability
+digest in its authentication context and then requires it to equal the active
+complete generation. Absence returns content-free `428`; drift returns `412`
+before notification persistence, inbox inspection, worker-state reporting, or
+OpenAPI construction. A custom intake path that collides with any control
 route is rejected before SQLite is created. Missing or altered notification
 schema fields, reused scopes, a request body, content type, query, wrong method,
 or private authenticator failure returns a content-free fail-closed response.
@@ -486,12 +563,28 @@ provided canonical request context. Do not learn and trust the digest from the
 same untrusted connection that it is intended to authenticate.
 
 `capabilities()` verifies the response envelope, the canonical digest, every
-schema and limit, all five operation definitions, distinct scopes, and the
-configured notification path. `health()`, `readiness()`, and `status()` first
-repeat that live contract verification; a contract change therefore blocks the
-operational read until the deployment deliberately updates its pin. Every HTTP
-request is separately authenticated and uses exactly one bounded transport
-attempt with no redirects.
+schema and limit, all six operation definitions, distinct scopes, and the
+configured notification path. `health()`, `readiness()`, `status()`, and
+`openapi()` first repeat that live contract verification; a contract change
+therefore blocks the operational read until the deployment deliberately
+updates its pin. Every HTTP request is separately authenticated and uses
+exactly one bounded transport attempt with no redirects.
+
+After discovery, the client reserves and sends
+`X-Localization-Capabilities-SHA256` on every operational request and binds the
+same digest into the host authentication context. The receiver checks it after
+authentication but before durable or operational state access. This prevents a
+generation change from accepting a notification under a contract the caller
+did not verify.
+
+`openapi()` then reconstructs the complete origin-free OpenAPI 3.1 document
+from the freshly verified capability object and requires the remote document,
+its canonical SHA-256, and its capability binding to match exactly. Rehashing
+a substituted schema, changing the custom notification path between requests,
+or returning another capability generation cannot produce trusted evidence.
+The transport retains the 16,384-byte request limit while accepting at most
+the receiver contract's advertised 1,000,000-byte response limit. The read
+does not touch the inbox or worker state.
 
 `notify()` validates the complete immutable terminal notification before any
 network call, repeats the pinned discovery, and sends the canonical bytes to
@@ -518,7 +611,7 @@ response between the two requests from passing as current evidence.
 Malformed JSON, duplicate keys, unexpected fields, inconsistent counts,
 rehashed semantic contract drift, redirects, and private transport failures
 raise `TerminalReceiverClientBlocked` with only a stable code and retryability.
-The three read methods never claim work, mutate receiver state, process a
+The four read methods never claim work, mutate receiver state, process a
 notification, or contain website text. `notify()` performs only the documented
 durable intake operation and returns its content-free acknowledgement.
 
@@ -550,9 +643,10 @@ The exact routes are:
 | `GET` | `/v1/localization/source/readiness` | `source-readiness:read` | Verify that the managed worker and durable service can accept work |
 | `GET` | `/v1/localization/source/capabilities` | `source-capabilities:read` | Discover the exact active HTTP contract |
 
-The capabilities route accepts no body or query. Its
-`blun.cms-source-capabilities-response.v1` response contains one
-`blun.cms-source-runtime-capabilities.v1` contract with the exact active
+Authenticated startup requires `capability_preflight=True`; omission blocks
+before any database is created. The capabilities route accepts no body or query. Its
+`blun.cms-source-capabilities-response.v2` response contains one
+`blun.cms-source-runtime-capabilities.v2` contract with the exact active
 methods, paths, scopes, principal schemas, request and response schemas,
 required top-level fields, success statuses, retry limits, and transport
 bounds. The nested `sha256` is calculated over the canonical capability object
@@ -561,10 +655,12 @@ reject unexpected contract drift without receiving website content or reading
 the three runtime databases. The route has its own
 `source-capabilities:read` credential, performs no state write, lease, repair,
 or network call, and returns fail-closed if its route metadata is incomplete or
-internally inconsistent.
+internally inconsistent. The response also carries the runtime's separately
+validated `blun.cms-source-capability-binding.v2`: the exact commercial
+capability digest, rendering-registry digest, and three durable database roles.
 
 The body-free readiness route uses
-`blun.cms-source-readiness-response.v2`. It returns HTTP `200` only while the
+`blun.cms-source-readiness-response.v3`. It returns HTTP `200` only while the
 managed worker is running and durable service health is `ok` or `degraded`;
 startup, shutdown, a worker exception, closed state, or blocked durable health
 returns HTTP `503`. Its separate `source-readiness:read` credential receives no
@@ -575,10 +671,11 @@ driven runtimes retain their explicit `run_once` contract.
 Change requests use
 `blun.cms-source-change-enqueue-request.v1`; removal requests use
 `blun.cms-source-removal-enqueue-request.v1`. Both contain the exact downstream
-payload plus an explicit `max_attempts` from 1 through 20. Successful V2
+payload plus an explicit `max_attempts` from 1 through 20. Successful V3
 responses return HTTP `202` with the canonical request identity, payload
-SHA-256, durable state, attempt count, retry ceiling, and exact capability
-digest. Replaying identical bytes converges on the same durable item. Reusing
+SHA-256, durable state, attempt count, retry ceiling, exact HTTP capability
+digest, and verified runtime binding. Replaying identical bytes converges on
+the same durable item. Reusing
 an identity with different content or policy returns HTTP `409` and does not
 alter stored work.
 
@@ -593,8 +690,8 @@ The status request is exact, query-free JSON and uses
 }
 ```
 
-Its `blun.cms-source-status-response.v4` response contains one nested
-`blun.cms-source-service-status.v3` snapshot. It binds the stored
+Its `blun.cms-source-status-response.v6` response contains one nested
+`blun.cms-source-service-status.v4` snapshot. It binds the stored
 `website_version`, `source_sequence`, canonical change hash, dispatch state and
 attempts, remote plan and job count, local lifecycle state, remote lifecycle
 status, lifecycle hash, required and approved locales, blocked locale reason
@@ -605,17 +702,22 @@ write. A caller can therefore distinguish queued work, a pending local
 registration, active localization, approval, publication, cancellation, and a
 terminal failure without accidentally advancing the worker.
 
-Version 2 additionally exposes only the terminal notification state, its
+The status projection additionally exposes only the terminal notification state, its
 content-free identity and hash, bounded attempt counters, and a public error
 code. When the terminal notifier exposes the pinned receiver `status` method,
 the snapshot also reports the independently durable processing observation,
-poll failures, receiver attempts, and stable local and receiver error codes.
-An intake acknowledgement is never presented as completed CMS processing.
-
-The corresponding `blun.cms-source-health-response.v4` and nested
-`blun.cms-source-service-health.v3` report notification and processing-observer
-backlog plus component
-health without revealing website content or callback responses.
+poll failures, receiver attempts, stable local and receiver error codes, and
+the exact terminal receiver capability SHA-256. Disabled observation uses an
+explicit `null` binding. An intake acknowledgement is never presented as
+completed CMS processing.
+
+The corresponding `blun.cms-source-health-response.v6` and nested
+`blun.cms-source-service-health.v4` report notification and processing-observer
+backlog plus component health without revealing website content or callback
+responses. The service-level receiver digest must exactly match the monitor
+component's stored digest. Missing, malformed, substituted, or contradictory
+bindings fail closed through the reference client and every outer lifecycle
+projection.
 
 Before parsing JSON or touching SQLite, the application calls the host-supplied
 authenticator with this content-free request:
@@ -653,9 +755,14 @@ credential, exception, source string, or target string.
 
 `integrations/website_localization_cms_source_client.py` is the provider-neutral
 client for this complete ingress. Construct `CMSLocalizationSourceHTTPClient`
-with one exact HTTPS origin, an `expected_capabilities_sha256` supplied through
-trusted deployment configuration, and a callback that provides authentication
-headers for the canonical request context. The callback receives the method,
+with one exact HTTPS origin, the HTTP contract pin, and the source runtime's
+commercial capability and rendering-registry pins supplied through trusted
+deployment configuration. When terminal observation is enabled, also supply
+the exact receiver generation as
+`expected_terminal_receiver_capabilities_sha256`; leaving it unset pins the
+client to the explicitly disabled `null` state. A callback provides
+authentication headers for the
+canonical request context and receives the method,
 origin, verified path and scope, body SHA-256, and the applicable event, site,
 or request identity; it cannot replace framing, idempotency, or binding headers.
 
@@ -666,14 +773,18 @@ operation definition to match the installed contract and trusted pin, takes
 the write path from that fresh result, and performs exactly one request. The
 immutable event, cancellation, or tombstone identity is the idempotency key.
 An accepted response must return the same operation, request and event IDs,
-canonical inner-payload hash, retry ceiling, and capability digest.
+canonical inner-payload hash, retry ceiling, capability digest, and exact
+runtime binding.
 
 `status()`, `health()`, and `readiness()` repeat discovery independently and
 then validate every returned field and cross-field invariant. Status is bound
-to the requested event and site. Health and readiness accept their documented
-`200` and `503` states only when the HTTP status agrees with the nested state.
-All five operational response schemas carry `capabilities_sha256`; a process
-swap or stale response between discovery and the operation therefore blocks.
+to the requested event, site, and configured terminal receiver generation.
+Health requires the same generation at service and monitor-component level;
+health and readiness accept their documented `200` and `503` states only when
+the HTTP status agrees with the nested state.
+All five operational response schemas carry `capabilities_sha256` and the
+runtime binding. A missing, malformed, substituted, or stale binding blocks
+even when the static HTTP schema still matches its separate contract pin.
 
 The adapter owns no retry loop. `CMSSourceClientBlocked` contains only a stable
 content-free code and retryability decision, so the website host may apply its
@@ -752,6 +863,854 @@ keeps the database connection open; close it only after the worker finishes.
 Worker exceptions are reduced to `source_delivery_runtime.worker_blocked`, and
 the failed runtime cannot accept more managed source events.
 
+When the source client supplies the verified runtime-capability, commercial
+rendering-registry, and terminal-receiver pins, the durable outbox also creates
+one canonical `source_delivery` binding record. It binds all three generations
+together with the source-delivery contract hash and validates the table shape,
+exact row, and derived digest before every queue operation. A same-generation
+restart resumes pending work. Only an empty unbound database, or an exact empty
+v1 binding whose historical adapter digest can be reconstructed, may be bound
+or migrated automatically. A non-empty legacy queue, changed generation,
+altered metadata, or unpinned reopen of an already bound database blocks before
+queue or network access. The production HMAC website-to-sidecar composition
+binds its separate outer database to the same three verified generations. On
+restart it checks the existing file and canonical binding read-only before any
+capability request. A local schema, file-safety, or generation failure therefore
+makes no network request; a new database or safely migratable empty database
+proceeds to the authenticated downstream preflight before creation or migration.
+
+#### Website-source delivery HTTP sidecar
+
+`integrations/website_localization_cms_source_delivery_http.py` makes the
+protected website outbox available to CMS and website backends that do not
+embed Python. Pass `http_authenticator` to
+`open_hosted_cms_source_delivery()` and serve the resulting `runtime.http`
+WSGI application behind TLS. Invalid authentication configuration is rejected
+during in-memory preflight before the SQLite file is created. Omitting the
+option preserves the manual Python runtime and leaves `runtime.http` as `None`.
+
+The sidecar exposes these independently authorized operations:
+
+- `POST /v1/localization/source-delivery/changes`
+- `POST /v1/localization/source-delivery/removals`
+- `POST /v1/localization/source-delivery/status`
+- `POST /v1/localization/source-delivery/source-status`
+- `GET /v1/localization/source-delivery/health`
+- `GET /v1/localization/source-delivery/readiness`
+- `GET /v1/localization/source-delivery/source-health`
+- `GET /v1/localization/source-delivery/source-readiness`
+- `GET /v1/localization/source-delivery/capabilities`
+
+The authenticator receives schema
+`blun.cms-source-delivery-sidecar-auth-request.v1` with the exact method, path,
+sorted request headers, and SHA-256 of the received body. It returns a stable
+principal, credential identity and version, and the route's exact scope.
+Change, removal, status, and source-status routes additionally require the
+authorized `site_id`; the sidecar compares it independently with the request
+and the runtime result. An unknown request and one belonging to another
+website both return the same content-free `404` response.
+
+Change and removal bodies carry the complete immutable payload plus distinct
+`source_max_attempts` and `delivery_max_attempts` values. The
+`Idempotency-Key` must equal the event, cancellation, or tombstone ID, and
+`X-Localization-Source-Payload-SHA256` must equal the canonical inner-payload
+hash. HTTP `202` is returned only after the exact binding has been persisted.
+The sidecar performs no delivery attempt itself; the managed worker retains
+the single-attempt, durable-backoff, and crash-recovery semantics.
+
+Status, lifecycle, health, and readiness operations never return website text.
+The source-status route is gated on an exact durably accepted sidecar row; the
+body-free source-health and source-readiness routes keep downstream queue state
+and processing availability separate from sidecar intake. Every outgoing
+runtime object is checked for its exact field set, types, hashes, state
+invariants, request
+identity, and applicable tenant before serialization. The capability route
+describes all nine schemas, methods, paths, scopes, limits, and safety
+semantics under one canonical SHA-256. That digest is repeated on every
+operational response, and any internal contract drift blocks the complete
+response instead of advertising a rehashed weakened interface. Each of the
+three source-facing reads also carries the separately validated source runtime
+binding without exposing content.
+
+#### Contract-pinned source-delivery sidecar client
+
+`integrations/website_localization_cms_source_delivery_client.py` is the
+provider-neutral HTTPS reference client for all nine sidecar operations.
+Construct `CMSSourceDeliverySidecarHTTPClient` with one exact HTTPS origin, the
+trusted sidecar capability SHA-256, the separately trusted downstream
+source-service capability SHA-256, and a callback that returns authentication
+headers for the immutable request context. Loopback HTTP is available only
+through the explicit test/development option.
+
+Before every operational request the client fetches the live capability
+object, validates its complete canonical form against the installed contract,
+and requires its digest to equal the deployment pin. The subsequent request
+uses only the method, path, schema, and success status from that fresh object.
+The authentication callback receives the origin, method, verified path, scope,
+exact body SHA-256, and applicable site, event, request, and payload identities
+under `blun.cms-source-delivery-sidecar-client-auth-context.v1`.
+It cannot supply `Host`, framing, content type, idempotency, or source-payload
+binding headers.
+
+`submit_change()` and `submit_removal()` validate and canonically copy the
+complete source event before discovery. The body carries distinct source and
+delivery retry ceilings, while the reserved payload header hashes only the
+immutable inner event. One call performs one transport attempt and follows no
+redirect. Acceptance requires the exact request, event, tenant, payload,
+retry-policy, sidecar-contract, and downstream-contract bindings.
+
+`status()` requires the caller's already known operation, request, event,
+tenant, and payload hash; a response cannot silently substitute another
+durable item. `source_status()` adds the complete validated localization
+lifecycle and source runtime binding only after exact durable source
+acceptance. `health()`, `readiness()`,
+`source_health()`, and `source_readiness()` accept HTTP `503` only as an exactly
+validated blocked snapshot. Transport and server failures expose stable
+content-free codes plus retryability, but the client never schedules a retry.
+
+For the authenticated production path, construct
+`RotatingHMACCMSSourceDeliveryClient` from
+`website_localization_cms_source_delivery_auth_runtime.py`. Supply the exact
+origin, sidecar capability SHA-256, downstream capability SHA-256, initial
+`HMACCredential`, clock/nonce policy, timeout, and optional transport once. The
+composition creates one private `RotatingSourceDeliveryHMACSigner` and one
+`CMSSourceDeliverySidecarHTTPClient` from that same immutable configuration.
+Invalid construction is reduced to
+`source_delivery_hmac.client_configuration_invalid` before any network call.
+
+The composed surface exposes `capabilities()`, `submit_change()`,
+`submit_removal()`, `status()`, `source_status()`, `health()`, `readiness()`,
+`source_health()`, and `source_readiness()` with the original contract
+signatures. `replace_credential()` updates the exact signer used by all nine
+routes. The client is process-bound before delegation, so a forked worker
+cannot reach its inherited transport; create a fresh client in the child from
+host-owned secret state. Client errors retain the underlying stable
+content-free retry decision,
+and neither the wrapper nor its representation exposes the credential, tenant,
+endpoint, or website content.
+
+#### Owned authenticated website submission runtime
+
+`integrations/website_localization_cms_source_delivery_submission_runtime.py`
+is the production composition root for a website process that submits through
+the authenticated sidecar. Use
+`open_durable_hmac_cms_source_delivery_submission()` for an externally driven
+loop or `open_hosted_hmac_cms_source_delivery_submission()` to start the owned
+non-daemon worker. Both construct one `RotatingHMACCMSSourceDeliveryClient`,
+one `CMSSourceDeliverySidecarOutboxAdapter`, and one guarded SQLite runtime.
+
+Supply the initial `HMACCredential`, exact HTTPS origin, trusted sidecar and
+downstream capability hashes, the expected source-runtime capability SHA-256,
+the expected commercial rendering-registry SHA-256, the expected terminal-
+receiver capability SHA-256, worker identity, and the middle
+`sidecar_delivery_max_attempts` once. Before opening the website SQLite file,
+the composition reads source readiness through the authenticated sidecar and
+requires its verified capability binding to match all three generation pins.
+Unavailable, missing, partial, malformed, or substituted evidence blocks with
+a stable content-free error before database creation. The hosted factory still
+validates all loop delays before that preflight.
+
+All three verified generation values become part of the v3 adapter capability
+digest and the outer outbox's v2 role-specific durable binding. A restart
+therefore resumes pending website work only under the exact same sidecar
+adapter, source-runtime, commercial-rendering, and terminal-receiver
+generation. The SQLite file retains the existing owner-only, process-bound,
+inode-guarded lifecycle. Only an exact empty v1 binding can migrate, using the
+reconstructed v2 adapter digest; existing legacy work is never relabelled.
+
+Call `submission_capabilities()` to discover the exact live contract of this
+complete website edge. The content-free
+`blun.cms-source-delivery-submission-capabilities.v7` snapshot advertises the
+public change, removal, acceptance-status, and lifecycle HTTPS contracts, all
+six composed operational
+projection schemas, the separately owned website, sidecar and source retry
+budgets, and the explicit rule that durable website-outbox acceptance is not
+source acceptance or publication. It also
+states that this edge neither generates translations nor grants publication
+authority. Its
+canonical SHA-256 binds the locally verified website generation to the current
+sidecar and source-service capability pins.
+
+The method validates the guarded SQLite generation before it performs one
+fresh authenticated sidecar capability request. A missing or changed local
+binding therefore causes no network traffic. A stale, substituted or malformed
+sidecar contract blocks the whole snapshot; the runtime never returns partial
+capabilities. Returned nested maps are defensive copies and contain no
+endpoint, credential, tenant, source text, target text or project price.
+
+For a separately hosted website process, wrap that same runtime with
+`build_submission_http()` from
+`integrations/website_localization_cms_source_delivery_submission_http.py`.
+It exposes the capability route plus two durable write routes:
+
+| Method | Path | Required scope |
+| --- | --- | --- |
+| `GET` | `/v1/localization/source-delivery/submission-capabilities` | `source-delivery-submission-capabilities:read` |
+| `POST` | `/v1/localization/source-delivery/submissions/changes` | `source-delivery-submission-change:write` |
+| `POST` | `/v1/localization/source-delivery/submissions/removals` | `source-delivery-submission-removal:write` |
+| `POST` | `/v1/localization/source-delivery/submissions/status` | `source-delivery-submission-status:read` |
+| `POST` | `/v1/localization/source-delivery/submissions/lifecycle` | `source-delivery-submission-lifecycle:read` |
+| `GET` | `/v1/localization/source-delivery/submissions/pipeline-health` | `source-delivery-submission-pipeline-health:read` |
+| `GET` | `/v1/localization/source-delivery/submissions/pipeline-readiness` | `source-delivery-submission-pipeline-readiness:read` |
+
+The two operator routes require an exact body-free HTTPS GET and a site-free
+operator principal. Their scopes are intentionally distinct. They expose only
+the already content-free composed runtime projections, after independently
+revalidating every nested component, capability hash, and runtime binding.
+Health preserves `ok`, `degraded`, and `blocked`; readiness preserves only
+whether every required worker can accept and process work. Neither route
+accepts a query, identifies a tenant, returns source or target text, or grants
+quality approval or publication authority.
+
+The capability-discovery route still requires HTTPS, no query, no request body, no content
+type, and no transfer encoding. Before any local database read or sidecar
+request, the adapter calls the deployment-owned authenticator with schema
+`blun.cms-source-delivery-submission-capabilities-auth-request.v1`, the exact
+method and path, normalized request headers, and the SHA-256 of the empty body.
+The authenticator must return only principal schema
+`blun.cms-source-delivery-submission-capabilities-principal.v1`, principal ID,
+credential ID and version, and the exact required scope. Deployments may use
+HMAC, mutual TLS, a bearer-token proxy, or another verifier; replay prevention,
+credential storage, and rotation remain host responsibilities.
+
+Each write route requires HTTPS, canonical UTF-8 JSON, an exact decimal
+`Content-Length`, no query or transfer encoding, and a body of at most
+4,000,000 bytes. Its envelope contains exactly one change or removal plus the
+independent `source_max_attempts` and `delivery_max_attempts` values, each from
+1 through 20. `Idempotency-Key` must equal the event, cancellation, or
+tombstone identity. `X-Localization-Source-Payload-Sha256` must equal the
+canonical SHA-256 of the nested source payload. Duplicate JSON keys,
+non-finite numbers, a UTF-8 BOM, wrong payload type, wrong identifier, wrong
+hash, or a different retry budget on replay blocks before persistence.
+
+The write authenticator receives only normalized request metadata and the
+whole-body SHA-256 under
+`blun.cms-source-delivery-submission-http-auth-request.v1`. It must return the
+exact write scope and an authorized `site_id` under
+`blun.cms-source-delivery-submission-write-principal.v1`. A foreign site is
+reported as not found and cannot reach readiness, generation, or queue state.
+The hosted worker and role-specific commercial capability generation must both
+be ready before enqueue. Only after SQLite commits the immutable outer-outbox
+row does the adapter return HTTP 202 with content-free identity, hashes,
+separate retry ceilings, current local queue status, and the verified website
+generation. That acknowledgement never means sidecar or source acceptance,
+quality approval, translation generation, or publication. An exact replay is
+safe; an identity collision returns a content-free conflict.
+
+The two operational read routes require HTTPS and an exact UTF-8 JSON envelope
+containing only schema, operation, request ID, event ID, site ID, and the
+canonical source-payload SHA-256. They use the distinct authentication schema
+`blun.cms-source-delivery-submission-read-auth-request.v1`; the authenticator
+must return the route-specific read scope and authorized site under
+`blun.cms-source-delivery-submission-read-principal.v1`. Foreign sites return
+the same not-found boundary as absent work before any runtime lookup.
+
+The status route returns the independently validated website and sidecar
+acceptance projection. The lifecycle route retains that projection as a
+nested object and, only after source acceptance, adds the validated source
+processing lifecycle and its separate capability binding. Exact request
+identity, retry limits, source and website bindings, counters, and nested site
+identity are rechecked before serialization. Neither HTTP 200 nor an
+`accepted` state implies linguistic approval or publication; malformed,
+cross-bound, or unavailable state returns only a content-free blocking error.
+
+Deployments that need read-only discovery may continue to use
+`build_submission_capabilities_http()` directly. Both builders validate the
+same v5 capability snapshot, so the advertised public routes cannot drift from
+the hosted write boundary.
+
+Python and separately deployed website backends may consume the complete
+edge through `CMSSourceDeliverySubmissionHTTPClient` in
+`integrations/website_localization_cms_source_delivery_submission_client.py`.
+Construct it with one exact HTTPS origin, the deployment-approved complete
+submission-capability SHA-256, and a host-owned authentication-header callback.
+The callback receives schema
+`blun.cms-source-delivery-submission-client-auth-context.v1`, exact method,
+origin, freshly discovered path and scope, canonical body SHA-256, and—where
+applicable—the site, event, request, and source-payload identities. Credentials
+remain outside the adapter.
+
+`submit_change()` and `submit_removal()` validate one complete source payload
+before discovery, use only the freshly advertised write contract, and add the
+reserved idempotency and source-payload digest headers after authentication.
+`submission_status()` and `submission_lifecycle()` require the caller's full
+known operation, request, event, site, and payload-hash binding; they do not
+offer identifier-only enumeration. `pipeline_health()` and
+`pipeline_readiness()` are distinct, body-free, site-free operator operations.
+
+Every method first validates the exact complete v5 capability shape, canonical
+digest, durable website binding, and sidecar/source generation hashes against
+the configured deployment pin. It then performs exactly one operational
+transport attempt and independently validates the entire response against the
+request and that same discovered generation. Authentication headers may not
+replace `Host`, framing, media-type, idempotency, or payload-binding headers.
+The default transport follows no redirects and performs no retry; a caller may
+schedule a bounded retry only when the stable content-free failure explicitly
+reports `retryable: true`, and must replay the identical immutable request.
+Representations and failures expose no origin, credential, tenant, source, or
+target text.
+
+#### Durable caller-side public submission
+
+`integrations/website_localization_cms_source_delivery_submission_dispatch.py`
+adds the crash-safe caller-owned handoff for that one-attempt client. Construct
+`DurableCMSSourceDeliverySubmissionDispatcher` over a dedicated SQLite
+connection and the same deployment-approved complete capability SHA-256 as the
+client. The database metadata permanently binds queued work to that generation;
+a restart with another pin blocks before a claim or network call.
+
+`enqueue()` accepts one complete change, cancellation, or tombstone and commits
+its canonical payload plus operation, request, event, site, payload hash, and
+all three retry ceilings before transport. `client_max_attempts` belongs only
+to the CMS-to-website hop. `delivery_max_attempts` remains the website-to-
+sidecar ceiling, and `source_max_attempts` remains the source-processing
+ceiling. An exact enqueue is idempotent; changed content or any changed retry
+budget under the same identity is a collision.
+
+`run_once()` validates the dispatcher's schema and the client's immutable pin,
+then claims at most one due row with a random token. It calls exactly one client
+method, prioritizing due cancellations and tombstones over equally old changes,
+and schedules exponential backoff only for a failure whose client
+contract explicitly marks it retryable. A permanent failure or exhausted local
+ceiling stays failed. If the process stops after remote HTTP 202 but before the
+local completion commit, lease expiry makes the next worker replay the exact
+stored request; the website edge's idempotency remains authoritative.
+
+`status()` and `health()` expose content-free identities, counters, stable
+failure codes, capability hashes, and response hashes. They never expose the
+stored payload. Once—and only once—a record is locally `accepted`, `status()`
+also returns the complete verified website capability binding from the
+canonical stored intake response. This identifies the exact delivery, runtime,
+commercial-rendering registry, and terminal-receiver generations without
+revealing website content. The binding's own hash and delivery capability pin
+are rechecked at every projection. Every read revalidates the complete row;
+altered source text, hashes, retry limits, leases, response evidence, schema,
+or generation metadata block fail-closed. Local `accepted` records only durable
+website intake and do not mean source acceptance, quality approval,
+translation completion, or publication readiness.
+
+#### Owned public-submission runtime
+
+`integrations/website_localization_cms_source_delivery_submission_dispatch_runtime.py`
+is the production composition root for that caller-side outbox. Use
+`open_durable_cms_source_delivery_submission_dispatch()` for an externally
+scheduled worker, or `open_hosted_cms_source_delivery_submission_dispatch()`
+to own one supervised non-daemon worker. Both factories validate the complete
+client pin, retry and lease policy, clock, worker identity, and—on restart—the
+exact stored schema and every durable row before operational schema mutation.
+
+For file-backed operation, pass a normalized absolute path below an owner-held
+safe directory. The runtime creates the SQLite file with mode `0600`, binds its
+device and inode, rejects links and replacements, checks the current process
+before acquiring locks, and serializes all connection access. It rechecks the
+file, parent directories, and client capability pin around every enqueue,
+status, health, or delivery transition. A stale or malformed generation is
+therefore rejected locally before the public HTTPS client can make a request.
+
+Hosted intake is gated on a live supervised worker. `worker_readiness()` is a
+content-free snapshot containing only worker state, outbox state, a stable
+error code, and the pinned capability digest; it grants no publication
+authority. `close()` first signals and joins the worker. If a transport call
+does not return within the configured bound, shutdown fails closed and leaves
+SQLite open so the caller can recover deliberately instead of closing storage
+beneath an active attempt.
+
+#### Authenticated CMS submission sidecar
+
+`integrations/website_localization_cms_source_delivery_submission_dispatch_http.py`
+wraps the owned runtime in a strict HTTPS/WSGI contract for non-Python CMS and
+website backends. Pass a callable `http_authenticator` to either runtime
+factory; the resulting application is available as `runtime.http`. A hosted
+runtime is required for public writes. An externally scheduled, unmanaged, or
+stopped worker remains observable but rejects enqueue before request parsing or
+outbox access.
+
+The canonical capability response at
+`GET /v1/localization/cms-submission-dispatch/capabilities` publishes the exact
+method, path, scope, principal schema, request schema, response schema, limits,
+retry ownership, non-publication semantics, and downstream public-submission
+capability pin. The complete object has its own canonical SHA-256. Health and
+readiness use separate body-free operator scopes. Health describes durable
+outbox integrity; readiness additionally requires the supervised worker to be
+alive and the outbox to be healthy.
+
+Queue and status responses share a closed status shape. A pending, leased,
+retrying, or failed row has a null `remote_website_capability_binding`; an
+accepted row must contain the exact complete binding and matching
+`remote_binding_sha256` and `remote_capabilities_sha256` values. The HTTP
+server and reference client independently enforce this invariant, so a stale,
+partial, or substituted generation is not treated as a valid status.
+
+`GET /v1/localization/cms-submission-dispatch/openapi` uses its own body-free
+operator scope and returns an origin-free OpenAPI 3.1 document generated from
+that exact capability object. It describes all eight routes with their methods,
+scopes, principal schemas, request and response schemas, required idempotency
+and payload-hash headers, transport limits, retry ownership, and fail-closed
+publication semantics. The response binds the canonical document hash to the
+active capability hash and contains no server URL, tenant identity, website
+content, model provider, or credential value.
+
+The enqueue payload is a closed discriminated union keyed by `schema` for
+`blun.cms-content-change.v2`, `blun.cms-content-cancellation.v1`, and
+`blun.cms-content-tombstone.v1`. Changes carry the complete closed localization
+request, including NFC source text, canonical BCP-47 source locale, content
+type, glossary/policy/model/software versions, and an optional unique target
+array restricted to the 24 exact EU locale profiles. Cancellation and
+tombstone shapes contain only their immutable request and source identities.
+The v3 capability document binds all three payload schema IDs. JSON Schema
+metadata records the UTF-8 source byte ceiling and source-language exclusion;
+the runtime remains authoritative for checks JSON Schema cannot express
+portably, including NFC bytes, canonical locale casing, and language-family
+exclusion.
+
+The capability response is also fully machine-readable rather than an open
+placeholder. Its OpenAPI component recursively closes every nested object and
+fixes each route, method, scope, principal, request and response schema, limit,
+retry owner, source-event schema, downstream capability pin, and fail-closed
+semantic to the active generation. The v4 capability document additionally
+binds `openapi_document_schema`; therefore an older or replaced description
+cannot keep the same capability SHA-256 even if its routes appear compatible.
+
+The v5 capability generation additionally publishes the exact ordered
+`error_statuses` for every operation. The v4 OpenAPI document renders those as
+concrete responses and has no catch-all `default` response. Enqueue exposes
+conflict and body-framing outcomes, status exposes its tenant-safe not-found
+outcome, and all routes expose their authentication and availability failures.
+For health and readiness only, `503` is a `oneOf` between the route's normal
+content-free monitor envelope and the standard fail-closed error envelope;
+this matches the runtime distinction between a valid degraded state and an
+inability to produce trustworthy monitoring evidence.
+
+The v6 capability generation and v5 OpenAPI document also bind semantic
+response invariants. `SubmissionStatus` uses JSON Schema 2020-12 conditionals
+to require a lease expiry exactly for `leased`, and complete remote status,
+attempt and digest evidence exactly for `accepted`. Health permits `ok` only
+with zero failures and expired leases, while `blocked` requires at least one
+of those signals. Readiness is a closed union between a running, healthy,
+error-free `ready` state and a `not_ready` state with a stable error code.
+Each operation carries the same ordered `x-response-invariants` list as its
+capability record. Stable identifiers retain rules that portable JSON Schema
+cannot encode, including attempt-count comparisons, request-identity equality
+and queue-count sums; runtime and the pinned reference client remain
+authoritative for those relationships.
+
+The v7 capability generation and v6 OpenAPI document bind every fail-closed
+error code to its exact route and HTTP status. Each concrete non-success
+response carries a closed `x-error-codes` list and an identical schema enum;
+the complete per-operation map is part of the capability SHA-256. Bodyless
+discovery and monitor routes include `411` for an invalid declared length and
+`413` for an oversized body, matching the shared framing parser rather than an
+idealized GET-only path.
+
+The reference client validates a remote error as a three-field closed envelope
+before exposing `http_status` and `remote_error_code` on its content-free
+exception. Codes outside the pinned status-specific set, extra fields,
+mismatched schemas, malformed JSON, and undeclared statuses never become
+trusted reasons. Verified `503` errors remain retryable and a verified `409`
+idempotency collision remains terminal; the exception message itself contains
+only the stable local failure code.
+
+The v8 capability generation and v7 OpenAPI document additionally require
+`X-Localization-Capabilities-SHA256` on every route except authenticated
+capability discovery. The header must equal the complete active sidecar
+capability SHA-256 and participates in the host authentication context. A
+missing header returns the advertised content-free `428`; a stale or replaced
+generation returns `412`. Both failures occur before enqueue, status lookup,
+health/readiness access, or OpenAPI generation, so a capability change between
+discovery and operation cannot persist or expose work under an unexpected
+contract. Discovery itself remains the bootstrap and therefore requires no
+self-referential precondition.
+
+The v12 capability generation and v11 OpenAPI document bind commercial-profile
+discovery to the actual enqueue operation. Every enqueue request includes
+`commercial_contract_binding`. For a `commercial` change it must exactly match
+the active profile identifier, profile SHA-256, and complete 24-locale
+rendering-registry SHA-256 advertised by the same capability generation. For
+all other content types, cancellations, and tombstones it must be `null`.
+
+The binding is part of the body authenticated before JSON parsing. The runtime
+then compares it with the freshly reconstructed capability before durable
+enqueue. The OpenAPI schema expresses the same content-type conditional, and
+the reference client derives the value only from its independently pinned
+capability. The binding is content-free and carries no price, currency, tax,
+term, brand, product, source text, target text, credential, or publication
+authority.
+
+The v13 capability generation and v12 OpenAPI document make that
+acknowledgement durable. The caller-owned outbox stores its canonical closed
+binding beside the immutable payload hash and returns it through queue, status,
+and lifecycle state. Claims and retries carry the same value, and every row is
+revalidated against both its source payload and the installed commercial
+profile before a network call or status response. Cancellation, tombstone, and
+non-commercial rows retain an exact `null` binding.
+
+Schema v2 migrates only an exact, empty schema-v1 outbox under a transaction.
+A populated legacy outbox remains byte-for-byte untouched and blocks startup:
+the service cannot truthfully infer which historic commercial contract its
+rows acknowledged. Missing, modified, non-canonical, stale, or cross-content
+bindings likewise block fail-closed rather than being repaired automatically.
+
+The v14 capability generation and v13 OpenAPI document bind that durable CMS
+acknowledgement to the website generation that actually accepts the work. For
+an accepted commercial change, the downstream
+`commercial_rendering_registry_sha256` must equal the same field in the stored
+`commercial_contract_binding`. A different website binding is rejected even
+when all of its fields and its own `binding_sha256` are internally consistent.
+
+This cross-generation invariant is checked before the acceptance transaction,
+again whenever the stored row is read after a restart or by health, and once
+more at both the HTTP serialization boundary and the reference client. The
+status and lifecycle remain content-free and grant no publication authority;
+an unresolved generation mismatch cannot be reported as accepted.
+
+The v11 capability generation and v10 OpenAPI document add
+`GET /v1/localization/cms-submission-dispatch/commercial-profile` with a
+separate body-free operator scope. It returns the exact public
+`translate-native.commercial.v13` profile, its ten ordered preservation and
+review dimensions, and the complete 24-locale rendering registry. The payload
+contains only policy, version, authority, locale, Unicode rendering, and hash
+data; project prices, brands, products, credentials, source text, and target
+text are excluded by the closed contract. It is explicitly content-free and
+grants no publication authority.
+
+Before producing that response, the dispatcher fetches and revalidates the
+live downstream website capability generation. The website binding's
+commercial-rendering SHA-256 must equal the canonical registry returned by the
+route. Missing capability preconditions, stale website generations, registry
+drift, malformed locale sets, or substituted profile fields block before any
+response is serialized.
+
+`POST /v1/localization/cms-submission-dispatch/requests` authenticates the
+method, path, headers, and exact raw-body SHA-256 before decoding JSON. Its
+tenant principal must match the payload's `site_id`; `Idempotency-Key` must
+match the immutable request identity; and
+`X-Localization-Source-Payload-SHA256` must match the canonical complete source
+payload. The request carries distinct `client_max_attempts`,
+`delivery_max_attempts`, and `source_max_attempts` values. HTTP 202 follows only
+after the local durable commit and explicitly means website intake only—not
+source acceptance, linguistic approval, or publication.
+
+`POST /v1/localization/cms-submission-dispatch/status` uses a distinct tenant
+read scope and requires the complete known operation, request, event, site, and
+payload-hash identity. A foreign tenant, altered identity, and absent request
+all produce the same content-free not-found response. Every operational result
+is independently revalidated against the active capability generation before
+serialization. Invalid framing, authentication outage, capability or storage
+drift, a malformed runtime result, and a dead worker therefore block without
+returning stored source content or invoking the downstream public client.
+
+`POST /v1/localization/cms-submission-dispatch/lifecycle` extends that exact
+tenant identity into the downstream source lifecycle. It is available only
+after the caller-owned outbox has durably recorded website acceptance; every
+earlier outer state returns the advertised non-retryable conflict and performs
+no downstream request. The runtime validates the stored acceptance binding,
+then the pinned public-submission client performs one read and verifies the
+complete nested website, sidecar, source, and source-processing generations.
+The outer HTTP edge validates the lifecycle again before serialization.
+Acceptance at either boundary remains explicitly distinct from linguistic
+approval and publication.
+
+#### Public submission sidecar reference client
+
+`integrations/website_localization_cms_source_delivery_submission_dispatch_client.py`
+is the provider-neutral HTTPS reference adapter for backends that do not share
+the Python runtime. Construct it with one exact HTTPS origin, the expected
+sidecar capability SHA-256, the independently expected downstream public
+submission capability SHA-256, and a credential-header callback. The two pins
+must reconstruct the current canonical contract exactly; they are never
+interchangeable.
+
+`enqueue()` accepts one complete change, cancellation, or tombstone and keeps
+the source-, delivery-, and client-stage retry ceilings distinct. `status()`
+requires the complete previously known operation, request, event, site, and
+source-payload identity. `lifecycle()` uses the same identity and refuses to
+contact the downstream service until the local status is accepted. `health()`,
+`readiness()`, `capabilities()`, `commercial_profile()`, and
+`openapi()` use their separate operator scopes. Each operational method first
+fetches the live capability document, accepts only the exact current closed
+shape, then makes one bounded request without following redirects or retrying
+internally.
+
+`openapi()` also reconstructs the expected document from the separately pinned
+sidecar and downstream capability generations and requires an exact match. A
+peer cannot make a substituted description acceptable merely by recomputing
+the advertised OpenAPI hash.
+
+The credential callback receives a content-free context containing the exact
+method, origin, path, scope, and body SHA-256 plus tenant identity where
+applicable. It cannot supply `Host`, framing, content, idempotency, or canonical
+payload-hash headers. Network and selected transient HTTP failures are marked
+retryable for the caller's durable scheduler; redirects, authentication,
+schema, identity, state, and capability failures are terminal. Every returned
+object is independently checked against both deployment generations and never
+grants localization approval or publication authority.
+
+A successful response uses schema
+`blun.cms-source-delivery-submission-capabilities-response.v1` and includes the
+HTTP API schema plus the complete freshly verified capability. The adapter
+revalidates every operation, retry-policy field, publication semantic, both
+downstream pins, the exact durable website binding, and the canonical digest.
+It never serializes the authenticated principal. Authentication outage,
+runtime outage, stale hash, foreign schema, extra field, or altered semantic
+returns a `blun.cms-source-delivery-submission-capabilities-http-error.v1`
+envelope with only `BLOCK` and a stable error code.
+
+`enqueue_change()` and `enqueue_removal()` persist work before transport.
+Their `delivery_max_attempts` controls only website-to-sidecar acceptance;
+their `source_max_attempts` remains the final processing ceiling; the factory's
+middle limit controls sidecar delivery. `status()` and `health()` describe the
+local acceptance outbox. `sidecar_status()`, `sidecar_health()`,
+`sidecar_readiness()`, `sidecar_source_status()`,
+`sidecar_source_health()`, `sidecar_source_readiness()`, and
+`sidecar_capabilities()` perform separately authenticated operational reads and
+never reinterpret local success as downstream completion.
+
+Use `submission_status(operation, request_id)` for a single content-free
+projection across both acceptance queues. While the website row is pending,
+leased, retrying, or failed, it performs no network request and reports stage
+`website_acceptance`. Only after local success does it query the sidecar with
+the persisted operation, request, event, site, and payload hash. The response
+must preserve those bindings, both capability pins, the configured middle
+delivery ceiling, and the source-processing ceiling.
+
+The projection schema is
+`blun.cms-source-delivery-submission-status.v2`. Its top-level status is
+`pending`, `failed`, or `accepted`; its stage is `website_acceptance`,
+`sidecar_delivery`, or `source_acceptance`. It includes the separate website
+and sidecar states, attempt counts and retry ceilings, the next-attempt time,
+lease-expiry flag, and a stable content-free error code. `accepted` means the
+source service has durably accepted the event. It does not mean translation,
+quality review, release approval, or publication succeeded.
+
+The `website_capability_binding` field is independently recomputed from the
+validated, role-specific SQLite generation before the status is projected. It
+contains only the outer adapter capability hash, source-runtime hash,
+commercial rendering-registry hash, terminal-receiver capability hash,
+database role, and their canonical binding hash. A missing, changed, or
+malformed binding blocks locally before a sidecar status request.
+
+`submission_lifecycle()` extends that accepted state with the independently
+validated source lifecycle. Its
+`blun.cms-source-delivery-submission-lifecycle.v4` projection keeps submission,
+source status, the verified website generation, and the verified source runtime
+binding separate. Missing or changed binding evidence blocks instead of
+returning a processing state.
+
+Use `submission_readiness()` to inspect the complete durable intake path
+without collapsing its two independently operated workers. The method first
+validates the website worker's local readiness object. If that worker or its
+outbox is not ready, it returns `not_ready` without making a network request.
+Only a locally ready runtime performs the authenticated, contract-pinned
+sidecar readiness request.
+
+The content-free
+`blun.cms-source-delivery-submission-readiness.v2` projection retains separate
+website and sidecar readiness, worker state, outbox state, and stable error
+code fields. It also carries the trusted sidecar and source-service capability
+hashes plus the locally verified website generation. Overall status is `ready`
+only when both workers report `running`, both
+outboxes report `ok`, both component error codes are absent, and the sidecar
+response matches the currently pinned contract. This is intake readiness; it
+does not assert that a particular localization or publication has completed.
+
+Use `submission_pipeline_readiness()` when the website must also prove that the
+source localization service can process accepted work. The method evaluates
+the existing intake projection first. If the website worker or sidecar is not
+ready, `source_readiness` remains `null` and no request reaches the next layer.
+Only fully ready intake performs the separately authenticated, body-free
+`source_readiness()` operation through the sidecar.
+
+The resulting
+`blun.cms-source-delivery-submission-pipeline-readiness.v3` object keeps the
+complete intake projection and source-worker projection separate, binds the
+current sidecar and source-service capability hashes plus the website and
+source runtime bindings, and reports overall
+`ready` only when both projections are independently ready. A stopped source
+worker, transport failure, malformed status combination, or capability drift
+blocks fail-closed. This operational probe is content-free and makes no claim
+that any particular locale has passed review or publication.
+
+Use `submission_health()` for one content-free operational view of both
+durable acceptance outboxes. The runtime validates its local health object
+before making any network request, then retrieves the sidecar health through
+the owned authenticated, contract-pinned client. Invalid local state therefore
+blocks offline; malformed remote counters, contradictory status, and changed
+capability bindings also block fail-closed.
+
+The `blun.cms-source-delivery-submission-health.v2` projection retains the
+complete whitelisted website and sidecar health snapshots separately,
+including counts, operation totals, due work, expired leases, terminal
+failures, contract mismatches, and stable error codes. Its overall status is
+`ok` only when both snapshots independently report `ok`. A blocked component
+can never be hidden by the other component's healthy state. The exact website
+generation binding is checked locally and included before the sidecar health
+request is allowed.
+
+Use `submission_pipeline_health()` to extend that health view through every
+durable source-processing queue. The runtime evaluates the website and sidecar
+intake projection first. If either intake outbox is blocked, `source_health`
+remains `null` and no source-health request is made. Healthy intake performs a
+separately authenticated, body-free source-health request through the sidecar.
+
+The resulting `blun.cms-source-delivery-submission-pipeline-health.v3` object
+keeps the intake projection and complete source-service projection separate,
+binds both current capability hashes and the website and source runtime
+bindings, and
+preserves `ok`, `degraded`, or
+`blocked` source state. Invalid counters, contradictory HTTP status, transport
+failure, or capability drift block fail-closed without returning content.
+
+Call `replace_credential()` only during a server-side generation overlap. It
+updates the exact signer owned by the worker without reopening the outbox or
+changing either contract pin. The wrapper blocks network and storage access
+after close or from a forked process; each child must create a fresh runtime
+from host-owned configuration. Representations and stable failures contain no
+secret, endpoint, tenant, source text, or provider response.
+
+#### Durable website submission through the sidecar
+
+`integrations/website_localization_cms_source_delivery_sidecar_adapter.py`
+connects that sidecar client to `DurableCMSSourceDeliveryOutbox` without
+collapsing retry ownership. Wrap the pinned or rotating-HMAC sidecar client in
+`CMSSourceDeliverySidecarOutboxAdapter`, configure the sidecar's downstream
+`sidecar_delivery_max_attempts`, and pass the adapter to
+`open_durable_cms_source_delivery()` or
+`open_hosted_cms_source_delivery()`.
+
+The runtime's `delivery_max_attempts` remains the website's ceiling for
+obtaining durable sidecar acceptance. `source_max_attempts` remains the source
+service's processing ceiling. The adapter's fixed
+`sidecar_delivery_max_attempts` is the independent middle ceiling used after
+acceptance. A transient failure reaching the sidecar therefore consumes only
+the outer budget.
+
+The adapter derives the outbox capability binding from a canonical record of
+the sidecar capability pin, downstream source-service capability pin, and
+middle retry ceiling. Any change blocks existing active rows before network
+access. Only an exact sidecar acceptance envelope is projected into the
+outbox's private completion receipt; downstream status is never represented as
+completed and must still be read through the sidecar status/lifecycle APIs.
+Malformed acknowledgements and undeclared exceptions fail closed.
+
+#### Rotatable source-delivery HMAC authentication
+
+`integrations/website_localization_cms_source_delivery_auth.py` provides a
+complete provider-neutral authentication implementation for the client and
+sidecar callback contracts. It is optional: deployments may still use bearer
+tokens, mutual TLS, an external identity proxy, or another verifier. HMAC here
+authenticates transport requests; it is not a linguistic-quality signature and
+cannot replace either review stage or a signed publication approval.
+
+Create an `HMACCredential` from a host-owned secret of at least 32 bytes, an
+explicit credential ID and generation, a sorted allowlist of route scopes, and
+the one authorized `site_id` whenever tenant scopes are present. The credential
+object redacts the secret from representations. Secrets are passed in memory;
+the module never reads, writes, generates, or rotates a live key file.
+
+`SourceDeliveryHMACSigner` is the `authentication_headers` callback for
+`CMSSourceDeliverySidecarHTTPClient`. `SourceDeliveryHMACVerifier` is the
+matching `http_authenticator` callback for
+`open_hosted_cms_source_delivery()`. Configure both from trusted deployment
+state with the identical HTTPS origin, sidecar capability SHA-256, downstream
+source-service capability SHA-256, and accepted credential generation. The
+canonical proof binds those values together with the exact method, live
+contract path, route scope, body hash, site, event, request and payload
+identities, and the actual idempotency and source-payload headers.
+
+For a long-lived client, use `RotatingSourceDeliveryHMACSigner` directly as
+the `authentication_headers` callback. Its origin, sidecar capability digest,
+downstream capability digest, clock policy, nonce source, and transport policy
+are fixed when it is constructed. `replace_credential()` validates one entire
+new `HMACCredential` and atomically replaces only the credential-bound signer
+under the same lock used to create proofs. Invalid replacement state keeps the
+last valid signer. The wrapper is process-bound and rejects inherited use after
+fork; each child must obtain its own host-supplied credential and signer.
+
+Every proof has a short bounded timestamp and a random nonce. The verifier
+checks the HMAC with constant-time comparison and then calls
+`DurableHMACReplayStore.consume()` before returning a principal. Construct the
+store over a dedicated caller-owned SQLite connection; threaded WSGI hosts
+must open that connection with `check_same_thread=False`. Keep its database on
+the same class of private durable storage as the delivery outbox and close it
+only after the HTTP host has stopped. The ledger contains only credential IDs,
+versions, nonces, proof hashes, and validity times—never secrets, request
+bodies, website text, translations, or provider responses.
+
+The store validates its schema and every retained row inside the same immediate
+transaction that consumes a nonce. Exact replay returns an invalid principal
+and therefore HTTP `401`. A store transaction conflict, malformed retained row,
+SQLite outage, or invalid clock raises a stable content-free infrastructure
+failure, which the sidecar maps to retryable HTTP `503` without accepting the
+request. Multiple credential generations may be configured simultaneously for
+a bounded rotation window; removing a generation retires it immediately.
+
+#### Protected authenticated sidecar runtime
+
+`integrations/website_localization_cms_source_delivery_auth_runtime.py`
+provides the production composition for the V6.67 proof. Call
+`open_hosted_hmac_authenticated_cms_source_delivery()` with distinct absolute
+outbox and replay-database paths, the provider-neutral source client, one or
+more explicit `HMACCredential` generations, worker identity, fixed HTTPS
+origin, and both trusted capability digests. The returned object owns the
+supervised delivery worker, sidecar WSGI application, outbox connection,
+authentication verifier, and replay connection as one lifecycle.
+
+Import the server-side `HMACCredential` alias from this runtime module so the
+credential values and verifier share the exact validated contract type. The
+secret still enters only as host-owned in-memory bytes and is never written to
+either database.
+
+The factory validates the complete authentication time window, credential
+scope, endpoint, contract pins, worker, retry policy, loop delays, SQLite
+timeouts, and distinct paths in memory before it opens either database. Each
+missing database is created exclusively with mode `0600`. Every later proof or
+authentication-health read rechecks the replay file's owner, type, link count,
+mode, device and inode, plus its safe parent chain. The runtime checks its
+creating process before entering a lock, serializes all connection use, and
+therefore rejects inherited pre-fork instances before SQLite or protected
+website state is touched.
+
+`authentication_health()` returns only schema, status, runtime state,
+consumed-nonce count, and stable error code. A local failure produces a
+`blocked` snapshot with no count. It never includes a path, site, credential, key, request
+body, source text, target text, or provider output. A missing, replaced,
+linked, permission-weakened, corrupt, closed, or foreign-process replay store
+makes the sidecar return retryable HTTP `503` during authentication, before
+the delivery runtime parses or persists protected content.
+
+Use `replace_credentials()` on either the composite runtime or its
+`authentication` member to rotate without stopping the delivery worker. A
+safe rollout proceeds in this order:
+
+1. Supply the old and new server generations together.
+2. Call `replace_credential()` on every client instance and verify traffic.
+3. Drain requests already emitted with the old credential and wait out the
+   configured proof validity and clock-skew window, unless an equivalent
+   deployment traffic barrier proves that none remain.
+4. Supply only the new server generation.
+
+The client signer lock serializes proof creation in one process. It cannot
+recall a proof already returned to the HTTP client, synchronize other fleet
+instances, or prove that a request has left the network. The server must
+therefore keep the old generation during the bounded drain window. The
+method materializes and validates the complete iterable, checks the replay
+database and process lifecycle, waits behind any in-flight authentication,
+and swaps exactly one fully constructed verifier. Invalid or unavailable
+replacement state leaves the previous verifier untouched. The same replay
+ledger remains open throughout, so a consumed proof stays consumed even if
+its credential generation is removed and later accepted again.
+
+The host remains responsible for fetching trusted secret-manager values and
+for deciding the overlap window. The runtime does not log, persist, return, or
+rotate secret material, and it never reads a key file or environment variable.
+
+Call `close()` only after the external HTTP server has stopped accepting new
+requests. The composite first signals and joins the delivery worker and closes
+the outbox, then closes the replay connection. If a provider call exceeds the
+configured worker-stop bound, the replay runtime deliberately remains open;
+the caller must resolve the still-running worker and retry shutdown rather
+than invalidating authentication underneath it.
+
 Premortem: an invalid deployment could create state before discovering a bad
 worker or timeout; two paths could alias one database; a pre-fork service could
 reuse a vanished parent's lock; or a permission change could redirect the next
@@ -974,8 +1933,11 @@ text out of access logs.
 `DurableCMSReceiverStore` in
 `integrations/website_localization_cms_receiver_store.py` supplies a complete
 SQLite reference implementation for the five stateful host callbacks. It uses
-one dedicated host-owned connection. The CMS registers each monotonic current
-source before delivery and explicitly pre-registers a tombstone against the
+one dedicated host-owned connection and requires both the canonical
+`release_evidence_is_current` validator and the configured publisher authority
+through a closed signature-validation callback supplied by the receiver. The CMS
+registers each monotonic current source before delivery and explicitly
+pre-registers a tombstone against the
 exact active publication before deletion. Commit and delete recheck those
 bindings inside `BEGIN IMMEDIATE`, so the earlier resolver lookup cannot race a
 source change. Replays are bound to immutable delivery and payload hashes, a
@@ -983,9 +1945,18 @@ replacement preserves the last-known-good bundle until its complete locale set
 commits. The successful replacement transaction then securely deletes the
 superseded payload and locale rows while retaining only content-free replay
 evidence; any cleanup failure rolls the switch back to the previous active
-bundle. Explicit deletion follows the same content-minimizing rule. The store's
-health callback validates schema, SQLite integrity, canonical payloads, locale rows, active pointers, and
-tombstone state before confirming the probe. Source and tombstone expectations
+bundle. Explicit deletion follows the same content-minimizing rule. The store
+retains the exact canonical publisher signature with each active payload. Its
+health callback validates schema, SQLite integrity, canonical payloads,
+publisher signatures, locale rows, active pointers, the current release-evidence
+contract, approval expiry, and tombstone state before confirming the probe.
+Active reads and idempotent publication replay run the same authorization checks
+after restart. A v1 database migrates to v2 without inventing missing
+signatures: signatureless active legacy rows remain blocked and unhealthy but
+can still be structurally tombstoned. Tombstone
+registration and deletion retain a structural-only path so an expired or
+contract-stale active bundle can always be removed without becoming publishable.
+Source and tombstone expectations
 carry separate canonical hashes, so a syntactically valid field substitution
 also blocks. `read_active_bundle` is for trusted
 CMS rendering code only. It requires the complete trusted publication
@@ -1037,7 +2008,7 @@ disabled, so a CMS can fail closed before submitting work. The object uses
 over every other canonical field. Paths and schemas come from the same runtime
 constants used for routing; they are not copied into a second configuration.
 
-The nested `blun.website-localization-capabilities.v3` object carries a
+The nested `blun.website-localization-capabilities.v9` object carries a
 `sha256` value over all its other canonical fields. Consumers can pin that
 digest for a deployment and deliberately reconfigure when it changes. The
 runtime rebuilds and validates the complete registry on every read; duplicate,
@@ -1045,40 +2016,275 @@ missing, noncanonical, or profile-mismatched entries return a fail-closed `503`
 without a partial locale list.
 
 Within it, `commercial_profile` is a separately hashed
-`translate-native.commercial-capabilities.v2` object. Its nested and separately
-hashed `review_summary_contract` defines the exact content-free result schema,
+`translate-native.commercial-capabilities.v15` object. Its nested and separately
+hashed `review_evidence_contract` defines the exact private report fields,
+coverage values, offer registry, Unicode code-point spans, item relations,
+ten-dimension order, limits, per-offer verdict matrix, aggregate-status
+derivation, and structural-only trust
+boundary without publishing any project content. Source-fidelity providers,
+CMS backends and the portable checker can therefore consume one canonical
+shape rather than inferring it from examples or prompt prose. The sibling
+`review_summary_contract` defines the exact content-free result schema,
 field set, verified/review-required state invariant, ten allowed ordered
-review dimensions, complete-evidence hash semantics, and excluded sensitive
-content. A CMS or independent-review adapter can validate targeted commercial
-escalation without receiving project prices, brands, source/target text, spans,
-or reviewer prose. Any registry or digest drift blocks the whole discovery
+review dimensions, exact review-evidence-contract/source/target/profile/
+locale-quality/evidence hash semantics, and excluded sensitive content. A CMS or independent-review adapter
+can validate targeted commercial escalation without receiving project prices,
+brands, source/target text, spans,
+or reviewer prose. The evidence contract now requires a canonical registry of
+unique offer IDs with ordered, non-overlapping source and target regions.
+Every proposition span must remain inside its named offer, and equivalent
+offer-assignment evidence must cover every registry entry exactly once.
+Every dimension must also acknowledge every registered offer exactly once in
+registry order. Equivalent, changed, and uncertain offer verdicts require
+their own offer-bound evidence; the validator derives and checks the global
+dimension status so a report cannot hide an omitted second offer behind a
+first offer's global pass.
+Discontiguous regions remain available for linked conditions and footnotes;
+uncertain semantic boundaries still route to independent review. Any registry
+or digest drift blocks the whole discovery
 response rather than advertising a partial contract.
 
+Commercial plan v5 and job v5 identities bind the exact review-evidence,
+content-free review-routing, and content-free review-resolution contract
+SHA-256 values. Changing any contract produces new job, idempotency, and plan identities;
+the worker, queue health monitor, and pre-lease validator reconstruct the
+current contracts and reject stale jobs before provider access. Non-commercial
+jobs carry none of the commercial digests.
+
+The sibling `review_routing_contract` defines the private actionable route as
+a separately hashed machine contract. It fixes exact Unicode code-point
+offsets with exclusive ends, complete source and target lengths, one ordered
+entry per opaque registry position, non-overlap, private-value exclusions, and
+the non-authoritative trust boundary. Every private route carries this exact
+digest. The runtime reconstructs it before evidence or receipt network access;
+the public capability exposes only the contract, never actual route spans.
+
+The `publication_http.release_evidence_contract` is independently hashed and
+fixes the complete public evidence field set, its target, digest, and evidence
+lineage bindings, commercial nullability, signed publication container, and
+excluded private content. The runtime compares the whole object with its
+canonical registry, so removing or reordering a field and recomputing both
+public hashes still blocks capability discovery before publication.
+
+The separately hashed `review_resolution_contract` makes the escalation result
+fully machine-readable. It requires the exact ordered unresolved dimensions,
+one resolved status and either a qualified-human route with a null provider or
+an independent-model route with the exact provider ID, model ID and model
+version distinct from the primary provider. The result binds the exact
+commercial profile and advertised resolution-contract SHA-256, and carries the
+primary provider identity so the CMS can verify that distinction itself. Only
+the verified receipt SHA-256 crosses the publication boundary. Raw receipts,
+credentials, qualified-human identity, reviewer prose, project prices, brands,
+source text and target text are excluded.
+Its digest is already fixed by the commercial plan and per-locale job, then
+carried unchanged through the worker result and evidence request. A later
+resolution-policy revision cannot reinterpret queued or completed work: stale
+bindings block before lease, provider access, receipt verification, or signed
+approval.
+
+The commercial capability additionally requires schema
+`translate-native.commercial-locale-quality-profile.v2` in every commercial
+job. One distinct version and digest is derived for each advertised EU locale
+from that locale's native, fidelity, adversarial and source-reference profile.
+The full object is bound into the job ID and all three provider requests; its
+version and digest remain in signed quality evidence. A stale, substituted or
+mutated locale profile blocks before any provider call.
+
+The profile includes a canonical
+`translate-native.commercial-rendering-reference.v1` derived from the tagged
+Unicode CLDR 48 numbers data for that exact target profile. Its default and
+native numbering systems, grouping threshold, symbols, and decimal, percentage,
+currency, ISO-currency, approximation, limit, and range patterns are sent to
+all three provider phases and covered by the profile digest. This is rendering
+guidance only: deterministic punctuation or numeric regex matching is not
+semantic proof, equivalent written forms remain eligible, and uncertainty is
+routed to independent model or qualified native-domain review.
+
+The separately hashed `commercial_rendering_registry` makes those exact
+references available to CMS and website clients without exposing localized
+content. It contains all 24 locales in canonical order and binds each reference
+to the exact commercial locale-profile version and digest advertised in the
+same response. The runtime reconstructs and compares the complete registry
+before returning capabilities; a missing, reordered, altered, or merely
+rehashed entry returns `503` without a partial registry. Consumers must still
+treat these values as display guidance and route uncertain semantic equality to
+the configured independent review path.
+
+For publication, `blun.website-localization-release-evidence.v14` carries the
+canonical release-evidence-contract SHA-256, content-free
+`evidence_request_id` and `evidence_revision` plus the compact universal
+`quality_profile` binding `{locale, version, sha256}`. The receiver recomputes
+that exact current target-locale binding for every content type before host
+code, and the durable store repeats the lookup on active reads, health checks,
+and idempotent replay while keeping stale bundles safely tombstonable.
+
+Commercial content additionally carries its separate compact
+`commercial_quality_profile` binding `{profile, version, sha256}` and the exact
+current routing and resolution-contract SHA-256 values. The resolution-contract
+digest is present for every commercial result, including `verified` results,
+so downstream systems can prove the escalation policy that governed the
+approval. All commercial fields must be null for every other content type. The
+release service and reference CMS receiver recompute the canonical contract
+digest before publication and host code; a prior signed approval cannot be
+rewrapped under a newer contract. A syntactically valid digest, a binding from
+another EU locale, or a prior profile generation is not accepted. An unresolved
+commercial summary additionally requires
+`commercial_review_resolution` with the exact ordered dimensions, a
+commercial profile and resolution-contract SHA-256, a `qualified_human` or
+`independent_model` method, the verified receipt hash, the primary provider
+binding, and the independent provider binding only for the model route. The CMS
+requires the two provider IDs to differ. Verified commercial summaries and
+non-commercial content require this field to be `null`. Raw
+receipts, qualified-human identities and reviewer prose are never published.
+
+The commercial summary exposes unresolved offers only as zero-based positions
+in the private offer registry, grouped by ordered review dimension. It does not
+publish configured offer identifiers. The resolution must echo the exact
+ordered position scope; malformed, stale, or substituted scope blocks before
+CMS persistence. A dimension may remain review-required with no position when
+global uncertainty or an empty registry prevents safe offer identification.
+The quality-evidence request and receipt verifier privately receive a separate
+text-free routing object that maps those positions to exact source and target
+Unicode code-point spans. It is bound into request and receipt identities but
+is never included in the public capability or CMS release-evidence value.
+
 ```json
 {
   "capabilities": {
     "change_schema": "blun.cms-content-change.v2",
     "cancellation_schema": "blun.cms-content-cancellation.v1",
     "commercial_profile": {
-      "profile": "translate-native.commercial.v2",
+      "profile": "translate-native.commercial.v13",
+      "locale_quality_profile": {
+        "schema": "translate-native.commercial-locale-quality-profile.v2",
+        "required": true,
+        "binding_fields": ["locale", "version", "commercial_profile", "quality_profile_version", "quality_profile_sha256", "rendering_reference", "sha256"],
+        "rendering_reference": {"schema": "translate-native.commercial-rendering-reference.v1", "authority": "Unicode CLDR", "version": "48", "purpose": "target-locale-rendering-guidance", "semantic_proof": false, "unresolved_route": "independent-model-or-qualified-native-domain-review"},
+        "required_commercial_checks": ["amount_currency", "discount_basis", "qualifiers", "tax_status", "billing_interval", "commitment", "renewal", "cancellation", "conditions", "offer_assignment"],
+        "provider_phases": ["transcreation", "target_native", "source_fidelity"],
+        "tamper_policy": "block-before-provider"
+      },
+      "review_evidence_contract": {
+        "checks": {
+          "exact_dimension_set": true,
+          "item": {
+            "duplicates": "forbidden-per-dimension",
+            "explanation": "non-empty-maximum-2000-code-points",
+            "matched_requires": "source-and-target-spans",
+            "offer": "registered-offer-id",
+            "relations": ["matched", "source_only", "target_only"],
+            "required_fields": ["offer", "relation", "source_span", "target_span", "explanation"],
+            "source_only_requires": "source-span-and-null-target-span",
+            "span_containment": "inside-named-offer-region",
+            "target_only_requires": "null-source-span-and-target-span"
+          },
+          "max_items_per_dimension": 1000,
+          "offer_assignment": {
+            "equivalent": "exactly-one-matched-item-per-registered-offer",
+            "other_equivalent_checks_require_equivalent_assignment": true
+          },
+          "offer_statuses": {
+            "coverage": "exactly-one-per-registered-offer",
+            "field": "offer_statuses",
+            "global_status": "changed-then-uncertain-then-equivalent-then-not_present",
+            "item_required_fields": ["offer", "status"],
+            "items_must_match_offer_status": true,
+            "order": "offer-registry-order",
+            "statuses": ["equivalent", "not_present", "changed", "uncertain"]
+          },
+          "required_dimensions": ["amount_currency", "discount_basis", "qualifiers", "tax_status", "billing_interval", "commitment", "renewal", "cancellation", "conditions", "offer_assignment"],
+          "status_items": {"changed": "one-or-more-specific", "equivalent": "one-or-more-matched", "not_present": "empty", "uncertain": "one-or-more-specific"},
+          "statuses": ["equivalent", "not_present", "changed", "uncertain"]
+        },
+        "content_policy": {"project_brands": false, "project_prices": false, "reviewer_prose": false, "source_spans": false, "source_text": false, "target_spans": false, "target_text": false},
+        "coverage": {"allowed": ["complete", "uncertain"], "complete": "every-proposition-and-offer-association-reviewed", "uncertain": "independent-review-required"},
+        "offer_registry": {
+          "field": "offers",
+          "identifier": {"pattern": "^[A-Za-z0-9_.:-]{1,256}$", "unique": true},
+          "item_required_fields": ["id", "source_spans", "target_spans"],
+          "max_items": 1000,
+          "regions": {"at_least_one_side_non_empty": true, "discontiguous": true, "fields": ["source_spans", "target_spans"], "non_empty_text": true, "ordered": true, "overlap": "forbidden-within-and-across-offers", "span_format": "zero-based-unicode-code-points-exclusive-end"}
+        },
+        "profile": "translate-native.commercial.v13",
+        "required_fields": ["schema", "coverage", "offers", "checks"],
+        "result_schema": "translate-native.commercial.v13",
+        "schema": "translate-native.commercial-review-evidence-capabilities.v2",
+        "sha256": "<sha256>",
+        "trust_boundary": {"numeric_regex_semantic_proof": false, "publication_authority": false, "semantic_truth": false, "unresolved_route": "independent-model-or-qualified-native-domain-review", "validates": "structure-offsets-and-verdict-consistency"}
+      },
+      "review_evidence_schema": "translate-native.commercial.v13",
       "review_summary_contract": {
         "content_policy": {"project_brands": false, "project_prices": false, "reviewer_prose": false, "source_spans": false, "source_text": false, "target_spans": false, "target_text": false},
-        "evidence_sha256": {"algorithm": "sha-256", "canonicalization": "utf-8-json-sort-keys-no-insignificant-whitespace", "covers": "complete-commercial-review-evidence"},
-        "profile": "translate-native.commercial.v2",
-        "required_fields": ["schema", "profile", "status", "review_required_dimensions", "evidence_sha256"],
-        "result_schema": "translate-native.commercial-review-summary.v1",
+        "evidence_sha256": {"algorithm": "sha-256", "binding_fields": ["schema", "profile", "review_evidence_contract_sha256", "target_locale", "commercial_quality_profile_version", "commercial_quality_profile_sha256", "source_sha256", "target_sha256", "evidence"], "binding_schema": "translate-native.commercial-review-evidence-binding.v5", "canonicalization": "utf-8-json-sort-keys-no-insignificant-whitespace", "covers": ["commercial-profile", "exact-review-evidence-contract", "exact-target-locale", "commercial-quality-profile-generation", "exact-source-sha256", "exact-target-sha256", "offer-registry-and-proposition-assignment", "complete-commercial-review-evidence"], "text_hashing": "exact-utf-8"},
+        "profile": "translate-native.commercial.v13",
+        "required_fields": ["schema", "profile", "status", "review_required_dimensions", "offer_count", "review_required_offers", "review_evidence_contract_sha256", "evidence_sha256"],
+        "result_schema": "translate-native.commercial-review-summary.v6",
+        "review_evidence_contract_sha256": {"algorithm": "sha-256", "equals": "<review-evidence-contract-sha256>", "purpose": "reject-stale-or-reinterpreted-private-evidence"},
+        "offer_count": {"maximum": 1000, "meaning": "opaque-offer-registry-size", "minimum": 0},
         "review_required_dimensions": {"allowed": ["amount_currency", "discount_basis", "qualifiers", "tax_status", "billing_interval", "commitment", "renewal", "cancellation", "conditions", "offer_assignment"], "order": ["amount_currency", "discount_basis", "qualifiers", "tax_status", "billing_interval", "commitment", "renewal", "cancellation", "conditions", "offer_assignment"], "unique": true},
-        "schema": "translate-native.commercial-review-summary-capabilities.v1",
+        "review_required_offers": {"configured_offer_identifiers_published": false, "dimension_must_be_review_required": true, "dimension_order": ["amount_currency", "discount_basis", "qualifiers", "tax_status", "billing_interval", "commitment", "renewal", "cancellation", "conditions", "offer_assignment"], "item_required_fields": ["dimension", "offer_indexes"], "offer_indexes": {"maximum_exclusive": 1000, "meaning": "zero-based-opaque-offer-registry-position", "minimum": 0, "order": "ascending", "unique": true}},
+        "schema": "translate-native.commercial-review-summary-capabilities.v7",
         "sha256": "<sha256>",
-        "statuses": {"review_required": {"requires_independent_review": true, "review_required_dimensions": "one-or-more"}, "verified": {"review_required_dimensions": "empty"}}
+        "statuses": {"review_required": {"requires_independent_review": true, "review_required_dimensions": "one-or-more", "review_required_offers": "zero-or-more"}, "verified": {"review_required_dimensions": "empty", "review_required_offers": "empty"}}
       },
-      "schema": "translate-native.commercial-capabilities.v2",
+      "review_routing_contract": {
+        "applies_when": {"offer_count": "exact-review-summary-offer-count", "review_summary_status": "review_required"},
+        "content_policy": {"configured_offer_identifiers": false, "project_brands": false, "project_prices": false, "reviewer_prose": false, "source_text": false, "target_text": false},
+        "offers": {"coverage": "exactly-one-per-registered-offer", "item_required_fields": ["offer_index", "source_spans", "target_spans"], "offer_index": {"maximum_exclusive": 1000, "meaning": "zero-based-opaque-offer-registry-position", "minimum": 0, "order": "ascending", "unique": true}, "order": "offer-registry-order", "regions": {"at_least_one_side_non_empty": true, "discontiguous": true, "fields": ["source_spans", "target_spans"], "non_empty_text": true, "ordered": true, "overlap": "forbidden-within-and-across-offers", "span_format": "zero-based-unicode-code-points-exclusive-end"}},
+        "profile": "translate-native.commercial.v13",
+        "required_fields": ["schema", "profile", "contract_sha256", "offer_count", "source_length", "target_length", "offers"],
+        "result_schema": "translate-native.commercial-review-routing.v2",
+        "schema": "translate-native.commercial-review-routing-capabilities.v1",
+        "sha256": "<sha256>",
+        "text_lengths": {"fields": ["source_length", "target_length"], "must_equal_complete_texts": true, "unit": "unicode-code-points"},
+        "trust_boundary": {"public_release_evidence": false, "publication_authority": false, "route_values": "private-evidence-and-receipt-boundary-only", "semantic_truth": false, "validates": "shape-offsets-order-count-and-text-lengths"}
+      },
+      "review_routing_schema": "translate-native.commercial-review-routing.v2",
+      "review_resolution_contract": {
+        "applies_when": {"review_summary_status": "review_required", "reviewed_dimensions": "exact-ordered-review-summary-dimensions", "reviewed_offer_count": "exact-review-summary-offer-count", "reviewed_offers": "exact-ordered-review-summary-offer-scope"},
+        "content_policy": {"project_brands": false, "project_prices": false, "qualified_human_identity": false, "raw_receipt": false, "reviewer_prose": false, "source_text": false, "target_text": false},
+        "methods": {"independent_model": {"primary_provider": "required", "provider": "required", "provider_id_must_differ_from_primary_provider": true, "receipt": "verified-independent-model-review"}, "qualified_human": {"primary_provider": "required", "provider": "null", "receipt": "verified-qualified-human-review"}},
+        "profile": "translate-native.commercial.v13",
+        "provider_identity": {"credentials_published": false, "fields": ["id", "model_id", "model_version"], "primary_provider": "required"},
+        "receipt_sha256": {"algorithm": "sha-256", "covers": "exact-verified-review-receipt", "raw_receipt_published": false},
+        "required_fields": ["schema", "profile", "contract_sha256", "status", "reviewed_dimensions", "reviewed_offer_count", "reviewed_offers", "method", "receipt_sha256", "primary_provider", "provider"],
+        "result_schema": "translate-native.commercial-review-resolution.v4",
+        "reviewed_dimensions": {"allowed": ["amount_currency", "discount_basis", "qualifiers", "tax_status", "billing_interval", "commitment", "renewal", "cancellation", "conditions", "offer_assignment"], "order": ["amount_currency", "discount_basis", "qualifiers", "tax_status", "billing_interval", "commitment", "renewal", "cancellation", "conditions", "offer_assignment"], "unique": true, "must_equal_review_summary": true},
+        "reviewed_offer_count": {"must_equal_review_summary": true},
+        "reviewed_offers": {"configured_offer_identifiers_published": false, "must_equal_review_summary": true},
+        "schema": "translate-native.commercial-review-resolution-capabilities.v4",
+        "sha256": "<sha256>",
+        "status": "resolved"
+      },
+      "review_resolution_schema": "translate-native.commercial-review-resolution.v4",
+      "schema": "translate-native.commercial-capabilities.v15",
       "sha256": "<sha256>"
     },
+    "commercial_rendering_registry": {
+      "commercial_profile": "translate-native.commercial.v13",
+      "content_policy": {"credentials": false, "project_brands": false, "project_prices": false, "source_text": false, "target_text": false},
+      "locales": [{
+        "commercial_quality_profile": {"sha256": "<sha256>", "version": "commercial-eu-mt-MT-2026-09-2"},
+        "locale": "mt-MT",
+        "rendering_reference": {
+          "locale": "mt-MT",
+          "minimum_grouping_digits": 1,
+          "native_numbering_system": "latn",
+          "numbering_system": "latn",
+          "patterns": {"currency": "¤#,##0.00", "decimal": "#,##0.###", "percent": "#,##0%", "range": "{0}–{1}"},
+          "schema": "translate-native.commercial-rendering-reference.v1",
+          "source": {"authority": "Unicode CLDR", "locale": "mt", "version": "48"},
+          "symbols": {"decimal": ".", "group": ","}
+        }
+      }],
+      "schema": "translate-native.commercial-rendering-registry.v1",
+      "sha256": "<sha256>",
+      "source": {"authority": "Unicode CLDR", "version": "48"}
+    },
     "content_types": ["commercial", "cta", "documentation", "headline", "legal", "marketing", "seo", "ui"],
     "default_target_policy": "all-eu-official-locales-except-source-language",
     "eu_language_source": "https://european-union.europa.eu/principles-countries-history/languages_en",
-    "job_schema": "blun.website-localization-job.v2",
+    "job_schema": "blun.website-localization-job.v5",
     "locales": [{
       "direction": "ltr",
       "eu_code": "MT",
@@ -1087,9 +2293,11 @@ response rather than advertising a partial contract.
       "native_name": "Malti",
       "quality_profile_sha256": "<sha256>",
       "quality_profile_version": "eu-mt-MT-2026-09-1",
+      "commercial_quality_profile_sha256": "<sha256>",
+      "commercial_quality_profile_version": "commercial-eu-mt-MT-2026-09-2",
       "script": "Latn"
     }],
-    "plan_schema": "blun.website-localization-plan.v2",
+    "plan_schema": "blun.website-localization-plan.v5",
     "publication_http": {
       "binding_headers": [
         {"binding": "delivery_id", "name": "Idempotency-Key"},
@@ -1112,14 +2320,48 @@ response rather than advertising a partial contract.
         "response_schema": "blun.cms-localization-publication-http-ack.v1"
       }],
       "request_content_type": "application/json; charset=utf-8",
-      "release_evidence_schema": "blun.website-localization-release-evidence.v1",
+      "release_evidence_contract": {
+        "bindings": {
+          "lineage_fields": ["evidence_request_id", "evidence_revision"],
+          "quality_profile": "exact-current-target-locale-quality-profile",
+          "sha256_fields": ["release_evidence_contract_sha256", "target_sha256", "result_sha256", "approval_sha256", "quality_receipt_sha256", "commercial_review_routing_contract_sha256", "commercial_review_resolution_contract_sha256"],
+          "signed_container": "blun.cms-localization-publication.v3",
+          "target_identity_fields": ["job_id", "target_locale", "target_sha256", "approval_id"]
+        },
+        "commercial_scope": {
+          "content_type": "commercial",
+          "non_commercial_fields": "all-null",
+          "quality_profile": "exact-current-target-locale-commercial-quality-profile",
+          "required_non_null": ["commercial_profile", "commercial_quality_profile", "commercial_review", "commercial_review_routing_contract_sha256", "commercial_review_resolution_contract_sha256"],
+          "review_evidence_contract_sha256": "exact-current-public-commercial-evidence-contract",
+          "review_resolution_contract_sha256": "exact-current-public-commercial-resolution-contract",
+          "resolution": "required-only-when-review-required"
+        },
+        "content_policy": {
+          "authentication_material": false,
+          "project_brands": false,
+          "project_prices": false,
+          "raw_receipt": false,
+          "commercial_review_routing": false,
+          "reviewer_identity": false,
+          "reviewer_prose": false,
+          "source_text": false,
+          "target_text": false
+        },
+        "release_evidence_schema": "blun.website-localization-release-evidence.v14",
+        "required_fields": ["schema", "release_evidence_contract_sha256", "job_id", "target_locale", "target_sha256", "approval_id", "content_type", "result_sha256", "approval_sha256", "quality_receipt_sha256", "evidence_request_id", "evidence_revision", "quality_profile", "commercial_profile", "commercial_quality_profile", "commercial_review", "commercial_review_routing_contract_sha256", "commercial_review_resolution_contract_sha256", "commercial_review_resolution"],
+        "schema": "blun.website-localization-release-evidence-capabilities.v8",
+        "sha256": "<sha256>",
+        "tamper_policy": "reject-complete-publication-before-host-commit"
+      },
+      "release_evidence_schema": "blun.website-localization-release-evidence.v14",
       "response_content_types": ["application/json", "application/json; charset=utf-8"],
-      "schema": "blun.cms-localization-publication-http-capabilities.v2",
+      "schema": "blun.cms-localization-publication-http-capabilities.v5",
       "sha256": "<sha256>"
     },
     "publication_schema": "blun.cms-localization-publication.v3",
     "quality_passes": ["target_native", "source_fidelity"],
-    "schema": "blun.website-localization-capabilities.v3",
+    "schema": "blun.website-localization-capabilities.v9",
     "sha256": "<sha256>"
   },
   "api_contract": {