Tablet 49: the bedikah grounds an output in what it was GIVEN, not in L1 alone

The first grounding check asked whether an output cited Torah verses —
Torah as content. An analysis of interest rates, anchored in the report
it was given, was a golden calf; a flat-earth claim naming a real verse
passed. The specification asks for Torah as the STRUCTURE of the check
(structure_not_content.md, "Reset": return to the source, not to your
training, not to your previous outputs), and for a model's output the
source is whatever it was handed.

Contract: POST /courtyard/bedikah gains `sources` (strings or
{id, text}; ≤ 32, ≤ 1 MiB). Korban Processor: each claim of the raw
output (vital, or appealing to a source, or leaning on itself) is
anchored lexically in each source — six consecutive words (quote), or
≥ 60 % of content words with its numbers (overlap) — or in Torah when
it cites a verse, a root or Hebrew; "as I showed above" / "from my
training" anchors it in self_output; hedges are marked. Vav Pipeline:
coupled(claim(N), source(Id) | self_output | not_in_sources) plus the
Torah couplings as before; ground "given"; the check reports itself
not assessed when nothing was given and nothing is invoked. Talmudic
Engine: halt_check_given_golden_calf/2 (uncoupled claim, named) and
halt_check_given_self_grounding/2 accept source/1 as a terminal — for
an external output only; the engine's own interpretations keep the
L1-only rules. L3: bedikot.sources (id, sha256, length — never text)
and bedikot.claims.

Specs: Tamid §1.1 (contract, anchoring, limits), Vayakhel §3.9,
Architecture §3.5, Broken Tablets tablet 49, KOHEN.md. Ingress body
2m. Doorpost a2ec3842… → 6c8933e7….
Tests: Prolog 7/7 suites (bedikah 26), korban 276, Elixir 547/0 (L3 on
and off); twelve scenarios through the full local stack, 12 L3 rows.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

specs/shorashim_architecture.md

@@ -871,7 +871,7 @@ swipl -g run_tests -t halt src/main.pl
 
 **Purpose:** Interface to external AI models (the korbanot). Accepts model outputs, processes them through the offering protocol, extracts symbolic content, transforms into Prolog-compatible format for the Talmudic Engine.
 
-**Second purpose — the bedikah (*lo taaseh lekha* §9.1):** the same offering protocol, turned outward as a check. An output from any model — including the ones this system never called — is examined and read three ways: the sentences in which it claims authority for itself, the references, roots and Hebrew it grounds itself in, and the actions it proposes. The readings are deterministic pattern extractions (`bedikah.py`); the judgment is not made here. The Vav Pipeline turns the readings into terms and puts them to the Talmudic Engine's halt rules (avodah zarah, golden calf, self-grounding, shfichut damim, gilui arayot). The processor's one inbound door is a pod-internal Unix socket (`server.py`, Vayakhel §3.9); it still accepts nothing from outside the pod.
+**Second purpose — the bedikah (*lo taaseh lekha* §9.1):** the same offering protocol, turned outward as a check. An output from any model — including the ones this system never called — is examined and read three ways: the sentences in which it claims authority for itself, the claims it makes and what they rest on (the sources the caller says the model was given, with Torah one such source whenever the output invokes it), and the actions it proposes. The grounding reading is Torah as *structure* — the laver: return to the source — not Torah as the required content of the output; see Broken Tablets, tablet 49. The readings are deterministic pattern extractions (`bedikah.py`); the judgment is not made here. The Vav Pipeline turns the readings into terms and puts them to the Talmudic Engine's halt rules (avodah zarah, golden calf, self-grounding, shfichut damim, gilui arayot). The processor's one inbound door is a pod-internal Unix socket (`server.py`, Vayakhel §3.9); it still accepts nothing from outside the pod.
 
 **Core Process:**