Release

Latest signed assistant evaluation

These hashes intentionally differ: the 40-character Git commit identifies source code; the artifact-set, catalog and report values are separate SHA-256 identities. Verification on this page means the signed report embeds the former identities exactly and its own full digest matches the release tag; it does not rerun or independently rescore the evaluation.

Code, legal data, retrieval artifacts and assistant behavior are one release unit. A deployment is not production merely because a container started.

Open the release diagram at full size

State machine

Why this design? A zero-traffic candidate can be tested against production-shaped services without changing the reader's route. Keeping the exact former production revision makes rollback an identity selection, not a rebuild that might fetch different bytes.

identities != signed_evaluation ? leave_traffic_unchanged : promote_once_and_retain_previous

maxInactiveRevisions is one in steady state and two only while a candidate waits. Azure Container Apps has no supported per-revision delete. An unresolved newer candidate cannot be discarded by lowering the limit without risking the older valid rollback, so cleanup follows identity and creation order rather than age.

Evidence before traffic

The deploy workflow creates a zero-traffic revision from the exact image and signed artifact set, then checks readiness, Model Context Protocol (MCP), Luxembourg and European Union (EU) search. The assistant evaluation binds the frozen cases, candidate, typed outcomes, latency and cost to a signed report under separate project-owner review. Only the traffic workflow may revalidate those records and promote; no automated actor approves its own output.

This page does not hard-code mounted state: runtime evidence supplies the active identities and capabilities. The traffic workflow also requires target and rollback to remain at min=max=1; quotas, idempotency and thread state must be externalized before multiple replicas are allowed.

Release evidence chain

This is the complete continuous integration and continuous delivery (CI/CD) chain at the level where an operator can decide whether traffic is safe. The detailed workflow and script mechanics stay in the linked runbooks rather than being copied into this dossier.

Status legend: Built means the implementation and deterministic tests exist; Measured means the named frozen artifact or result was reproduced; Quarantined means activation is denied by its gate; Next means exact-release evidence or an operator action is still outstanding. These labels describe the evidence cited here, not a claim about an uninspected live revision.

The offline retrieval benchmark and live assistant evaluation answer different questions. The first uses 200 fixed judgments and deterministic metrics to decide whether hybrid retrieval may activate; it does not call an answer model or a model grader. The second uses 25 natural-language cases against the real Azure-backed candidate and a separately authenticated release grader to test planning, typed execution and bounded final responses.

Why this design? Keyword retrieval remains the production default because a semantic model is a release artifact, not a configuration preference. Hybrid mounts only when the exact signed database, vectors, encoder and benchmark evidence pass together; a failed or missing result keeps the capability quarantined without weakening deterministic search.

Why this design? Every stage pins exact commits, digests and byte lengths because a tag, cache hit or protected branch can move after a build starts. Navigation may follow main; release authority comes only from the immutable identities recorded in signed evidence.

One article, followed end to end

This is the whole claim of the product in one table. It follows a single provision, Article 6 of the General Data Protection Regulation, from the bytes the publisher served through to the citation the interface renders. Every step carries the SHA-256 of what it produced, so any link in the chain can be recomputed instead of believed, and the right-hand column states what that step does not prove.

It was reproduced from the frozen EU database whose file SHA-256 is f827e089bddff64709926af4341bc0ddbfbef829a5c3e29400754aec3b649fd9. It is measured local evidence for that exact build, not a claim about any signed release.

Assistant evaluation gate

Evaluation flow

Server-Sent Events (SSE) carry the versioned intermediate contract; the equal terminal object is the authoritative completed response.

Question -> resolve identity -> Plan once -> validate or correct once -> freeze -> execute typed tools -> typed SSE and terminal result -> optional runtime prose check -> deterministic release checks -> separate release grade -> signed promotion gate

Why this design? One bounded correction recovers a malformed plan before it can touch legal tools, while the freeze prevents a model from adapting its legal request after seeing results. This keeps planning useful without creating an observation-driven agent loop.

plan = validate(first_proposal) ?? validate(one_corrected_proposal)
freeze(plan); execute_in_user_order(plan) // no observation, no replan

The Runtime grounding judge checks only optional generated factual prose during an ordinary request and falls back to the typed result. The separate Release grader receives the frozen question, rubric, bounded reply, typed operations and trace. Before grading, the deterministic runner checks tool arguments, legal and transport outcomes, UI effect, model identity, tokens, latency and stream equality. It reads typed SSE plus the matching terminal object—not Azure logs or model chain-of-thought—and the signed report omits prompts, legal text, raw tool payloads and free-form grader reasons.

Verified limits

These are present release boundaries, not generic risks. A limit stays visible until the named evidence exists; a model answer cannot waive it.

Operational thresholds are detailed under limits and scale, retrieval activation under local hybrid retrieval, dated gaps under known defects, and permanent guards derived from failures under incidents.

Container registry and Blob retention

The Azure Container Registry is shared and still has a legacy role-based access control (RBAC) boundary. Broad digest deletion is rejected because Lex cannot prove that another application does not pull a digest. The clean target is a dedicated registry or an audited move of every shared consumer to repository-scoped attribute-based access control (ABAC) and managed identities; only then can an exact-digest allowlist become an automated deletion plan.

Private Azure Blob staging objects have a narrower ownership proof. They are disposable coordination records, not the canonical release. The publisher may delete only the exact create-only staging names it created, with matching ETags, after the GitHub Immutable Release assets and signature have been downloaded and matched by hash and length, or after a failed draft has been reconciled. Canonical GitHub release tags and assets are outside Blob cleanup entirely. Moving the canonical boundary to Azure immutable write-once, read-many (WORM) storage is a future option only when retention or compliance requirements justify a separate architecture decision and migration evidence.

Mounted release evidence

The release model above is the invariant. This table reads process configuration and verified mounted indexes at request time. It reports the revision's identities and capabilities; signed promotion receipts separately prove whether traffic was authorized.

Mounted index identities

Mounted total: 2,652 works and 7,022 dated versions. Artifact verification remains a distinct job on Verify artifacts.