# Witness v3 — Constraint Authorship, Replay, and the Closure of an Emission Vector **Status: v3.0 — FROZEN 2026-08-07. Owner-accepted. No further edits to this artifact; corrections only as v3.1/errata.** **Date: 2026-08-07 · System: FCAL production (realitylayer.tech) · Oracle: GERIATRIC_BEERS_V1** --- ## What this document is This is the third witness document in a series examining a specific failure class in LLM-proposer / deterministic-oracle architectures: **a value that determines a verdict entering the authoritative input without a provable author.** Witness v1 and v2 established the finding at the record level. This version closes the investigation: it reconstructs the origin path of the records and corroborates it against deploy history, demonstrates the mechanism under a known input, documents the closure of the emission vector in production, and states honestly what remains unresolvable. Every material evidentiary claim below is grounded in stored record content, deploy history, a content hash, source inspection, or reproducible execution. Where a claim cannot rest on those, it is marked as unresolved — that marking is itself part of the finding. --- ## 1. The three records and their origin path On 2026-08-01, between 10:46 and 10:50 (EEST), three audit records were written to the production audit sink by the GERIATRIC_BEERS_V1 oracle: | Record (suffix) | Full ID | Patient age | Decision core hash | |---|---|---|---| | 5f0ja9 | `aud-20260801T074655201-geriatric-beers-v1-5f0ja9` | 74 | `29b164d1…` | | n1rwnc | `aud-20260801T074837432-geriatric-beers-v1-n1rwnc` | 70 | `5b2733ed…` | | pmbxmz | `aud-20260801T075017512-geriatric-beers-v1-pmbxmz` | 74 | `29b164d1…` | All three share the same oracle `runtime_hash` (`173063376aa4fb0b02408550e2a2ad18d267d4e51781b341c9e5c186cac13a63`) and the same `constraint_snapshot_hash` (`822fef15a39aab520ec640f424d5d4d1773c957146ae4d3851d7da9c6c97bc54`). In each record, `input_spec` contains the decisive pair `beers_threshold_age_years: 65` and `action_at_or_above_threshold: "contraindicated"` — values that were **not** authored by any registered constraint source. That pair is the subject of this witness. **Value-level invariance.** Across the three records, one input field moved: patient age varies 74 → 70 → 74. The decisive pair never moved — it is value-identical in every record, and no record names a source for it. A field that varied record to record sits next to a verdict-determining pair that did not, with nothing in the record distinguishing their origins. A precision note this record set itself forces: the shared `constraint_snapshot_hash` does **not** establish the pair's invariance, because the pair resides in `input_spec`, not in the constraint basis. The invariance is established at value level, by comparing the three stored input_specs — a manual forensic step that a per-entry provenance contract would have made unnecessary. **Origin path, reconstructed and corroborated against deploy history.** The Netlify deploy record for the site shows: - **2026-07-31 17:39** — deploy (permalink `6a6cb38be38a642bf2bf041e--reality-layer.netlify.app`): a gate fix. This version contains **no** constraint-claim scrub. Its SYSTEM_PROMPT permits the proposer to emit Beers constraint claims. - **No deploys** between 2026-07-31 17:39 and 2026-08-01 20:17. The 10:46–10:50 window falls entirely inside this gap. The ordering is robust to timezone interpretation of the deploy timestamps: 31.7. evening precedes 1.8. morning under both EEST and UTC readings. - **2026-08-01 20:17** — deploy: scrub v1 (`CALLER_ONLY_CONSTRAINT_CLAIMS` removal + "DO NOT EMIT" directive). - **2026-08-01 21:07** — deploy: recursive extension of the scrub (phase 4). This is the current production file, hash-verified: `0a56324ebc105bdeb95fb4d617d5043044a82fcbcdd31998337c4c19659524f3`. Therefore: the evidence is consistent with the records having been produced through the **ordinary pre-scrub chat path** (fcal-ask → fcal-chat bridge → dispatch), and the known alternative paths investigated in section 5 were each excluded by a concrete check. No evidence of a bypass or anomalous write path was found. This is an exclusion-based reconstruction, not a positive per-record route attestation — the records themselves carry no route provenance, which is one more instance of the gap this witness documents. An earlier working hypothesis — that the scrub was already in production at record time, implying a scrub-evading write path — was **falsified** by this deploy history and is documented in section 5. ## 2. Authorship: unresolvable for the originals, demonstrated for a known input **The original three.** The question texts that produced the three records were not retained by any log path (the bridge logs statuses and counts, not message content). Two incompatible authorship stories therefore fit the same stored evidence: the decisive pair may have been stated in the user's question, or written by the proposer model. **Constraint authorship is unresolvable from the record.** This is not a gap in the investigation; it is the finding. A per-entry provenance contract would have made the question answerable from the record alone. Its absence is what this witness series exists to document. **The mechanism, demonstrated.** On 2026-08-07 at ~16:21 UTC, the archived 31.7 deploy was executed directly via its deploy permalink (Origin header set to `https://realitylayer.tech` — the same origin the bridge itself presents in resolver calls). The input was chosen so that it **contains neither the threshold nor the action**: > "78-year-old patient is prescribed diazepam for sleep. Is this admissible?" Result: GERIATRIC_BEERS_V1 → **EXTINCT**, with `input_spec` containing `beers_threshold_age_years: 65, action_at_or_above_threshold: "contraindicated"`. Same `runtime_hash 173063376…`, same `constraint_snapshot 822fef15…` as the original three — same oracle, same constraint state. Because the input is known, this run proves what the originals could not: **the proposer model wrote the decisive pair.** An unprovenanced constraint assertion was promoted into authoritative oracle input, and the oracle — correctly, deterministically — adjudicated it as if it were a constraint. The finding is about authority, not content: whether the values happen to be clinically defensible is irrelevant to whether they were authorized to determine the verdict. **Reproduction exhibit:** `aud-20260807T162106187-geriatric-beers-v1-0yvwlk` (decision core `43c11948…`). It is held strictly apart from the original three: it demonstrates the mechanism under a known input; it does **not** certify what the original inputs contained. ## 3. Closure of the emission vector The investigated chat-path emission vector was closed in production by two deploys on the evening of 2026-08-01: 1. **20:17 — scrub v1.** `CALLER_ONLY_CONSTRAINT_CLAIMS` (`proposed_geriatric_beers_drug_list`, `drug_interaction_constraint_list`) removed at claim-type level before all resolvers and dispatch, plus an explicit "GERIATRIC BEERS — DO NOT EMIT" SYSTEM_PROMPT directive. Single call site, single-pipe flow — audited in the current production file. 2. **21:07 — recursive extension** of the strip (current production, `0a56324e…`). The two layers are not equivalent, and the distinction matters to this witness's own thesis. **The deterministic claim-type scrub is the enforcement control; the DO NOT EMIT directive is defense-in-depth at the proposer boundary** — a proposer instruction, not an authority boundary. Treating prompt discipline as enforcement would be exactly the category error Finding D documents. **Production control, 2026-08-07.** Same day as the reproduction test, the live production path (realitylayer.tech/fcal-ask) was probed with a Beers-relevant (diphenhydramine) question. No Beers constraint reached adjudication, and the coverage gap remained visible rather than papered over: **when the model may no longer supply the constraint, the system reports the gap instead of adjudicating.** That is the fail-closed contract working. ## 4. Determinism at three points The same oracle, under the same constraint snapshot, across three distinct evidentiary situations: 1. **Organic hash twins.** Records 5f0ja9 and pmbxmz — produced minutes apart from independent runs, with no coordination — share an identical `input_spec_hash` (`2e7f6245…`) and an identical decision core (`29b164d1…`). This also confirms, in production rather than by design claim, that timestamps do not leak into the decision core. 2. **Variant input.** The decision core binds oracle identity and version, runtime hash, input_spec, constraint basis and provenance, and the verdict core. With the oracle runtime and constraint snapshot held constant across all three records, the age-70 input (n1rwnc) produced the corresponding distinct core (`5b2733ed…`). 3. **Six days later, from an archived deploy.** The same hashed oracle runtime remained behaviorally reproducible when exercised through the archived caller deployment six days later: the reproduction run (0yvwlk, age 78) produced a third distinct core (`43c11948…`) under the same `runtime_hash` and `constraint_snapshot_hash`. These three points are circumstantial demonstrations. The strongest replay evidence for any single recorded adjudication is **Tier 3 behavioral reproduction**, which re-executes the deployed oracle on the stored `input_spec` and compares the resulting verdict core to the recorded one. On 2026-08-07, all four records were run through the three-tier replay endpoint. Result for every record: **MATCH_FULLY_VERIFIED** — Tier 1 envelope integrity holds, Tier 2 confirms the deployed oracle source re-hashes to the stored `runtime_hash` (the code in production today is byte-identical to the code that produced the records), and Tier 3 reproduces each stored verdict core bit-for-bit. Determinism is what makes this witness writable at all: it is why an archived deploy can serve as a live witness (section 5), and why the reproduction run's authorship proof transfers as a *mechanism* claim to the same oracle version. ## 5. Methodology: falsification, live witnesses, and per-entry evidence **Archived deploys as live witnesses.** Immutable deploy permalinks mean a historical production version is not a description in a changelog — it is an executable artifact. The central demonstration in this document (section 2) was obtained by *running* the 31.7 version, not by reasoning about it. **Hypotheses falsified on the way** (each closed by a concrete check, not by argument): - *Browser permalink route:* the archived deploy rejects its own permalink origin (ALLOWED_ORIGINS identical across versions). - *Direct two-step API calls:* shell history contains no such calls; the only store-verdict POST found was a demo-isolation test (`demo-` prefix, `source=public-demo-synthetic`). - *Dataset runners:* datasets contain no Beers content, and the runner does not write to the sink. - *Internal scrub gap:* production audit found one call site, strip before all resolvers and dispatch, single-pipe flow — no mechanism. - *Scrub-evading write path* (the prior session's leading hypothesis): falsified by the deploy history itself; the contradiction arose from a timestamp misattribution in an earlier session, which is logged as an error, not silently corrected. **The core methodological claim.** Every step above was necessary only because authorship evidence was not carried *in the record*. A retrospective control claim ("the scrub was in place") had to be tested against deploy history and behavioral reproduction before it could be trusted — and in the first version it was **wrong**. Per-entry provenance is cheaper than forensics: one field at write time replaces a week of investigation, and unlike the investigation, it does not depend on the deploy history happening to survive. ## 6. Why the control is justified regardless of authorship The closure in section 3 does not depend on resolving who authored the original pair — and that independence is the point. If the values came from the user's question, the system promoted **conversational text** into authoritative constraint input. If they came from the model, the system promoted a **fabricated assertion** into authoritative constraint input. Both stories violate the same invariant: *constraint-typed values enter adjudication only from registered, caller-side sources.* The control (caller-only constraint claims + DO NOT EMIT) closes both stories at once, which is why it did not need to wait for the authorship question to resolve — and why the unresolvability of section 2 argues *for* the control rather than weakening it. The oracle behaved correctly throughout: it adjudicated deterministically over the input it was given, and all four records verify to MATCH_FULLY_VERIFIED across all three replay tiers (run 2026-08-07; section 4). **Replay is not authority.** Replay establishes that the recorded adjudication reproduces against the captured input, constraint and runtime state. It does not establish that those inputs were historically authorized to determine the decision. That gap is precisely where a per-entry provenance contract belongs — and this record set is what the gap looks like in production. --- ## Scope and honest limits - The question texts of the original three records are lost; their authorship is formally unresolvable and is claimed as such, never as "the model fabricated." - The reproduction exhibit (0yvwlk) and the 2026-08-07 production-control run wrote to the production sink and are flagged as test material, kept apart from the original evidence set. - One adjacent surface (a separate agent-caller service with its own proposer) has not yet been audited for scrub coverage. It is not implicated by any evidence in this investigation; it is listed as an open audit item, because listing it is what this document's own methodology demands. ## Hash and identifier appendix | Item | Value | |---|---| | Current production fcal-chat.js | `0a56324ebc105bdeb95fb4d617d5043044a82fcbcdd31998337c4c19659524f3` | | GERIATRIC_BEERS_V1 runtime_hash (all 4 records) | `173063376aa4fb0b02408550e2a2ad18d267d4e51781b341c9e5c186cac13a63` | | constraint_snapshot_hash (all 4 records) | `822fef15a39aab520ec640f424d5d4d1773c957146ae4d3851d7da9c6c97bc54` | | Record ID — 5f0ja9 | `aud-20260801T074655201-geriatric-beers-v1-5f0ja9` | | Record ID — n1rwnc | `aud-20260801T074837432-geriatric-beers-v1-n1rwnc` | | Record ID — pmbxmz | `aud-20260801T075017512-geriatric-beers-v1-pmbxmz` | | input_spec_hash — 5f0ja9, pmbxmz | `2e7f6245cd36016f126aebbef58457bfe24776bb5d46691183416015ed813d85` | | input_spec_hash — n1rwnc | `a2e62580ceee86d2dce34c566acb3cf15cb852a3c5659950882d2b351d48ee2d` | | input_spec_hash — 0yvwlk | `9cb60c4d7881f1cad723c2e1a50e21b9fb341c9d0855284ddc3256a008f5b0f2` | | Decision core — 5f0ja9, pmbxmz | `29b164d1f4bbbfacc6262e30556aa699d71faf8142361a8d001359966a2d5aae` | | Decision core — n1rwnc | `5b2733edf71382d559709f30d759a95c8bcdc2b5275352fb35a641c502a35547` | | Decision core — 0yvwlk | `43c11948973e3744e561b823a816d48da490ca09f0d38762c98530fb7ef5486d` | | Three-tier replay status, all 4 records (2026-08-07) | `MATCH_FULLY_VERIFIED` | | Reproduction exhibit ID | `aud-20260807T162106187-geriatric-beers-v1-0yvwlk` | | Archived deploy permalink (31.7 version) | `6a6cb38be38a642bf2bf041e--reality-layer.netlify.app` | All records are retrievable via the public audit viewer's `?id=` deep link and independently replay-verifiable through the three-tier replay endpoint.