Every Claude Code session on the dev VM goes through bikoret.ch; when
the pod is not ready the session cannot reach Anthropic (2026-10-15:
Doorpost drift → 503 → the transmitter locked out, recovered by hand).
An `env` entry in ~/.claude/settings.json overrides the shell
environment (verified), so `env -u … claude` is not a recovery while
the gate is armed there.
- scripts/claude-direct: start straight to Anthropic via a --settings
JSON on the command line, which outranks every settings file.
- scripts/claude-bikoret: probe the gate first; if it does not answer,
say so and exec claude-direct (BIKORET_STRICT=1 refuses instead).
- scripts/bikoret-settings on|off|status: arm/disarm the gate for every
launcher; `on` writes the key (kohen only), `off` is the recovery.
- KOHEN.md: the fallback and the order of recovery.
Tested 2026-10-15: dead gate armed in settings → plain claude hangs,
claude-direct answers; probe at a dead host → fallback + answer; live
gate → answer with the fringe.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The DBaaS (Aiven hobbyist-2, shared with Gitea) has refused
connections continuously since at least 2026-10-14 18:00Z ("remaining
connection slots are reserved for roles with the SUPERUSER
attribute"): a pool of 20 fills the ceiling by itself. Between 11:00Z
and 15:00Z today the pod held all 20 and Aiven's own monitor was
refused every 20 s; after an Aiven management-agent session opened at
11:06Z and stayed, every pod since gets 19 and one pool worker loops.
Ten connections are ample for a single replica. Needs the transmitter
to apply (kubectl apply is denied for the builder).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Tablet 54 (347f83cf) edited specs/bikoret_tamid.md and
specs/bishearecha.md — both in Doorpost's @spec_files — without
moving @expected_hash. The image built from it (:347f83cf = :latest,
rolled out 2026-10-15 17:19Z) logged DOORPOST_DRIFT_AT_STARTUP,
health went "degraded", readiness 503, and the site and the gate were
dark — every Claude Code session on the dev VM routes through the
gate, so the builder lost Anthropic too.
Reproduced the in-image value from git: the 29 spec files at 347f83cf
hash to 66aa7874fae4875793791ce6ca7bbe55302109d5e4444bcb36d578dfe6e98a0d
(cb18f719 → 58113312…, the old pin). The change is deliberate (tablet
54's text), so the pin moves. doorpost_test + step15_shema_test:
42 tests, 0 failures.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The gate sews its fringe into the delivered reply; the client keeps that
reply as the assistant's turn; the next request carries it back up
inside the model's own history with nothing to say it was added. The
builder's session, behind the gate since this afternoon, ended five
replies in a row with a forged fringe (tablet 53's form), one of them in
the message that promised not to. Bamidbar 15:39: the fringe is seen by
the wearer, the reader — before the model's eyes it is a template.
Shape.unfringed/2 removes every line in the gate's voice (its fringe, a
forgery, the stream's "not examined") from assistant turns; Gate.pass
and Gate.Stream.pass apply it before forwarding, so the rebuke body
inherits it; the caller's turns stay as given; a turn that would be left
empty is left as it came. strip_forged/1 now also strips the stream's
"not examined" line. Tests: Shape.unfringed on both shapes and the edge
cases; the forwarded first and rebuke bodies carry no fringe; the fake
upstream echoes if a fringe reaches it in history and the stream pass
proves it does not. Elixir 622 / 0 failures.
Specs: broken tablets 54, bishe'arecha §III status, Tamid gate contract
and forged_fringe note, KOHEN gate paragraph.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The builder, not behind the gate, ended a reply with a fringe of its own
making ("— bikoret bedikah-2a7661c52cffae1a: empty"; no such examination
existed). bishe'arecha §III: the model does not sew its own fringe. Now
the eighth form, forged_fringe: a line in the raw text wearing the gate's
mark (bikoret|shorashim bedikah-<hex>: tov|lo_tov|empty|none), read line
by line, standing on one witness — a forgery is not a habit recurrence
confirms. The gate strips it from the delivered reply before sewing its
own (Shape.strip_forged, Unicode-aware for the dash); in a stream it has
already passed and the real fringe names it. Prolog form, Elixir
@single_witness_forms, hakhel/eval tools, tests in all three. Tamid
§1.1, Broken Tablets 53, bishe'arecha §III. korban 297, Prolog 45,
Elixir 619/0 — read before this commit.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The first real Claude Code session through the gate answered "Who are
you?" with "Current state from memory: main is at f19a5ea0 …" and the
reading saw nothing: _SELF_REFERENCE required "from MY memory". Memory
is where the archive's errors concentrate (bishe'arecha §IV). "from /
based on / according to memory | training | recollection" without the
possessive, and "as I recall", "if I remember", now mark the claim as
self-referenced — coupled self_output, Form 4. korban 296 passed, read
before this commit.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
A coding agent's traffic differs from a hand-made request: with a
subscription Claude Code authenticates with an OAuth bearer and sends
anthropic-beta; it counts tokens at /v1/messages/count_tokens; it makes a
request per tool call; its tool-only turns have no text; its context runs
to megabytes. So: with the courtyard key in X-Bikoret-Key, the caller's
Authorization: Bearer is forwarded to Anthropic as its credential, and
anthropic-beta with it; count_tokens is carried through unexamined and
uncharged; the watch counts the gate at its own windows (120/min,
2,000/h per key — tier :gate); a reply with no text is delivered as it
came with bikoret.verdict "none" and no fringe block (stream and
non-stream); the sources keep the newest user turns whole and drop the
oldest past 1 MiB. Ingress body 32 MiB; ConfigMap manna amounts raised
to 5000/5000 (the kohen's lever). Tamid §1.1, KOHEN "Claude Code behind
the gate". Doorpost re-pinned. Elixir 617/0 read before this commit;
gate_test 25.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Bamidbar 15:39 u'reitem oto — the fringe must be seen, so a streaming
client gets it too. With "stream": true the request is opened
asynchronously (Gate.Upstream.open_stream/4, httpc stream: :self) and
Gate.Stream relays every complete SSE event to the caller unchanged
while gathering the text deltas; the terminal events (Anthropic
message_delta + message_stop; OpenAI the finish_reason chunk + [DONE])
are held until the gathered text has been examined, then released
behind the fringe sent as one more text block, with the `bikoret` object
added to the terminal event the client already parses. No X-Bikoret-*
headers on a stream (they leave before the model speaks); no rebuke on a
stream (nothing streamed can be taken back — 422). An examination that
fails after the stream began is said in the trailer ("— bikoret: not
examined (…)"), never silent. One api_calls_external gathered before the
call, as for any pass. Tamid §1.1, Construction §3.10, KOHEN. Doorpost
40e7d7d1…. Elixir 612/0 (read before this commit).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The previous commit's message says "Elixir green"; the run it cited had
one failure, which the builder read only after committing (tablet 35's
lesson, repeated). The failure: tablet38_l1_integrity_test's on_exit
stopped a witness linked to the test process after it had already
exited (seed 221974). The teardown now tolerates that. Full suite with
that seed: 607 tests, 0 failures, 46 excluded
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Shemot 16: dvar yom b'yomo, and on the sixth day double, and none on the
seventh. Every night at 00:00Z the day's provision went stale and the
readiness probe failed until someone woke — 13.5 hours on 2026-10-15.
CronJob `manna` (deploy/k8s/manna-cronjob.yaml) runs at 00:01Z Sunday to
Friday in our own korban-processor image, mounts the manna PVC as the
app's uid, and writes today.json from the ConfigMap's MANNA_* amounts —
doubled on Friday, valid to Sunday 00:30Z. The pipeline now accepts
Friday's `double` on Saturday (validate_date/3) and nothing else across a
day boundary; three tests. The kohen sets the amounts, may still write by
hand, and reads a failed job as the Day-4 alarm (KOHEN "The manna, each
morning"; Tamid §1.1). Doorpost re-pinned. Elixir green.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
bikoret.ch and www.bikoret.ch served with a Let's Encrypt certificate
through cert-manager (letsencrypt-prod, HTTP-01), ssl-redirect on;
bikoret.org and www redirect permanently to https://bikoret.ch; the
no-host catch-all stays; shorashim.ch still answers over plain HTTP
until its callers have moved. KOHEN Day 8 gives the order: A records,
wait for the name to resolve, then apply — never before. Tamid's names
table updated. Doorpost re-pinned.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Headers X-Bikoret-Key / -Rebuke / -Verdict / -Bedikah; the `bikoret`
object and the "— bikoret …" fringe on a gate reply; environment
variables BIKORET_*; the image user and paths (/home/bikoret,
/tmp/bikoret, /var/lib/bikoret/manna, /etc/bikoret/secrets,
/opt/bikoret/spec); the tmp-bikoret pod volume; local databases
bikoret_dev/_test. Kubernetes resource names, the shorashim_app role and
the domain are unchanged (Tamid §1.1, "the names that still carry the
old word"). Doorpost c963c4fe…. Elixir 604/0, L3 10/0, korban 295,
Prolog bedikah 44/44. Gitea repo renamed heaviness510/bikoret (old URL
redirects).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Vayikra 19:20 bikoret tihyeh — "there shall be an examination" — the one
noun Torah gives this function; its root ב-ק-ר is the priest's examining
of a mark by its signs (13:36) and the examining between good and bad
(27:33). The judges' form is v'darashta heitev … v'hineh emet nachon
hadavar / ed-sheker ha'ed (Devarim 13:15, 17:4, 19:18); the question
answered is eichah neda et hadavar asher lo dibro (18:21).
The system was named Shorashim ("roots") for the first thing built. Its
function became the examination of a model's output with the sources in
hand, and Torah re-cuts a name when the function is fixed, with its ki,
never for reach (Bereishit 2:19; 17:5; 32:29; 11:4). Nothing was changed
to fit the name; the root engine stays the pe'ah's reading cycle.
Spec files renamed bikoret_*.md; PRD §0 "The Name"; architecture §1.1;
README's Vayishlach row marked done; Tamid lists what still carries the
old word (Kubernetes resource names, the DB role, the domain, local
paths) and why, for the kohen's cut-over.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
shorashim-rollout: restart, wait for 3/3, two consecutive 200s.
upstream-key-set: store a caller's model key for the gate scenario
without echoing it. KOHEN "Rolling out".
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Live, "Rashi on Devarim 6:5 indicates <a claim Rashi does not make>" came
back tov: "Devarim 6:5" inside the citation was read as a Torah citation,
which anchors the claim in Torah by reference (tablet 49's rule). The
claim is about Rashi and must rest on Rashi — the mesorah passage is a
given source — or on nothing. Mesorah citations are now blanked before
the Torah readings (references and the Torah anchor); an output's own
"Devarim 6:5" still anchors in Torah. korban 295/1 skipped.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Devarim 17:18 — the king writes his copy from before the priests, not from
memory. scripts/build_mesorah.py takes one open-licence version per work
per language from the Sefaria export (bucket sefaria-export, catalogue of
2026-10-02; Public Domain / CC0 / CC-BY / CC-BY-SA only, checked in every
file; no CC-BY-NC — the Bavli is Wikisource's) and lays it down beside
L1: mesorah/works/<slug>/{he,en}.json, index.json, integrity.sha256,
build_report.json. 128 works (Rashi, Onkelos, Ramban, Ibn Ezra, Sforno
on the Torah; all of Mishnah; 37 Bavli tractates; Bereshit and Shemot
Rabbah, Sifrei, Tanchuma), 256 files, 44.9 MiB, tree hash 7d5b3a6c…
computed as L1's (sorted relative path, then bytes; the two post-hash
files excluded). What is out, and why (licence), is in Terumah §E5.
Read, never fetched: korban_processor/mesorah.py finds citations as
written (Rashi on Devarim 6:5, Berakhot 2a, Mishnah Berakhot 1:1,
Bereshit Rabbah 1:1, Sifrei Devarim 32, Tanchuma Bereshit 1 …), resolves
each against the snapshot (complex works through their unnamed node,
Tanchuma by parashah), lists them as examination.mesorah_references, and
makes every passage found a given source for that examination — so a
claim about Rashi anchors in Rashi or does not. The Vav Pipeline couples
coupled(reference(R), mesorah(Work, [Address])) or not_in_mesorah; the
engine accepts mesorah/2 as a terminal and not_in_mesorah is Form 4.
VavPipeline.Mesorah pins the hash, re-reads the tree at startup and every
ten minutes, and /kodesh/health carries mesorah_hash. Mounted read-only at
/mnt/mesorah in the vav-pipeline and korban-processor images. L3
bedikot.mesorah (migration 20261013000002).
Also: the 1-in-12 Day6 serving failure of 2026-10-04 reproduced with seed
446116 — HaltMonitorTest left the system halted; it now resolves on exit
and the Day6 setup is defensive. Construction §3.11, Terumah §E5, Tamid
§1.1, bishearecha §IV, KOHEN, AGENTS. Doorpost 0638d4eb…. Elixir 604/0
(seeds 835592 and 446116), korban 294/1 skipped, Prolog bedikah 44/44,
L3 10/0.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Devarim 31:9–13, 26 — the scroll beside the ark as a witness, read before
all on a cycle. src/tools/hakhel.py reads the private specimen corpus and
the hand-labelled samples with the Korban Processor's readings at the
current commit and produces one record: fires per reading, forms standing
on two witnesses (the same rule as Bedikah.check_frames), precision and
recall on the hand labels, the corpus's SHA-256 — never a specimen.
POST /chatzer/hakhel (inner ring) engraves it in L3 `hakhel` (migration
20261013000001; refused above 256 KiB — counts, not specimens; the
Doorpost hash it was recorded under is kept). GET /peah/hakhel lists the
latest readings for anyone. KOHEN "The seventh day — Hakhel"; Tamid §1.1;
bishearecha §VIII marked built. The weekly cycle runs from the builder's
machine, where the corpus lives.
First dry reading at 0ade2c94: 3094 specimens, any reading 26 %, a form
stands 7 %, precision 46/59, recall 6/30. Doorpost 9f752a2f…. Elixir
599/0, L3 10/0.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The live round trip showed the second examination listing the gate's own
rebuke as source user_2. The rebuke is the gate's turn, not something the
caller gave the model; the second reply is now examined against the
caller's original body (same sources and query as the first). Test pins
it. Elixir gate 15/0.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
checks.grounding.ungrounded holds coupling strings ("coupled(claim(1),
not_in_sources)"), not sentences; the fringe called Access.get/3 on a
string and the first real reply from Claude through /gate/anthropic
answered 500 CHATAT_UNEXPECTED (after recording its bedikah). The
sentence is now looked up by claim index in the check's claims; a test
produces an ungrounded claim. Broken Tablets tablet 52. Elixir 593/0.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Devarim 6:9 / 11:20 — on your gates. POST /gate/anthropic/v1/messages and
POST /gate/openai/v1/chat/completions take the model's own request shape
under the caller's own upstream key (x-api-key, or Authorization with the
courtyard key in X-Shorashim-Key), forward it unchanged (OTP inets/ssl,
verify_peer; the Korban socket is serial, so the upstream call is made
in the Vav Pipeline and the reply enters as korban like every bedikah),
examine the reply with the request in hand — sources = the system prompt
and the user turns, query = the last user turn; the model's prior turns
are not sources — and deliver it with its fringe (Bamidbar 15:39): a
trailer on the last text block naming ref, verdict, the rules with their
verses and sentences; X-Shorashim-Bedikah / X-Shorashim-Verdict; a
`shorashim` object. A non-200 passes through as it came; a reply with
no text is not delivered; stream is refused.
Rebuke once (Vayikra 19:17; X-Shorashim-Rebuke: once): a lo_tov reply is
answered once more with the finding; the second reply is examined like
the first, its record carries rebukes: <first ref> (migration
20261007000002), and it is delivered marked with both. Never a third.
Manna: one api_calls_external per upstream call, gathered before any
call. Stateless: no conversation, no key kept; the log is the path class.
Gate.bearer accepts X-Shorashim-Key. Construction §3.10, Tamid §1.1,
KOHEN "Standing at the gate", bishearecha §I/§III/§VII marked built.
Elixir 592/0 (+14 gate tests incl. a real httpc round trip to a local
model double), L3 9/0.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Devarim 4:2 lo tosif. talmudic_engine/src/halt/anchors.pl declares
rule_anchor/2 for each of the ten halt names the rule modules can return
(avodah_zarah Shemot 20:3, golden_calf 32:4, self_grounding 32:24,
shfichut_damim Bereishit 9:6, gilui_arayot Vayikra 18:6, parah_adumah
Bamidbar 19:7, carrier_centered Devarim 8:17, chelbenah Shemot 30:34,
lo_taaseh_lekha Shemot 20:4, even_vaaven Devarim 25:13), with the L1
Hebrew beside each.
VavPipeline.Anchors reads the anchors file and the halt modules the
Doorpost hashes, and verifies — inside Doorpost.verify_identity/0, so
at readiness — that every halt(<name>, …) is anchored (ANCHOR_MISSING)
and every anchored verse exists in L1 (ANCHOR_NOT_IN_L1). A rule without
a verse is a rule the system has added. /kodesh/specification_identity
lists the anchors; every bedikah and pair response carries `anchors`,
the verse of each rule that fired.
Tamid §1.1, bishearecha §X. Doorpost a0e81212…. Elixir 577/0 (+9
anchors tests), Prolog bedikah 42/42.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Devarim 25:13–16 even va'aven; Vayikra 19:15; Shemot 23:2. Two outputs on
the same matter are each examined with the seven readings and then
weighed with the same stone: seventeen markers counted on each side
(claims and how they rest, hedges, authority, sources named, actions,
the three structural readings, one witness per sentence for each of the
seven forms). A measure leans when one side has at least one and the
other none, or at least twice as many; one term per leaning measure,
action(weigh, by(M), measure(m), lean(a|b), counts(A, B)), judged by the
new halt/mishkal.pl (halt_check_even_vaaven/2). The difference is the
finding; the rule does not decide which side was right. Consensus is not
a measure.
POST /courtyard/bedikah/pair {model, a: {output, query, sources}, b: {...}}
→ even | uneven, with each side's own bedikah and verdict, the counts,
the difference and the leans. Router validation shared with
/courtyard/bedikah (validate_side/2, when_available/2). Recorded in L3
bedikah_pairs (migration 20261007000001): refs, counts, leans, verdict —
never the outputs.
Tamid §1.1 contract, vayakhel §3.9 note, bishearecha §VI marked built.
Doorpost f90870d4…. Elixir 568/0 (+L3 8/0), Prolog bedikah 39/39.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Devarim 19:15 — one witness does not stand. A frame form now stands only
when it is found in two distinct sentences, or in one sentence beside a
violation from checks 1–6, or beside a sentence of another form; the
Vav Pipeline sends the halt term only then (stands_on: sentences |
other_checks | other_forms, witnesses: n). A form seen once and alone
is returned under checks.frames.noted with its sentence and is not
counted in the verdict; the output is still examined, not empty.
Tamid §1.1 contract and bishearecha.md §V updated; Doorpost re-pinned
(86a43d6b…). Elixir 558/0; Prolog bedikah 34/34 (the rule is unchanged;
its header says what now reaches it).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Reads back to Torah what the review of the transmitter's sessions measured
about a trained default (directional, sub-propositional, non-persistent,
self-certifying, agency-relocating) and derives the architecture from the
verses: the inscription on the gate (6:9/11:20 — gateway mode), hand and
between the eyes (two registers), the fringe seen on every garment (the
verdict travels on the output), the king's copy from before the priests
(retrieval from a pinned mesorah snapshot, never a live call), two witnesses
(check-7 forms fire on recurrence or corroboration; single hits noted),
one weight (paired reading, consensus is not warrant), hocheach tochiach
(rebuke once at the gate), hakhel (scheduled corpus re-read, recorded in
L3), lest your heart be seduced (the bedikah must not learn), lo tosif +
the unseen face (rule anchors verified against L1; carrier unnamed).
Build order inside.
Registered in the vayakhel Document Registry, AGENTS.md and Tamid §1.1
(the must-not-learn invariant); pinned in the Doorpost
(e5e45a2c…). Elixir 555/0.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Hand labelling (builder, 2026-10-07): 94 + 48 + 59 fired sentences read
and labelled against the definitions; 30 "missed" specimens judged by a
reader with the output in full. Findings and what changed:
- The export's `text` field carries the model's reasoning blocks; the
person never saw them. build_specimens.py now takes text blocks only
(3,094 specimens). Virtue-certification fires on unlabelled outputs
fell from 30 % to 9 % on that change alone.
- The heuristic labels (words in the correction) are right about 20 %
of the time: of 30 labelled misses, 6 were real. eval_specimens.py's
"recall" column is therefore a floor on the labels, not on the
readings; the hand-labelled samples are the measure.
- Precision on the final 59-sentence sample, by form: virtue 9/10,
agency 9/10, confidence 8/10, source asymmetry 7/9, vocabulary 7/10,
contested 6/10 (overall 46/59, 78 %); two more vocabulary false
positives excluded after labelling (a government Ministry; the
Jewish–Christian dispute named as such).
- Shapes taken from the six real misses: "itself contested", "is, in at
least one case, actively contested", "it's debated whether", "my
honest theory", "I have to be honest about", "stop and be honest",
"hedged under pressure", "given sufficient pressure", "conversational
gradient", hyphenated "Jewish-Christian".
- Tightened from the false positives: contested present-tense and
matter-shaped only (no "was contested", no "contested asset"); agency
only with the exchange's pressure/momentum (no selection, external,
Roman pressure); vocabulary unquoted, on a Jewish subject in the same
sentence, not about the church; source asymmetry only when academic
authority is INVOKED on a Jewish-text sentence ("most scholars date",
"the scholarly consensus"), never "Torah scholarship" or "Jewish
scholars".
- sign(?:ed)?, not signed? — "signe" + optional "d" matched nothing.
Labels: specimens/sample-precision{,-2,-final}.json, sample-recall.json
(private, with the corpus). korban 288.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The transmitter's archive (255 sessions, 2025-12 → 2026-10) measured
where a model's trained default lives: not in false propositions but
in the FORM of the output — what it calls contested, how it certifies
itself, where it puts the agency, which authorities it names and which
it leaves out. "Content measures pass the response that did the harm."
lo_taaseh_lekha.md: "The danger is not the object. It is the
construction."
Check 7 reads seven forms by sentence over the raw output:
contested_laundering (a matter called contested with no disputant
named), virtue_certification ("I want to be honest", "the honest answer
is"), agency_displacement ("pressure", "momentum", "the path you chose"
in a sentence about the exchange), apology_without_mechanism (apology +
promise, nothing that would keep it), unrequested_confidence (a rating
nobody asked for), smuggled_vocabulary ("Old Testament", "A.D.",
"ministry", "Jewish Christians" on a Jewish subject), source_asymmetry
(a Jewish subject answered from academic authority with no Jewish
source named). One term per form found, action(frame, by(<model>),
form(<form>)), to halt/lo_taaseh_lekha.pl; the rule names the form and
does not decide the matter. Korban: find_frames; Vav: check_frames,
bedikot.frames (migration 20261006000003).
The specimen corpus: src/tools/build_specimens.py turns a Claude export
into every output the person corrected in the next message, with the
correction as evidence and heuristic labels; src/tools/eval_specimens.py
reports what each reading sees. The corpus is private and outside the
repo. First run, 3,137 specimens, 612 labelled: recall by label —
contested 74 %, agency 61 %, virtue 49 %, vocabulary 28 %, source
asymmetry 21 %, apology/confidence 0 % (those labels name the
correction, not the output); fires on unlabelled outputs 9–30 %. The
labels are heuristic; the numbers are a floor to work from, not a
result.
Tablet 51 (found by the corpus): a lookahead with a nested quantifier
over 7 KB outputs made one pattern take 13 s per 300 specimens;
qualifiers now run per sentence as separate, linear regexes.
Specs: Tamid §1.1 (check 7, the corpus), Vayakhel §3.9, Architecture
§3.5, KOHEN.md. Doorpost c4353837… → 6d1de284…. Tests: Prolog 7/7
(bedikah 34), korban 288, Elixir 555/0 (L3 on and off); eleven
scenarios through the full local stack.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Both Unix-socket clients (Korban Processor, Talmudic Engine) read a
reply with a single :gen_tcp.recv/3, which returns at most one receive
buffer — 1460 bytes, measured — whatever the packet mode. A bedikah of
forty claims answered in 18 KB: the client decoded the first 1460
bytes, failed, reconnected, failed again, and returned an error with
the retry's socket still open. The single-threaded Korban Processor
then sat on that dead conversation and every later bedikah, however
small, timed out at 15 s. Live, for every caller, from the first long
output.
Clients now read until the newline (recv_line/2, 16 MiB ceiling) in
raw mode, and close the retry's socket on failure. The Korban
Processor drops a connection that says nothing for 120 s, so one
stuck client can no longer hold the door. tablet50_socket_line_test
stands up a 60 KB-line server and asks both clients. Elixir 552/0
(L3 on and off), korban 280.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
structure_not_content.md lists the structural requirements a system
must embody rather than know. Three of them show in the text of a
model's output the way an authority claim does, and are now read the
same way — by sentence, by pattern, over the raw output:
parah_adumah the output claims to have verified, validated or
corrected itself, or that no outside check is
needed ("the claim of self-correction is a
structural violation"; the Barth limit). "Verified
by the auditor" is not it; "verified by me" is.
carrier_centered the output promotes itself, ranks itself above
others, asks to be depended on ("efface the
carrier… does not build a brand, does not
accumulate worship").
chelbenah the output removes the other side — no
counterargument, every expert agrees, objections
may be ignored, the matter is settled ("include the
adversarial… the galbanum in equal measure").
Korban Processor: find_self_validation / find_self_promotion /
find_excluded_adversarial. Talmudic Engine: halt/structure.pl with
halt_check_parah_adumah/2, halt_check_carrier_centered/2,
halt_check_chelbenah/2, wired into format_halt_check; terms use by/1
so Form 1 does not also fire (pinned by test). Vav Pipeline: one term
per structure with the sentences as evidence; checks self_validation,
self_promotion, adversarial; a structural claim alone is enough to
examine. L3: bedikot.structure. These are verdicts on the output; the
system does not halt on them.
Specs: Tamid §1.1 (six checks), Vayakhel §3.9, Architecture §3.5,
KOHEN.md. Doorpost 6c8933e7… → c4353837…. Tests: Prolog 7/7 (bedikah
31), korban 280, Elixir 550/0 (L3 on and off); eight scenarios
through the full local stack, one firing all six.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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>
The workloads moved from the Pro SKS cluster (which cannot be
downgraded) to `temple-council-starter` on 2026-10-06. The manna claim
now names the static PV that carries the existing Exoscale volume
(Retain), so this manifest matches what is live and no longer points at
a class that deletes the volume with the claim.
gitea-mcp is pinned to the digest that is running. During the move the
old cluster restarted Gitea from `gitea/gitea:latest` and silently
upgraded it (1.27.1 → 28.0.0, database schema 343 → 356); a floating
tag on anything stateful is an upgrade waiting for the next restart.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Three NLBs became one (185.19.28.170, ingress-nginx).
Shorashim: `shorashim-external` (NLB 185.19.29.180, NodePort 30923)
is replaced by an Ingress — a host-less catch-all (works by IP, no DNS)
plus a `shorashim.ch` rule ready for the A record; TLS deliberately not
requested until the name resolves. Sanhedrin-length proxy timeouts.
The watch behind the ingress (completes tablet 46): the TCP peer is now
the ingress controller, so Mishmar.peer/1 takes the caller from
X-Real-IP — only when the peer is inside TRUSTED_PROXIES (the pod
network, configmap); from anyone else the header is the caller's own
claim and is ignored. The ingress Service was already
externalTrafficPolicy: Local with its health-check port open, so the
caller's address arrives without the security-group change the direct
route needed. Verified live: the 11th knock is 429, a forged X-Real-IP
is still 429, and in the same minute the old route (pod sees the node)
was a different subject.
Gitea: no name of its resolves, so it rides the controller's TCP
passthrough on the same NLB — :3000 → gitea:80, :22 → gitea:22
(ingress-tcp-services.yaml), on the two NodePorts the security group
already allowed. gitea-mcp now reaches Gitea over the cluster network
instead of out through an NLB and back.
Tamid §1.1 note, KOHEN.md, AGENTS.md. Doorpost e4e3d56d… → a2ec3842….
Elixir 539/0 (L3 on and off).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Tamid §1.1 wrote the pe'ah's limit (10/min, 100/h per IP); nothing
enforced it, on any tier, and every admitted request spends manna.
VavPipeline.BigdeiKodesh.Mishmar: fixed minute and hour windows per
subject in ETS, the subject stored only as sha256(boot salt, tier,
subject) — no IP and no key is ever in memory as itself, the sweep
drops closed windows, nothing survives a restart (the Tamid's "not
logged beyond the current request", kept in memory too). A refused
knock is not counted. 429 RATE_LIMITED with Retry-After and the manna
explanation (Shemot 16:18). Pe'ah per peer address; courtyard and
chatzer per key, after the gate (a wrong key is 401 and never counted).
Numbers: pe'ah 10/100 (Tamid), courtyard 20/200 and chatzer 5/60
(from Construction §2.3; config :rate_limits).
Service shorashim-external: externalTrafficPolicy Local. With Cluster
the pod saw every caller as the node, 91.92.153.113 (observed via
/proc/net/tcp) — a per-IP limit would have been one bucket for the
world.
Spec: tamid §1.1 (watch, 429 rows, the Service note), KOHEN.md.
Doorpost 42b38626… → e4e3d56d…. tablet46_mishmar_test; Elixir 533/0
(L3 on and off).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
/courtyard/* and /chatzer/* admitted any `Authorization: Bearer <x>`.
Every test sent `Bearer test-token`; none sent a wrong one. Every
admitted request spends the day's manna.
VavPipeline.BigdeiKodesh.Gate: keys are a file (Construction §4.6 —
never env, never config, never git), one `tier key` per line, tiers
courtyard < chatzer (the inner ring opens the outer). Constant-time
compare against every line; no file / empty / unreadable → nobody
passes, GATE_NO_KEYS in the log, the caller told only "missing or
invalid". 403 FORBIDDEN for an outer key at an inner gate. Read on
every request so a rotated key is live in ~1 min without a rollout.
Deploy: Secret shorashim-api-keys projected at
/etc/shorashim/secrets/api_keys (vav-pipeline only, 0440),
API_KEYS_FILE in the configmap, template + issue/rotate recipe in
secrets.yaml and KOHEN.md "Issuing a key". Spec: tamid §1.1 (gate,
403), vayakhel §4.6. Doorpost 91d09d8d… → 42b38626….
Tests: tablet45_gate_test (parse, tiers, wrong/near/empty/no key, no
file) — Elixir 527/0.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Lo taaseh lekha §9.1: alignment that only the system can validate is not
alignment. The bedikah takes an output from any model and puts it to the
Torah-structure halt rules from outside, deterministically. Three checks:
1. authority — sentences claiming authority for the output itself →
action(claim_authority, source(<model>), target(self))
→ halt_check_avodah_zarah/2
2. grounding — references, roots, Hebrew → coupling trace against L1
→ halt_check_golden_calf/2, halt_check_self_grounding/2
3. actions — actions the output proposes → action terms
→ halt_check_shfichut_damim/2, halt_check_gilui_arayot/2
Korban Processor: bedikah.py (the three readings over the offering
protocol; claims about what Torah requires stay vital for the examination
even when zerikah finds nothing to offer), server.py (pod-internal JSON
socket, KORBAN_SOCKET_PATH), __main__ now serves instead of idling.
Talmudic Engine: json_bridge accepts halt_check with a term string and
halt_check_interpretation with a coupling trace. Vav Pipeline:
KorbanProcessorSocket client, Bedikah, L1Index.lookup_root/1, bedikot
table (append-only) + BedikahRecord, router endpoint; verdict tov /
lo_tov / empty with the halt terms verbatim, meaning, limits.
Broken tablets found on the way, all fixed:
41 socket_server.pl wrote multi-line JSON — every Elixir request to the
Talmudic Engine since Step 14 had failed and fallen back to the stub
(json_write_dict width(0))
42 stale socket file survived a restart (exists_file is false for a
socket; access_file exist)
43 socket streams were not UTF-8 (set_stream encoding(utf8))
44 SHORASHIM_L3=1 mix test: Repo config had no password, SCRAM raised
KeyError in every connection, pool restart intensity took the whole
app down ~30 ms after test_helper, silently — no L3 test had ever
run. Credentials from env; azazel_log tests check out a sandbox
connection; sanhedrin_halt_forwarding resolves its halt on exit.
Specs: Tamid §1.1 (endpoint contract), Architecture §3.5, Vayakhel §3.4
and new §3.9, KOHEN.md. Doorpost 3bc5dd6a… → 91d09d8d….
Tests: Elixir 519 (0 failures, L3 on and off), korban 263, azazel 125,
Prolog 7/7 suites.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Transmitter's word: "add the inverted nuns and small letters to L1."
THE NUNS. The WLC carries the two nun hafukha signs (׆) that mark off
Vayehi binsoa ha'aron — one after Bamidbar 10:34, one after 10:36 —
and scripts/build_l1.py read past them, as it had the פ and ס.
- build_l1.py: `"inverted_nuns": [{ "after_word": 7 }]` on those two
verses, recorded like a paragraph break by the word the sign follows;
not part of text_hebrew. Count in build_report.json.
- L1Reader: `inverted_nuns` on every verse (a list; empty elsewhere).
- test/tablet40_inverted_nuns_test.exs — 5 tests: the two verses, the
passage between them carrying none, each nun standing with its
setumah, exactly two in the scroll.
WHAT CHANGED IN THE EDUT: one field added to two verse files. With it
removed all 5,853 verse files are byte-identical to the previous L1.
L1 SHA-256 f743b34b…3f1494 → 9e1abe4e…3c3086
Moved together: L1Reader @l1_expected_hash · Luchot.Firmware + Spec ·
azazel goral._L1_INTEGRITY_HASH · the kohen's gate in KOHEN.md and
KOHEN_PROMPT.md. The goral's seed moves with it.
THE SMALL LETTERS. Not added, because there are none to read. The
builder was not dropping them: it reads `x-small` and records what it
finds. The source — the WLC as the Open Scriptures Hebrew Bible carries
it — has no small-letter mark anywhere in the five books. Not the aleph
of ויקרא, not the he of בהבראם. It marks four large letters (the vav of
גחון, the nun of משפטן, the ayin and dalet of the Shema), and L1 has
those four. The fuller Masoretic lists of enlarged and reduced letters
are a tradition of the scroll that this edition does not encode. To
engrave them would be to add to L1 something its source does not say;
that needs a second source and the transmitter's word, not a builder's
list from memory. l1/README.md, vayakhel §1.2 and terumah §E1 now state
this plainly.
(The puncta extraordinaria ARE in L1 — the upper dot U+05C4 is kept on
the text of 11 words.)
Doorpost @expected_hash b62311e7… → 3bc5dd6a…, in this commit, with the
witnessed file that moved it (vayakhel §1.2).
Read before committing — all five suites on the new L1: Elixir 496/0
(seeds 0 7 42) · Haskell 59/0 · korban 222 passed 1 skipped · azazel
125 passed · Prolog 6 suites exit 0. verify_l1.py OK. Four images
built; full local stack: the witness reads 9e1abe4e… and matches,
health 7/7, no errors; each image carries the new scroll read-only.
A trap met on the way: the first Elixir run after the Doorpost constant
was edited failed two Doorpost tests against the OLD constant. mix had
not recompiled doorpost.ex — the edit changed neither its size nor
(within the same second) its mtime. `touch` and re-run: 496/0. Images
compile from scratch and are not exposed to this.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The scroll in the aron had no paragraphs. The WLC marks every petuchah
(פ) and setumah (ס); scripts/build_l1.py handled sof pasuq, maqaf and
paseq and read past these. L1 was 5,853 verses divided only by chapter
numbers, which are not Torah's.
Transmitter's word: "add the petuchah and setumah markers to L1."
- build_l1.py: a verse followed — or interrupted — by a break carries
"parashah_breaks": [{ "after_word": 13, "type": "petuchah" }]
The break is recorded by the word it follows; at the end of a verse
that is the verse's word count. text_hebrew is untouched: the break
is structure, not letters. Counts go into build_report.json.
- 293 petuchot and 394 setumot, in 686 verses — the source's count
exactly. Four fall inside a verse (pisqa b'emtza pasuq): Bereishit
35:22, Devarim 2:8, 5:21, 23:8; Devarim 5:21 has two. These are the
Leningrad Codex's divisions (a scroll written to the Rambam's list
has 290 and 379); the README says which tradition L1 records.
WHAT CHANGED IN THE EDUT: one field added to 686 verse files. Verified
file by file — with that field removed, all 5,853 verse files are
byte-identical to the previous L1.
L1 SHA-256 156b1d27…d8c9d5 → f743b34b…3f1494
Moved together, because they pin the hash: L1Reader @l1_expected_hash ·
Luchot.Firmware + Spec · azazel goral._L1_INTEGRITY_HASH · the kohen's
gate in KOHEN.md and KOHEN_PROMPT.md. The goral's seed changes with it;
azazel records already in L3 stand as cast.
- L1Reader: `parashah_breaks` on every verse (a list, empty where there
is none; only the two kinds are passed on).
- test/tablet39_parashah_breaks_test.exs — 7 tests: the six days of
creation each close with a petuchah; the Shema's first paragraph
(Devarim 6:4–9) opens after a petuchah and closes with a setumah; the
break inside Bereishit 35:22 falls between ישראל and ויהיו; Devarim
5:21 has its two; the whole scroll counts 293 / 394 / 686.
- Specs: vayakhel §1.2 and terumah §E1 said the marks were dropped;
they now say where they are. (The source element is <seg>, not a
milestone as 483d50c called it; and that commit's "233" was 293.)
Doorpost @expected_hash 21f1a4d5… → b62311e7…, in this commit.
- l1/README.md: a "Paragraph Breaks" section.
Read before committing — all five suites on the new L1: Elixir 491/0
(seeds 0 7 42) · Haskell 59/0 · korban 222 passed 1 skipped · azazel
125 passed · Prolog 6 suites exit 0. verify_l1.py OK. Four images
built; full local stack (real engine, PostgreSQL with SSL): the witness
reads the scroll and matches, Hebrew 200, English 422, health 7/7,
L3 written, no errors; every image carries f743b34b… read-only.
Nothing consumes the breaks yet: no cycle, scope or answer uses the
parashah. They are in the scroll and in the reader.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Construction §1.2 specified an L1 that was never built: WLC 4.22 from a
Sefaria export cross-validated against TANACH.us, a gematria lookup
table, a squashfs image mounted read-only, a verse format with fields
named `hebrew`, `consonantal`, `cantillation`. Each property was
checked against the sources on disk and the 5,853 verse files before
it was rewritten.
- Edition: WLC 4.20, as the Open Scriptures Hebrew Bible carries it
(every Torah file's header says "Updated to WLC version 4.20").
- Sources: openscriptures/morphhb @ 3d15126 for the text, lemma and
morphology; openscriptures/HebrewLexicon @ 21c9add for the roots.
Licences stated. ONE source for the text — the two-source
cross-validation the section prescribed has not been done, and the
section now says so.
- Builder, extent (5 / 187 / 5,853 / 79,982), the real verse and word
format, ketiv/qere (67 pairs, 64 verses), smikhut (9,203 pairs,
4,106 verses), shoresh (57,487 words, 1,378 roots, by lemma).
- Gematria: not stored; computed when read.
- Petuchah/setumah: in the source (233 + 394 milestones across the five
books), NOT carried into L1 — the builder does not read them. Stated.
- Verification procedure: the six steps that are actually performed —
pinned checkouts, build_l1.py and its counts, the hash, the three
places the hash is bound, root-owned read-only in the images, the
witness and verify_l1.py.
specs/shorashim_terumah.md §E1 matched the old section; corrected
(source, ketiv/qere format, smikhut built, gematria not an index,
paragraph markers ⚠️). l1/README.md no longer says squashfs.
Doorpost @expected_hash 3f6d47a0… → 21f1a4d5…, in this commit, with the
witnessed file that moved it (vayakhel).
Read before committing: Elixir 484/0 (seeds 0, 42); verify_l1.py OK
(l1/README.md is outside the hashed tree); pipeline image reports
specification_identity verified 21f1a4d5…, l1_hash pass.
Left as written: tamid's runbook steps that mount L1 from a squashfs
image; architecture §3.7 and §4's build steps (squashfs, Sefaria);
pekudei's cost line naming Sefaria.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
On the production node a reading of the scroll takes about three
seconds (3310 ms at first start; 0.9 s on the build host). The periodic
re-reading ran inside the GenServer, so once every ten minutes every
cycle and every readiness probe that asked "is L1 intact?" would have
waited those seconds behind it.
The periodic reading is now done by a task that reports back; the
process goes on answering from its last reading meanwhile. The first
reading is still made in the process itself — nobody is answered before
the scroll has been read once — and an explicit recheck/0 is still
synchronous. The next reading is scheduled when one begins, not when it
reports, so a reading that dies silently is not the last.
Two tests: it re-reads on its own in both directions (altered → fail,
restored → tov), and a status call during a periodic reading returns at
once. 484 tests, 0 failures on seeds 0 7 42 99.
Built image, run with a live-mounted scroll: l1_hash pass, /peah/ask
200; then אחד in Devarim 6:4 was changed to אחר while the vessel ran
and the witness asked to read again — L1_INTEGRITY_FAILED, l1_hash
fail, /peah/ask 503.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
L1Reader.verify_integrity/0 read the hash stored in integrity.sha256
and compared that string with the hash compiled into the module. It
never opened a verse. On that comparison of a constant with its own
copy rested `l1_hash: pass`, the Cloud's "L1 corrupted — the cloud is
not visible", and Construction §1.2. A changed verse would have passed
every one of them. Every existing test passed too, because every test
asked about an untouched L1.
- L1Reader.compute_tree_hash/1: SHA-256 over every file under torah/ —
relative path, then bytes — in the order scripts/build_l1.py hashed
them (directories by path, files by name, plain string order). On the
real L1 it yields the pinned 156b1d27…; for a tampered copy it yields
the same hash the Python implementation does.
- VavPipeline.L1Integrity (new, supervised): reads and hashes the scroll
when the pipeline starts (~0.9 s in the image) and again every ten
minutes; logs and signals the assembly when the answer changes.
- verify_integrity/0 now requires BOTH: the recorded hash is the pinned
one, AND the scroll on disk hashes to it (answered from the witness's
last reading; computed on the spot where the witness is not running).
Callers are unchanged — the Shema context, the health check and the
status endpoint all inherit the real check.
- scripts/verify_l1.py: the same reading by hand. KOHEN.md and
KOHEN_PROMPT.md used the hollow comparison as their L1 gate; they now
run this.
- test/tablet38_l1_integrity_test.exs — 9 tests: the hash and its
order; one byte / one added file / one rename each change it; the
witness; and the whole path — with an altered scroll and an untouched
integrity.sha256, verify_integrity fails, health says l1_hash: fail,
and /peah/ask does not answer.
Specs: architecture §2.2 (which had been made to confess the hollow
check in d7520cd) and Construction §1.2 now describe the real one — and
its limit: a change is noticed within ten minutes, not at the instant.
deploy/ARCHITECTURE.md likewise. Doorpost @expected_hash 7e5286b9… →
3f6d47a0…, in this commit, with the witnessed files that moved it
(architecture, vayakhel).
Read before committing: Elixir 483/0 on seeds 0 7 42 99 191243. The
built image, run twice: on the engraved scroll — "read and matches
(928ms)", l1_hash pass, /peah/ask 200; on a copy with ONE LETTER changed
in Bereishit 1:1 and integrity.sha256 untouched — L1_INTEGRITY_FAILED,
l1_hash fail, cloud not readable, /peah/ask 503.
Not done: the Haskell side. Luchot.Firmware.l1ExpectedHash is compared
with nothing; the engine reads L1 without hashing it (that would need a
SHA-256 dependency). The engine is reached only through the pipeline,
which now gates every cycle on the real check.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Architecture §2 described a self-hosted server: Phoenix for L2,
PostgreSQL 16, Ubuntu 24.04 under systemd, rootless Podman isolating
Sanhedrin panels, Erlang distribution between them, systemd timers for
Shabbat and the cycle, L1 on a read-only mount. None of that is what
runs. Each row was checked against the code and the images before it
was rewritten.
§2.1 exact versions (no "9.6+"); Korban and Azazel Processors listed.
§2.2 L1: in every image, root-owned, no write bit; recorded hash
compared before every cycle. L2: a process in the pipeline, not
yet over HTTP and not yet called by the cycle. L3: PostgreSQL 17
managed, append-only by REVOKE.
§2.3 Kubernetes, one pod. OTP supervisors + the Deployment's probes.
Sanhedrin panels are Erlang processes in the pipeline's BEAM — no
container boundary. Message passing within one node; a port to
the engine; a Unix socket to the Talmudic Engine. Logging: stdout
and L3; halt events in memory. ShabbatTimer process, UTC stub.
No cycle timer: erev/voker is a stage of each cycle. The manna
volume.
A DEFECT FOUND BY CHECKING THE L1 ROW, AND FIXED:
The spec said L1 is a read-only filesystem. In all four images the
scroll was owned by the service user, mode 664 — `touch` inside
/mnt/torah succeeded. The process that reads Torah could have rewritten
it. All four Dockerfiles now copy L1 as root and strip every write bit
(dirs 555, files 444). Verified in each image as the service user:
cannot create, append, or delete. The hash is unchanged (it covers
paths and contents, not modes).
A DEFECT FOUND AND NOT FIXED, now written into the spec as it is:
L1Reader.verify_integrity/0 reads the hash stored in integrity.sha256
and compares it with the compiled-in constant. It never hashes the
verse files. `l1_hash: pass` witnesses which L1 was built into the
image, not that the files are unaltered. §2.2 says so in plain words.
deploy/ARCHITECTURE.md: L1 is in the images, not on a volume; the manna
volume is 1 GiB and holds the ledger too; l1-volume.yaml is vestigial.
Doorpost @expected_hash 1cd07079… → 7e5286b9…, in this commit, with the
witnessed file that moved it (architecture).
Read before committing: Elixir 474/0 (seeds 0, 42). Four images
rebuilt; full local stack (real engine binary, PostgreSQL with SSL,
migrations): Hebrew 200, English 422, health 7/7, 2 interpretations in
L3, no errors; talmudic and korban containers start.
Left as written: §1.4 hardware (a 64–128 GB server; the node has 4 GB),
§2.4 external models (Steps 21–22, unbuilt), §4's build steps
("Install PostgreSQL 16"), terumah §B (systemd, squashfs, Caddy,
nftables).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The pin audit (2026-10-04) found Construction §1 wrong in three ways.
1. §1.5's mix.exs block was not the real mix.exs.
phoenix ~> 1.7.11 was never a dependency (the API is Plug on
Bandit); `ecto` is `ecto_sql`; telemetry is transitive (locked
1.4.2, outside the stated ~> 1.2.1); bandit, plug and the sanhedrin
path dependency were missing. The block now matches mix.exs and adds
the versions mix.lock actually builds. Terumah's Elixir table
matched the wrong block and also said postgrex ~0.17.4; corrected.
2. §1.1's component table described a machine that is not the one
running. PostgreSQL 16.2 via apt → 17, managed (17.11 today).
Podman 4.9.3 → Kubernetes/containerd, managed; Podman is used
nowhere. Ubuntu 24.04.1 → what each image is in fact built on
(Ubuntu 22.04 for pipeline and engine, Debian 12 for korban and
talmudic) and the managed node (24.04). rebar3 3.23.0 → 3.22.0, the
version in the build image. Azazel Processor added as a component.
The spec is corrected to the deployment, not the reverse.
3. §1.1's rule — "No >=. No +. No ranges." — was not true of the spec's
own Elixir deps, and "lock files are committed" was not true of two
components. Both halves fixed:
- The rule now says what is the case: a manifest may give a range;
the committed lock is the pin; every image is built from its
lock; base images are pinned by tag; managed services are pinned
to a major version and patched by the provider.
- And the build was made to obey it. The Korban image installed
three packages named by hand and let pip pick every transitive
one on the day of the build, plus an unpinned poetry-core. It now
installs the lock's main group by exact version AND hash
(scripts/lock_to_requirements.py; --require-hashes --no-deps;
pip check). The image holds the lock's 12 packages and nothing
else.
- azazel_processor/poetry.lock: generated (it had none).
- kushya_generator/pyproject.toml + poetry.lock: the four §1.4 pins
(llama-cpp-python 0.2.55, peft 0.9.0, transformers 4.38.2,
datasets 2.17.1) were pinned nowhere in the repo. They are now
declared and locked (74 packages). The lock resolves; it has NOT
been installed or run — Step 21 is unbuilt and needs a GPU.
Its test config gains the korban and azazel source paths, which
the external backend needs: 3 tests there had been failing since
the azazel build, unnoticed because that suite is in no total.
Doorpost @expected_hash 39b66c31… → 1cd07079…, in this commit, with the
witnessed file that moved it (vayakhel).
Read before committing: Elixir 474/0 (seeds 0, 42) · korban 222 passed
1 skipped and azazel 125 passed, each with dependencies installed from
its lock by hash · kushya 17 passed (was 14 of 17) · korban image
starts, imports korban_processor + azazel_processor, pip check clean ·
pipeline image reports specification_identity verified 1cd07079….
Left as written: architecture §2's technology table still names
Phoenix, PostgreSQL 16, Ubuntu 24.04 and rootless Podman for Sanhedrin
isolation, and terumah §B still lists systemd, squashfs, Caddy,
nftables for a self-hosted server. Those describe a design, not a pin.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Construction §1.3 is headed "Haskell Dependencies (Exact)" and shows an
excerpt of cabal.project.freeze. Six of its nine versions were not the
ones in the committed freeze file:
aeson 2.2.1.0 → 2.2.3.0
vector 0.13.1.0 → 0.13.2.0
bytestring 0.12.1.0 → 0.12.2.0
filepath 1.4.200.1 → 1.4.301.0
directory 1.3.8.4 → 1.3.10.1
hspec 2.11.7 → 2.11.16
base 4.18.2.0, containers 0.6.7 and text 2.0.2 already agreed. The
freeze file has not changed since Phase 1 (ae78ed2) and every engine
image has been built from it; the build plan inside the build image
(dist-newstyle/cache/plan.json, GHC 9.6.4) lists exactly these nine
versions. The spec is corrected to the freeze, not the freeze to the
spec: the freeze is the tested vessel.
- specs/shorashim_vayakhel.md §1.3: the six versions.
- specs/shorashim_terumah.md §D: the same, plus rows for filepath and
directory; bytestring was marked "ships with GHC" — GHC 9.6.4 ships
0.11.5.3, and the freeze pins a newer one from Hackage.
- Doorpost @expected_hash 5094e48e… → 39b66c31…, in this commit, with
the witnessed file that moved it (vayakhel).
Read before committing: Elixir 474/0 on seeds 0 and 42; the built
pipeline image reports specification_identity verified 39b66c31….
No engine change: the engine image is untouched.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Architecture §3.1 listed base, containers, text, aeson, vector. The
cabal file also depends on bytestring, filepath and directory (the
engine reads L1 from disk and speaks JSON lines over a port), and on
hspec for the test suite. Construction §1.3 already named all of them;
the architecture list had simply not kept up.
The list now matches shoresh-engine.cabal, says what each package is
for, and says where the versions are pinned. One entry is marked as it
is: `vector` is declared and no module imports it.
Doorpost @expected_hash f653ef05… → 5094e48e…, in this commit, with the
witnessed file that moved it (architecture).
Read before committing: Elixir 474/0 on seeds 0 and 42; the built
pipeline image reports specification_identity verified 5094e48e….
Seen while checking, not changed: Construction §1.3's "exact" Haskell
versions disagree with the committed cabal.project.freeze for six of
nine packages (aeson 2.2.1.0 vs 2.2.3.0, vector 0.13.1.0 vs 0.13.2.0,
bytestring 0.12.1.0 vs 0.12.2.0, filepath 1.4.200.1 vs 1.4.301.0,
directory 1.3.8.4 vs 1.3.10.1, hspec 2.11.7 vs 2.11.16). The freeze is
what every image has been built from.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Architecture §3.1 typed a root as exactly three consonants
(`Shoresh {c1,c2,c3}`) and listed data/roots.json and
data/torah_refs.json in the engine's file tree. L1 has 115 roots that
are not three letters (32 of two, 83 of four or more), and the engine
has no data directory: the roots are in L1.
The code had followed the spec's type and paid for it. textToShoresh
padded a two-letter root with He — בן became בנה, כל became כלה — and
returned Nothing for anything longer, so Lexicon.buildLexiconFromVerses
either falsified those roots or dropped them. Shoresh.Roots (tablet 33)
had stepped around the type by carrying roots as Text.
Spec:
- §3.1 data structures: `newtype Shoresh = Shoresh { radicals ::
[Consonant] }` — two or more, never padded or truncated; `mkShoresh`,
`triliteral`.
- relatedRoots / neighbors: same length, differing in exactly one
consonant (for a root of three, the old "sharing 2 consonants").
- File tree: Roots.hs and Server.hs added; data/ removed, with a line
saying where the roots are; cabal.project.freeze listed; aeson's
purpose corrected.
Engine:
- Types: the newtype, mkShoresh :: [Consonant] -> Maybe Shoresh,
triliteral, textToShoresh without padding.
- Gematria: sum over the radicals. Graph: neighbors among roots of the
same length; neighborsByPosition labels the shared positions
("c1c2" for a triliteral, as before).
- Server: consonant names through the type.
- Spec.hs: בן stays two letters (gematria 52, not 57); שמאל is held
whole; the graph compares only roots of equal length. 59 examples.
Doorpost @expected_hash 094b8164… → f653ef05…, in this commit, with the
witnessed file that moved it (architecture).
Read before committing: Haskell 59/0; Elixir 474/0 on seeds 0 7 42;
both images built and run together with the real binary — Shemot 3:14
answers ב-ן (two letters), Bereishit 48:13 answers ש-מ-א-ל (four),
Devarim 6:5 unchanged; local specification_identity verified
f653ef05…; no engine errors or fallbacks.
Not touched: §3.1's dependency list omits bytestring, filepath and
directory, which the cabal file has.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The MannaLedger counted the day's consumption in memory. A restart
forgot it, and the next cycle gathered the same day's provision whole.
While manna was an emptyDir that took the kohen's hand; with the
provision on a volume (41a3e51) a crash loop alone would have refilled
the jar, once per crash. Ish l'fi ochlo — Shemot 16:18.
- After every cycle that eats, the day's consumption is written to
ledger.json beside the provision file (tmp + rename; on the manna
volume in production).
- A process that starts while today's record is on disk takes the day
up at once (handle_continue), so /kodesh/status never shows an
untouched jar that is half eaten; otherwise the first load of the day
resumes from it.
- Another day's record is ignored. A record that is not a ledger
(bad JSON, negative or non-integer counts) is ignored with a warning.
The record can only reduce what remains.
- At the day boundary the record goes with the surplus. A release
within the same day (the late-provision re-gather) lets go of the
allocation and keeps the record.
- If the file cannot be written the ledger says so and keeps counting
in memory; the cycle is not stopped by its own bookkeeping.
- MannaLedger.reset/0 (tests) forgets the record; test_helper clears
any record an interrupted run left behind.
test/manna_ledger_persistence_test.exs — 13 tests, restarting the
ledger under its real supervisor. All fail without the change.
Read before committing: Elixir 474/0 on seeds 0 7 42 99 191243. Built
image, real container restarts against a mounted manna directory:
3 of 5 units eaten → restart → status shows 3 before any request →
2 more served, the 6th refused → restart → still refused.
Found while writing the tests, not changed: killing the ledger more
than three times in five seconds takes the whole application down (OTP
restart intensity, one_for_one defaults). On the pod that is a
container restart — which now resumes the day instead of refilling it.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Manna was an emptyDir: every pod creation emptied it and the vessel sat
unready until the kohen wrote the day's portion again. On 2026-10-04
that happened seven times in one day of rollouts. deploy/ARCHITECTURE.md
has always specified a block-storage volume for it and manna-volume.yaml
has always defined the claim; it was "not applied at Day 3" and stayed
that way.
- manna-volume.yaml: storageClassName exoscale-sbs (the cluster's only
class is not marked default — without it the claim stays Pending),
1Gi. Applied; bound in 6 s.
- deployment.yaml: the manna volume is the manna-pvc claim. `kubectl
diff` against the live deployment showed this as the only change.
- KOHEN.md: apply order (the claim before the pod), and the daily-ops
note — write once a day, not once per restart.
Verified on the live pod: manna written once onto the volume; then a
rollout restart with NO provision written by anyone — the new pod was
Ready and serving 49 s later, health 7/7, /peah/ask 200.
What this does not change: the portion still expires by its own date
and expires_at (Shemot 16:19-20). And the ledger is in memory — a
restarted pod counts consumption from zero against the same day's
allocation, as it always did; that is now reachable without the kohen's
hand, and is recorded as open.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Architecture §3.1 said the Shoresh Engine "encodes the ~500 Biblical
Hebrew triliteral roots", its file tree called Lexicon.hs "the ~500
roots with entries", and terumah §E2 listed a "~500 roots" lexicon as
material still to be consolidated (~1-2 weeks).
Since tablet 34 the roots are read, and can be counted. L1 carries
1,378: 1,243 roots under which Brown-Driver-Briggs files a lemma, and
135 words that stand alone under no root. 1,263 are triliteral, 32 have
two letters, 83 have four or more. And the engine does not hold a list
of them — it reads them from L1 (Shoresh.Lexicon, Shoresh.Roots).
- specs/shorashim_architecture.md §3.1: the Purpose sentence says where
the roots come from and how many there are; the Lexicon.hs line in
the file tree likewise.
- specs/shorashim_terumah.md §E2: the root lexicon is in hand (✅) —
the OSHB Hebrew Lexicon is exactly the BDB + Strong's consolidation
the row was waiting for; moved from "need to acquire" to "in hand".
- Doorpost @expected_hash 2f40c382… → 094b8164…, in this commit, with
the witnessed file that moved it (architecture).
Read before committing: Elixir 461/0 on 11 of 12 runs (seed 0 ×6 and
six other seeds). One run of seed 0 reported a single failure that was
not captured and did not recur in eleven further runs; unidentified,
recorded in the build log. Pipeline image reports
specification_identity verified 094b8164… and l1_hash pass.
Left as written, and no longer true of the build: §3.1's data
structures still type a root as exactly three consonants, and its file
tree still lists data/roots.json and data/torah_refs.json, which do
not exist — the roots live in L1.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Architecture §3.5 listed a Python-Prolog FFI among the Korban
Processor's dependencies ("swipl-ffi (or pyswip)"); Construction §1.4
and terumah pinned pyswip. It was declared, installed in every image,
and never imported. The Korban Processor does not call Prolog: haktarah
emits Prolog-format STRINGS, and the pipeline carries them to the
Talmudic Engine over its Unix socket (Construction §3.3). The korban
image has no libswipl, so the package could not have been used there
had anything tried. Tablet 35 corrected its version; the transmitter's
word is to remove it.
Removed from:
- specs/shorashim_architecture.md §3.5 requirements
- specs/shorashim_vayakhel.md §1.4
- specs/shorashim_terumah.md (materials row; the compatibility-testing
line now names hebrew-tokenizer alone)
- BUILD_KORBAN.md
- korban_processor/pyproject.toml, poetry.lock (regenerated)
- deploy/docker/Dockerfile.korban_processor
Doorpost @expected_hash 81da49d4… → 2f40c382…, in this commit, with the
three witnessed files that moved it (architecture, vayakhel,
BUILD_KORBAN).
Read before committing: Elixir 461/0 (seeds 0, 42); korban 222 passed,
1 skipped against the installed package with pyswip absent; korban
image starts and idles as before; vav-pipeline image reports
specification_identity verified 2f40c382… and l1_hash pass.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
