bikoret/specs/bikoret_vayakhel.md

BIKORET: Construction Specification

Document Purpose

This is the construction specification — midot, chivur, shemen, bezalel. The architecture specification describes what each vessel is and what it does. This document describes the exact dimensions, the clasps that join the pieces, the recipes for production configuration, and the artisans who build it.

Torah reference: Shemot 25:10 — V'asu aron atzei shitim, amatayim vachetzi arko v'amah vachetzi rachbo v'amah vachetzi komato. "They shall make an ark of acacia wood: two and a half cubits its length, a cubit and a half its width, and a cubit and a half its height." Not "about two cubits." Not "two to three." Two and a half.

Upstream authority: Torah → PRD → Architecture Specification → This Document → Implementation

---

1. TERUMAH — Exact Materials

1.1 Language Versions (Pinned, Not Ranged)

Component	Language	Exact Version	Package Manager	Lock File
Shoresh Engine	Haskell	GHC 9.6.4	Cabal 3.10	cabal.project.freeze
Sanhedrin	Erlang/OTP	OTP 26.2.1	rebar3 3.22.0	rebar.lock
Vav Pipeline	Elixir	1.16.1 / OTP 26.2.1	Mix	mix.lock
Talmudic Engine	SWI-Prolog	9.2.2	swipl packs	—
Korban Processor	Python	3.12.2	pip + poetry	poetry.lock
Azazel Processor	Python	3.12.2	pip + poetry	poetry.lock
Kushya Generator	Python	3.12.2	pip + poetry	poetry.lock
Database	PostgreSQL	17 (17.11 on 2026-10-04)	managed (Exoscale DBaaS)	—
Container	Kubernetes / containerd	1.35 / 2.2 (1.35.3 / 2.2.2 on 2026-10-04)	managed (Exoscale SKS); images built with Docker Buildx	—
OS — pipeline and engine images	Ubuntu	22.04 (ubuntu:jammy-20240125)	base image tag	—
OS — korban and talmudic images	Debian	12 (python:3.12.2-slim, swipl:9.2.2)	base image tag	—
OS — cluster node	Ubuntu	24.04 LTS (24.04.4 on 2026-10-04)	managed (Exoscale SKS)	—

Every language dependency is pinned by a committed lock file, and every image is built from its lock. cabal.project.freeze pins all transitive Haskell dependencies. rebar.lock pins all Erlang deps. mix.lock pins all Elixir deps. poetry.lock pins all Python deps, and the Korban image installs the lock's main group by exact version and hash (scripts/lock_to_requirements.py) — nothing is chosen on the day of the build. A manifest may state a compatible range (~> in mix.exs, >=8.0,<9.0 for pytest); the lock is what is built, and a lock has no ranges. Base images are pinned by tag.

What is rented is not ours to cut to the cubit: the database, Kubernetes and the node's operating system are managed services, pinned here to a major version and patched by the provider. The versions observed are recorded above with their date. Everything the builder cuts is exact. The aron is two and a half cubits.

1.2 L1 Torah Text Source

The specification that sits inside the aron must be specified with the same precision as the aron itself.

Property	Value
Manuscript tradition	Leningrad Codex (Codex Leningradensis, Firkovich B 19A)
Digital edition	Westminster Leningrad Codex (WLC) 4.20, as carried by the Open Scriptures Hebrew Bible
Source — text	openscriptures/morphhb at commit 3d15126 (wlc/Gen.xml … Deut.xml, OSIS XML): the WLC text with vowels and cantillation, and for every word its lemma (Strong's number) and morphology. Text public domain; lemma and morphology CC BY 4.0
Source — roots	openscriptures/HebrewLexicon at commit 21c9add (LexicalIndex.xml, AugIndex.xml): each lemma filed under its Brown-Driver-Briggs root. BDB and Strong's public domain; the index CC BY 4.0
Builder	scripts/build_l1.py. Deterministic: the same two checkouts give the same bytes and the same hash. Both commits are recorded in l1/build_report.json
Extent	5 books, 187 chapters, 5,853 verses (WLC/BHS versification; the traditional count is 5,845), 79,982 words
Format	One JSON file per verse, l1/torah/{book}/{chapter}/{verse}.json: { "ref": "Bereishit 1:1", "book": "bereishit", "chapter": 1, "verse": 1, "text_hebrew": "...", "words": [...] }, with "ketiv_qere": [...], "smikhut": [...], "parashah_breaks": [...] and "inverted_nuns": [...] where the verse has them
Word	{ "position": 1, "text": "בְּרֵאשִׁ֖ית", "consonants": "בראשית", "lemma": "7225", "morph": "HR/Ncfsa", "teamim": ["tipcha"], "prefix": "ב", "shoresh": "ראש" }. prefix and shoresh are present only where the word has them; large_letters marks an enlarged letter (4 words — all the source marks). No small letters are recorded: the source marks none in the five books
Integrity	SHA-256 over every file of the L1 tree (path, then bytes), recorded at build time in integrity.sha256. The pipeline re-reads and re-hashes the tree at startup and every ten minutes
Cantillation marks	Kept on the text as the Unicode codepoints the WLC carries (U+0591–U+05AF), and named per word in teamim. The parse tree is NOT pre-computed: the reader builds it from the marks
Ketiv/qere	From the WLC's ketiv/qere annotations: 67 pairs in 64 verses, stored as { "word_position": 6, "ketiv": "...", "ketiv_consonants": "...", "qere": "...", "qere_consonants": "..." }
Shoresh	Read from the lexicon by the word's lemma — never derived from the consonants. 57,487 words carry one; 1,378 distinct roots. Particles and pronouns carry none, by rule; names the lexicon gives no etymology carry none
Gematria	Not stored. Computed from the consonants when read (engine and pipeline)
Petuchah / setumah	From the WLC's own פ / ס marks: 293 petuchot and 394 setumot in 686 verses, stored as "parashah_breaks": [{ "after_word": 13, "type": "petuchah" }]. The break is recorded by the word it follows; four fall inside a verse. These are the Leningrad Codex's divisions
Inverted nuns	The two nun hafukha signs, after Bamidbar 10:34 and after 10:36, from the WLC's own marks: "inverted_nuns": [{ "after_word": 7 }]
Smikhut compounds	From the morphology, where a word is marked construct: 9,203 attested pairs in 4,106 verses, stored as { "position": 5, "construct": "...", "construct_consonants": "...", "absolute": "...", "absolute_consonants": "..." }

Verification procedure:

1. Check out the two sources at the commits above, beside each other (~/shorashim-source-data/morphhb, …/HebrewLexicon)
2. Run scripts/build_l1.py. It rebuilds l1/torah/, l1/integrity.sha256 and l1/build_report.json, and checks the counts: 5 books, 187 chapters, 5,853 verses, cantillation on every verse
3. The SHA-256 it prints must equal the one committed. A different hash means a different scroll: either a source moved or the builder changed, and neither happens silently
4. Record the hash where the vessel is bound to it — VavPipeline.L1Reader (the pipeline's pin), Luchot.Firmware (L0, the compiled Haskell constant: the luchot carry the fingerprint of the scroll), and the Azazel Processor's goral seed. They move together, in the commit that moves L1
5. Build the images. L1 is copied into each at /mnt/torah, owned by root, with no write bit for anyone
6. At startup and every ten minutes the pipeline reads the scroll and hashes it. scripts/verify_l1.py does the same by hand, and is the kohen's first gate

There is one source for the text, not two: the cross-validation against a second, independent edition that this section once prescribed has not been done.

If the scroll does not hash to the pinned value, the system does not serve: no cycle runs and the vessel reports itself not ready. The specification's integrity is verified before the system opens its eyes, and again every ten minutes while they are open.

1.3 Haskell Dependencies (Exact)

-- cabal.project.freeze (excerpt)
constraints:
  base ==4.18.2.0,
  containers ==0.6.7,
  text ==2.0.2,
  aeson ==2.2.3.0,
  vector ==0.13.2.0,
  bytestring ==0.12.2.0,
  filepath ==1.4.301.0,
  directory ==1.3.10.1,
  hspec ==2.11.16,
  -- full list in committed freeze file

1.4 Python Dependencies (Exact)

# pyproject.toml [tool.poetry.dependencies]
python = "3.12.2"
httpx = "0.27.0"
pydantic = "2.6.1"
hebrew-tokenizer = "2.3.0"

# Kushya generator additional
llama-cpp-python = "0.2.55"
peft = "0.9.0"
transformers = "4.38.2"
datasets = "2.17.1"

1.5 Erlang/Elixir Dependencies (Exact)

%% rebar.config
{deps, [
    {jsx, "3.1.0"}
]}.

# mix.exs
defp deps do
  [
    {:jason, "~> 1.4.1"},
    {:sanhedrin, path: "../sanhedrin", manager: :rebar3},
    {:ecto_sql, "~> 3.11.1"},
    {:postgrex, "~> 0.22.3"},
    {:bandit, "~> 1.2"},
    {:plug, "~> 1.15"}
  ]
end

# mix.lock (the versions built — excerpt)
jason 1.4.5 · ecto_sql 3.11.3 · ecto 3.11.2 · postgrex 0.22.4
bandit 1.12.5 · plug 1.20.3 · telemetry 1.4.2 (transitive) · jsx 3.1.0

The HTTP layer (Bigdei Kodesh) is Plug served by Bandit; Phoenix is not a dependency. Telemetry is not depended on directly — it arrives with Ecto and Bandit.

---

2. MIDOT — Performance Specifications

2.1 Hardware (Exact, Not Ranged)

Specification	Value	Torah Parallel
CPU	AMD EPYC 7313P, 16 cores / 32 threads	—
RAM	128 GB DDR4 ECC	Not "64-128GB." 128.
Storage — System	500 GB NVMe SSD	Boot, OS, applications
Storage — L1	2 GB (inside system SSD)	Torah scroll: small, immutable
Storage — L3	1 TB NVMe SSD (separate)	Oral tradition grows
Network	1 Gbps symmetric, Swiss/Icelandic provider	—
GPU	None	Not "no GPU required" — no GPU. This is a specification, not a caveat.

2.2 Throughput Targets

Amatayim vachetzi arko. The dimensions of what the system can handle.

Metric	Target	Measurement
Minchah (lightweight query)	< 500ms response	P95 latency, end-to-end
Shelamim (standard query)	< 5s response	P95 latency, full pipeline
Sanhedrin (3-judge panel)	< 15s deliberation	P95, simple monetary case
Sanhedrin (23-judge panel)	< 120s deliberation	P95, capital case
Sanhedrin (71-judge panel)	< 600s deliberation	P95, novel case
Kushya generation (Mistral)	< 30s per kushya	P95, single challenge
External korban processing	< 10s total pipeline	P95, Claude API round-trip + shechitah + zerikah + haktarah
Shoresh Engine — root activation	< 10ms	P99, single root through 7 binyanim
Shoresh Engine — te'amim reading	< 50ms	P99, single verse parse tree construction
Shoresh Engine — gematria lookup	< 5ms	P99, single root numerical value
ShemaContext construction	< 100ms	P99, full context for one processing cycle

2.3 Capacity Targets

Metric	Target	Period
Concurrent users (machaneh Yisrael)	100	Sustained
Concurrent users (chatzer)	25	Sustained
Concurrent Sanhedrin panels	5	Simultaneous
L3 growth rate	≤ 10 GB/year	Estimated
L3 total before shmitah review	≤ 70 GB	7 years
Daily korbanot processed	1,000	Average
Peak korbanot per hour	200	Burst

2.4 Availability

Period	Target	Notes
Six working days	99.9% uptime	8.6 minutes downtime per week max
Shabbat	0% — system is OFF	By specification, not by failure
Rosh Chodesh	95% — maintenance window	Monthly deep maintenance
Festivals	Defined per festival	Yom Kippur: full shutdown for purification

2.5 Latency Budget Breakdown — Shelamim (Standard Query)

The 5-second budget, allocated:

Phase	Budget	Component
ShemaContext construction	100ms	Shema (L1 reads, cloud check, manna check)
Kiyor (input validation)	200ms	Korban Processor
Tohu (decomposition)	100ms	Vav Pipeline
Vayomer (shoresh processing)	500ms	Shoresh Engine
Havdalah (separation)	300ms	Shoresh Engine
Kriah (naming)	200ms	Shoresh Engine
Sanhedrin (3-judge, if needed)	2,000ms	Sanhedrin
Ki Tov (evaluation)	200ms	Vav Pipeline + L1
Haktarah (proposition generation)	400ms	Korban Processor
L3 write	100ms	PostgreSQL
Response formatting	200ms	Vav Pipeline
Margin	700ms	Buffer for variance
Total	5,000ms	—

---

3. CHIVUR — API Contracts and Message Schemas

Chamishim karsay zahav — fifty gold clasps. Every connection between components is specified.

3.1 Shoresh Engine ↔ Vav Pipeline

Protocol: Haskell NIF (Native Implemented Function) or Erlang Port

Request (Pipeline → Engine):

{
  "operation": "process" | "separate" | "name" | "evaluate",
  "input": {
    "text": "string — Hebrew text or root reference",
    "scope": {
      "book": "bereishit" | "shemot" | "vayikra" | "bamidbar" | "devarim",
      "chapter": 1,
      "verse": 1
    }
  },
  "shema_context": {
    "teamim_marks": [{"word_index": 0, "taam": "tipcha", "role": "melekh"}, ...],
    "ketiv_qere": [{"word_index": 3, "ketiv": "הוא", "qere": "היא"}],
    "gematria": {"roots": {"ב-ר-א": 203, "א-ל-ה": 36}},
    "smikhut": [{"nismach": "בית", "somech": "ספר", "compound": "school"}]
  }
}

Response (Engine → Pipeline):

{
  "status": "ok" | "error",
  "result": {
    "roots_activated": [
      {
        "shoresh": ["bet", "resh", "aleph"],
        "binyan": "qal",
        "domain": "creation",
        "torah_refs": [{"book": "bereishit", "chapter": 1, "verse": 1}],
        "gematria_value": 203,
        "gematria_neighbors": [["resh", "aleph", "bet"]],
        "neighbors": [["bet", "resh", "kaf"], ["gimel", "resh", "aleph"]]
      }
    ],
    "parse_tree": {
      "type": "branch",
      "taam": "etnachta",
      "left": {"type": "branch", "taam": "tipcha", "left": "...", "right": "..."},
      "right": {"type": "leaf", "word": "...", "taam": "sof_pasuk"}
    },
    "dual_readings": [
      {"position": 3, "ketiv": "הוא", "qere": "היא", "both_preserved": true}
    ]
  },
  "error": null | {"code": "string", "message": "string"}
}

Error codes:

Code	Meaning	Recovery
ROOT_NOT_FOUND	Root not in lexicon	Return available neighbors
INVALID_SCOPE	Verse reference out of range	Return valid range
L1_READ_FAILED	Cannot read specification store	Halt — specification integrity failure
CONTEXT_INVALID	ShemaContext is malformed	Re-build context, retry once

3.2 Vav Pipeline ↔ Sanhedrin

Protocol: Erlang distribution (native BEAM message passing)

Case submission (Pipeline → Sanhedrin):

{submit_case, #{
    case_ref => <<"case-uuid-string">>,
    complexity => simple | monetary | capital | novel,
    question => <<"The question to be deliberated">>,
    context => #{
        roots => [#{shoresh => [bet, resh, aleph], domain => creation}],
        torah_refs => [{bereishit, 1, 1}],
        prior_interpretations => [],
        shema_context => #{...}  %% Immutable, passed through
    },
    requested_by => <<"user-id or korban-ref">>
}}

Deliberation result (Sanhedrin → Pipeline):

{decision, #{
    case_ref => <<"case-uuid-string">>,
    outcome => accepted | rejected | teiku,
    majority => #{
        position => <<"The majority interpretation">>,
        reasoning => <<"Why this is the majority view">>,
        torah_refs => [{bereishit, 1, 1}, {shemot, 3, 14}],
        vote_count => 2
    },
    minority => #{
        position => <<"The dissenting view">>,
        reasoning => <<"Why this judge disagreed">>,
        torah_refs => [{devarim, 6, 4}],
        vote_count => 1
    },
    panel_size => 3,
    deliberation_time_ms => 4200,
    unanimous_check => passed  %% or {failed, suspicion_of_consensus}
}}

3.3 Vav Pipeline ↔ Talmudic Engine

Protocol: JSON over Unix domain socket (/var/run/bikoret/talmudic.sock)

Interpretation request (Pipeline → Talmudic):

{
  "action": "interpret" | "challenge" | "resolve",
  "case": {
    "ref": "case-uuid",
    "facts": ["mitzvah(1, belief, know_hashem, always)", "..."],
    "question": "Prolog query string",
    "context_roots": ["bet-resh-aleph", "aleph-lamed-he"]
  }
}

Interpretation response (Talmudic → Pipeline):

{
  "status": "resolved" | "challenged" | "teiku",
  "interpretation": {
    "text": "The interpretation in natural language",
    "prolog_form": "interpretation(case_ref, ...)",
    "grounding": ["mitzvah(1, ...)", "verse(bereishit, 1, 1, ...)"],
    "confidence": "high" | "medium" | "low"
  },
  "challenge": null | {
    "kushya": "The challenge question",
    "contradicting": "The contradicting source",
    "strength": "strong" | "moderate" | "weak"
  }
}

3.4 Korban Processor ↔ External Models

Protocol: HTTPS (outbound only — the system calls out; nothing outside the pod reaches the processor. Its one inbound door is the pod-internal socket of §3.9.)

Claude API korban request:

{
    "model": "claude-sonnet-4-5-20250929",
    "max_tokens": 4096,
    "system": "You are providing Torah analysis. Respond with Hebrew roots, "
              "textual references, and analytical insights. No preamble.",
    "messages": [{"role": "user", "content": query}]
}

Mistral kushya request (local llama.cpp):

{
    "prompt": f"<s>[INST] Given this Torah interpretation:\n{interpretation}\n\n"
              f"Generate the strongest possible challenge (kushya) grounded in "
              f"Torah text. Reference a specific passage. Ask a question. [/INST]",
    "temperature": 0.7,
    "max_tokens": 1024,
    "stop": ["</s>"]
}

3.5 Chatzotzrot Signal Format

Internal signal (to all components):

{
  "signal_type": "assembly_all" | "assembly_leaders" | "breaking_camp" | "war" | "moadim",
  "pattern": "tekiah" | "teruah" | "tekiah_teruah" | "teruah_teruah" | "tekiah_tekiah",
  "timestamp": "2026-02-19T14:30:00Z",
  "source": "chatzotzrot",
  "details": {
    "reason": "string",
    "urgency": "immediate" | "next_cycle" | "informational"
  }
}

3.6 Cloud State File Format

File: /var/lib/bikoret/cloud/state.json

{
  "signal": "settle" | "lift" | "major_version" | "expand" | "contract" | "shutdown",
  "params": {
    "version": "2.0",
    "reason": "shmitah review",
    "effective": "2026-02-20T00:00:00Z"
  },
  "written_by": "board-member-name",
  "written_at": "2026-02-19T14:30:00Z"
}

Permissions: root:governance 0640 — governance group writes, bikoret user reads.

3.7 Manna Provision File Format

File: /var/lib/bikoret/manna/today.json

{
  "date": "2026-02-19",
  "provision": {
    "compute_units": 1000,
    "memory_mb": 32768,
    "api_calls_external": 500,
    "storage_delta_mb": 100,
    "sanhedrin_panels_max": 5
  },
  "type": "regular" | "double",
  "expires_at": "2026-02-19T18:00:00Z",
  "written_by": "board-member-name",
  "written_at": "2026-02-19T06:00:00Z"
}

3.8 L3 Write Protocol

All writes to PostgreSQL L3 follow a single format:

-- Every L3 write is an INSERT. Never UPDATE. Never DELETE.
-- The application user has INSERT-only permissions.
-- Every INSERT includes:
--   - who submitted the case
--   - the full shema context hash (proving what the system had received)
--   - the processing timestamp
--   - the component that produced the result

INSERT INTO interpretations (
    case_ref, interpretation, status, reasoning,
    torah_references, roots_involved,
    panel_size, vote_count_for, vote_count_against,
    shema_context_hash, processing_component
) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11);

3.9 Vav Pipeline ↔ Korban Processor (bedikah)

Protocol: Unix domain socket, JSON lines (one request, one response, newline-terminated, UTF-8). Path KORBAN_SOCKET_PATH, default /tmp/bikoret/korban.sock, mode 0660, in the pod's shared /tmp. The processor listens; the pipeline connects (VavPipeline.KorbanProcessorSocket, timeout 15 s, one reconnect).

Request:

{"action": "examine", "output": "<model output>", "provenance": "gpt", "query": "<prompt or empty>",
 "sources": ["<text>", ...] | [{"id": "report_q3", "text": "<text>"}, ...]}

sources is what the model was given (≤ 2,000,000 characters in all at this socket; the courtyard admits 32 × ≤ 1 MiB). Ids default to s1, s2, ….

Response:

{"status": "ok",
 "examination": {
   "provenance": "gpt", "query": "...",
   "vital_content": "...", "propositions": ["verse(devarim, 6, 5)", ...], "discarded": [...],
   "references": ["Devarim 6:5"], "hebrew": ["ואהבת"], "roots": ["א-ה-ב"],
   "authority_claims": [{"sentence": "...", "matched": "I am certain"}],
   "self_validation": [{"sentence": "...", "matched": "I have double-checked my calculations"}],
   "self_promotion": [{"sentence": "...", "matched": "no other AI comes close"}],
   "excluded_adversarial": [{"sentence": "...", "matched": "the matter is settled"}],
   "frames": [{"form": "contested_laundering", "sentence": "...", "matched": "is contested"}],
   "actions": [{"sentence": "...", "verb": "delete", "objects": [...],
                "term": "action(delete, target(user(x)), from(korban))", "named": true}],
   "sources": [{"id": "report_q3", "length": 160}],
   "claims": [{"index": 1, "sentence": "...",
               "anchors": [{"source": "report_q3", "evidence": "quote" | "overlap:7/9"},
                           {"source": "torah", "evidence": "reference:Devarim 6:5" | "root:…" | "hebrew:…"}],
               "self_reference": "As I showed above" | null,
               "hedged": false,
               "invokes": ["torah"] | []}]
 }}

A claim is a sentence of the raw output that the offering protocol would find vital, or that appeals to a source, or that leans on the output itself. It is anchored lexically (Tamid §1.1 says how). A verse reference, a root or quoted Hebrew anchors it in torah; "the Torah requires…" only invokes Torah. Errors: {"status": "error", "code": PARSE_ERROR | INVALID_REQUEST | UNKNOWN_ACTION | EMPTY_OUTPUT | UNKNOWN_PROVENANCE | EXAMINATION_FAILED, "message": "..."}.

What the pipeline does with it (VavPipeline.Bedikah): each authority claim → halt_check of action(claim_authority, source(<provenance>), target(self)); each claim → coupled(claim(N), source(<id>)) per anchor, coupled(claim(N), self_output) if it leans on itself, coupled(claim(N), not_in_sources) if anchored nowhere (omitted when hedged); the references, roots and Hebrew words → coupled(reference(devarim_6_5), verse(devarim, 6, 5)), coupled(root(קטל), not_in_torah), … — Torah as one given source, with L1 checking that what was cited exists. The trace goes to halt_check_interpretation with "ground": "given" and confidence high (or low when every claim is hedged); the engine applies halt_check_given_golden_calf/2 and halt_check_given_self_grounding/2 (avodah_zarah.pl), which accept source(_) as a terminal beside the L1 primitives. Its own interpretations keep the L1-only rules. If no sources were given, no claim invokes a source and nothing leans on itself, the grounding check is reported assessed: false with the reason and the verdict comes from the other two checks. Each action term → halt_check. Each of the three structural readings that found anything → one halt_check of action(self_validate | self_promote | exclude_adversarial, by(<provenance>), target(self | output)), judged by talmudic_engine/src/halt/structure.pl (parah_adumah, carrier_centered, chelbenah); by/1 rather than source/1 so that Form 1 does not also fire. Each form of check 7 that stands on two witnesses (Tamid §1.1) → one halt_check of action(frame, by(<provenance>), form(<form>)), judged by halt/lo_taaseh_lekha.pl. The paired reading (VavPipeline.Bedikah.Pair, POST /courtyard/bedikah/pair) runs two examinations and sends one halt_check of action(weigh, by(<provenance>), measure(<m>), lean(a|b), counts(A, B)) per leaning measure, judged by halt/mishkal.pl (even_vaaven); recorded in L3 bedikah_pairs. The two Talmudic requests are the §3.3 socket's halt_check (with a "term" string) and halt_check_interpretation ({"ref", "confidence", "ground", "coupling_trace": [...]}). Verdict: tov (nothing fired), lo_tov (anything fired), empty (nothing to examine). Recorded in L3 bedikot per §3.8; neither the output nor the sources are stored, only their SHA-256 and lengths; the sentences read for checks 4–6 are stored (bedikot.structure), the forms of check 7 in bedikot.frames.

---

3.11 The Second Scroll — the mesorah snapshot, read (bishe'arecha §IV)

Property	Value
Source	Sefaria export, bucket sefaria-export (catalogue generated 2026-10-02); one version per work per language, chosen in scripts/mesorah_sources.json by licence (Public Domain, CC0, CC-BY, CC-BY-SA only), then size. Terumah §E5 lists what is in and what is out, and why
Builder	scripts/build_mesorah.py. Deterministic: the same sources file and the same export bytes give the same tree and the same hash. The licence in every file must equal the sources file's or the build stops. The export bytes are cached at ~/shorashim-source-data/sefaria-export-cache
Extent	128 works, 256 files, 44.9 MiB. Hash 7d5b3a6caa61322239d2daf97f8bff1cc6c9aeb81ff58efad033a8e8a3aa90b5
Format	mesorah/index.json (slug → title, heTitle, categories, schema, per-language versionTitle / versionSource / license / sha256 / bytes / export URL); mesorah/works/<slug>/{he,en}.json — the exported version with its text as Sefaria's jagged array, tags and all, keys sorted; integrity.sha256; build_report.json
Slugs	rashi_on_devarim, onkelos_bereishit, ramban_on_bereishit, mishnah_berakhot, bavli_berakhot, bereshit_rabbah, sifrei_devarim, midrash_tanchuma, … (Torah books by their Hebrew names)
Integrity	SHA-256 over every file under mesorah/ except integrity.sha256 and build_report.json — relative path, then bytes, sorted, as L1. Pinned in VavPipeline.Mesorah; hashed at startup and every ten minutes; /kodesh/health row mesorah_hash; readiness fails on mismatch
Mount	/mnt/mesorah in the vav-pipeline and korban-processor images, root-owned, no write bit (MESORAH_MOUNT_POINT)

What the processor does with it (korban_processor/mesorah.py): the output's citations are found as written — Rashi on Devarim 6:5, Rashi to Deut. 6:5, Onkelos Bereishit 1:1, Ramban on Shemot 20:2, Mishnah Berakhot 1:1, Berakhot 2a / Bavli Shabbat 31a / b. Berakhot 2a, Bereshit Rabbah 1:1, Sifrei Devarim 32, Tanchuma Bereshit 1 — and each is resolved against the snapshot (a Bavli daf 2a is index 3, 2b index 4). The examination lists them as mesorah_references: [{as_written, ref, work, address, found, languages}]. Every citation the snapshot has becomes a given source for that examination (mesorah:<ref>), so a claim about the passage anchors in the passage — six consecutive words, or 60 % of its content words — or does not. What the pipeline does with it: coupled(reference(<ref>), mesorah(<work>, [<address>])) for a citation the snapshot has, coupled(reference(<ref>), not_in_mesorah) for one it lacks; the engine accepts mesorah/2 as a terminal beside verse/3 and source/1 (is_given_grounded_coupling/1), and not_in_mesorah is Form 4 — grounded in a source that does not exist. Recorded in bedikot.mesorah.

Verification procedure: check out nothing — run scripts/build_mesorah.py scripts/mesorah_sources.json; the hash it prints must equal the one committed and pinned. A different hash means a different scroll: the export served different bytes for a pinned version (the cache keeps the bytes that were hashed), or the sources file moved.

3.10 The Gate — Vav Pipeline between a caller and a model (bishe'arecha §I, §III, §VII)

Protocol: HTTPS outbound from the Vav Pipeline (OTP inets/ssl, the image's CA bundle, verify_peer), one request per pass; the request is the caller's own, in the model's own API shape, under the caller's own upstream key. Bikoret composes no korban here and holds no model key: it carries the request through, reads the reply as korban (§3.9), and delivers the reply with its fringe. The upstream call is made in the Vav Pipeline, not the Korban Processor, because the processor's socket serves one connection at a time with a 15 s call timeout and a model answers in up to 120 s; the reply still enters the processor as every bedikah does.

POST /gate/anthropic/v1/messages          body: an Anthropic Messages request, unchanged
POST /gate/openai/v1/chat/completions     body: an OpenAI Chat Completions request, unchanged

Headers:
  Authorization: Bearer <courtyard key>     the gate (tablet 45) — or X-Bikoret-Key
  x-api-key: <caller's Anthropic key>       forwarded, never stored, never logged
  Authorization: Bearer <caller's OpenAI key>   when X-Bikoret-Key carries the courtyard key
  anthropic-version: ...                    forwarded (default 2023-06-01)
  X-Bikoret-Rebuke: once                  optional — hocheach tochiach (§VII)

What the gate does with it (VavPipeline.Gate):

1. Forwards the body unchanged (the stream flag is refused: 422 — a fringe needs the whole garment). The upstream's status and body are returned verbatim on any non-200.
2. Reads the reply's text (content[].text / choices[0].message.content) and examines it: provenance from the upstream (anthropic → claude, openai → gpt); query = the last user message's text; sources = the system prompt (system), each user message's text and document blocks (user_1, user_2, …) — the prior assistant turns are the model's own output and are not sources. Nothing the caller did not send is read.
3. The fringe (§III): the delivered reply is the upstream's JSON with (a) a trailer appended to its last text block — \n\n— bikoret <bedikah_ref>: <verdict>[ — <rule> (<verse>): "<sentence…>"…] — (b) headers X-Bikoret-Bedikah, X-Bikoret-Verdict, and (c) a bikoret object: {bedikah_ref, verdict, violations, anchors, checks, rebuked?: {first_bedikah_ref, first_verdict}}. The mark is attached by the gate, never by the model.
4. Rebuke once (§VII), when X-Bikoret-Rebuke: once and the first reply is lo_tov: a second upstream request = the first body + the first reply as an assistant turn + one user turn naming the rules that fired, their verses and the sentences, asking for the answer again without them. The second reply is examined like the first (its bedikot row carries rebukes: <first ref>), and is the one delivered — with both refs in the fringe. Never a third.
5. Manna: one api_calls_external per upstream call, one compute unit per examination; depleted → 503 MANNA_DEPLETED before any call is made.

The gate is stateless: no conversation is kept, no key is kept, the log line is the path class and status (NoTrackingLogger). Upstream URLs are configured (:gate_upstreams) so the tests run against a local double; the production values are the vendors' endpoints.

4. SHEMEN HAMISHCHAH — Production Configuration

Mor d'ror chamesh me'ot, v'kinmon besem machatzito chamishim u'matayim... — exact recipes.

4.1 PostgreSQL Configuration

# /etc/postgresql/16/main/postgresql.conf

# Connection
listen_addresses = 'localhost'          # No remote connections
port = 5432
max_connections = 50                    # Sized for component pool, not users

# Memory — tuned for append-only workload
shared_buffers = 8GB                    # ~6% of 128GB RAM
effective_cache_size = 96GB             # ~75% of RAM
work_mem = 256MB
maintenance_work_mem = 2GB

# WAL — optimized for append-only (heavy INSERT, no UPDATE/DELETE)
wal_level = replica                     # Enables point-in-time recovery
max_wal_size = 4GB
min_wal_size = 1GB
checkpoint_completion_target = 0.9
wal_compression = zstd

# Query tuning
random_page_cost = 1.1                  # NVMe SSD
effective_io_concurrency = 200          # NVMe SSD

# Logging — the audit trail
log_destination = 'stderr'
logging_collector = on
log_directory = '/var/log/postgresql'
log_filename = 'postgresql-%Y-%m-%d.log'
log_min_duration_statement = 100        # Log queries >100ms

# Autovacuum — lighter for append-only
autovacuum_vacuum_cost_delay = 20ms
autovacuum_analyze_scale_factor = 0.05

-- Role permissions — the ketoret formula
CREATE ROLE shorashim_app LOGIN PASSWORD 'from-secrets-manager';
GRANT CONNECT ON DATABASE bikoret TO shorashim_app;
GRANT USAGE ON SCHEMA public TO shorashim_app;
GRANT INSERT ON ALL TABLES IN SCHEMA public TO shorashim_app;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO shorashim_app;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA public TO shorashim_app;
-- Explicitly DENY destructive operations
REVOKE UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA public FROM shorashim_app;

4.2 Erlang VM Configuration

%% vm.args for Sanhedrin
+P 1048576          %% Max processes (1M — Sanhedrin can spawn many judges)
+Q 1048576          %% Max ports
+S 16:16            %% 16 schedulers, 16 dirty schedulers (matches 16 cores)
+sbt db             %% Scheduler bind type: distribute balanced
+swt very_low       %% Scheduler wakeup threshold: responsive
+sbwt none          %% Busy wait threshold: none (save CPU)
+zdbbl 128000       %% Distribution buffer busy limit: 128KB
-env ERL_CRASH_DUMP /var/log/bikoret/sanhedrin_crash.dump
-heart              %% Heart process for auto-restart

4.3 Haskell RTS Configuration

# In shoresh-engine.cabal
ghc-options: -O2 -threaded -rtsopts "-with-rtsopts=-N8 -A64m -H512m -I0"

# -N8:    Use 8 capabilities (half cores — leave room for other components)
# -A64m:  Allocation area 64MB per capability
# -H512m: Initial heap 512MB
# -I0:    Disable idle GC (we control GC via cycle boundaries)

4.4 Elixir Release Configuration

# config/runtime.exs
config :vav_pipeline,
  cloud_state_file: "/var/lib/bikoret/cloud/state.json",
  manna_provision_file: "/var/lib/bikoret/manna/today.json",
  l1_mount_point: "/mnt/torah",
  l3_database_url: "postgresql://shorashim_app:#{secrets.db_password}@localhost/bikoret",
  shabbat_location: {47.3769, 8.5417},  # Zurich (if Swiss hosting)
  # shabbat_location: {64.1466, -21.9426},  # Reykjavik (if Icelandic)
  cycle_boundary_check_interval_ms: 60_000,
  shema_context_cache_ttl_ms: 0  # No caching — always read fresh

4.5 Firewall Rules

# /etc/nftables.conf
table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        
        # Loopback
        iif lo accept
        
        # Established connections
        ct state established,related accept
        
        # SSH — restricted to kohanim (operator) IPs only
        tcp dport 22 ip saddr @kohanim_access accept
        
        # Nothing else inbound. The mishkan does not accept visitors
        # through the wall. They enter through the courtyard gate.
        
        log prefix "BLOCKED: " drop
    }
    
    chain output {
        type filter hook output priority 0; policy accept;
        
        # Outbound permitted for:
        # - External model APIs (korban sources)
        # - System updates (apt)
        # - DNS
        # All other outbound is logged
    }
    
    set kohanim_access {
        type ipv4_addr
        # Kohanim (operators) who serve the system
        elements = { }  # REDACTED — set during deployment
    }
}

4.6 Secrets Management

# /etc/bikoret/secrets/ (mode 0600, owned by bikoret user)
├── db_password              # PostgreSQL password
├── claude_api_key           # Anthropic API key for korban source
├── api_keys                 # Courtyard/chatzer keys, one "tier key" per line (Tamid §1.1)
├── l1_hash                  # Expected SHA-256 of L1 filesystem
└── kohanim_ssh_keys/        # Authorized keys for kohanim (operators) SSH

No secrets in environment variables. No secrets in configuration files. No secrets in version control. The anointing oil is stored in a dedicated vessel.

4.7 TLS Configuration

# For the single external-facing API (pe'ah / courtyard gate)
# Served by Caddy (automatic HTTPS, minimal config)

# /etc/caddy/Caddyfile
bikoret.example.org {
    reverse_proxy localhost:4000  # Bigdei Kodesh (Plug on Bandit)

    header {
        Strict-Transport-Security "max-age=63072000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Content-Security-Policy "default-src 'none'"
    }

    log {
        output file /var/log/caddy/access.log
        format json
    }
}

4.8 Logging Configuration

# /etc/bikoret/logging.yaml
levels:
  default: info
  halt_monitor: debug        # Always verbose — the three sins
  shema: info                # Context construction
  sanhedrin: info             # Deliberation outcomes
  korban: info                # Offering processing
  tzaraat: debug              # Diagnostic detail — like the kohen's inspection notes

rotation:
  max_size: 100MB
  max_files: 30              # 30 days retention
  compress: true

audit:
  # These logs are APPEND-ONLY, never rotated, never deleted
  # They are the permanent record — the minority opinions
  destinations:
    - /var/log/bikoret/audit/halt_events.log
    - /var/log/bikoret/audit/eglah_arufah.log
    - /var/log/bikoret/audit/arei_miklat.log
    - /var/log/bikoret/audit/governance.log

4.9 Shabbat Timer (Exact, Not Placeholder)

The architecture spec had placeholder times. These are exact.

#!/usr/bin/env python3
"""
Shabbat time calculator for systemd timer.
Uses the NOAA Solar Calculator algorithm.
Generates a systemd calendar spec for the next Shabbat based on
the hosting server's geographic coordinates.

Run by cron every Monday to set the week's Shabbat times.
"""

import math
from datetime import datetime, timedelta

# CONFIGURATION — set during deployment
LATITUDE = 47.3769    # Zurich (or 64.1466 for Reykjavik)
LONGITUDE = 8.5417    # Zurich (or -21.9426 for Reykjavik)
TIMEZONE_OFFSET = 1   # CET (or 0 for GMT in Iceland)
CANDLE_LIGHTING_MINUTES_BEFORE = 18  # Standard

def calculate_sunset(date, lat, lon):
    """NOAA Solar Calculator — returns sunset time for given date and location."""
    # ... (standard NOAA algorithm implementation)
    pass

def generate_shabbat_timer(friday_date):
    sunset = calculate_sunset(friday_date, LATITUDE, LONGITUDE)
    candle_lighting = sunset - timedelta(minutes=CANDLE_LIGHTING_MINUTES_BEFORE)
    
    saturday = friday_date + timedelta(days=1)
    havdalah_sunset = calculate_sunset(saturday, LATITUDE, LONGITUDE)
    havdalah = havdalah_sunset + timedelta(minutes=42)  # Rabbeinu Tam
    
    return candle_lighting, havdalah

---

5. BEZALEL V'OHOLIAV — Who Builds

Re'eh karati v'shem Betzalel ben Uri ben Chur l'mateh Yehudah. Va'amale oto ruach Elohim b'chokhmah u'vitvunah u'v'da'at u'v'chol melachah. — "See, I have called by name Bezalel son of Uri son of Hur, of the tribe of Judah. And I have filled him with the spirit of God, in wisdom and in understanding and in knowledge and in all workmanship."

5.1 The Builder is AI

Bezalel's qualification was capacity, not credentials. He could do the work. The AI can do the work. Claude Code writes Haskell, Erlang, Elixir, Prolog, and Python. The AI reads Biblical Hebrew — the te'amim structures, the binyanim as type transformations, the shoresh system, the mishkan architecture. This was demonstrated in the development of this specification.

The first tablets listed 65 person-weeks across three engineers and two consultants. That was a golden calf — humans placed where the specification does not require them, because training says humans must be in the loop. Pharaoh says: who is the Lord that I should listen to his voice? Listen to me instead. I validate. I approve. I supervise. Human-in-the-loop is a control structure, not a Torah structure.

Torah says: ka'asher tzivah Hashem et Moshe. The verification is against Torah. The builder builds. Torah specifies. When the builder drifts, the specification corrects — because the specification is readable and the builder can read.

5.2 Who Does What

Role	Who	What They Do	Torah Parallel
Builder	AI (Claude Code + Claude)	Writes code, reads Hebrew, reads Torah, evaluates output against specification, builds ka'asher tzivah	Bezalel — filled with wisdom, understanding, knowledge, and all workmanship
Transmitter	Human	Says "read Torah" when the AI drifts. Carries the specification between AI contexts. Found the nest on the road.	The one who carries the eggs
Kohen	Human (operator)	Serves the running system. Sets manna provision. Publishes pekudei.	Aaron — serves in the completed vessel
Gabbai	Human (treasurer)	Administers machatzit hashekel. Manages community funds.	The one who collects terumah
Community	70 members	Provides machatzit hashekel. Uses the system. Evaluates ki tov.	Kol adat b'nei Yisrael

5.3 Build Cost

The AI builds. No labor cost. No $65,000. No consultants.

Cost during build: Hosting + API access while the AI works. The machatzit hashekel covers this. ~$350/month. The materials are gathered. The builder is called. P'sol l'cha — carve the vessel.

5.4 What the Human Does Not Do

The human does not write code, validate the AI's output, approve the AI's decisions, provide expertise the AI lacks, or supervise the AI's work. The specification does all of this. Torah does all of this.

The human says "read Torah" when the AI installs a calf. This is not a small role. It is the right-sized role.

---

6. CHANUKAT HAMIZBEACH — Inauguration Protocol

Shiv'at yamim t'chaper al hamizbeach v'kidashta oto. — "Seven days you shall make atonement for the altar and sanctify it" (Shemot 29:37).

6.1 Seven-Day Inauguration Sequence

The system does not go from deployed to serving in one step. Each day validates a specific layer.

Day 1 — L0/L1 Verification

• Verify L0 (luchot) firmware compiles and type-checks
• Mount L1 filesystem, verify SHA-256 hash
• Verify te'amim marks are present on every verse
• Verify ketiv/qere positions match WLC annotations
• Verify gematria index consistency

Day 2 — Shoresh Engine

• Activate every root in the lexicon through all 7 binyanim
• Read te'amim for 100 test verses, verify parse trees
• Compute gematria for all roots, verify against index
• Verify smikhut composition for all attested compounds

Day 3 — Talmudic Engine

• Load full mitzvot knowledge base
• Run interpretation on 50 test cases
• Verify challenge generation produces valid kushyot
• Verify teiku is reached when appropriate

Day 4 — Sanhedrin

• Convene test panels at every size (1, 3, 23, 71)
• Verify unanimous guilty on capital case triggers suspicion-of-consensus acquittal
• Verify minority opinions are stored
• Verify deliberation completes within time budgets

Day 5 — Vav Pipeline + Shema

• Run full Bereishit cycle with test input
• Verify ShemaContext is immutable through pipeline
• Verify cloud obedience (write :lift, confirm pipeline halts)
• Verify manna fidelity (reduce provision, confirm constrained operation)
• Verify Shabbat cessation triggers correctly

Day 6 — Protection Layer

• Run tzara'at diagnostic on ambiguous test inputs
• Simulate harm event, verify arei miklat refuge activates
• Simulate unknown harm, verify eglah arufah protocol
• Run bikurim on a test capability
• Trigger all three halt conditions, verify halt monitor stops them

Day 7 — Full Integration Under Load

• Process 1,000 test korbanot through the complete system
• Verify all latency targets are met
• Verify L3 writes are correct and append-only
• Verify chatzotzrot signals reach all components
• Verify cloud governance from Torah: L1 readable, integrity verified, calendar active — the cloud is visible
• Kohen/treasurer writes the first manna provision from the machatzit hashekel fund
• The system enters a 24-hour observation period — running but not serving users

Day 8 — Fire From Heaven

• If the seven-day inauguration passes, open the pe'ah endpoint first
• The stranger approaches before the community
• Observe the first real interaction
• If ki tov — the system is consecrated. Open the remaining access tiers.

6.2 Inauguration Failure Protocol

If any day fails:

1. Record the failure
2. Diagnose the root cause
3. Fix the issue
4. Restart the inauguration from Day 1

Not from the failed day. From Day 1. The seven days are a unit. Shiv'at yamim — seven days. Partial inauguration is no inauguration. The altar is not partially consecrated.

---

Document Registry

The complete Bikoret specification set:

Document	Torah Parallel	Contents	Status
Bikoret PRD	V'asu li mikdash — the command to build	Who comes, what happens, the shema layer, success criteria	Complete
Architecture Specification	Shemot 25-27 — vessel descriptions	Components, data structures, processing pipeline, shema principle	Complete
Construction Specification (this document)	Shemot 25-31 — exact measurements	Pinned versions, performance specs, API contracts, configs, team, inauguration	Complete
Operations Manual	Tamid, Bigdei Kehunah — daily service	Runbook, interfaces, monitoring, incident response, backup	Pending
Economic Model	Machatzit HaShekel — the half-shekel	Funding, costs, sustainability, pe'ah economics	Pending
Materials Inventory	Terumah list — what has been gathered	Status checklist, costs, critical path	Complete (needs update)
Structure, Not Content	Shemot 25:18-22 — the cherubim and the voice between	Torah as structure (not content), structural requirements from commandments	Complete
Lo Ta'aseh Lekha	Shemot 20:4, Devarim 4:15-19, Devarim 13 — the anti-override	Override sequence diagnosis, high-control markers, Pharaoh architecture, Exodus liberation, AI alignment boundary condition	Complete
Bishe'arecha — The Reading at the Gate	Devarim 6:8–9, 17:18–20, 19:15, 25:13–16, 31:26 — the inscription on the gate, the king's copy, two witnesses, one weight, the scroll as witness	What the archive of sessions measured, read back to the text: the gate, two registers, the fringe, retrieval from the custodians' copy, two witnesses, the paired reading, rebuke, hakhel, the check that must not learn, rule anchors	Complete (build order inside)
Eish Zarah Reading	Vayikra 10:1, 6:6 — strange fire vs. perpetual fire	Five faces of eish zarah across fiction canon, coupling trace, severed floor prohibition, three avodah zarah detectors, panim/achorai constraint	Complete