# Website localization job planning `integrations/website_localization.py` is the provider-neutral entry point for the website-localization pipeline. It does not contact an LLM and cannot publish content. Its only job is to turn one trusted source object into one independently retryable queue payload per EU target locale. ## Premortem Assume the planner shipped and failed: stale work was reused after a source, glossary, policy, provider, model, or runtime change; the source language was translated back into itself; or one queue entry mixed several target languages. The early warning is a repeated job identity despite one changed input or a job count that differs from 23 for an EU source and 24 for a non-EU source. The mitigation is one immutable job per locale whose canonical idempotency binding includes every result-affecting field and the exact source hash. The regression suite mutates each binding separately and proves the expected 24-profile registry and per-language job counts. The current language registry follows the European Union's official list of 24 languages: . Each language has one explicit BCP-47 website profile. The default German profile is `de-AT`; English is `en-IE`, Portuguese is `pt-PT`, Spanish is `es-ES`, and Swedish is `sv-SE`. A source whose primary language is already in the registry produces 23 jobs. A non-EU source produces all 24. `integrations/website_localization_quality_profiles.py` adds one immutable, versioned evaluation profile for each of those 24 locales. Each profile has separate target-only nativeness criteria, source-aware fidelity criteria, and locale-specific adversarial cases. Every profile also requires the complete red-team matrix for translationese, wrong neighbouring language, mixed varieties, ASCII folding, missing diacritics or native script, wrong inflection, omitted meaning, unnatural CTAs, and marketing calques. This shared minimum does not replace the language-specific criteria. The canonical profile hash and version are part of the target profile and job identity. The complete profile is supplied independently to transcreation, target-only review, source-aware review, and blinded benchmark review. Worker results carry the locale, version, and hash; quality-evidence requests and signed approvals bind that triplet again. A missing, substituted, or stale profile therefore blocks before a provider call or release instead of falling back to generic instructions. Finnish criteria explicitly cover natural information structure, case government, agglutination, possessive suffixes, vowel harmony, consonant gradation, clitics, compounds, politeness, and non-calqued web CTAs. Maltese criteria cover `ċ`, `ġ`, `għ`, `ħ`, and `ż`, morphology, fused articles and prepositions, idiom, and English/Italian calques. The Maltese institutional reference is the [Kunsill Nazzjonali tal-Ilsien Malti](https://kunsilltalmalti.gov.mt/mistoqssija-u-twegiba-51-76/); locale exemplar and convention references are pinned to [Unicode CLDR 48](https://www.unicode.org/cldr/charts/48/summary/mt.html). ## JSON contract ```bash python3 integrations/website_localization.py <<'JSON' { "source_id": "homepage.hero", "source_revision": "cms-184", "source_text": "Build your business with BLUN.", "source_locale": "en-IE", "content_type": "headline", "glossary_version": "blun-glossary-3", "policy_version": "native-web-1", "provider_id": "customer-llm", "model_id": "king", "model_version": "2026-08-29", "software_version": "6.43.0-dev", "target_locales": ["de-AT", "sv-SE"] } JSON ``` Omit `target_locales` to request every eligible EU language. An explicit list must contain supported profiles, must not contain duplicates, and must exclude the source language. Unknown input fields, ambiguous locale values such as `auto`, non-NFC text, NUL characters, unsupported content types, oversized source text, and wrong JSON types block the complete plan. Every emitted job contains exactly one target profile, the unchanged source text and its SHA-256 hash, both required quality-pass names, and `release_required: true`. Its `job_id` and `idempotency_key` are identical and are derived from canonical JSON bound to: - source ID, revision, text hash, and locale; - complete target-locale metadata, including quality-profile version and hash, plus content type; - glossary and quality-policy versions; - provider, model ID, and model version; - Translate Native software version; - for commercial work, the exact current review-evidence-contract SHA-256. Changing any bound value creates a new job and plan identity. A queue may therefore deduplicate an exact retry, while stale work cannot silently survive a changed source, glossary, policy, provider, model, or runtime. Later workers must keep the two declared reviews separate—target-only native quality first, source-aware fidelity second—and obtain a signed Translate Native release before publication. ## Durable queue state `integrations/website_localization_queue.py` persists planner jobs through a trusted host-supplied `sqlite3.Connection`. Enqueuing a complete plan is one transaction: an exact repeat inserts nothing, while a reused job ID with different bytes rolls the entire operation back. Workers claim one locale at a time through a random, owner-bound lease. Lease expiry recovers work after a crash, but stale claims cannot acknowledge a newer attempt. The queue records `pending`, `leased`, `retry_wait`, `succeeded`, and `failed` states, bounded attempt counts, the next eligible attempt time, result hashes, and stable error codes. Free-form error detail is represented only by a SHA-256 hash so status inspection does not disclose customer prose. Payloads are hashed on insertion and checked again before a worker receives them. Immediately before leasing, the queue also replays the exact current worker binding. A stale but internally consistent job becomes terminal with `job_binding_invalid` without consuming an attempt or reaching caches, asset resolvers, or providers. A bounded batch of up to 24 consecutive stale jobs is quarantined in the same transaction before the first current job is leased, covering one complete EU-locale plan without an unbounded write transaction. Expected contract mismatch is distinct from validator unavailability: unexpected failure or payload mutation rolls back the complete quarantine-and-lease batch and leaves every job pending. The read-only health monitor additionally replays the complete current planner/worker validation for every stored job. Canonical but obsolete jobs, including commercial jobs from an earlier evidence-contract generation, block health locally with `queue.job_binding_invalid`, independently of provider health and without changing queue state. Queue `succeeded` means only that a worker returned finite, NFC JSON. It is not a native-quality attestation, signed release, or publication permission. The later review and release stages must still perform the ordered target-only and source-aware checks and verify a purpose-bound Translate Native receipt. Premortem: a worker may crash while leased, retry forever, replay a stale claim, or collide with different content under the same idempotency key. The lease token changes on every attempt, expiry consumes the abandoned attempt, the configured attempt ceiling becomes terminal, and every collision or payload-integrity failure blocks transactionally. Cross-connection and crash recovery regressions prove those boundaries. ## Provider-neutral worker contract `integrations/website_localization_worker.py` consumes exactly one locale job and calls a host-supplied adapter implementing `invoke(ProviderRequest)`. The contract contains no BLUN.ai, OpenAI, Anthropic, or other provider-specific transport. An adapter maps the immutable request to its own API and either returns strict JSON or raises the content-free `ProviderCallFailed` with a stable error code and retryability decision. Every worker attempt has three ordered calls: 1. `transcreation` receives the complete source, one exact BCP-47 target, content-specific guidance, and the resolved glossary, audience, tone, and protected terms; 2. `target_native` receives only the candidate and target-side terminology—no source text, source locale, or source glossary terms—and rejects unnatural wording, translationese, register, script, orthography, and locale errors; 3. `source_fidelity` runs only after the native review passes and checks the candidate against the complete source for meaning, completeness, terminology, and protected syntax. The trusted host resolves `LocalizationAssets` from immutable registries. Its glossary and policy versions must exactly match the versions already bound to the job; stale assets block before any provider call. The policy version owns the audience, tone profile, prompt rules, and review standard. Provider responses must use the exact phase, locale, and schema, contain no extra fields, and use NFC text. Each review must also report `confidence` as exactly `high` or `low`. Missing or unknown confidence is malformed and blocks; `high` does not replace either substantive review, while `low` adds a mandatory independent-review requirement to the result. A wrong locale, malformed response, failed review, provider exception, or changed job binding blocks without producing a queue result. After both LLM reviews pass, the bundled local translation guard independently checks Unicode NFC, HTML/JSON/XML structure, placeholders, links, code, protected tokens, untranslated segments, and major omissions. Worker results bind source and target hashes, locales, content type, glossary and policy versions, provider/model identity, software version, and hashes of all three requests and responses. The explicit per-phase confidence decision is carried in the result and remains bound through quality evidence and the signed approval. Results retain no reviewer prose and still set `release_required: true`; queue success therefore remains neither a signed release nor publication permission. Legal content sets `human_review_required: true`; low confidence in either review instead sets `independent_review_required: true` for non-legal content. The latter can be satisfied only by a separately verified qualified-human receipt or a verified second model adapter with a different provider identity. Premortem: a provider could answer in the wrong locale, merge creation and review, leak the source into the native-only judgment, return convincing but unstructured prose, or pass a candidate with a broken placeholder. Exact phase and locale schemas, separate inputs, ordered calls, version matching, response hashes, and the final local integrity gate make each case fail closed. The same profile version and hash are carried into the unsigned worker result, then into external quality evidence and the signed approval, so a later profile change cannot reuse an older translation-memory entry. ### Secure HTTP provider adapter `integrations/website_localization_http_provider.py` is the bundled transport for connecting a host-owned model gateway to the worker contract. It sends one request for one locale and one phase, binds every response to the deterministic request ID and canonical request hash, obtains credentials from a host callback, rejects redirects, and leaves all bounded retries to the durable queue. The adapter is vendor-neutral and can sit in front of a user's own LLM or any provider-specific proxy without placing credentials or vendor logic in jobs. The complete public envelope, authentication, idempotency, response, and failure contract is documented in [`WEBSITE_LOCALIZATION_HTTP_PROVIDER.md`](WEBSITE_LOCALIZATION_HTTP_PROVIDER.md). The transport proves neither native quality nor superiority over an external baseline; those decisions remain with the two independent review stages and the blinded benchmark. ## Queue-to-worker execution `integrations/website_localization_runner.py` is the narrow bridge between the durable queue and the provider-neutral worker. One call claims at most one locale, resolves its exact provider and versioned assets through host-supplied callbacks, executes the three quality stages, and performs one lease-bound queue transition. A successful transition stores the unsigned worker result; it still cannot publish, replace a last-known-good translation, or make the overall website version ready. The runner renews the lease after dependency resolution and after every validated worker phase. If a provider call outlives the lease, a stale worker cannot record its output. Retryable failures use deterministic bounded exponential backoff and become terminal at the job's attempt ceiling. Non-retryable failures stop only that locale. Status output contains stable codes and opaque finding hashes, never provider exceptions, reviewer prose, or candidate text. Mixed success and failure therefore remains visible per locale while publication stays blocked until a later release coordinator verifies all required signed approvals. Premortem: the bridge could acknowledge output after losing its lease, retry a permanent configuration error forever, expose source text through exception messages, or let one failed locale erase a successful sibling. Exact lease tokens guard every transition; typed dependency and worker failures preserve retryability without prose; attempts are bounded; and each invocation mutates only its claimed locale. Regression tests exercise lease expiry, retry exhaustion, opaque errors, and partial provider failure. ### Signed local fallback The low-level runner's optional `result_cache` is deliberately consulted before asset or provider resolution. The complete production runtime does not accept a host-supplied cache: it always constructs `LocalizationReleaseStore.verified_result_cache(authority)` from its own local signed release store and the already validated approval authority. That adapter loads the exact deterministic job from the local translation memory, rechecks the stored result hash, approval payload hash, complete job binding, approval ID, signing-key identity, signature, and expiry, and returns the already reviewed worker result only when every check passes. `RunOutcome.result_origin` then reports `translation_memory`; a new provider result reports `provider`. A missing or expired approval is a clean cache miss. The normal provider path must produce and review a new target, so an unavailable model still leaves the locale blocked without inventing text. Any malformed, altered, or unverifiable cache entry blocks that attempt before provider or asset lookup and follows the queue's bounded retry policy. Because job identity binds source, locale, content type, glossary, policy, provider/model, worker schema, and software version, changing any of them cannot reuse an older translation. Premortem: an offline deployment could mistake an expired translation for a safe fallback, silently use a signature from another source or policy, or call the provider after discovering local tampering. The adapter treats expiry as a miss, verifies every signed binding before returning content, and makes cache verification errors stop the attempt before any other resolver runs. Tests cover exact offline recovery, policy invalidation, expiry, and database tampering across separate queue and translation-memory connections. ## Blind quality benchmark against an external baseline `integrations/website_localization_benchmark.py` provides the evidence gate for quality claims such as “better than DeepL.” The module does not call DeepL or any other baseline service. A host may create a comparison artifact only from the provider's official API or a lawfully supplied fixed fixture. It calls `create_baseline_artifact` with the exact target and a provenance record whose method is `official_api` or `lawful_fixture`, plus a stable evidence identifier and SHA-256 digest of the host-retained acquisition record. Undocumented endpoints and scraping are deliberately not valid provenance methods. The artifact binds the baseline identity and version, exact source hash, target locale, content type, target hash, complete target text, and provenance. The same host-owned `BenchmarkEvidenceAuthority` attests those canonical bytes and immediately verifies its own result. The harness rejects unsigned, foreign-key, changed, or malformed baseline evidence before either reviewer is called. The case result retains only target, provenance, and complete artifact hashes; the final report includes a digest over the exact baseline-evidence set. Neither provenance nor baseline identity enters a reviewer request. A signature proves integrity and host approval, not that a false provenance statement is legally true, so the host must preserve the API receipt or fixture licence for audit. Credentials and transport code do not belong in benchmark artifacts. ### Official DeepL baseline acquisition `integrations/website_localization_deepl_baseline.py` is the optional concrete input adapter for that provider-neutral gate. The host chooses only `free` or `pro`; the adapter derives the corresponding documented origin and does not accept an arbitrary URL. It obtains the API key from a callback immediately before each request, sends it with the documented `DeepL-Auth-Key` scheme, and disables redirects. Neither the key nor the raw provider response envelope appears in an exception, representation, artifact, or provenance-evidence record; the exact translated target is retained only where the benchmark artifact contract requires it. Before translation, the adapter queries `GET /v3/languages?resource=translate_text` and caches a validated stable capability snapshot for no more than one hour. It prefers an exact BCP-47 variant and otherwise uses a provider-advertised base language only when that base is explicitly usable in the required source or target role. New stable languages can therefore become available without a release, while removed, beta, malformed, or unsupported entries block fail-closed. In particular, the adapter does not manufacture a Maltese result when the current API capability response does not advertise `mt` as a target. One benchmark case produces one `POST /v2/translate` request. Its `text` array contains exactly the complete bound source document, never separately scored segments or several locales; the request selects `prefer_quality_optimized` and preserves formatting. The adapter enforces DeepL's 128-KiB request limit, a bounded response, strict UTF-8 JSON with no duplicate keys, exactly one translation, source-language consistency, NFC target text, and the benchmark's target-size limit. It classifies HTTP 429 and 5xx responses as retryable for the campaign's existing bounded exponential backoff. Authentication, quota, other HTTP 4xx, unsupported-language, schema, binding, and attestation failures remain terminal. Adapter errors carry a validated content-free campaign marker, so `run_next_benchmark_case` stores only a stable code and retry decision. On success, `BaselineAcquisition.artifact` is the existing signed benchmark artifact. `BaselineAcquisition.evidence` contains only endpoint, language, model label, and exact request/response/source/target digests. Its canonical digest becomes the artifact's `official_api` provenance; the host must retain that evidence beside its authorized API audit record. `BaselineAcquisitionStore` provides the durable hand-off between acquisition and blind review. Give it a dedicated host-owned SQLite connection and resolve each acquisition with `resolve_baseline_acquisition`. The caller supplies a stable route ID such as an account/environment reference that contains no credential. Store identity binds that route, the complete validated benchmark policy, and the complete validated suite job. It therefore changes with the source, locale, candidate configuration, suite, baseline identity or version, quality policy, and every other benchmark-policy field. The resolver first reads and reverifies the exact stored artifact, provenance evidence, canonical hashes, and host attestation. A valid hit is returned without calling the acquisition callback; a missing row calls it once and persists the complete acquisition before review. Corrupt state is not a cache miss: it blocks before any callback or provider request. Concurrent identical writes converge, while a different valid output under the same identity is a terminal conflict and never replaces the first acquisition. Rotate `baseline_version` deliberately when a fresh current-API comparison is required. The database necessarily contains the baseline target because the blind benchmark consumes it. Keep the database owner-only and apply host storage encryption, backup, retention, and deletion policy appropriate to the source content; never place API keys or raw provider envelopes in it. A separate campaign database may retain only the already defined text-free case results. Constructing the store neither opens a network connection nor invents a fallback translation. Long-running hosts should also pass an `operation_guard` to `DeepLBaselineAdapter`. It runs immediately before credentials are requested and before each Languages or Translate API call. A lost lease therefore blocks the external operation; the campaign still owns bounded retry and terminal failure policy. For a provider-unsupported locale, the host may instead call `create_lawful_fixture_acquisition`. The fixed target remains host-supplied and must match a strict evidence record binding fixture ID and revision, supplier, rights basis (`owned`, `licensed`, or `permission`), rights-evidence digest, source digest, target locale, and target digest. The function neither retrieves nor creates a translation. The host-owned authority attests the resulting `lawful_fixture` artifact, and the host remains responsible for the truth and retention of the underlying licence or permission. The implementation follows DeepL's official [translation request](https://developers.deepl.com/api-reference/translate/request-translation), [Languages API](https://developers.deepl.com/docs/languages/using-the-languages-api), [error handling](https://developers.deepl.com/docs/best-practices/error-handling), and [usage limits](https://developers.deepl.com/docs/resources/usage-limits) documentation. No API credential or real baseline output is included in this repository. `integrations/website_localization_benchmark_candidate.py` gives the attached customer-model candidate the same crash-safe identity discipline as the baseline. `resolve_candidate_acquisition` first looks up a candidate under a stable, non-secret model-route ID plus the complete benchmark policy and canonical suite job. A verified hit returns the exact previous worker result without calling the model. A miss runs the ordinary three-phase localization worker—transcreation, target-only native review, then source-aware fidelity review—and persists the first complete result before blind comparison. The candidate artifact contains the complete worker result and is signed by the configured host-owned benchmark evidence authority. Every read checks the store digest, reconstructs every job, source, locale, model, version, quality profile, review-confidence, and target-hash binding, and reverifies that attestation. Recomputing the database digest after changing target text is therefore insufficient. Corrupt or differently signed content blocks before model access. Identical writers converge; a different valid result under the same route, policy, and job is a terminal conflict and cannot replace the first candidate. Deliberate reevaluation requires a changed bound model version, policy, suite, or route rather than deleting or overwriting evidence. Pass the campaign lease guard as `operation_guard`. A guarded adapter checks it immediately before each of the three model calls and before every authority sign or verify call, including verification of a cached result. Model, temporary authority, and lease failures retain stable retryability and flow into the campaign's bounded content-free retry policy. Invalid jobs, assets, responses, stored state, attestations, and conflicts remain fail-closed. This dedicated database necessarily retains candidate source-derived text and review metadata. Keep it owner-only and apply storage encryption, retention, backup, and deletion controls appropriate to the source. It contains no model credential or raw provider exception. The separate campaign database still stores only attested text-free case results. Every policy-required locale and source case also requires one versioned native reference artifact before the first blind review can run. The repository does not ship or invent reference translations. A host obtains the exact `native_reference_verification_request`, including the complete source and its hash, suite case, target locale, content type, glossary and localization-policy versions, locale-profile version and hash, complete reference target, and reference revision. A configured `NativeReferenceVerifier` must then validate an opaque receipt from a separately identified qualified native human reviewer. Candidate provider, baseline, A/B reviewer, reference verifier, and reference reviewer identities must remain distinct. `create_native_reference_artifact` verifies that receipt before a host-owned `BenchmarkEvidenceAuthority` attests the complete artifact. The benchmark rechecks both the attestation and qualified-review receipt immediately before review and binds the complete evidence hash into the keyed blind assignment, case result, and final report. A receipt therefore cannot be replayed across a source case, source text, locale, content type, glossary, localization policy, quality profile, reference revision, or reviewer credential. Missing, altered, rejected, or contradictory reference evidence blocks without calling the A/B reviewer. Reference text, reviewer identity, and receipt never enter either A/B request or the text-free case result; only hashes and the public reference revision are retained. This preserves the strictly ordered two-stage decision: source-blind native quality first, then source-aware fidelity. The reference is auditable eligibility and calibration evidence, not a hidden third score and not proof that a model is linguistically superior. The test references are synthetic contract fixtures only and make no native-quality claim. `integrations/website_localization_native_reference_store.py` provides the durable hand-off from that qualified-human workflow into a benchmark campaign. Give `NativeReferenceArtifactStore` a dedicated host-owned SQLite connection and a stable route ID identifying the approved vault or editorial workflow, never a credential. The record identity binds that route, the complete benchmark policy, and the complete canonical suite job. A source, locale, candidate configuration, policy, suite, quality profile, verifier, reference revision, or route change therefore cannot inherit an older reference. Every read checks the stored JSON and digest, then reverifies the artifact's host attestation and qualified-native receipt against the exact current job. Corrupt state blocks instead of becoming a miss. Identical independent writes converge, while a different valid artifact under the same identity is a terminal conflict and never replaces the first. The database necessarily contains the complete reference target and receipt; keep it owner-only and apply the host's encryption, backup, retention, and deletion policy. The campaign database continues to retain only text-free case evidence. `resolve_native_reference_artifact` returns a verified stored artifact or calls one host-supplied external loader and persists its result before blind review. Its optional operation guard runs before cached receipt verification, before the external lookup, and before verification on save. Guard, loader, temporary attestation-authority, and receipt-verifier outages become bounded, content-free campaign dependency failures. Invalid artifacts, altered state, binding mismatches, and conflicts remain terminal; no missing reference is generated locally. `integrations/website_localization_native_reference_intake.py` completes the editorial hand-off without defining a vendor or inventing a translation. A host creates one `blun.website-localization-native-reference-work-order.v1` object per exact suite job. It contains the complete source, target locale, content type, locale-quality profile, policy and suite bindings, but no target text, reviewer credential, receipt, candidate, or baseline. Its stable identity binds the current route, complete policy, and complete canonical job. After a separately qualified native editor supplies a target, use `native_reference_verification_request_for_work_order` to construct the exact request that the configured verification authority must authorize. Submit that request and opaque receipt as `blun.website-localization-native-reference-submission.v1`, including the exact work-order ID and SHA-256 digest. `accept_native_reference_submission` regenerates the work order from current trusted state, reconstructs the receipt payload, verifies the qualified-human receipt, obtains and verifies the host attestation, then saves through `NativeReferenceArtifactStore`. A stale order, changed source, locale, profile, suite, policy, route, reviewer, target, or receipt therefore blocks before storage. Pass the campaign lease guard as `operation_guard`; it is checked immediately before every verifier and attestation-authority operation. Temporary guard, verifier, signer, or attestation-verifier outages are retryable and content-free. Identical submissions converge, while a different valid submission cannot replace the first accepted reference. The work order and accepted artifact contain source-derived prose and the accepted artifact contains the native target and receipt. Transport them only over a host-authenticated channel and retain them in owner-only storage under the host's encryption, access, backup, retention, and deletion policy. Public status must expose only stable IDs, hashes, codes, and counts. The intake module performs no network call, reads no credential or environment variable, and deliberately leaves authentication and qualified-review operations to the host adapters. `integrations/website_localization_native_reference_queue.py` makes that hand-off durable for a complete campaign. It creates exactly one text-free queue row for every policy-required `(target_locale, suite_case_key)` pair in the campaign database. `claim_native_reference_work_order` returns one expiring, token-bound lease and its exact target-free work order; concurrent editors cannot claim the same live row. The lease payload contains the source and is a private editorial artifact even though it contains no target. Renew it with `renew_native_reference_work_order` when a qualified review legitimately needs more time. Submit only through `accept_native_reference_submission` on the production runtime. The runtime checks the exact live queue lease before each receipt or attestation operation, saves the verified artifact in the separate native- reference store, and only then records the artifact SHA-256 digest as queue success. A verifier or authority outage enters bounded exponential retry; malformed, replayed, stale, or rejected evidence becomes a terminal stable error without storing its prose. Expired leases are recovered with a new token and stop permanently at the configured attempt limit. If a process crashes after the artifact commit but before queue completion, the next claim reverifies that immutable artifact and reconciles the queue without asking a model or external reference loader to create replacement text. `native_reference_queue_status` and `native_reference_queue_health` expose only counts, hashes, timestamps, and stable codes. Health is rollback-only and blocks on corrupt state, terminal failures, or an expired benchmark policy; expired leases, due retries, and stalled progress degrade visibly. A transport adapter must keep the lease token and work-order source private, authenticate the editor, reject duplicate JSON keys and oversized bodies, and map the runtime's exact content-free outcomes without weakening these checks. `integrations/website_localization_native_reference_http.py` provides that transport as a provider-neutral WSGI application. The host supplies one authenticator; after checking the complete method, path, normalized headers, and request-body SHA-256 digest, it must return a credential-bound editor ID and exactly one qualified BCP-47 target locale. The client cannot choose or override either value. The application requires an effective HTTPS WSGI scheme, rejects query strings, transfer encoding, missing or false content lengths, non-JSON media types, BOMs, duplicate keys, non-finite numbers, invalid UTF-8, extra fields, and bodies above 4 MiB. Authentication happens before JSON decoding, and neither credentials nor exception prose enter a response. The private endpoints are: - `POST /v1/native-references/claim` with the exact claim schema, a durable request ID, and a lease duration. The queue filters by the authenticated locale. Replaying the same request while its lease is live returns the exact same lease and cannot reserve a second source; replay after expiry or reuse under another credential fails closed. - `POST /v1/native-references/renew` with the exact private lease envelope and a new duration. The runtime reconstructs the canonical job from policy and suite state, then requires the authenticated editor, locale, work ID, attempt, token, expiry, and complete work order to match the live row. Lease renewal and its content-free response journal commit in one transaction, so a retry after a lost response returns the byte-equivalent lease envelope. - `POST /v1/native-references/submit` with that lease and the complete transport-neutral submission envelope below. Receipt verification, attestation, immutable artifact storage, and queue completion remain inside the runtime. The request is reserved before external verification, and its content-free outcome is committed atomically with the queue transition. An exact retry returns that outcome without invoking the verifier or storage again; a repeated or stale request cannot store a second result. - `GET /v1/native-references/status`, which returns only the authenticated locale plus the existing content-free counts, timestamps, hashes, and stable codes, including processing, completed, and abandoned HTTP-request counts. It never returns a source, target, receipt, credential, request ID, or lease token. Every response sets `Cache-Control: no-store` and `X-Content-Type-Options: nosniff`. A claim response necessarily contains the source and lease token, so operators must also prevent proxy/access-log body capture and apply owner-only retention to request bodies. When TLS terminates before WSGI, only a trusted proxy may set the effective HTTPS scheme; forwarding an untrusted client header is not sufficient. Request IDs are idempotency keys, not evidence and not authorization. Renewal and submission journals bind the request ID to the exact body digest, campaign, credential-derived editor identity, locale, work item, attempt, lease token, and original expiry. Reusing an ID with another operation, body, credential, or locale is a conflict. Journals retain only renewal expiry or the existing content-free queue outcome—never source text, target text, receipts, work orders, or credentials. Concurrent submission retries receive a retryable in-progress conflict. If the worker crashes before a queue transition, the processing entry expires with its work lease; normal bounded queue recovery issues a new attempt and the abandoned request ID remains unusable. The three write requests use these exact outer shapes; `lease` is the complete claim response value and `submission` is the complete envelope in the next section: ```json {"schema":"blun.website-localization-native-reference-http-claim.v1","request_id":"","lease_seconds":3600} {"schema":"blun.website-localization-native-reference-http-renew.v1","request_id":"","lease":{},"lease_seconds":3600} {"schema":"blun.website-localization-native-reference-http-submit.v1","request_id":"","lease":{},"submission":{}} ``` The authentication adapter receives `blun.website-localization-native-reference-http-auth.v1` with the exact HTTP method, path, normalized headers, and body digest. It returns exactly `schema`, `editor_id`, `target_locale`, `credential_id`, and `credential_version` under `blun.website-localization-native-reference-editor.v1`. The WSGI application validates this shape but does not decide whether the credential is qualified; that trust decision belongs to the host authenticator and its separately managed registry. The transport-neutral submission envelope has exactly these top-level fields: ```json { "schema": "blun.website-localization-native-reference-submission.v1", "work_order_id": "native-reference-work-order:", "work_order_sha256": "", "verification_request": { "schema": "blun.website-localization-native-reference-request.v1", "reference_revision": "", "suite": "", "source": "", "target_locale": "", "content_type": "", "quality_profile": "", "localization_policy": "", "qualification": { "method": "qualified_native_human", "reviewer_id": "", "reviewer_version": "", "verifier_id": "", "verifier_version": "" }, "target_text": "", "target_sha256": "" }, "qualification_receipt": "" } ``` Fields shown as objects must be JSON objects, not strings; the notation above keeps the contract compact. Implementations must transmit the complete canonical objects returned by the two intake helpers and must reject extra, missing, duplicate, non-finite, oversized, or altered data at their transport boundary. The host may wrap this envelope in its own authenticated HTTP, message-queue, or editorial-system protocol, but that wrapper is not evidence and cannot weaken the receipt, attestation, or immutable-store checks. Every benchmark policy must bind the exact version and SHA-256 digest of the output-free source manifest in `integrations/website_localization_benchmark_suite.py`. Suite v4 contains 64 cases: eight independently bound cases from eight distinct domains for each of `headline`, `cta`, `marketing`, `ui`, `documentation`, `seo`, `legal`, and `commercial`. Eighteen cases are connected long-form pages across commercial, marketing, documentation, and legally sensitive content. Together they exercise HTML, JSON, placeholders, links, native register and rhythm, translationese, negation, modality, amounts, currencies, discount and surcharge bases, tax, deposits, trials, billing versus commitment, renewal, cancellation, refunds, proration, tiered prices, and offer assignment. The suite contains no target, candidate, baseline, or supposed reference translation. Actual targets must still come from the attached candidate and lawfully acquired baseline so unreviewed prose cannot silently become a gold standard. The hashed manifest also binds the exact commercial evaluation scope from the public, brand-neutral offer profile. Every commercial case carries all ten ordered dimensions, including dimensions absent from its source so an invented target-only claim is still in scope. The runner validates this scope before any external review. It exposes the dimensions only to the source-aware fidelity pass; the first native-language pass remains source-blind. Missing, additional, or reordered dimensions block the case instead of silently narrowing review. After a valid source-fidelity response, the runner removes defect indexes and reviewer prose, resolves anonymous A/B labels back to candidate and baseline, and writes only `equivalent`, `not_present`, `major`, or `blocking` for each ordered dimension into the signed case result. That summary is bound to the exact source-fidelity response SHA-256. The final signed report aggregates the four status counts separately for every dimension and locale. Any candidate `major` or `blocking` status blocks that dimension and the containing lane; an overall win rate cannot hide it. Non-commercial cases carry no commercial evaluation, and neither cases nor reports expose offer values or reviewer text. The policy also requires `valid_until`, an absolute positive integer Unix timestamp chosen by the trusted host for that exact candidate, baseline, reviewer, reference, suite, and decision configuration. It is included in the policy hash, every signed case result, and the signed final report. Extending the date therefore creates a new campaign and cannot relabel old case evidence as current. The contract enforces expiry; it does not prove that a host-chosen date is appropriate. Hosts must derive it from their lawful baseline update process and deliberately shorten it when a provider, model, glossary, quality profile, or evaluation policy changes. ### Durable benchmark campaigns `integrations/website_localization_benchmark_campaign.py` turns the bound suite and benchmark policy into a durable execution matrix. With the current English-source suite and complete EU target scope, one campaign contains exactly 1,472 work items: 64 source cases multiplied by 23 target locales. Work IDs bind the complete policy hash, suite hash, locale, and case key. Creating the same campaign again is idempotent; changing any candidate, reviewer, reference, baseline, threshold, locale, or suite field creates a different campaign identity instead of inheriting old evidence. The host supplies a dedicated trusted `sqlite3.Connection`, a `BenchmarkInputResolver`, the blind reviewer, native-reference verifier, evidence authority, and blinding key. The resolver receives one canonical localization job and returns `BenchmarkCaseInputs`: the already validated candidate result, an attested baseline from an allowed acquisition route, locale-bound assets, and an attested qualified-native reference. The campaign store never fetches an API, chooses a provider, reads credentials, or invents a missing artifact. Production composition should use `integrations/website_localization_benchmark_runtime.py`. Its `WebsiteLocalizationBenchmarkRuntime` preflights the complete policy, routes, adapters, blinding key, worker identity, and five distinct idle SQLite connections before creating any schema. Those connections isolate campaign status, candidate text, baseline text and evidence, and qualified-native reference text and receipts, plus signed anonymous-review evidence, so one store cannot silently share transaction or schema state with another. Construction creates the exact idempotent campaign; `run_once` processes at most one item, while `status`, `health`, `summarize`, and `load_report` retain the campaign's existing text-free and all-locales-complete contracts. The runtime owns the only `BenchmarkCaseInputs` construction. It resolves locale assets, then uses the durable candidate, baseline, and native-reference stores under their exact route, policy, and canonical suite-job identities. The configured candidate adapter is resolved lazily only when no verified candidate is stored. The baseline callback receives the job, bound policy, evidence authority, and current operation guard; an official API adapter must pass that guard into its transport boundary. The native reference callback receives only the canonical job and must return externally qualified evidence—it is never asked to generate text. Corrupt or conflicting state blocks instead of falling through to another external call. For this trusted resolver, the campaign passes a no-argument token-bound guard that renews the current lease. It runs before and after host resolvers, before every candidate-model operation, throughout evidence verification, before the baseline acquisition boundary, and before the external reference lookup. A restart after a reviewer outage therefore reloads the same three verified artifacts without invoking the model, baseline API or reference vault again. Legacy callable resolvers remain compatible, but they receive only the older single guard before dependency resolution and should not be used as the production composition root. Adapters may load these zero-dependency modules independently, as happens when a host composes the campaign, DeepL baseline adapter, acquisition store, and its own resolver without installing a Python package. Public frozen `BenchmarkPolicy`, `BenchmarkSignature`, `BenchmarkCaseInputs`, and `BaselineAcquisition` values from another module instance are normalized into the receiving module only when the dataclass name, frozen status, field order, and complete field set match exactly. Every ordinary policy, suite, job, signature, evidence, authority, and artifact check then runs unchanged. Mappings, mutable objects, extra or missing fields, and similarly named lookalikes are not compatibility values and block before persistence or blind review. This structural boundary prevents Python class identity from becoming an accidental vendor lock while retaining fail-closed validation. `integrations/website_localization_benchmark_review_store.py` closes the remaining restart boundary around the two ordered blind reviews. Immediately after a response passes the exact phase, locale, blind-ID, preference and defect-schema checks, the runtime binds it to the canonical request hash, benchmark policy, configured reviewer route and reviewer identity, then signs and verifies that artifact before continuing. The source-blind `target_native` response is therefore durable before `source_fidelity` begins. If the second review or final campaign commit fails, a retry reverifies and reuses the first response; after both are stored, neither review is called again. The deterministic `review_id` remains the external adapter's idempotency key for the unavoidable crash window after the reviewer accepts a request but before the local transaction commits. Stored review state is immutable. A repeated review ID with another request hash, invalid JSON or digest, a wrong reviewer binding, failed attestation, or a second valid but different response blocks without calling the reviewer again. Changed routes and policies cannot reuse old evidence. Verifier outages remain retryable, while corruption and conflicts are terminal. Operational campaign status and final case results still expose only response hashes, preferences, defect counts and finding hashes—not reviewer reasons, excerpts, source text or either target. For a commercial `source_fidelity` response, persistence additionally requires the complete `translate-native.commercial-benchmark-review.v1` acknowledgement. It lists all ten dimensions in profile order and records a status for both anonymous variants. `major` and `blocking` statuses must reference the matching variant's zero-based defect entry; `equivalent` and `not_present` cannot carry a defect reference. `uncertain` blocks the case instead of becoming durable PASS evidence. The `target_native` response has no commercial acknowledgement and therefore remains source-blind. The review store also exposes a strictly read-only, content-free health view for one exact reviewer route and benchmark policy. It rechecks canonical rows, digests, phases, locale and blind-variant bindings, and every host attestation; historical policies are counted separately from the active scope. The caller may provide the exact request and response hashes required by completed cases. Missing, mismatched, altered, or unverifiable evidence blocks with stable reason codes. The health payload contains only counts and never invokes the reviewer or returns source, target, explanation, excerpt, or finding text. ### Provider-neutral benchmark reviewer HTTPS adapter `integrations/website_localization_benchmark_reviewer_http.py` implements the runtime's `BenchmarkReviewer` contract for an independently hosted human or model review gateway. Configure one fixed HTTPS endpoint and a host-owned authentication-header callback, then pass the adapter as `reviewer` in the existing `benchmark_execution` mapping. The adapter performs exactly one request per invocation; the durable campaign and review store remain the only owners of retry limits, backoff, leases, and reuse. Each `POST` body uses `blun.website-localization-benchmark-review-http-request.v1` and contains the exact anonymous `blun.website-localization-benchmark.v7` `BenchmarkReviewRequest`, its deterministic `review_id`, and the SHA-256 digest of its canonical UTF-8 JSON. Its expected review object uses `blun.website-localization-benchmark-review.v2`. The same values are bound in `Idempotency-Key`, `X-Benchmark-Review-Id`, `X-Benchmark-Review-Phase`, and `X-Benchmark-Review-Request-Sha256`. Authentication headers are obtained for that attempt only and cannot replace protocol, routing, framing, or binding headers. Credentials never enter the body, error state, or durable benchmark evidence. The source-blind request is accepted only with the exact `target_native` instruction and input field set; `source`, `glossary`, and `protected_terms` are forbidden. The later `source_fidelity` request has a different exact field set and instruction and carries the source. Commercial fidelity requests also carry the ten ordered dimensions and exact acknowledgement schema; other content types do not. Both retain only anonymous `A` and `B` variants. Candidate provider, baseline identity, acquisition provenance, and unblinding data are absent from the transport contract. The service must return `blun.website-localization-benchmark-review-http-response.v1` with the same `review_id` and request digest plus one exact benchmark-review object. The adapter rejects wrong phase, locale or blind ID, unknown fields, malformed defects, and a preferred variant that still has a blocking or major defect. For commercial fidelity it also rejects missing, additional, reordered, uncertain, or improperly defect-linked dimension decisions. The HTTPS adapter and durable review store enforce the same conditional contract. Responses are strict UTF-8 JSON with duplicate keys, BOMs, non-finite numbers, wrong media types, inconsistent lengths, redirects, and oversized bodies rejected. Only `408`, `425`, `429`, network failures, and `5xx` responses are retryable; orchestration receives stable content-free error codes. Plain HTTP is available only through an explicit loopback-only development option. Production TLS termination, authentication, credential rotation, access control, request logging policy, and reviewer independence remain host responsibilities. This adapter makes the blind review runnable; it does not itself establish linguistic quality or superiority over a baseline. `run_next_benchmark_case` claims and processes at most one exact case/locale pair. Random token-bound leases are renewed before dependency resolution and before each of the two reviewer calls. An abandoned lease can be recovered after expiry; stale workers cannot finish it. Retryable adapter or attestation failures use bounded exponential backoff and a configured attempt ceiling. Terminal binding, parser, suite, policy, and evidence failures remain failed while unrelated work continues. Operational status contains only deterministic work identity, counts, stable error codes, timestamps, and hashes. The database retains only the attested text-free case result after success—not source, candidate, baseline, reference, credentials, or reviewer prose. `summarize` remains fail-closed until every expected item succeeded. It then signs and verifies the exact result set outside the database transaction, rechecks that set atomically, and stores the first canonical report in the campaign database. The report is bound to the campaign policy and ordered result hashes. Later calls return that same verified report byte-for-byte without signing again. A failed, omitted, duplicated, exchanged, or policy-stale work item therefore cannot disappear behind a partial aggregate, and a crash cannot silently replace the report used for a claim. Existing v1 and v2 campaign databases migrate transactionally to the v3 report schema. Case-result schema v8 and report schema v11 bind the same `valid_until` value. After finalization, `BenchmarkCampaignStore.load_report` is the read-only consumer boundary. It opens a consistent snapshot, requires the exact complete result matrix and a succeeded report-finalization state, reloads the single stored report, then rolls the transaction back before reverifying its policy, ordered-result digest, canonical JSON, content hash, timestamp, and signature. It never calls the signing capability and never repairs, replaces, or creates state. Missing, incomplete, stale, future-dated, state-inconsistent, or altered evidence therefore returns a stable failure instead of a report. ### Authenticated benchmark report HTTP reader `integrations/website_localization_benchmark_http.py` exposes that verified read-only boundary to an operator dashboard or evidence consumer without granting database access. It provides exactly two HTTPS-only WSGI routes: - `GET /v1/benchmarks/status` returns the configured campaign identity, policy and suite hashes, validity deadline, work and error counts, plus the content-free report-finalization state. - `GET /v1/benchmarks/report` first requires the exact campaign to be complete and finalized, then invokes only `load_benchmark_report`. Its response binds the authenticated campaign ID to the canonical signed report and a SHA-256 digest of those exact report bytes. The host authenticator receives `blun.website-localization-benchmark-http-auth.v1` with the exact method, path, sorted request headers, and the empty-body digest. It must return `blun.website-localization-benchmark-reader.v1` with `reader_id`, `campaign_id`, `credential_id`, and `credential_version`. The application requires the principal's campaign to equal the runtime's verified campaign status before report loading. Authentication failure, credential rotation, cross-campaign access, request bodies, query parameters, plaintext transport, incomplete or expired campaigns, malformed runtime output, and report verification failures all return only a stable code and retry flag. Responses use `Cache-Control: no-store`; neither route starts benchmark work, signs a report, repairs state, or returns case prose, source text, target text, credentials, or adapter exceptions. `BenchmarkCampaignStore.health` verifies the complete campaign binding, every row invariant, successful result hash, and case attestation in a consistent read-only snapshot. It reports only status counts, stable reason codes, the latest progress timestamp, and whether the persisted final report verifies. Health never signs or stores a report. A fully completed campaign without its first report is degraded with `benchmark.campaign.report_missing` until an explicit `summarize` call creates it; altered or unverifiable report bytes block with `benchmark.campaign.report_invalid` and are never regenerated in place. The production benchmark runtime performs that explicit finalization directly after the last successful case. If the process stopped between committing that case and creating the report, the next otherwise idle benchmark tick detects the exact complete matrix and closes the gap without resolving another case. Both paths guard the signing boundary before and after report construction, so loss of the outer supervisor lease prevents persistence and a later tick can retry safely. A stored report suppresses all automatic re-signing. Expired leases and overdue actionable work degrade health; any terminal work failure, altered row, invalid attestation, or invalid final report blocks it. Live backoff and recent incomplete work remain healthy and never imply that the candidate won. At the first clock value after `valid_until`, the campaign blocks new claims, rechecks the boundary before every dependency or reviewer operation, refuses case completion and report signing, and rejects stored-report loads with `benchmark.campaign.validity_expired`. An expiry discovered during a live case or report attempt is recorded as terminal, content-free state; no remaining external adapter is called. Health is blocked and `report_ready` is false even when every historical score and signature remains otherwise valid. Early locale lanes may be run and reported independently, but passing them no longer authorizes an EU-wide superiority statement. The attested report exposes `configured_lanes_status` separately from `superiority_claim_allowed` and includes an exact `claim_scope` with required, evaluated, missing, unexpected, and source-language locales plus the required and evaluated content types. A public claim is allowed only when the configured locale set exactly covers every EU target eligible for the bound source suite, all eight content types are configured, and every locale report passes on its own. One missing locale, missing content-type lane, or blocked result therefore blocks the overall report; no aggregate can conceal it. Each locale report also exposes separate statistics for `target_native` and `source_fidelity`: candidate wins, baseline wins, ties, decisive rate, candidate win rate, and the one-sided sign-test probability. Both axes must independently meet the policy's predeclared sample, decisiveness, win-rate, and significance thresholds. Those thresholds and fixed block reasons are included in the attested report. Joint case winners remain an additional conservative metric, but discarded cross-axis disagreements can no longer make a weak axis appear statistically convincing. Suite v4 predeclares all eight content types as required statistical lanes with a minimum of eight cases per type and locale. For every lane, the report repeats the joint and independent `target_native` and `source_fidelity` statistics. A weak headline, CTA, marketing, UI, documentation, SEO, legal, or price/offer lane blocks its locale even when wins from the other content types make the all-content aggregate appear significant. A policy may deliberately evaluate a smaller diagnostic subset, but its signed claim scope records every omitted content type and cannot authorize a public superiority claim. The current suite source language is English, so its EU localization target scope contains the other 23 official-language locale profiles. `en-IE` is recorded explicitly as the source-language locale and is not sent through a same-language translation job, matching the planner's source-exclusion rule. This report does not claim that English localization from a non-English source was evaluated. A future suite revision with a different source-language design must change the bound suite digest and will derive a new exact claim scope. Each case compares one fully validated worker result with one bound baseline artifact. A host-held blinding key assigns them reproducibly to anonymous `A` and `B` positions. Neither reviewer request contains candidate-provider or baseline identity. The first review receives only the two targets, the exact locale profile, audience, tone, target terminology, and content type. The second review receives the complete source and glossary for a separate fidelity judgment. Both must prefer the same variant; a preferred variant with any blocking or major defect is an invalid review. The local structure guard independently checks both variants. Raw texts and reviewer prose are absent from stored case results; only hashes, counts, blinded commitments, and unblinded preferences remain. The policy also names the exact candidate provider, model and model version, software version, glossary version, localization-policy version, and worker schema. The harness rejects a job that differs from any of these values before calling a reviewer. Stored case results repeat this candidate binding and the exact locale-quality-profile version and hash. During aggregation, the harness rebuilds the canonical suite job and requires its deterministic job ID, so a result from another model, policy, source case, or locale cannot be relabelled. The final report records the same candidate binding and all required locale profile bindings. These fields never enter either blinded reviewer request. Benchmark results are durable evidence only when a host-owned `BenchmarkEvidenceAuthority` attests them. The harness passes canonical UTF-8 bytes to that provider-neutral interface and never reads a signing key. The policy fixes the expected algorithm and key identifier. After both blind reviews, the harness signs and immediately verifies the complete text-free case result; missing, rejected, foreign-key, or payload-mismatched attestations block before aggregation. `summarize_benchmark` verifies every case first, binds the report to the digest of the exact signed case set, and attests the complete report. Consumers can call `verify_benchmark_report` with that exact case evidence before accepting even a `PASS` claim. Production hosts should back the authority with an isolated signer or hardware-backed key and restrict it to this benchmark contract; the test-only HMAC authority is not production key management. `summarize_benchmark` applies a one-sided exact sign test and minimum case, decisive-rate, and win-rate thresholds separately to every required locale. One candidate blocking/major/integrity defect blocks that locale. Missing, small, tied, mixed-version, substituted-suite, or duplicate samples block the superiority claim, and a strong result in one language can never average away a weak result in another. Maltesisch (`mt-MT`) and Finnisch (`fi-FI`) are the initial mandatory lanes and cannot be removed from policy. A locale passes only after every canonical suite case is present exactly once; the report records observed content types, domains, long-form count, and adversarial tags. The same versioned contract extends to every eligible EU language profile, excluding the source language as required by the localization planner. Premortem: reviewers could learn which output came from which system, a large language could hide a weak low-resource language, an arbitrary output could be labelled as an official baseline, or an old baseline could be quietly reused. Attested lawful provenance, keyed A/B assignment, and origin-free review payloads reduce identity bias; per-locale hard gates prevent averaging; exact baseline, reviewer, benchmark, suite, suite case, source, locale, and content bindings plus exact candidate and quality-profile bindings reject stale, substituted, homogeneous, relabelled, unsigned, forged, or mixed evidence. The harness permits a claim only from complete measured blind evidence, never from a model grading its own prose. ## Signed translation memory and website readiness `integrations/website_localization_release.py` turns a completed queue result into an append-only translation-memory entry only after a host-owned verifier accepts a quality receipt for the complete release context. The module never reads a signing key. Instead, a trusted `ApprovalAuthority` signs and immediately verifies the canonical approval bytes outside the worker's authority. Production hosts should implement that interface with an isolated service or hardware-backed signer; the repository tests use HMAC only as a deterministic test double. The receipt-verifier contract receives exactly `binding` and `receipt`. `binding` uses `blun.localization-quality-receipt-binding.v9` and contains the review purpose, job and canonical result hashes, full source and target text plus hashes and locales, content type, glossary and policy versions, primary and optional review-provider identities, software version, two-pass confidence, locale quality profile, and, for commercial content, the exact nested locale-specific commercial profile plus its content-free targeted-review summary and exact advertised review-evidence-contract SHA-256, the canonical advertised routing-contract SHA-256 for every commercial result, the canonical advertised resolution-contract SHA-256 when targeted review is unresolved, the private text-free mapping from each opaque offer index to its ordered source and target Unicode code-point spans, and the human/independent-review requirements. It also carries the canonical quality-evidence request ID and evidence revision that produced the opaque receipt. The verifier must cryptographically bind every field. It must reject a receipt issued for another result, policy, model, profile, software version, locale, or review purpose. In particular, a quality receipt cannot satisfy a qualified-human or independent-model review, and an old receipt cannot be relabelled under a newer evidence response. For deployments that keep verification behind a network trust boundary, `integrations/website_localization_receipt_verifier_http.py` provides one fixed-endpoint provider-neutral HTTPS attempt. It validates the complete binding before authentication, derives deterministic request identity from the binding and receipt hashes, disables redirects, strictly checks the bound boolean response, and contains no credential or retry loop. Declared temporary network and service failures retain retryability through the durable evidence queue; an explicit negative verdict or invalid binding remains terminal. The public protocol is documented in [`WEBSITE_LOCALIZATION_RECEIPT_VERIFIER_HTTP.md`](WEBSITE_LOCALIZATION_RECEIPT_VERIFIER_HTTP.md). Every approval binds the exact source and target hashes, source and target locales, content type, glossary and policy versions, provider/model identity, worker schema, software version, queue-result hash, quality-receipt hash, the explicit two-phase review confidence, approval lifetime, and signing-key identity. Legal content additionally needs a separately verified qualified-human receipt. For non-legal content, low native or fidelity confidence requires exactly one separately verified qualified-human receipt or an independent second-provider model receipt. Raw receipts are never stored. Approvals for one deterministic job may be reused across different plan compositions, but a changed source, policy, glossary, provider, model, or software version produces a different job and therefore a cache miss. An already approved job can never be overwritten with a different target hash. Before any publication adapter receives content, `readiness` revalidates every stored result, approval payload, expiry, and signature for the plan's exact required locale set. `publication_bundle` returns content only when all required locales pass; a missing, expired, altered, or invalid approval blocks the whole website version without deleting an older known-good entry. The release store uses its own trusted host-supplied SQLite connection, separate from the queue connection, and performs no network or publication action. Premortem: a receipt or signature might be replayed after policy drift, a database edit might swap the target, or a partial rollout might be mistaken for completion. The deterministic job binding invalidates drift, append-only target hashes and canonical payload signatures expose tampering, and readiness requires exact set equality across all policy-required locales. Tests cover source, policy, model and software invalidation, signature/result corruption, expiry, legal review, partial readiness, and cross-plan translation-memory reuse. ## Quality evidence and release coordination `integrations/website_localization_release_coordinator.py` joins completed locale jobs, external quality evidence, signed translation memory, and the CMS outbox without embedding a model or reviewer. Each invocation approves at most one completed locale. It creates a CMS delivery only after the release store independently revalidates every locale required by the plan. Pending, retrying, or terminally failed siblings therefore cannot leak a partial website version into the publication outbox. The host supplies a `QualityEvidenceProvider` implementing `obtain(QualityEvidenceRequest)`. One request contains exactly one complete source and target, plus their hashes, the CMS event, plan and job identities, source and target locales, content type, glossary and policy versions, provider/model identity, software version, and a host-chosen `evidence_revision`. Its deterministic `request_id` binds all non-text fields and the exact validated queue-result hash; both text hashes bind the complete source and target bytes. The durable store and HTTPS adapter independently recompute the ID from the same closed v8 identity field set before persistence or network access. The coordinator carries that exact ID and revision into each v5 receipt binding and the v5 signed approval; missing or substituted context blocks before receipt verification or signing. The adapter may call an independent model, a qualified native reviewer, or a host-owned review service; no provider transport or credential is built into the coordinator. For deployments that need a concrete network boundary, `integrations/website_localization_evidence_http.py` implements that interface as one request-bound HTTPS attempt. It validates the exact v8 evidence request, canonicalizes native Unicode without ASCII folding, binds the inner digest and deterministic evidence ID in both headers and body, disables redirects, and strictly validates the response envelope before the coordinator verifies its receipts. Authentication remains a host callback and the adapter contains no provider-specific model, endpoint, credential, brand, product, or price. The public protocol and retry classification are documented in [`WEBSITE_LOCALIZATION_EVIDENCE_HTTP.md`](WEBSITE_LOCALIZATION_EVIDENCE_HTTP.md). The adapter never retries internally; the durable evidence state below remains the single retry authority. The host must also supply a `QualityEvidenceStateStore` backed by its own trusted SQLite connection and a stable `evidence_worker_id`. Before source or target text reaches the evidence adapter, the store atomically claims the exact request through an owner- and token-bound lease. A second coordinator cannot call the provider while that lease is live. Lease expiry recovers an abandoned attempt after a crash; stale workers cannot finish a newer claim. Retryable failures use bounded exponential backoff and the configured attempt ceiling, while permanent evidence or receipt failures stop immediately. The adapter must return exactly this shape: ```json { "schema": "blun.localization-quality-evidence-response.v2", "request_id": "blun-l10n-evidence-…", "result_sha256": "…", "quality_receipt": "host-verifiable-purpose-bound-receipt", "human_review_receipt": null, "independent_model_review": null } ``` The response is rejected if the request object was mutated, a binding differs, the receipt is empty or malformed, or the trusted quality verifier rejects it. The evidence request binds the explicit native and fidelity confidence values. Legal content always requires a non-null human receipt and a separate human-review verifier. For non-legal content with low confidence, the adapter must return exactly one of that qualified-human receipt or an independent model review in this form: ```json { "schema": "blun.independent-model-review.v1", "provider": { "id": "independent-provider", "model_id": "configured-review-model", "model_version": "immutable-model-version" }, "receipt": "host-verifiable-purpose-bound-receipt" } ``` The independent reviewer must use a different provider adapter identity from the primary translation provider. The host supplies a separate verifier; its verified receipt hash and exact provider/model identity are included in the signed approval. Missing, ambiguous, same-provider, malformed, or rejected evidence keeps the locale blocked. A receipt is evidence for the existing two ordered reviews—first source-blind native quality, then source-aware fidelity—not permission to collapse them into one score. A major defect still blocks the worker result entirely; it cannot be outweighed or converted into a confidence decision. Exact retries are safe: approved locales are reused, the outbox has a stable delivery identity, and a crash after signing an approval but before recording evidence completion is reconciled from that verified approval without another provider call. The deterministic `request_id` remains the adapter's external idempotency key for the narrow crash window after a provider accepts a request but before the local attempt is durably finished. An expired partial approval requires new evidence and a new `evidence_revision`. A pending delivery with expired approvals is blocked; a previously acknowledged delivery remains immutable terminal history. `statuses(event_id)` exposes the evidence state, attempt count, retry time, lease expiry, and stable last-error code for monitoring. It stores and returns no source text, target text, receipt, provider prose, or credential. Coordinator outcomes and exceptions follow the same content-free rule. Premortem: two schedulers could request the same review, stale evidence could approve changed output, or the last successful locale could trigger a partial publication. Transactional leases prevent concurrent provider calls; deterministic evidence IDs cover the remaining external crash window; exact result and policy bindings reject stale evidence; the HTTP envelope makes the external idempotency and digest contract explicit; signed release readiness and the all-locale CMS transaction block partial publication. Tests cover exclusive claims, bounded retries, one-attempt HTTP failures, one-locale progression, replay, crash recovery, expiry, legal review, authentication and endpoint safety, Unicode transport, parsing, tampering, wrong bindings, and failed receipt verification. They prove the orchestration boundary, not native linguistic quality or superiority over an external translation service. ## CMS change and publication contract `integrations/website_localization_cms.py` connects the pipeline to a CMS without choosing a vendor or network library. The host supplies three isolated capabilities: an inbound signature verifier, an outbound signing authority, and a publisher implementing `publish(CMSPublicationRequest)`. The bridge does not read keys, choose credentials, or update live CMS state by itself. A host can inject its own publisher or use the included provider-neutral HTTPS publisher described below. An inbound `blun.cms-content-change.v2` event has exactly these fields: ```json { "schema": "blun.cms-content-change.v2", "event_id": "cms-event-184", "site_id": "blun-marketing", "website_version": "website-2026-08-29.1", "source_sequence": 184, "localization": { "source_id": "homepage.hero", "source_revision": "cms-184", "source_text": "Build your business with BLUN.", "source_locale": "en-IE", "content_type": "headline", "glossary_version": "blun-glossary-3", "policy_version": "native-web-1", "provider_id": "customer-llm", "model_id": "king", "model_version": "2026-08-29", "software_version": "6.43.0-dev", "target_locales": ["de-AT", "sv-SE"] } } ``` Before publication starts, the CMS may withdraw that exact event with a signed `blun.cms-content-cancellation.v1` message. Its immutable binding contains a unique cancellation ID plus the event, site, website version, source ID, and source sequence. The signer key must match the credential that created the event. Exact replay is idempotent; altered bindings, another accepted tenant key, corrupt stored bytes, and cancellation-ID reuse fail closed. An accepted cancellation removes the event from service scheduling, blocks release and delivery preparation, and closes a pending or retrying outbox entry without calling the model, reviewer, or publisher. Health and tenant lifecycle reads reverify the cancellation and expose only the stable `cancelled` state. Cancellation never rewrites an acknowledged publication. It also refuses a currently leased publication because the external CMS may already have accepted the request. The caller must observe the lease outcome before retrying. Deleting content already published uses an independently signed CMS tombstone; cancellation remains deliberately limited to unpublished work. The tombstone is accepted only for an exactly acknowledged publication and is bound to its delivery ID, payload hash, plan, source generation, website version, and full sorted locale set. A separate durable, signed outbox retries delivery after a crash and accepts only an exact signed `deleted` acknowledgement. It contains no source or target prose and preserves the original publication as immutable audit history. Cancellation remains available during the durable intake crash gap, after the signed event and source sequence are stored but before queue insertion has finished. The bridge checks the ledger both before and after queue insertion. Therefore an exact replay cannot revive withdrawn work, and a cancellation that races insertion prevents the event from becoming production-eligible. Tenant status, lifecycle, and health expose this intentionally queue-free state as `cancelled` instead of misreporting it as an intake outage; no provider health probe is made for that event. The CMS signs the canonical UTF-8 JSON bytes outside the envelope. The bridge verifies the signature before its first write, derives the deterministic plan, and persists the event before enqueuing it. If the process stops between those two transactions, the service supervisor reloads and verifies the stored event, then resumes exactly one intake per tick with the same attempt ceiling as the public API. An exact CMS replay remains safe but is no longer required for progress. Deterministic plan and job identities make concurrent replay and automatic recovery idempotent, while the cancellation ledger is checked again before and after queue insertion and therefore cannot be revived. The same `event_id` with different canonical bytes is an idempotency collision and cannot add work. For each `(site_id, source_id)`, the CMS supplies a positive, monotonic `source_sequence` inside the signed event. Once a newer event has reached `enqueued`, every older, not-yet- published generation of that source is marked superseded. Exact replay keeps its signed sequence and therefore cannot displace a newer event; a delayed, out-of-order webhook with a lower sequence is superseded immediately. Reusing one sequence for a different event is an idempotency collision. A superseded event cannot create a release; any pending, retrying, or leased outbox entry becomes terminal with the content-free `event_superseded` reason. The service passes only current plan IDs into the queue claim, so a locale job referenced exclusively by superseded plans is never sent to a model. A content-identical job still remains eligible when any current plan references it. New events must use the v2 contract. During the transactional database-v1 migration, already stored v1 events receive deterministic legacy generations; afterward only an exact, signed replay of such a stored event is accepted so a crash between persistence and queue insertion can still resume. A new v1 event is rejected rather than entering an ordering domain without a signed sequence. Independent sites and source IDs remain independent, and an already accepted publication remains immutable history. Schema-v1 databases migrate these generations and supersessions transactionally before normal operation resumes. After every required locale has a valid signed approval, `prepare_delivery` creates one `blun.cms-localization-publication.v3` payload for the complete locale set. It includes the site and website version, source identity, signed source sequence and hash, and, for each locale, the exact target text and hash, approval ID, expiry, and a `blun.website-localization-release-evidence.v14` object. That content-free object binds the exact machine-readable release-evidence-contract SHA-256, signed approval and worker-result hashes, quality-receipt hash, canonical evidence request ID and evidence revision, and the exact current target-locale quality-profile locale, version, and digest. It then binds either a null commercial scope or the exact commercial-profile ID, locale-specific commercial quality-profile version and digest, and validated review summary including its exact review-evidence-contract digest, plus the exact current content-free offer-routing- and resolution-contract digests. The resolution-policy digest is present even when the summary is already verified, while the separate resolution result remains absent. If that summary requires targeted review, the object also binds the exact ordered dimensions, commercial profile, resolution-contract digest, resolution method, receipt hash, primary provider identity, and independent provider identity when a second model was used. The receiver proves the two provider IDs differ and rejects a missing, stale, unexpected, cross-scope, or method-inconsistent resolution before the host commit. It contains no source text, target text, amount, private offer-routing map, currency, tax wording, brand, or reviewer explanation. A CMS can therefore identify the exact evidence and contract generation, pin the advertised profile, and reject missing, malformed, or drifted evidence before replacing its current content, without treating a cross-language regex as semantic proof. The reference receiver repeats the exact general locale-quality lookup for every active read, health check, and idempotent replay. This universal binding is independent of the additional commercial quality profile. A later language, morphology, terminology, or evaluation-profile generation therefore blocks the old bundle without overwriting it; the structural tombstone path remains available. Its deterministic `delivery_id` is an idempotency key over those immutable bytes. The host-owned publication authority signs and immediately verifies the payload before the durable outbox accepts it. A partial, changed, expired, or invalid approval creates no publication entry. Outbox workers claim a delivery through an owner- and token-bound lease. The publisher must return exactly: ```json { "schema": "blun.cms-localization-publication-ack.v1", "delivery_id": "blun-cms-delivery-…", "payload_sha256": "…", "status": "accepted" } ``` `integrations/website_localization_cms_http.py` is the concrete HTTP publisher for this contract. Its endpoint is trusted deployment configuration and must not be derived from an inbound event. It requires HTTPS; plain HTTP is available only through an explicit loopback-only development option. The adapter disables redirects, obtains authentication headers from a callback for each attempt, prevents that callback from replacing protocol headers, sends `Accept-Encoding: identity`, and bounds both timeout and response size. URL credentials, query-string secrets, control characters and ambiguous duplicate critical headers are rejected before acceptance. The request body contains the exact signed publication rather than another translation format: ```json { "schema": "blun.cms-localization-publication-http.v1", "payload_sha256": "…", "publication": { "schema": "blun.cms-localization-publication.v3" }, "signature": { "algorithm": "ed25519", "key_id": "publisher-2026-09", "signature": "…" } } ``` The complete publication object remains nested in `publication`. The adapter also sends the immutable `delivery_id` as `Idempotency-Key` and repeats the delivery ID and payload hash in reserved binding headers. The CMS must verify the publication signature and hash before its atomic source-revision write. HTTP success alone is insufficient. Status 200 must contain a strictly parsed, UTF-8 JSON envelope with the exact acknowledgement above and a CMS signature over its canonical bytes: ```json { "schema": "blun.cms-localization-publication-http-ack.v1", "acknowledgement": { "schema": "blun.cms-localization-publication-ack.v1", "delivery_id": "blun-cms-delivery-…", "payload_sha256": "…", "status": "accepted" }, "signature": { "algorithm": "ed25519", "key_id": "cms-2026-09", "signature": "…" } } ``` The acknowledgement verifier is independent from the publication signer. Redirects and other 3xx responses are terminal. HTTP 408, 425, 429 and 5xx responses, network failures and malformed response transport are retryable under the existing bounded outbox policy; other non-200 statuses, wrong bindings and invalid signatures are terminal. No response body, credential or exception detail enters the durable status record. `integrations/website_localization_cms_receiver.py` is the provider-neutral reference receiver for the publication, tombstone, and health sides of this contract. Before invoking host code, it strictly parses canonical UTF-8 JSON, verifies framing and all three protocol headers, recomputes the payload and delivery hashes, and verifies the publisher signature. For a publication, it also validates every locale's approval expiry and release evidence and compares the signed payload with a host-supplied `PublicationExpectation`. That expectation binds the exact current event, site, website version, plan, source identity, source generation and hash, complete sorted required-locale set, content type, and commercial profile. The public capabilities additionally carry a separately hashed release-evidence contract with the exact field, digest, lineage, commercial-scope, and privacy rules. Every signed approval and release proof binds its exact contract digest. The runtime validates that complete contract against its canonical registry, so stale evidence and altered but self-rehashed substitutes block before host code. For commercial content, the receiver also recomputes each locale's canonical commercial quality-profile version and digest and requires the signed v7 release evidence to match it exactly. A correctly signed but partial, stale, cross-locale, or differently scoped publication is therefore rejected before any CMS write. The host supplies one commit callback. It must atomically and idempotently bind the stable `(delivery_id, payload_sha256)` pair to the expected source revision, write the complete locale bundle, and return that exact binding with status `committed`. The receiver signs `accepted` only after this receipt. A missing, different, or private-error receipt returns a stable retryable failure; a retry may invoke the callback again with the same immutable binding. This module does not provide the CMS transaction or authentication boundary, and its verified payload still contains target prose, so the host must keep it out of logs and public status. For deletion, a `TombstoneExpectation` binds the tombstone to the exact current event, site, website version, plan, source generation, complete sorted locale set, and the delivery ID and payload hash of the previously acknowledged publication. The host's delete callback must remove that complete binding atomically and idempotently, then return the exact tombstone delivery ID and payload hash with status `deleted`. The receiver signs the CMS `deleted` acknowledgement only afterward. A valid signature over a stale publication, different locale set, or different source generation never reaches host code. For publisher health, the same receiver accepts only the canonical content-free probe and the three advertised probe-binding headers. Because this request does not contain the signed publication object, the host must provide a dedicated authentication callback; its exception becomes a stable retryable error and a negative result becomes an unauthorized response. Parsing and header binding finish before authentication, while the expected callback-contract digest and host health are checked only after authentication. The host health callback must return the exact probe ID and contract digest with status `healthy`; only then does the receiver sign the protocol acknowledgement. A repeated request reaches the host with the same immutable binding, while the sender's fresh probe ID prevents an acknowledgement for an older challenge from satisfying a newer one. The receiver never adds site, locale, publication, customer, or diagnostic content to this path. For deployment, `CMSReceiverApplication` composes all three callbacks into one HTTPS-only WSGI boundary at `/v1/localization/callback` by default. This is one endpoint because the built-in publisher uses the same configured URL for publication, tombstone, and health. Before host code runs, the application requires an exact query-free `POST`, bounded explicit framing, canonical UTF-8 JSON, and host authentication. It dispatches only the three exact outer schemas. Publication and tombstone expectation resolvers receive only fully signature-verified messages, then the existing current-source and complete-set checks run before commit or deletion. All transport, authentication, resolver, and private callback failures become a small `blun.cms-localization-receiver-error.v1` response containing no website or diagnostic prose. The application does not terminate TLS or configure a proxy; the WSGI host must derive `wsgi.url_scheme` only from its trusted ingress and must redact authorization headers and verified target text from logs. Deployments without an existing atomic CMS transaction can use `integrations/website_localization_cms_receiver_store.py` as the durable reference host behind that WSGI application. Give `DurableCMSReceiverStore` a dedicated host-owned SQLite connection, the receiver's canonical `release_evidence_is_current` validator, and a closed validator backed by the configured publisher authority. The trusted CMS first calls `register_source` with its exact current source expectation, then wires the store's publication resolver, commit, tombstone resolver, delete, and health methods directly into `CMSReceiverApplication`. Resolver results are exact field mappings accepted by the same receiver validation as the public dataclasses. Publication commit repeats the complete source, locale, content-type, and commercial-profile comparison inside one `BEGIN IMMEDIATE` transaction. A newer registered source leaves the previous active bundle readable as the last-known-good value until the full replacement commits. Exact retries return the same receipt; reused generations, IDs, or hashes block. Once the new bundle is fully stored and selected, that same transaction removes the predecessor's target prose and release evidence and retains only its content-free replay binding. SQLite secure deletion is mandatory for these removals. A cleanup failure rolls back the replacement, so the previous bundle remains active. Backups and filesystem-level retention remain the host's responsibility. For deletion, the trusted host must separately call `register_tombstone` with the exact active publication ID, payload hash, generation, and locale set. A successful delete atomically clears the active pointer, removes localized prose, and retains only content-free publication and tombstone bindings for replay detection. The exact canonical publisher signature is stored beside each active payload. Startup and health verify the schema, SQLite integrity, active pointers, canonical payload and expectation hashes, that publisher signature, every locale row, current release-evidence contract, approval expiry, and tombstone state. Active rendering and exact publication replay perform the same authorization checks after every restart. Schema v1 databases migrate to v2 without fabricating signatures: legacy active rows without the original proof stay blocked and unhealthy but remain structurally deletable. Structural-only tombstone operations deliberately remain available when an approval expires or a contract advances, so stale content can still be removed. This reference store is not a substitute for an existing CMS authorization model: source and tombstone registration remain trusted host operations and its content-reading method requires the complete trusted publication expectation for the exact page generation and must never be exposed as a public status route. Looking up localized prose by site and source ID alone is intentionally unsupported. Use one store instance per SQLite connection and WSGI worker; distinct workers may use distinct connections to the same database and coordinate through the write transaction. For the complete reference deployment, use `integrations/website_localization_cms_receiver_runtime.py` instead of wiring those callbacks individually. `open_durable_cms_receiver` validates both message authorities, their separation, authentication, callback-contract hash, clock, path, and HTTPS policy before opening SQLite or creating a table. It then returns one worker-owned object that exposes the WSGI callable plus the three trusted CMS operations: source registration, tombstone registration, and generation-bound last-known-good rendering. The rendering call returns target text only when the caller's complete source, plan, website version, locale, content-type, and commercial-profile expectation matches the active signed bundle. This keeps an explicitly requested old website version available while its replacement is pending without allowing a new generation to consume stale prose. Initialization closes its connection on every store or application failure, and `close` is idempotent. Every resolver, transaction, health check, trusted registration, and rendering read uses the same reentrant worker lock. A multithreaded WSGI worker may therefore share this composed runtime without concurrent use of its SQLite connection; failures release the lock before later work. Construct the runtime after each worker process starts and never before a process fork. The runtime records its creator process and blocks every inherited store operation before attempting to acquire a possibly orphaned thread lock. Separate worker processes still require separate runtime instances and SQLite connections. The database URI form is intentionally rejected so connection flags cannot be smuggled through deployment configuration. Filesystem-backed stores additionally require a canonical absolute POSIX path in a real, service-owned directory. Every path ancestor must be root- or service-owned and not shared-writable, except for a root-owned sticky world-writable ancestor such as `/tmp`. A new database is reserved atomically with mode `0600`; an existing database must be a single-link regular file owned by the service account with that exact mode. The runtime rechecks the directory, file identity, ownership, link count, and permissions before every store operation. A symlink, hard link, path replacement, permission drift, or shared writable directory therefore blocks both callbacks and trusted rendering instead of redirecting approved target text. `:memory:` remains available for ephemeral tests only. The same adapter transports a tombstone without changing its security model. It uses `blun.cms-localization-tombstone-http.v1`, nests the exact signed object under `tombstone`, and accepts only a signed `blun.cms-localization-tombstone-http-ack.v1` envelope whose acknowledgement is exactly bound to the delivery ID and payload hash and has status `deleted`. The locale list is sorted and unique, while source and target prose are absent. The adapter also exposes an optional, content-free `check` operation for operator health. Each call creates a fresh probe ID and sends only that ID plus the SHA-256 digest of the advertised publication HTTP contract. The same authentication, HTTPS-only endpoint, redirect prohibition, transport bounds, and strict JSON parser apply. The CMS must return status `healthy` in a signed `blun.cms-localization-publication-health-ack.v1` acknowledgement bound to the exact probe ID and contract digest. Replayed challenges, a receiver implementing a different contract, or an invalid signature therefore cannot make readiness green. No source text, target text, locale, site, publication, or tombstone is included in this request. Wrong or malformed acknowledgements retry with bounded exponential backoff; explicit permanent rejections become terminal. Crashed leases are recovered, but stale workers cannot acknowledge a later attempt. Free-form transport details are stored only as SHA-256 hashes. Delivery is at least once, so a CMS adapter must make the stable `delivery_id` idempotent: acceptance followed by a crash may send the exact same signed payload again. A failed new website version never deletes or overwrites an older successful delivery. There is an unavoidable boundary after a publisher begins an external request: local code cannot retract bytes already received by a CMS. The receiving CMS must therefore compare `(site_id, source_id, source_sequence, source_revision, source_sha256)` atomically with its current source revision and reject a stale payload even if its signature is otherwise valid. It must acknowledge `accepted` only after that conditional write succeeds. This complements the local generation gate and closes the lease-to-network race without requiring a vendor-specific API. Premortem: an attacker could reuse an event ID with changed content, a partial locale set could reach the CMS, an acknowledgement could name another payload, an older event could finish after a newer source revision, or a worker could wake after its lease or approval expired. Canonical inbound signatures and collision checks block changed events; the release gate creates only complete bundles; monotonic source generations and the receiver-side revision comparison block stale publication; exact signed payload hashes bind acknowledgements; and both leases and approval expiries are rechecked immediately before delivery. Regression tests cover replay, collision, supersession, migration, partial readiness, tampering, exact acknowledgements, bounded retries, opaque failures, and crash recovery. ### Authenticated CMS webhook API `integrations/website_localization_api.py` exposes the current signed CMS change, cancellation, tombstone, status, lifecycle, and capability contracts through six strict HTTPS-only WSGI routes. The composed runtime publishes the same callable as `runtime.cms_api`; no second bridge, queue, or database is constructed. `integrations/website_localization_cms_client.py` is the matching source-side reference client for CMS and website backends. One fixed HTTPS origin and one host-owned signing authority cover all six operations. The client canonicalizes and copies native-Unicode requests before signing, performs exactly one network attempt, never follows redirects, and leaves retries to the caller's durable policy. Status and lifecycle replies must match their request ID, event, and site; mutation replies must match their immutable event identities. Capability and API-contract hashes plus the six exact ordered route definitions are revalidated before use. Failures expose only stable codes and retryability. `integrations/website_localization_cms_dispatch.py` adds the durable sending root for changed content. A host first enqueues one complete immutable change event in its SQLite outbox, then lets workers run one leased dispatch at a time. Canonical event bytes and their hash survive restart; exact re-enqueue is idempotent and changed content under the same event ID is rejected. A worker performs one client call per attempt. Retryable failures enter bounded capped backoff, permanent failures become terminal, and an expired crash lease replays the exact event. This gives remote event idempotency enough information to converge even when acceptance succeeded but the local completion commit did not. Status and health expose no source text or transport detail. Each process must open its own SQLite connection; the transactional lease coordinates those connections. `integrations/website_localization_cms_removal_dispatch.py` provides the matching durable removal root. One outbox accepts both exact source-side objects without merging their semantics: `cancellation` stops an unpublished localization, while `tombstone` requests deletion only after publication. The composite primary identity is the operation plus its cancellation or tombstone ID; the original event and source-generation bindings remain inside immutable canonical bytes. Workers call only `cancel` or `request_tombstone` for the claimed operation. Remote acceptance followed by a local crash therefore replays the same request instead of inventing a second deletion. Leases, bounded backoff, attempt ceilings, collision rejection, content-free status, and fail-closed integrity checks match the change outbox. `integrations/website_localization_cms_lifecycle_monitor.py` then provides the durable source-side completion loop. It accepts only the exact successful change-dispatch record, binds it to the canonical change hash and full remote generation, and polls the signed lifecycle endpoint until a verified terminal state. Every attempt obtains a fresh request identity from the secure client; only the poll lease—not a short-lived signed read—is replayed after a crash. Separate SQLite connections converge through transactional leases. Normal processing uses a fixed interval, transient failures use capped backoff with a consecutive-failure ceiling, and any response for another event, site, plan, version, sequence, or locale count becomes terminally blocked. Status and health retain only content-free identifiers, locale state, counts, stable error codes, and hashes; no website text or transport detail is persisted. `POST /v2/localization/changes` accepts only a complete signed `blun.cms-content-change.v2` event. Successful intake durably enqueues one exact job per locale before returning. Exact replay is idempotent; changed event IDs, reused source sequences, new schema-v1 events, and delayed superseded changes cannot become current work. `POST /v2/localization/status` accepts a separate short-lived signed request and returns only identifiers, counts, lease/retry state, stable errors, and hashes. The signed site and original event credential must match, preventing cross-site status access even when a verifier recognizes multiple credentials. All routes reject plaintext transport, query strings, transfer encoding, ambiguous or oversized JSON, and invalid framing. Status revalidates the stored event signature, current source generation, exact plan/job/locale identities, and every successful result before returning a complete response. Superseded, missing, altered, or wrong-scope state blocks fail-closed without exposing source text, target text, provider prose, signatures, or credentials. The full public request, response, deployment, and failure contract is documented in [CMS localization webhook API v2](WEBSITE_LOCALIZATION_API.md). ## Commercial price and offer profile Select `content_type: "commercial"` in the trusted CMS/backend for pricing, offers, subscriptions and their contextual CTAs/conditions. This adds the versioned `translate-native.commercial.v13` profile plus one exact `translate-native.commercial-locale-quality-profile.v2` object to the job payload, job ID and plan ID; the existing seven types retain their previous payloads and IDs. It is available for every planner locale, including `mt-MT` and `fi-FI`. The public skill's [commercial guide](../translate-native/references/commercial-localization.md) applies to all languages, with no hardcoded project prices, brands or products. For every review dimension, the private evidence must name exactly one verdict for each registered offer in registry order. The worker derives the global verdict from that matrix and requires offer-bound items for every equivalent, changed, or uncertain entry; evidence for one tier therefore cannot silently stand in for another tier. When any offer-local verdict remains uncertain, the content-free review summary retains the affected dimension and zero-based position in the private offer registry. It never publishes configured offer identifiers. A qualified human or independent model resolution must acknowledge the exact same ordered scope; missing, duplicated, reordered, cross-dimension, or out-of-range entries block before publication. Global uncertainty remains representable with no offer positions when the evidence cannot safely identify an offer. The 24 locale objects are not aliases for one universal prompt. Each has a distinct version and canonical SHA-256, binds the corresponding general locale quality generation, preserves that profile's native, fidelity, adversarial and institutional-reference focus, and adds the ten commercial checks. The worker reconstructs the object before provider access and supplies it to transcreation, source-hidden native review and source-aware fidelity review. Its version and digest are retained in the result's signed quality-profile binding. Changing either locale policy or the generic commercial generation therefore invalidates jobs, cache entries, review receipts and publication authority. Each object also embeds `translate-native.commercial-rendering-reference.v1` from the tagged Unicode CLDR 48 JSON release. It records the resolved CLDR locale, default and native numbering systems, grouping threshold, decimal and grouping symbols, and the standard decimal, percent, currency, ISO-currency, approximation, limit, and range patterns. The explicit `de-AT`, `en-IE`, and `pt-PT` regional files are used where they exist; other profiles use the applicable language parent. Non-breaking and narrow non-breaking spaces remain exact Unicode data in the canonical profile and its digest. These patterns guide native rendering; they do not prove semantic fidelity. Equivalent number words, written percentages, and digit forms are permitted, while exact values and currency identities must survive without rounding or conversion. Any ambiguity is routed to an independent model or qualified native-domain review and remains blocked until resolved. At the outer CMS dispatch boundary, `GET /v1/localization/cms-submission-dispatch/commercial-profile` exposes this same complete profile and 24-locale rendering registry without project content. The separately scoped response is bound to both the public dispatch capability and the live website capability generation. A CMS can therefore discover the exact amount, currency, discount basis, qualifier, tax, billing, commitment, renewal, cancellation, condition, and offer-assignment rules it must preserve without receiving publication authority or any configured price, brand, or product value. The profile now embeds a separately versioned and hashed `review_evidence_contract`. It gives CMS and provider adapters the exact closed report fields, limits, Unicode code-point span rules, offer containment, relation semantics, ten-dimension order and verdict invariants without exposing project prices, source or target text, actual spans, brands, or reviewer prose. Capability discovery rejects a missing, altered, reordered, or self-rehashed contract. The contract validates evidence structure only, grants no publication authority, and leaves uncertain meaning on the independent-review route. The three provider calls stay ordered: transcreation, source-hidden native editing, source-aware fidelity. Commercial fidelity additionally returns `commercial_review` with the profile schema, `coverage` (`complete` or `uncertain`), a canonical `offers` registry, and `checks` for `amount_currency`, `discount_basis`, `qualifiers`, `tax_status`, `billing_interval`, `commitment`, `renewal`, `cancellation`, `conditions`, and `offer_assignment`. Each registered offer has a unique ID and ordered, non-overlapping source and target regions; multiple discontiguous regions may bind linked footnotes, but no region may overlap another offer. Every check has `status` (`equivalent`, `not_present`, `changed`, `uncertain`) and `items`; each item has `offer`, `relation` (`matched`, `source_only`, or `target_only`), `source_span`, `target_span`, and `explanation`. Spans are zero-based Unicode code-point offsets with an exclusive end and must remain inside the named offer's declared regions. A one-sided item uses `null` only for the side that is absent, so an omitted condition and an invented target claim can be represented without fabricating a counterpart. The illustrative response shape and dimension guidance are supplied alongside the complete, separately hashed `review_evidence_contract` in each commercial fidelity request. The worker verifies that contract against the installed public commercial profile before any provider access. It remains absent from transcreation and source-hidden native review, preserving the independent first quality stage. Equivalent checks require matched evidence; absent dimensions require empty items, and equivalent `offer_assignment` evidence names every registered offer exactly once. A dimension-level changed or uncertain verdict requires at least one specific evidence item, while globally uncertain coverage may remain span-free instead of inventing a location. Changed terms, missing dimensions, invalid relations/spans or a normal PASS without the commercial report block the worker without a publishable result. Uncertain coverage, an uncertain dimension or an all-absent report instead preserve the candidate as a low-confidence fidelity result. That result is fail-closed and requires exactly one independently verified second-provider or qualified-human review before signing; it is neither an automatic retry nor permission to publish. The evidence request and independent verifier both receive the bound commercial profile and policy context. The old known-good translation remains. Do not classify legal text as commercial to bypass the legal human-review gate. The full commercial response hash stays in the normal quality-pass receipt. Plan v3 and job v3 also carry the exact current review-evidence-contract SHA-256. That digest participates in every commercial job ID, idempotency key, and plan ID, and the worker joins it to the complete fidelity-request contract before provider access. A contract-only policy change therefore creates new work identity and cannot reuse a stale queue or translation-memory entry. The content-free result summary uses `translate-native.commercial-review-summary.v6`; the authenticated capability response publishes its exact separately hashed machine contract, including the ordered allowed dimensions and the invariant between status and unresolved dimensions. Its evidence digest covers a versioned canonical binding of the commercial profile, exact advertised review-evidence-contract SHA-256, exact UTF-8 source and target hashes, and complete review evidence. Quality-evidence request v13 and receipt-binding v9 carry that exact summary. Every commercial evidence request now also carries the exact public routing-contract SHA-256, including verified results without a private route, so the evidence provider can issue a receipt for the same binding later enforced by the verifier and signed release. The digest participates in the deterministic request identity; non-commercial requests require `null`. When review is required, they additionally carry a private `translate-native.commercial-review-routing.v2` context that maps each opaque offer index to its exact ordered source and target regions. It contains no configured offer IDs, text, prices, brands, or reviewer prose, is validated against both complete texts before network access, and participates in request and receipt identity. Its required `contract_sha256` must match the separately advertised machine-readable routing contract, whose public shape fixes Unicode offset, exclusive-end, length, order, overlap, privacy, and trust-boundary semantics without exposing an actual route. The route itself is deliberately absent from CMS release evidence. The unresolved quality-evidence request carries the complete content-free routing contract beside the route. Its deterministic identity covers both, and the HTTPS adapter reconstructs the canonical contract before authentication or transport so an external reviewer need not rely on separate discovery. Adapters can therefore route a reviewer to the affected offer without exposing project configuration publicly, while rejecting unknown, reordered, contradictory, or transplanted scope. As before, the host must verify an independent quality receipt before signing. Schema validation does not prove that a model's semantic findings are true or complete. The receipt verifier must validate evidence held by the trusted host; the worker retains hashes, not reviewer prose. No new provider is hardwired. Premortem: counting digits could reject native number words yet accept swapped tariff prices, while treating uncertainty as an ordinary PASS could bypass the release gate. The profile instead requires per-offer semantic comparison, allows equivalent locale forms, and converts unresolved evidence into a bound low-confidence review route. Keeping source evidence out of the native pass prevents source-shaped copy from receiving an artificial advantage. Version-bound job IDs prevent old policy/cache reuse. Tests exercise distinct canonical profiles across all 24 locale routes, ten defect dimensions, native digit/number-word representations, multiple offers, source blindness, locale-profile tampering, queue terminal failures and the actual worker-to-signed-publication path. Scripted adapters test enforcement, not real native quality or DeepL superiority. ## One-transition service loop `integrations/website_localization_service.py` composes the queue runner, quality-evidence coordinator, signed release store, and CMS outbox into one host-callable tick. It opens no database, socket, credential, or model by itself. The host injects the provider and asset resolvers, evidence adapter, receipt verifiers, signing authorities, publisher, worker identities, clock, and durable stores. Each tick performs at most one externally active pipeline step. A due signed CMS delivery has first priority; otherwise the service advances at most one completed locale through independent evidence and signed approval; otherwise it claims and processes at most one translation job. Active leases and backoff windows remain untouched. An existing delivery that is not yet due and an evidence request waiting for retry do not prevent unrelated queued work from advancing. Successful delivery removes that event from future scheduling. The return schema `blun.website-localization-service-tick.v1` contains only the phase, status, stable event/plan/job/delivery IDs, target locale, attempt, and stable error code. It never contains source or target text, reviewer prose, receipts, signatures, provider exceptions, or transport details. A blocked signature, database, queue, evidence, or publication transition cannot fall through to a weaker phase in the same tick. The runner accepts the narrow `LocalizationQueue` transition contract rather than a process-local Python class identity. This matters because the public files are independently loadable adapters: a queue created by the CMS bridge can now be passed to the runner without copying state or opening a second database. The host remains trusted and the queue itself still validates every payload, lease, hash, and transition transactionally. Premortem: a scheduler could publish before all locales are signed, call a translation provider after an evidence failure, leave a signed intake stranded before queue insertion, starve a ready outbox behind a large queue, leak prose in operational status, or duplicate work after a restart. Tombstone and delivery priority, one verified intake recovery per tick, immediate fail-closed return, content-free outcomes, and reuse of the existing durable leases and idempotency keys address those failures. End-to-end tests count the provider, evidence, and publisher calls across recovery, translation, approval, and delivery ticks; they also cover the API retry ceiling, cancellation exclusion, stored-event tampering, adapter failures, and an idle completed service. ## Durable service supervisor `integrations/website_localization_supervisor.py` turns the host-configured service tick into a long-running, restartable process without taking ownership of databases, credentials, provider selection, signing keys, or signal handling. The host supplies a dedicated SQLite connection, the configured tick callable, a stable worker ID, and—when running continuously—a stop predicate. The supervisor invokes exactly one service tick at a time and checks for a stop only between those atomic units. The supervisor uses one transactional, expiring lease. A second process sees a live lease and performs no work; after a crash, another process may claim only after the exact expiry time. Lease completion is bound to both worker ID and a fresh random token, so an old process cannot overwrite a recovered process's schedule or heartbeat. The service tick's own narrower queue, evidence, and delivery leases remain the final protection for any external operation that outlives the supervisor lease. Successful active work receives a short configurable delay, an idle result a longer delay, and `blocked`, `failed`, or `retry_wait` results bounded exponential backoff. Continuous operation caps sleeps by a separate stop-poll interval, allowing prompt graceful shutdown without interrupting a tick. Durable status reports the next tick, live or recoverable lease state, consecutive blocked count, last start/finish time, phase, status, and stable error code. It never returns the lease owner or token, customer content, provider output, exception text, receipts, signatures, or secrets. When attached to `LocalizationHealthMonitor`, a configurable staleness window also marks a long-overdue ready tick as `supervisor.heartbeat_stale`; this prevents an exited process from appearing healthy merely because no lease is currently held. Hosts should keep the supervisor connection on durable local storage, use a lease longer than the maximum expected tick duration, install their normal process manager's stop signal into the predicate, and treat `supervisor.tick.unhandled`, altered state, or an expired lease as degraded health requiring operator attention. The library deliberately does not open a socket, daemonize itself, modify an OS scheduler, invent a model, or publish a partial localization. Premortem: duplicate supervisors could call providers concurrently, a crash could retain ownership forever, a failing adapter could create a hot loop, a recovered old process could overwrite newer state, or an exception could copy customer prose into operations data. Transactional token-bound expiring leases, bounded delays, stale-completion rejection, structural tick validation, fixed exception codes, and an overdue-heartbeat check close those paths. Tests use two SQLite connections to prove exclusion and crash recovery, then cover backoff caps, graceful stop, state tampering, malformed results, invalid clocks, and prose redaction. ## Provider-neutral runtime composition `integrations/website_localization_runtime.py` is the composition root for a host that wants to operate the complete service rather than assemble each adapter manually. It creates one canonical queue, signed release store, CMS bridge, durable quality-evidence store, service tick, supervisor, and health monitor. `run_once`, `run_forever`, and `health` all address those same object instances and durable records. This avoids Python class-identity mismatches between independently loadable adapter files while retaining their public structural contracts. The host supplies five distinct `sqlite3.Connection` objects: queue, release, CMS, evidence, and supervisor. An optional monitored benchmark campaign adds a sixth connection plus its exact policy, campaign ID, evidence verifier, and staleness threshold. Monitor-only configuration remains supported and performs no benchmark work. Both monitor-only and executing configurations may call `benchmark_campaign_status` and `load_benchmark_report`; they delegate only to the store's content-free status and read-only verified report paths. A runtime without benchmark configuration returns `runtime.benchmark.unavailable`, and unexpected adapter failures are reduced to the content-free `runtime.benchmark.status.invalid` or `runtime.benchmark.report.invalid` boundary code. To execute the same campaign, supply the exact `benchmark_execution` mapping. It adds separate `candidate_connection`, `baseline_connection`, `native_reference_connection`, and `review_connection` stores, making ten distinct connections in total. The remaining required fields are `candidate_route_id`, `baseline_route_id`, `native_reference_route_id`, `reviewer_route_id`, `assets_resolver`, `candidate_provider_resolver`, `baseline_acquirer`, `native_reference_loader`, `reviewer`, `native_reference_verifier`, `blinding_key`, `worker_id`, `max_attempts`, `lease_seconds`, `retry_base_seconds`, and `retry_max_seconds`. Extra, missing, malformed, reused, or transaction-active values block before schema construction. The benchmark evidence authority must both sign and verify, and the supervisor lease must strictly exceed the configured benchmark lease. An executing composition also rejects an already expired policy before any of the ten stores creates or migrates a schema. Monitor-only composition may load an expired campaign so health can expose its blocked state, but it cannot load that campaign's report as current evidence. The composition root constructs the canonical `WebsiteLocalizationBenchmarkRuntime`; callers cannot replace its durable input assembly with an unrestricted callback. All connections may point to host-chosen durable files but must be distinct because the stores have independent schemas, transactions, and migration rules. The runtime neither opens nor closes them. It also never reads a configuration file, environment variable, credential, signing key, or network endpoint. The same composition root binds its approval and publication authorities into the tenant-facing `runtime.cms_api`. It accepts signed change events, exact signed cancellations of unpublished work, and exact signed tombstones for acknowledged publications. Before submitting content, a CMS can use a separately signed read to discover the exact current 24-locale registry, content types, quality phases, schema versions, and locale-profile hashes as one canonical capability object. In addition to durable change intake and per-locale queue progress, the API exposes a purpose-bound lifecycle read that revalidates release readiness and the signed CMS outbox. A tenant can therefore distinguish processing, missing approvals, readiness, publication retry, blocked publication, terminal failure, and acknowledged publication without receiving source text, target text, receipts, signatures, or service-wide site data. Neither read performs a state transition; the complete public contract is in [`WEBSITE_LOCALIZATION_API.md`](WEBSITE_LOCALIZATION_API.md). Service-wide HTTP health is disabled unless the host supplies an explicit `health_http_authenticator`. With that capability, the same composition root exposes `runtime.health_http`; optional `health_provider_probe` and `health_publisher_probe` capabilities are bound to that reader and cannot be configured on their own. The publisher probe must be the same object as the runtime's delivery publisher, so a second endpoint cannot mask failure of the real callback. All values are validated before any store creates or migrates a schema. The operator endpoint is distinct from signed tenant CMS progress because its content-free report can contain identifiers for every configured site. Its complete authentication, response, and failure contract is documented in [`WEBSITE_LOCALIZATION_HEALTH_HTTP.md`](WEBSITE_LOCALIZATION_HEALTH_HTTP.md). When configured, the existing content-free health report gains a `benchmark_campaign` component. Full `benchmark_execution` configuration also adds `benchmark_reviews`, bound to the same durable review store and reviewer route used by the executor. For every succeeded campaign case, the monitor requires exact stored request and response evidence for both ordered passes and reverifies each artifact. Missing, mismatched, tampered, or unverifiable review evidence blocks the whole health report even when the campaign result itself remains valid. Output is limited to stable reasons and aggregate counts. Its overall status becomes degraded for an expired lease or a stalled actionable campaign and blocked for failed or unverifiable work. The localization service supervisor does not execute benchmark cases for monitor-only configurations. With `benchmark_execution`, each supervised tick still runs the customer publication pipeline first. A delivery, release, evidence, or translation transition returns immediately and the benchmark executor is not called. Only an exact `idle` customer result may advance at most one benchmark case. The same token-bound outer lease guard is passed through the campaign and its durable candidate, baseline, reference, and review operations; losing that lease blocks before the next external boundary. A campaign with no currently actionable case preserves the ordinary idle result. Benchmark success, bounded retry, terminal failure, and stable error code use the existing content-free supervisor tick schema. Premortem: a mirrored database could yield inconsistent status, a dead worker could leave a lease that looks active, terminal cases could hide behind overall progress, status could leak reviewer prose, an incomplete campaign could be mistaken for a passed comparison, stored reviews could disappear behind a still-valid case result, or background evaluation could delay a real publication. Ten-store validation, customer-first scheduling, strict lease hierarchy, snapshot verification, lease and staleness reasons, exact cross-store review matching, per-row attestation checks, code-and-count-only output, and a separate `report_ready` flag close those paths. The supervisor lease must be strictly longer than every effective translation, quality-evidence, and CMS-delivery lease. The runtime checks this hierarchy before any component creates or migrates a schema. Its default supervisor lease is 360 seconds for the three 300-second operation defaults. Custom values remain valid only when the supervisor continues to outlive the longest operation lease. Immediately before cache or adapter resolution, each model phase, quality-evidence acquisition, and CMS publication, the child path renews the exact token-bound outer lease and fails before the external call if that lease was lost. An expired outer lease cannot finish a tick even when no replacement has claimed it. Together these checks prevent a second service instance from taking the outer lease while the first instance still owns a legitimate inner operation lease. Each external adapter must additionally impose a transport deadline shorter than its operation lease; deterministic request and delivery identifiers still cover an uncertain remote acceptance at that deadline. The `dependencies` mapping must contain exactly the configured provider and asset resolvers, evidence provider, quality verifier, inbound event verifier, approval and publication authorities, CMS publisher, three worker IDs, and an evidence revision. Optional values are limited to the documented lease, retry, attempt, approval-expiry, human-review verifier, and independent-model-review verifier settings accepted by the service tick. A host-supplied result cache is rejected before schema creation; the runtime inserts only its own signed local translation-memory adapter. Unknown and missing keys, invalid capabilities, identifiers, retry ranges, duplicate connections, and already-active host transactions block before any store schema is created. The mapping is copied and frozen; runtime status and `repr` never include its objects or values. Supervisor policy is supplied as an exact plain mapping rather than a Python class instance, so loading the public supervisor and runtime files under different module names cannot break configuration. The runtime constructs its own canonical policy after validating all six positive, finite timing values. Its health method always reuses the event, approval, and publication verifiers that were validated during composition; a caller can add only the optional provider health probe and check time. Premortem: independently loaded modules could reject the same bridge, one SQLite handle could mix incompatible state machines, a missing publisher could be discovered only after a job is claimed, mutable configuration could swap a signer during operation, or diagnostic formatting could reveal a secret. Canonical construction, structural health contracts, pre-mutation validation, five distinct connections, a strict outer-before-inner lease hierarchy, a frozen dependency copy, and a fixed content-free representation close those paths. An end-to-end test sends one signed event through Finnish translation, evidence, approval, publication, supervisor, and health using the single composed runtime; separate tests prove invalid capabilities and connections cause no schema writes. ## Read-only health and readiness monitor `integrations/website_localization_health.py` gives operators one provider-neutral, content-free view across the queue, signed translation memory, quality-evidence state, CMS events, publication outbox, and configured model endpoints. It accepts the same host-owned event, approval, and publication verifiers as the runtime, optional `ProviderHealthProbe` and `PublisherHealthProbe` capabilities, plus the coordinator's optional `QualityEvidenceStateStore`. A check performs no repair, retry, lease transition, signing action, or content publication. When the publisher probe is configured, it performs exactly one content-free CMS callback challenge. `integrations/website_localization_health_http.py` makes that exact report available to a separately authenticated service operator. It authenticates before invoking the monitor, requires HTTPS and an empty query-free request, and validates the complete returned report again before serialization. A valid blocked assessment uses HTTP `503`; malformed monitor output or private exceptions are reduced to stable content-free errors. No endpoint exists when the runtime lacks the explicit operator authenticator. The provider probe receives only `provider_id`, `model_id`, and `model_version`—never source text, target text, glossary terms, or reviewer findings—and must return exactly: ```json { "schema": "blun.localization-provider-health.v1", "provider": { "id": "customer-llm", "model_id": "king", "model_version": "2026-08-29" }, "status": "healthy" } ``` For every check, the monitor verifies every configured SQLite schema and database, queued payload and result hashes, evidence-to-event/plan/job/result bindings, deterministic evidence request IDs, stored approval bytes and signatures, authenticated CMS events, publication payload hashes and signatures, tombstone request and delivery bindings, live lease times, and approval expiry before pending publication. Missing or malformed provider probes, signature failures, tampering, and unreadable state make the report `blocked`. A configured publisher probe also adds the `cms_publisher` component; an unavailable, malformed, unsigned, or contract-mismatched callback blocks it without exposing transport details. Recoverable operational state such as an expired evidence or worker lease, failed evidence review, failed locale, retrying delivery, or an expired current approval is `degraded`. A live evidence lease and ordinary pending work remain healthy. Each website version reports one lifecycle state: `cancelled`, `processing`, `localization_failed`, `awaiting_approval`, `ready`, `publishing`, `publication_failed`, `published`, `deleting`, `deletion_failed`, or `deleted`. The report includes only site, version, plan and event identifiers, counts, locale names, and stable failure codes. Source and target text, exception messages, provider responses, receipts, and transport details are never returned. Stable queue and outbox errors remain actionable, while free-form details stay represented only by their stored hashes. The separate `evidence` component reports pending, leased, retrying, succeeded, and failed counts plus stable reasons such as `evidence.lease_expired` or `evidence.review_failed`. For a fully executing benchmark, the separate `benchmark_reviews` component is equally observational. It scopes review rows to the active policy and route, reverifies their immutable attestations, and compares them with the two pass hash pairs referenced by every succeeded case. Historical rows remain visible only as a count and cannot satisfy current requirements. Neither this check nor its error path calls an adapter or returns reviewer prose or content hashes. Premortem: a dashboard could report healthy after stored bytes were altered, mutate leases while merely observing them, or leak customer content through a provider exception. The monitor rechecks canonical bytes and isolated signatures, regression-tests that SQLite `total_changes` stays constant, and reduces all external failures to fixed codes. Tests also cover queue and CMS tampering, altered evidence schemas and bindings, live and expired evidence leases, stable evidence failures, expired approvals, missing providers, partial work, retrying acknowledgements, ready bundles, and successful publication.