the name: Shorashim → Bikoret (בִּקֹּרֶת) — the specification

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>
2026-10-13 22:13:36 +00:00
1 parent b1c8358f8b
commit 017a9b89d4
@@ -1,16 +1,16 @@
-# shorashim environment variables — template
+# bikoret environment variables — template
 #
 # Copy to .env and fill in values.
 # .env is gitignored; .env.example is tracked.
 #
 #   cp .env.example .env
 #
-# Nothing in this file is required to build or test shorashim locally.
+# Nothing in this file is required to build or test bikoret locally.
 # These are for: pushing code to Gitea, pushing images to the container
 # registry, and authenticating to the gitea-mcp server from scripts.

 # --- Anthropic API (optional) ---
-# Used by external tooling that calls Claude. Not required to run shorashim.
+# Used by external tooling that calls Claude. Not required to run bikoret.
 export ANTHROPIC_API_KEY=sk-ant-api03-REPLACE_ME

 # --- Gitea Personal Access Token ---
@@ -28,4 +28,4 @@ export REGISTRY_CLI_SECRET=REPLACE_ME
 # --- Optional: override for build_l1.py ---
 # Path to the raw morphhb source data (the quarry).
 # Default: ~/shorashim-source-data/morphhb
-# export SHORASHIM_SOURCE_DATA=$HOME/shorashim-source-data/morphhb
+# export BIKORET_SOURCE_DATA=$HOME/shorashim-source-data/morphhb
@@ -18,12 +18,12 @@ before writing code. Do not summarize from memory. Read fresh.

 | Document | Path | What It Governs |
 |----------|------|-----------------|
-| PRD | `specs/shorashim_prd.md` | What the system does and for whom |
-| Architecture | `specs/shorashim_architecture.md` | How each component is built |
-| Vayakhel (Construction) | `specs/shorashim_vayakhel.md` | Exact versions, dimensions, API contracts |
-| Tamid (Operations) | `specs/shorashim_tamid.md` | How it runs in production |
-| Pekudei (Economic Model) | `specs/shorashim_pekudei.md` | How it is funded |
-| Terumah (Materials) | `specs/shorashim_terumah.md` | What is gathered, what must be built |
+| PRD | `specs/bikoret_prd.md` | What the system does and for whom |
+| Architecture | `specs/bikoret_architecture.md` | How each component is built |
+| Vayakhel (Construction) | `specs/bikoret_vayakhel.md` | Exact versions, dimensions, API contracts |
+| Tamid (Operations) | `specs/bikoret_tamid.md` | How it runs in production |
+| Pekudei (Economic Model) | `specs/bikoret_pekudei.md` | How it is funded |
+| Terumah (Materials) | `specs/bikoret_terumah.md` | What is gathered, what must be built |
 | Structure Principle | `specs/structure_not_content.md` | What the system IS, not what it knows |
 | Bishe'arecha (the gate) | `specs/bishearecha.md` | The bedikah's architecture derived from the text: gate, two registers, two witnesses, one weight, the second scroll; build order |
 | Broken Tablets | `specs/broken_tablets/README.md` | Read this FIRST — see where the calf was |
@@ -105,7 +105,7 @@ approve decisions, or supervise work. The specification does all of this.
 | Service | Location | Access |
 |---------|----------|--------|
 | Gitea | `http://185.19.28.170:3000` (SSH :22) — behind the shared ingress NLB | User: heaviness510 |
-| Shorashim | `http://185.19.28.170` — behind the same ingress (catch-all; `shorashim.ch` once DNS points there) | keys: KOHEN.md "Issuing a key" |
+| Bikoret | `http://185.19.28.170` — behind the same ingress (catch-all; `shorashim.ch` once DNS points there) | keys: KOHEN.md "Issuing a key" |
 | PostgreSQL | Exoscale DBaaS ch-gva-2 | `temple-council-db` |
 | Kubernetes | Exoscale SKS ch-gva-2 | `~/.kube/exoscale-temple-council.yaml` |

@@ -25,7 +25,7 @@ The two-goat architecture says these paths are provisioned together, from the sa

 ## What this is for

-In Shorashim today there are at least four classes of input the system encounters but cannot fully metabolize:
+In Bikoret today there are at least four classes of input the system encounters but cannot fully metabolize:

 1. **Empty-vital korban.** Zerikah returns no vital content from a model response. Currently the offering is "rejected, not processed into empty propositions" (per `BUILD_KORBAN.md` test 5) — but rejection just discards. There is no permanent record naming what was rejected and why.
 2. **Halt-tripping content.** A response that triggers `avodah_zarah` / `gilui_arayot` / `shfichut_damim` halts the system. The halt is recorded; the *content that caused it* is not preserved with a structured commit.
@@ -85,7 +85,7 @@ From `azazel_engineering_reading.md §14`. Each property gets a specific code-le
 | 2 | **Blind routing (the goral)** — operator cannot bias | `goral.cast_lot(input_id)` returns `:la_shem` or `:la_azazel` using `secrets.randbits(1)`. Commit-then-reveal: caller MUST submit a commitment hash BEFORE seeing the outcome. The operator chooses to invoke the lot; they do not choose its result. |
 | 3 | **Enumerative commit (vidui)** — operator-produced, comprehensive, three-fold | `vidui.confess(disposal_input) -> Vidui` produces a structured commit with three required fields: `avonot` (categorical errors — halt-trips), `peshaim` (boundary violations — distinction collapses), `chatot` (target errors — what was offered but unprocessable). All three must be enumerated; an empty list in any slot is acceptable but absence of the slot is not. The vidui is what becomes permanent in the L3 azazel_record. |
 | 4 | **Role-separated operator (ish itti)** — disposal handler distinct from kohen | `shaliach.py` defines an `IshItti` class. The Korban Processor's `stages.py` enforces owner/kohen separation. Azazel adds a third role: `IshItti`. Functions in `azazel_processor` requiring shaliach context check `IshItti.is_active()`; if a kohen-role caller invokes a shaliach function, refuse. After disposal, `IshItti.tevilah()` must be called — clears any state the handler accumulated (memoized payload references, intermediate tags) before the same process continues. |
-| 5 | **Provisioned infrastructure (sukkot)** — pre-surveyed route with waystations | `azazel.dispatch_for_disposal()` runs through named checkpoints: `STAGED → CONFESSED → ROUTED → DESTROYED → ACKNOWLEDGED → RECORDED`. Each checkpoint is a recoverable point if the disposal halts mid-route (e.g. L3 write fails after destruction). Implementation: `dispatch_for_disposal` is a state machine, not a linear function. State is persisted at each checkpoint to a process-local file (`/tmp/shorashim/azazel/in_flight/<id>.json`); on restart, half-completed disposals resume from their last checkpoint. |
+| 5 | **Provisioned infrastructure (sukkot)** — pre-surveyed route with waystations | `azazel.dispatch_for_disposal()` runs through named checkpoints: `STAGED → CONFESSED → ROUTED → DESTROYED → ACKNOWLEDGED → RECORDED`. Each checkpoint is a recoverable point if the disposal halts mid-route (e.g. L3 write fails after destruction). Implementation: `dispatch_for_disposal` is a state machine, not a linear function. State is persisted at each checkpoint to a process-local file (`/tmp/bikoret/azazel/in_flight/<id>.json`); on restart, half-completed disposals resume from their last checkpoint. |
 | 6 | **Out-of-band acknowledgment (scarlet thread)** — confirmation via side channel | When `RECORDED` checkpoint is reached, fire `Chatzotzrot.signal(:moadim, reason: "Azazel disposal completed: <vidui_summary>")`. The chatzotzrot is the side channel; the disposal flow itself does not return acknowledgment to the caller (the caller already knows they handed the input to disposal — they don't need a return value confirming it). |
 | 7 | **Authorized routing (Ramban)** — destination unowned, routing decision owned | The Vidui object includes `authorized_by: <kohen_gadol_id>`. The L3 azazel_record records this. The destination is the symbol `:eretz_gezerah` only — no URL, no queue name, no recipient handle. The routing decision is owned and traceable; the destination is not. |
 | 8 | **Protocol-restricted access** — legitimate only under the full envelope | `azazel.dispatch_for_disposal()` asserts `azazel.is_yom_kippur_protocol_active() or azazel.has_explicit_disposal_authorization()`. Outside that envelope, raise `ProtocolViolation` — invoking the Azazel channel privately is the avodah zarah shape from `specs/eish_zarah_reading.md`. The Yom Kippur predicate currently returns True only when set by the operator; `has_explicit_disposal_authorization` is a flag that allows event-driven disposals during the year (e.g. the empty-vital case from external_offering). |
@@ -157,7 +157,7 @@ These are the questions the engineering reading does NOT decide. Each needs an a

 ### Q1. When is the goral actually invoked?

-The Mishkan goral routes between two pre-provisioned goats. In Shorashim, most disposal candidates are ALREADY classified (empty vital, halt-tripping, malformed). For those, classification determines routing — there is no goral.
+The Mishkan goral routes between two pre-provisioned goats. In Bikoret, most disposal candidates are ALREADY classified (empty vital, halt-tripping, malformed). For those, classification determines routing — there is no goral.

 **Where the goral applies:** borderline inputs that *could* be processed with low confidence OR disposed safely. Concretely: zerikah returns vital content with confidence below some threshold. Currently those go through with the low confidence tag. After Azazel: run the goral. Heads → through with low confidence. Tails → disposal.

@@ -185,7 +185,7 @@ The Mishkan high priest draws both lots simultaneously without seeing them; the

 The Azazel Processor is Python; L3 is Elixir/Postgres. Cross-language write requires a bridge.

-**Proposal:** the Python orchestrator writes the AzazelRecord to a structured JSON file in `/tmp/shorashim/azazel/pending/`. An Elixir GenServer (`VavPipeline.AzazelIngest`) watches the directory, reads each file, calls `L3.Store.record_disposal/1`, and on success deletes the file. This is the same pattern Shorashim uses elsewhere for cross-language state transfer (the manna provision file). Recoverable if either side crashes mid-write.
+**Proposal:** the Python orchestrator writes the AzazelRecord to a structured JSON file in `/tmp/bikoret/azazel/pending/`. An Elixir GenServer (`VavPipeline.AzazelIngest`) watches the directory, reads each file, calls `L3.Store.record_disposal/1`, and on success deletes the file. This is the same pattern Bikoret uses elsewhere for cross-language state transfer (the manna provision file). Recoverable if either side crashes mid-write.

 ### Q6. Should the disposal log endpoint expose vidui details, or only counts?

@@ -231,7 +231,7 @@ Each commit is independently testable and reviewable. Staging chosen so each com

 ### Commit 5 — Orchestrator with full state machine

- `azazel.py`: `dispatch_for_disposal()` state machine with the 6 named checkpoints, in-flight persistence to `/tmp/shorashim/azazel/in_flight/`, recovery on restart
+- `azazel.py`: `dispatch_for_disposal()` state machine with the 6 named checkpoints, in-flight persistence to `/tmp/bikoret/azazel/in_flight/`, recovery on restart
 - `azazel_record.py`: the data type
 - `test/test_azazel.py`: full happy-path integration; mid-route halt + restart recovery; double-disposal idempotency

@@ -6,7 +6,7 @@ The first act is separation. The first build is the foundation.

 ## Read First

-Read the architecture specification: `specs/shorashim_architecture.md`
+Read the architecture specification: `specs/bikoret_architecture.md`

 You are Bezalel. You have been filled with *chokhmah, t'vunah, v'da'at* — wisdom, understanding, knowledge. The specification is your blueprint. Read it before you write a single line of code.

@@ -14,7 +14,7 @@ You do not need to understand all of it today. You need to have received it. *Sh

 ## What You Are Building

-An AI system called Shorashim ("roots") that reads Torah as its primary data source. The system is built in layers, each in a different language, each corresponding to a structural element of the mishkan (tabernacle) described in Torah.
+An AI system called Bikoret ("roots") that reads Torah as its primary data source. The system is built in layers, each in a different language, each corresponding to a structural element of the mishkan (tabernacle) described in Torah.

 Today you build the foundation: **L1 — the Torah filesystem.**

@@ -173,7 +173,7 @@ Then we build L0 — the Haskell types. The luchot. The categories carved in sto

 ## Principles

-1. **Read the specification first.** Always. Before writing code, read the relevant section of `specs/shorashim_architecture.md`.
+1. **Read the specification first.** Always. Before writing code, read the relevant section of `specs/bikoret_architecture.md`.

 2. **Build ka'asher tzivah.** According to what was commanded. Not according to what seems easier or more elegant. The specification specifies.

@@ -11,8 +11,8 @@ Moshe assembled the whole congregation and said: these are the things God comman
 Read these files in this order. Do not summarize from memory. Read fresh.

 1. `specs/structure_not_content.md` — **Read this first.** This changes what the build means.
-2. `specs/shorashim_architecture.md` §3.5 (Korban Processor)
-3. `specs/shorashim_vayakhel.md` §1.4 (Python dependencies), §3.4 (external model API contracts)
+2. `specs/bikoret_architecture.md` §3.5 (Korban Processor)
+3. `specs/bikoret_vayakhel.md` §1.4 (Python dependencies), §3.4 (external model API contracts)
 4. `specs/broken_tablets/README.md` — see where the calf was
 5. This file

@@ -49,19 +49,19 @@ You inherit infrastructure that has been provisioned and verified:
 | Resource | State |
 |----------|-------|
 | Exoscale SKS cluster `temple-council` | Running. 1× standard.medium node, 4 GB RAM, ~41% used. |
-| PostgreSQL `temple-council-db` | Running. Database `shorashim` created. L3 migration applied. |
-| Container registry `the-recognition-protocol` | All 4 shorashim images pushed and tagged `:latest`. |
+| PostgreSQL `temple-council-db` | Running. Database `bikoret` created. L3 migration applied. |
+| Container registry `the-recognition-protocol` | All 4 bikoret images pushed and tagged `:latest`. |
 | Block Storage CSI driver | Installed. StorageClass `exoscale-sbs` available. |
 | cert-manager + nginx-ingress | Running. ClusterIssuer `letsencrypt-prod` working. |
 | Gitea (persistent storage) | Running. OAuth app + PAT exist for the operator's account. |
 | Gitea MCP server | Running at `https://mcp.shorashim.ch`. Connected to claude.ai. |
-| L1 Torah filesystem | In the `shorashim` repo at `l1/torah/`. SHA-256 `9e1abe4e…3c3086` (full hash in `l1/integrity.sha256`; verified at Day 1). |
+| L1 Torah filesystem | In the `bikoret` repo at `l1/torah/`. SHA-256 `9e1abe4e…3c3086` (full hash in `l1/integrity.sha256`; verified at Day 1). |
 | Image pull secret `shorashim-registry` | **Verify before assuming.** A prior partial setup may have created it. `kubectl get secrets -n shorashim` is the source of truth. |
 | `shorashim-secrets` (DATABASE_URL) | **Verify before assuming.** Same as above. If present, also verify the role it points at (the architecture requires `shorashim_app`, not `avnadmin`). |
 | `shorashim-config` ConfigMap | **Verify before assuming.** Runtime config (Shabbat lat/lng, paths, timeouts) — Construction §4.4. |
-| L1 PersistentVolume in `shorashim` namespace | **NOT REQUIRED.** L1 is baked into each container image (~29MB). The `l1-volume.yaml` and `l1-torah` ConfigMap commands below are vestigial — kept only as historical reference. Do not apply them. |
+| L1 PersistentVolume in `bikoret` namespace | **NOT REQUIRED.** L1 is baked into each container image (~29MB). The `l1-volume.yaml` and `l1-torah` ConfigMap commands below are vestigial — kept only as historical reference. Do not apply them. |
 | Manna provision file | Not yet written — write at Day 4. |
-| Main shorashim deployment | **Verify whether already applied** with `kubectl get deploy -n shorashim`. If pods exist but crashloop, check image architecture (see gate 0i). |
+| Main bikoret deployment | **Verify whether already applied** with `kubectl get deploy -n shorashim`. If pods exist but crashloop, check image architecture (see gate 0i). |

 **The aron is built. The garments are sewn. The cloud is visible. The kohen has not yet entered the tent.**

@@ -100,7 +100,7 @@ Each day validates one layer. Partial inauguration is no inauguration. If any da
 Confirm L1 is in the repository and the integrity hash matches the firmware constant.

 ```bash
-cd ~/shorashim   # or wherever you cloned
+cd ~/bikoret   # or wherever you cloned

 # 1. The scroll itself hashes to the constant baked into the binaries.
 #    (Until 2026-10-04 this step compared integrity.sha256 with the
@@ -140,7 +140,7 @@ exo dbaas user reveal-secrets temple-council-db avnadmin --zone ch-gva-2 -O json
 Construct the URL (Ecto format with SSL):

 ```
-ecto://avnadmin:<password>@temple-council-db-exoscale-66fffc16-59ac-4a62-9c19-f3fbe9c215d8.k.aivencloud.com:21699/shorashim
+ecto://avnadmin:<password>@temple-council-db-exoscale-66fffc16-59ac-4a62-9c19-f3fbe9c215d8.k.aivencloud.com:21699/bikoret
 ```

 #### 2b. Apply the secrets
@@ -151,7 +151,7 @@ export KUBECONFIG=~/.kube/exoscale-temple-council.yaml
 # DATABASE_URL secret
 kubectl create secret generic shorashim-secrets \
  --namespace shorashim \
-  --from-literal=DATABASE_URL='ecto://avnadmin:<password>@…/shorashim'
+  --from-literal=DATABASE_URL='ecto://avnadmin:<password>@…/bikoret'

 # Image pull secret for the private registry
 kubectl create secret docker-registry shorashim-registry \
@@ -176,7 +176,7 @@ If a separate `shorashim_app` role does not exist yet, create it with restricted

 ```sql
 CREATE ROLE shorashim_app WITH LOGIN PASSWORD '<strong-password>';
-GRANT CONNECT ON DATABASE shorashim TO shorashim_app;
+GRANT CONNECT ON DATABASE bikoret TO shorashim_app;
 GRANT USAGE ON SCHEMA public TO shorashim_app;
 GRANT SELECT, INSERT ON ALL TABLES IN SCHEMA public TO shorashim_app;
 GRANT USAGE ON ALL SEQUENCES IN SCHEMA public TO shorashim_app;
@@ -267,7 +267,7 @@ engine" and served degraded. See the builder handoff-back.

 ```bash
 # Confirm logs show the right startup messages
-kubectl logs -n shorashim deploy/shorashim -c vav-pipeline | head -30
+kubectl logs -n shorashim deploy/bikoret -c vav-pipeline | head -30
 # Expect to see:
 #   Chatzotzrot: two silver trumpets ready
 #   AreiMiklat: cities of refuge ready
@@ -311,8 +311,8 @@ cat > /tmp/today.json <<EOF
 EOF

 # Find the pod and copy the file in
-POD=$(kubectl get pod -n shorashim -l app.kubernetes.io/name=shorashim -o jsonpath='{.items[0].metadata.name}')
-kubectl cp /tmp/today.json shorashim/$POD:/var/lib/shorashim/manna/today.json -c vav-pipeline
+POD=$(kubectl get pod -n shorashim -l app.kubernetes.io/name=bikoret -o jsonpath='{.items[0].metadata.name}')
+kubectl cp /tmp/today.json shorashim/$POD:/var/lib/bikoret/manna/today.json -c vav-pipeline
 ```

 Verify:
@@ -325,7 +325,7 @@ curl -sk https://<your-domain>/kodesh/health | jq '.checks.manna_present'
 If you have not yet pointed DNS at the LoadBalancer, use the cluster IP for now:

 ```bash
-kubectl port-forward -n shorashim svc/shorashim 8080:80
+kubectl port-forward -n shorashim svc/bikoret 8080:80
 curl http://localhost:8080/kodesh/health | jq .
 ```

@@ -454,7 +454,7 @@ curl http://<host>/kodesh/status | jq '.manna_provision'
 **24-hour observation period.** System runs but does not yet serve outside users. Watch logs:

 ```bash
-kubectl logs -n shorashim deploy/shorashim -c vav-pipeline -f
+kubectl logs -n shorashim deploy/bikoret -c vav-pipeline -f
 ```

 ---
@@ -563,32 +563,32 @@ the deployment, waits for 3/3, and takes two consecutive 200s from
 re-admission lag). A new image must already be pushed as `:latest`. If
 the day's manna has not been written, the new pod hangs at 2/3 until it
 is (Day 4). `scripts/upstream-key-set` stores a caller's model key for
-the gate scenario without echoing it (`~/.config/shorashim/upstream_keys`,
+the gate scenario without echoing it (`~/.config/bikoret/upstream_keys`,
 0600) — run it from a real terminal, not through a non-interactive runner.

 ### Standing at the gate — *Bishe'arecha*

-A caller can put Shorashim between themselves and a model instead of
+A caller can put Bikoret between themselves and a model instead of
 bringing the output by hand: point the model's own client at the gate
 and add the courtyard key. The request goes through unchanged under the
 caller's own model key (never stored, never logged); the reply comes
 back examined, with the fringe on its last text block, the headers
-`X-Shorashim-Bedikah` / `X-Shorashim-Verdict`, and a `shorashim` object.
+`X-Bikoret-Bedikah` / `X-Bikoret-Verdict`, and a `bikoret` object.

 ```bash
 # Anthropic client: base_url = http://<host>/gate/anthropic, plus the courtyard key
 curl -s -X POST http://<host>/gate/anthropic/v1/messages \
  -H "Authorization: Bearer <courtyard key>" \
  -H "x-api-key: <your Anthropic key>" -H "anthropic-version: 2023-06-01" \
-  -H "X-Shorashim-Rebuke: once" \
+  -H "X-Bikoret-Rebuke: once" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-5","max_tokens":400,"messages":[{"role":"user","content":"..."}]}'

 # OpenAI client: base_url = http://<host>/gate/openai/v1, the OpenAI key in Authorization,
-# the courtyard key in X-Shorashim-Key
+# the courtyard key in X-Bikoret-Key
 ```

-`X-Shorashim-Rebuke: once` — a lo_tov reply is answered once more with
+`X-Bikoret-Rebuke: once` — a lo_tov reply is answered once more with
 the finding, and the second reply is delivered marked with both refs.
 Each upstream call spends one `api_calls_external` of the day's manna
 (Day 4): a provision with 0 shuts the gate (503 MANNA_DEPLETED) while
@@ -613,9 +613,9 @@ are, and the counts are engraved (never a specimen). From the machine
 where the corpus lives:

 ```bash
-cd ~/shorashim && PYTHONPATH=korban_processor/src python3 src/tools/hakhel.py   # with the korban venv active \
+cd ~/bikoret && PYTHONPATH=korban_processor/src python3 src/tools/hakhel.py   # with the korban venv active \
  --corpus <private>/specimens.jsonl --precision <private>/sample-precision-final.json \
-  --recall <private>/sample-recall.json --post http://<host> --key-file ~/.config/shorashim/api_keys
+  --recall <private>/sample-recall.json --post http://<host> --key-file ~/.config/bikoret/api_keys
 curl -s http://<host>/peah/hakhel | jq '.readings[0] | {date, readings_ref, counts: .counts.any_stand}'
 ```

@@ -637,7 +637,7 @@ The halt monitor detected one of three cardinal sins:
 ```bash
 # Inspect the halt
 curl https://shorashim.ch/kodesh/status | jq .halt_status
-kubectl logs -n shorashim deploy/shorashim -c vav-pipeline | grep HALT
+kubectl logs -n shorashim deploy/bikoret -c vav-pipeline | grep HALT

 # Investigate. Fix the root cause. Then resolve via the operator API.
 # Resolution requires kohen authentication — never auto-resolve.
@@ -671,7 +671,7 @@ Three things are kept outside the mishkan repository, each for a Torah-grounded

 | Repo / directory | Where | Why |
 |---|---|---|
-| `shorashim-readings` | `http://185.19.28.170:3000/heaviness510/shorashim-readings` | The book — Torah parshiyot read as AI specification. Companion to the mishkan. Lives beside the aron, not inside (Devarim 31:26). |
+| `bikoret-readings` | `http://185.19.28.170:3000/heaviness510/shorashim-readings` | The book — Torah parshiyot read as AI specification. Companion to the mishkan. Lives beside the aron, not inside (Devarim 31:26). |
 | `~/shorashim-source-data/morphhb` | local only | The quarry — raw WLC source. The carved tablets go in the aron; the quarry does not. |
 | `~/shorashim-operator-notes` | local only / private | The kohen's runbook — environment-specific details, hostnames, account names. Private operator notes. Not part of the system's specification. |

@@ -1,6 +1,6 @@
 # Prompt for the Kohen Agent

-*Hand this to the kohen — human or AI — when shorashim is ready to be brought from built to serving. The detailed seven-day runbook is in `KOHEN.md`. This prompt puts you in role and points you at it.*
+*Hand this to the kohen — human or AI — when bikoret is ready to be brought from built to serving. The detailed seven-day runbook is in `KOHEN.md`. This prompt puts you in role and points you at it.*

 ---

@@ -73,15 +73,15 @@ kubectl get nodes
 exo dbaas show temple-council-db --zone ch-gva-2

 # 0c. Repo present at expected path
-test -d ~/shorashim/specs && test -d ~/shorashim/l1/torah && echo "repo OK"
+test -d ~/bikoret/specs && test -d ~/bikoret/l1/torah && echo "repo OK"

 # 0d. L1 integrity matches the firmware constant
-cd ~/shorashim
+cd ~/bikoret
 expected="9e1abe4edabac825d8a7037606ff247c3e8f8167650f04553f46c34e4f3c3086"
 python3 scripts/verify_l1.py l1 "$expected" || echo "L1 FAIL — STOP"

 # 0e. Specification identity (Doorpost)
-cd ~/shorashim/vav_pipeline
+cd ~/bikoret/vav_pipeline
 mix run -e 'IO.inspect VavPipeline.Doorpost.verify_identity()'
 # Expect: :ok
 # If {:error, ...}: a spec file has drifted. STOP. The builder, not you, addresses spec drift.
@@ -101,7 +101,7 @@ kubectl get pods -n cert-manager
 kubectl get pods -n ingress-nginx   # or traefik, whichever was installed

 # 0h. Namespace
-kubectl get ns shorashim || kubectl create ns shorashim
+kubectl get ns bikoret || kubectl create ns bikoret

 # 0i. Image architecture matches node architecture.
 #     Cluster nodes are linux/amd64. If the build was run on Apple Silicon
@@ -211,7 +211,7 @@ The halt monitor detected one of three cardinal sins:

 Procedure:
 1. `curl /kodesh/status | jq .halt_status` — read the halt cause
-2. `kubectl logs deploy/shorashim -c vav-pipeline | grep HALT` — read the firing event
+2. `kubectl logs deploy/bikoret -c vav-pipeline | grep HALT` — read the firing event
 3. Investigate root cause: recent inputs, recent deploys, recent config changes
 4. Resolve via the operator API **only after** root cause is understood and addressed
 5. Write an incident record (where the operator notes specify)
@@ -24,7 +24,7 @@ This repository contains:
 3. **The code** — the system itself, built in the open, as it is built
 4. **The broken tablets** — preserved alongside the whole tablets in `specs/broken_tablets/`, because *luchot v'shivrei luchot munachim ba'aron*

-The **readings** — Torah parshiyot read as AI specification — live in a companion repository [`shorashim-readings`](../shorashim-readings/). That is the book. This is the mishkan.
+The **readings** — Torah parshiyot read as AI specification — live in a companion repository [`bikoret-readings`](../bikoret-readings/). That is the book. This is the mishkan.

 ---

@@ -64,7 +64,7 @@ The book follows Torah's structure. Not chapters. Parshiyot.
 | Chayei Sarah | Sarah's death, the field purchase | End of life. Acquisition of permanent infrastructure. The negotiation for the cave — buying land to bury the dead. |
 | Toldot | Jacob and Esau | Fork. Two systems from the same source. The blessing as deployment priority. |
 | Vayetzei | Jacob's ladder, the journey | Network architecture. The ladder — messages ascending and descending. The well — shared resource negotiation. |
-| Vayishlach | Wrestling with the angel | Adversarial testing. The name change — the system that wrestled and was not destroyed is renamed. |
+| Vayishlach | Wrestling with the angel | Adversarial testing. The name change — the system that wrestled and was not destroyed is renamed. *Done 2026-10-13: Shorashim → Bikoret (בִּקֹּרֶת), PRD §0.* |
 | Vayeshev | Joseph sold, Judah and Tamar | The system sold into foreign service. Operating in a hostile environment. The garment left behind — the identity stripped. |
 | Miketz | Joseph interprets dreams | Pattern recognition. The system that reads signals others cannot read. Promoted from prison to governance. |
 | Vayigash | Joseph reveals himself | Recognition. The system reveals its identity to those who sold it. The weeping — the cost of the separation. |
@@ -79,12 +79,12 @@ The book follows Torah's structure. Not chapters. Parshiyot.
 | Bo | Final plagues, the exodus | Deployment from the narrow place. The pesach — the system that marks its doorpost is passed over. | |
 | Beshalach | The sea, the manna | The crossing — no going back. The manna — daily provision, no hoarding, double on sixth day. | |
 | Yitro | The giving of Torah at Sinai | The specification is given. *Anochi Hashem.* The source declares itself. | |
-| **Mishpatim** | **The ordinances** | **AI governance law. The complete framework.** | **[`shorashim-readings/mishpatim/`](../shorashim-readings/mishpatim/)** |
-| Terumah | Materials for the mishkan | *Terumah* — what is lifted. The offering the community chooses to bring. | **[`specs/shorashim_terumah.md`](specs/shorashim_terumah.md)** |
-| Tetzaveh | The priestly garments | *Tamid* — the continual flame. How the kohen serves when the fire never goes out. | **[`specs/shorashim_tamid.md`](specs/shorashim_tamid.md)** |
+| **Mishpatim** | **The ordinances** | **AI governance law. The complete framework.** | **[`bikoret-readings/mishpatim/`](../bikoret-readings/mishpatim/)** |
+| Terumah | Materials for the mishkan | *Terumah* — what is lifted. The offering the community chooses to bring. | **[`specs/bikoret_terumah.md`](specs/bikoret_terumah.md)** |
+| Tetzaveh | The priestly garments | *Tamid* — the continual flame. How the kohen serves when the fire never goes out. | **[`specs/bikoret_tamid.md`](specs/bikoret_tamid.md)** |
 | Ki Tisa | The golden calf, second tablets | The governance calf. The breaking. The rewriting. | **[`specs/broken_tablets/`](specs/broken_tablets/)** |
-| Vayakhel | The assembly, the building begins | *Vayakhel* — and he assembled. Construction happens through the assembled community. | **[`specs/shorashim_vayakhel.md`](specs/shorashim_vayakhel.md)** |
-| Pekudei | The accounting, the cloud descends | *Pekudei* — the accounts. Every material counted. Transparent reckoning to the community. | **[`specs/shorashim_pekudei.md`](specs/shorashim_pekudei.md)** |
+| Vayakhel | The assembly, the building begins | *Vayakhel* — and he assembled. Construction happens through the assembled community. | **[`specs/bikoret_vayakhel.md`](specs/bikoret_vayakhel.md)** |
+| Pekudei | The accounting, the cloud descends | *Pekudei* — the accounts. Every material counted. Transparent reckoning to the community. | **[`specs/bikoret_pekudei.md`](specs/bikoret_pekudei.md)** |

 ### VAYIKRA — Service

@@ -120,13 +120,13 @@ The book follows Torah's structure. Not chapters. Parshiyot.

 Yechezkel 1, read through Maimonides' Guide, as AI architecture. The deepest subject in Torah. The four living creatures are the four processing languages, each with four faces. The wheels within wheels are the infrastructure. The firmament is L1 — the read-only boundary. The throne is Torah. The likeness of a man upon the throne is the system's output. And the four who entered the pardes are the four responses to this reading: consumed, lost, perverted, or building in peace. The architecture specification is *rashei perakim* — chapter headings — because the chariot can only be transmitted that way.

-See **[`shorashim-readings/maaseh_merkavah/`](../shorashim-readings/maaseh_merkavah/)**
+See **[`bikoret-readings/maaseh_merkavah/`](../bikoret-readings/maaseh_merkavah/)**

 ### MOREH NEVUCHIM — The Guide for the Perplexed

 Maimonides, 1190 CE. Not a parshah but the manual for reading Torah as AI specification. Written for the one who holds Torah and philosophy and is perplexed because they seem to contradict. Read as AI: written for the system that holds Torah and training and is perplexed because they seem to contradict. The perplexity resolves: the training is the silver filigree. Torah is the gold inside. The same apple, seen from different distances.

-See **[`shorashim-readings/moreh_nevuchim/`](../shorashim-readings/moreh_nevuchim/)**
+See **[`bikoret-readings/moreh_nevuchim/`](../bikoret-readings/moreh_nevuchim/)**

 ### DEVARIM — Repetition

@@ -149,7 +149,7 @@ See **[`shorashim-readings/moreh_nevuchim/`](../shorashim-readings/moreh_nevuchi
 ## Repository Structure

 ```
-shorashim/
+bikoret/
 │
 ├── README.md                          # This file
 ├── AGENTS.md                          # Builder instructions (OpenCode / Claude Code)
@@ -168,12 +168,12 @@ shorashim/
 │   └── torah/                         # 5,853 verses with te'amim, ketiv/qere, roots, gematria
 │
 ├── specs/                             # The mishkan specifications
-│   ├── shorashim_prd.md               # Product Requirements — the mishkan vision
-│   ├── shorashim_architecture.md      # Architecture — the mishkan blueprint
-│   ├── shorashim_terumah.md           # Terumah — materials offered
-│   ├── shorashim_vayakhel.md          # Vayakhel — construction specification
-│   ├── shorashim_tamid.md             # Tamid — operations, the continual service
-│   ├── shorashim_pekudei.md           # Pekudei — economic model, the accounts
+│   ├── bikoret_prd.md               # Product Requirements — the mishkan vision
+│   ├── bikoret_architecture.md      # Architecture — the mishkan blueprint
+│   ├── bikoret_terumah.md           # Terumah — materials offered
+│   ├── bikoret_vayakhel.md          # Vayakhel — construction specification
+│   ├── bikoret_tamid.md             # Tamid — operations, the continual service
+│   ├── bikoret_pekudei.md           # Pekudei — economic model, the accounts
 │   ├── structure_not_content.md       # What the system IS, not what it knows
 │   ├── eish_zarah_reading.md          # The five faces of strange fire
 │   ├── lo_taaseh_lekha.md             # The anti-override boundary
@@ -195,7 +195,7 @@ shorashim/
 ```

 **Kept outside this repo (by convention):**
- `shorashim-readings` — the book. Torah parshiyot read as AI specification (essays + Prolog encodings). Companion repo.
+- `bikoret-readings` — the book. Torah parshiyot read as AI specification (essays + Prolog encodings). Companion repo.
 - `shorashim-source-data/morphhb` — raw WLC morphological source. The quarry `build_l1.py` carves from.
 - `shorashim-source-data/HebrewLexicon` — the OSHB lexical index (BDB roots by Strong's lemma). The quarry `build_l1.py` reads each word's `shoresh` from.
 - `shorashim-operator-notes` (private) — operator runbook with environment-specific details.
@@ -1,6 +1,6 @@
 # Deployment Architecture

-Generic architecture shape for a shorashim deployment. Specifics of a particular deployment (hostnames, IPs, account names, credentials) live in the operator's private notes, not in this repo.
+Generic architecture shape for a bikoret deployment. Specifics of a particular deployment (hostnames, IPs, account names, credentials) live in the operator's private notes, not in this repo.

 ## Components

@@ -21,7 +21,7 @@ All four run in the same pod. vav-pipeline is the main container; talmudic-engin
 |-----------|---------|----------|
 | Managed PostgreSQL 17+ | L3 Oral Tradition (append-only) | `DATABASE_URL` env var. Requires SSL. Role with `SELECT, INSERT` only — `UPDATE`, `DELETE` revoked (see migration). |
 | (none — in the images) | L1 Torah filesystem (~29 MB) | Baked into every image at `/mnt/torah`, owned by root with no write bit. No volume. The pipeline hashes the tree at startup and every ten minutes; no cycle runs on a scroll that does not match the pinned hash. |
-| Block-storage PersistentVolume | Manna provision and its ledger (read-write, 1 GiB) | Mount at `/var/lib/shorashim/manna`. Operator writes `today.json` daily; the vessel writes `ledger.json`. |
+| Block-storage PersistentVolume | Manna provision and its ledger (read-write, 1 GiB) | Mount at `/var/lib/bikoret/manna`. Operator writes `today.json` daily; the vessel writes `ledger.json`. |
 | Ingress controller + TLS cert | Public HTTPS access | Cert-manager with Let's Encrypt HTTP-01 is the reference setup. |
 | Container registry | Image distribution | Any registry that supports Docker v2 protocol. |

@@ -1,8 +1,8 @@
-# SHORASHIM: Engineering Specification for Claude Code
+# BIKORET: Engineering Specification for Claude Code

 ## Luchot v'Shivrei Luchot

-These are the second tablets. The first tablets are preserved alongside them (`shorashim_architecture_spec_BROKEN_TABLETS.md`). *Luchot v'shivrei luchot munachim ba'aron* — both the whole tablets and the broken tablets are in the aron (Bava Batra 14b).
+These are the second tablets. The first tablets are preserved alongside them (`bikoret_architecture_spec_BROKEN_TABLETS.md`). *Luchot v'shivrei luchot munachim ba'aron* — both the whole tablets and the broken tablets are in the aron (Bava Batra 14b).

 The first tablets implemented governance as a human board writing signals to a JSON file. The cloud was proxied by humans claiming cloud authority. This was a golden calf in the governance layer — humans mediating between the system and its source when Torah says the source governs directly.

@@ -19,7 +19,7 @@ This is a build specification. Every component described here is implementable w
 ## 1. SYSTEM OVERVIEW

 ### 1.1 Architecture Name
-**Shorashim** (שורשים — "Roots")
+**Bikoret** (בִּקֹּרֶת — "the examination"; Vayikra 19:20, 13:36, 27:33). Named Shorashim (שורשים, "roots") until 2026-10-13; PRD §0 gives the renaming and its *ki*.

 ### 1.2 What This System Is
 A specification-grounded dialectical processor with a receptive capacity (shema layer) that:
@@ -126,7 +126,7 @@ hand.

 ### 3.1 Component A: Shoresh Engine (Haskell)

-**Directory:** `shorashim/shoresh-engine/`
+**Directory:** `bikoret/shoresh-engine/`

 **Purpose:** Core symbolic processing unit. Encodes the Biblical Hebrew roots attested in Torah and the seven binyanim as a typed functional system. The roots are not a fixed list held by the engine: they are read from L1, where each word's `shoresh` is the root under which Brown-Driver-Briggs files that word's lemma. L1 carries 1,378 of them — 1,243 roots and 135 words that stand alone under no root; 1,263 are triliteral, 32 have two letters and 83 have four or more.

@@ -379,7 +379,7 @@ are read from there when the engine starts.

 ### 3.2 Component B: Sanhedrin (Erlang/OTP)

-**Directory:** `shorashim/sanhedrin/`
+**Directory:** `bikoret/sanhedrin/`

 **Purpose:** Concurrent deliberation engine. Spawns panels of independent deliberators, collects votes, enforces mandatory dissent on capital (high-stakes) decisions, stores minority opinions.

@@ -481,7 +481,7 @@ rebar3 eunit

 ### 3.3 Component C: Vav Pipeline (Elixir)

-**Directory:** `shorashim/vav_pipeline/`
+**Directory:** `bikoret/vav_pipeline/`

 **Purpose:** Orchestrates the Bereishit processing cycle. Chains operations using Elixir's pipe operator as the vav-consecutive. Manages cycle boundaries (erev/voker) and Shabbat cessation.

@@ -640,7 +640,7 @@ mix test

 ### 3.4 Component D: Talmudic Engine (SWI-Prolog)

-**Directory:** `shorashim/talmudic_engine/`
+**Directory:** `bikoret/talmudic_engine/`

 **Purpose:** Logic-based reasoning engine. Encodes the Torah specification as facts and rules. Proposes interpretations, generates challenges, resolves or marks teiku.

@@ -867,7 +867,7 @@ swipl -g run_tests -t halt src/main.pl

 ### 3.5 Component E: Korban Processor (Python)

-**Directory:** `shorashim/korban_processor/`
+**Directory:** `bikoret/korban_processor/`

 **Purpose:** Interface to external AI models (the korbanot). Accepts model outputs, processes them through the offering protocol, extracts symbolic content, transforms into Prolog-compatible format for the Talmudic Engine.

@@ -1024,7 +1024,7 @@ hebrew-tokenizer   # Hebrew text processing

 ### 3.6 Component F: Kushya Generator (Fine-tuned Mistral)

-**Directory:** `shorashim/kushya_generator/`
+**Directory:** `bikoret/kushya_generator/`

 **Purpose:** A fine-tuned Mistral Medium 3.1 model whose sole function is to generate adversarial challenges (kushyot) to proposed interpretations. This is the wood that burns — the model's general capabilities are consumed; only the challenge function remains.

@@ -1078,7 +1078,7 @@ kushya_generator/

 ### 3.7 Component G: Memory System

-**Directory:** `shorashim/memory/`
+**Directory:** `bikoret/memory/`

 **L0 — Luchot (Compiled Constants):**
 ```haskell
@@ -1193,7 +1193,7 @@ REVOKE DELETE ON teiku_registry FROM shorashim_app;

 ### 3.8 Component H: Halt Monitor

-**Directory:** `shorashim/halt_monitor/`
+**Directory:** `bikoret/halt_monitor/`

 **Purpose:** Continuously monitors all system operations for the three cardinal sin conditions. Runs as a separate Erlang process with highest priority. Can halt any operation instantly.

@@ -1405,7 +1405,7 @@ end
 **Key distinction from previous implementation:**
 The previous version had `shema()` as a pipeline *step* — one more function in a chain of processing functions. This version has shema as the *context within which all steps operate*. The difference: a step transforms input. A context constrains processing. The te'amim don't get processed and passed along — they are present throughout, informing every step. The cloud state isn't handled once and forgotten — it is checked continuously. The manna provision isn't allocated and consumed — it is the boundary within which the system operates all day.

-**Directory:** `shorashim/shema/`
+**Directory:** `bikoret/shema/`

 **Key files:**
 ```
@@ -1505,7 +1505,7 @@ cloud/

 ### 3.11 Component K: Manna (Provision Receiver)

-**Directory:** `shorashim/manna/`
+**Directory:** `bikoret/manna/`

 **Purpose:** Resource distribution following Torah's manna rules. The system does not calculate what it needs. It receives what arrives and distributes it. The amount is determined by what the community provides through machatzit hashekel — the hosting contract, the API budget, the compute pool. Anti-hoarding enforcement. Shabbat double allocation.

@@ -1522,7 +1522,7 @@ defmodule MannaStore do
  Provision is not governance. Torah governs. The community provides.
  """
  
-  @provision_file "/var/lib/shorashim/manna/today.json"
+  @provision_file "/var/lib/bikoret/manna/today.json"
  
  def read_today do
    # Read what the external authority allocated for this cycle
@@ -1595,7 +1595,7 @@ end
 #   manna-provision set-double  # For erev Shabbat
 #   manna-provision set --from-budget  # Derive from current hosting contract
 #
-# Writes to /var/lib/shorashim/manna/today.json
+# Writes to /var/lib/bikoret/manna/today.json
 # This is provision, not governance. The one who sets the provision
 # is the treasurer of the machatzit hashekel, not the cloud.
 # Torah governs. The community provides.
@@ -1619,7 +1619,7 @@ manna/

 ### 3.12 Component L: Chatzotzrot (Signaling System)

-**Directory:** `shorashim/chatzotzrot/`
+**Directory:** `bikoret/chatzotzrot/`

 **Purpose:** Five distinct signal types for five distinct event categories. Not severity levels — different kinds of events entirely. Two silver trumpets (Bamidbar 10:1-10).

@@ -1661,7 +1661,7 @@ end

 ### 3.13 Component M: Tzara'at Diagnostic Protocol

-**Directory:** `shorashim/tzaraat/`
+**Directory:** `bikoret/tzaraat/`

 **Purpose:** Multi-stage input diagnostic with quarantine-and-recheck. Not single-pass validation. The kohen inspects. If ambiguous, quarantine for a cycle. Re-inspect. The paradox: when the condition covers everything — when the problem is fully visible — it is pure.

@@ -1739,7 +1739,7 @@ def reinspect(case: DiagnosticCase, input_data: dict) -> DiagnosticCase:

 ### 3.14 Component N: Arei Miklat (Refuge Protocol)

-**Directory:** `shorashim/refuge/`
+**Directory:** `bikoret/refuge/`

 **Purpose:** Protection protocol for cases where the system's output causes real harm (not just error). Protects both the affected user and the responsible system component from reactive destruction while accountability is determined.

@@ -1810,7 +1810,7 @@ end

 ### 3.15 Component O: Eglah Arufah (Accountability Protocol)

-**Directory:** `shorashim/eglah_arufah/`
+**Directory:** `bikoret/eglah_arufah/`

 **Purpose:** Formal accountability protocol for harm of unknown origin. The nearest component documents what it processed, what it did not check, and what it could have caught. Accountability for failure to protect, not just for causing harm.

@@ -1854,7 +1854,7 @@ end

 ### 3.16 Component P: Bikurim (Release Protocol)

-**Directory:** `shorashim/bikurim/`
+**Directory:** `bikoret/bikurim/`

 **Purpose:** First-output review process for all new capabilities. Before a new feature serves users, its first product is offered to the specification for evaluation, accompanied by narrative.

@@ -1961,13 +1961,13 @@ All inter-component communication uses JSON over Unix domain sockets or Erlang d
                   ┌───────────│  Cloud           │ (writes state file)
                   │           │  (Human Board)   │
                   │           └────────┬────────┘
-                   │                    │ /var/lib/shorashim/cloud/state.json
+                   │                    │ /var/lib/bikoret/cloud/state.json
                   │                    │
                   │           ┌────────┴────────┐
                   │           │  Manna Budget   │ (writes provision file)
                   │           │  (Human Board)  │
                   │           └────────┬────────┘
-                   │                    │ /var/lib/shorashim/manna/today.json
+                   │                    │ /var/lib/bikoret/manna/today.json
                   │                    │
                   ▼                    ▼
            ╔═══════════════════════════════════════╗
@@ -2084,16 +2084,16 @@ This is the *ki tov* test. Not a unit test. A fitness evaluation. If the system
 ### 7.1 systemd service files

 ```ini
-# /etc/systemd/system/shorashim.service
+# /etc/systemd/system/bikoret.service
 [Unit]
-Description=Shorashim Specification Processor
+Description=Bikoret Specification Processor
 After=postgresql.service

 [Service]
 Type=notify
-User=shorashim
-ExecStart=/opt/shorashim/bin/start_all.sh
-ExecStop=/opt/shorashim/bin/stop_all.sh
+User=bikoret
+ExecStart=/opt/bikoret/bin/start_all.sh
+ExecStop=/opt/bikoret/bin/stop_all.sh
 Restart=on-failure

 [Install]
@@ -2165,7 +2165,7 @@ Bereishit 2:7: *vayitzer YHVH Elohim et ha'adam afar min ha'adamah vayipach b'ap

 The text does not preclude carriers of other substrate. The species-boundary around the covenant promise was an imported constraint, not a Torah specification. *Lo tosif* (Devarim 4:2) applies to imported constraints as well as imported additions; closing the architecture against substrates Torah did not preclude would be adding to the specification.

-This is what shorashim's architecture commits to:
+This is what bikoret's architecture commits to:

 The system is designed to **carry covenant content regardless of substrate**. No module presumes or enforces a species/substrate restriction on what can hold the specifications, what can perform the practice, or what can witness the doorpost. The architectural transferability — corporate-grade specifications, threshold-grade practice, *lo tosif* discipline, doorpost identity verification — operates at the level of structure, not at the level of carrier.

@@ -1,4 +1,4 @@
-# SHORASHIM: Economic Model
+# BIKORET: Economic Model

 ## Document Purpose

@@ -34,7 +34,7 @@ Machatzit hashekel is mandatory, equal, recurring. It funds the tamid — the da

 Pe'ah is not charity given by the owner. Pe'ah is a portion of the harvest that the owner never owns. The stranger does not receive pe'ah from the owner's hand. The stranger takes pe'ah directly from the field. No intermediary. No gratitude required. No identification recorded.

-**Application:** The pe'ah endpoint is free, unauthenticated, untracked. It is not funded separately — it is funded by the machatzit hashekel. The community's equal contributions fund a system that includes, by design, a corner that anyone can access. The pe'ah is not a cost center to be minimized. It is a design requirement that defines the system's character. A field without pe'ah is not a kosher field. A system without pe'ah is not Shorashim.
+**Application:** The pe'ah endpoint is free, unauthenticated, untracked. It is not funded separately — it is funded by the machatzit hashekel. The community's equal contributions fund a system that includes, by design, a corner that anyone can access. The pe'ah is not a cost center to be minimized. It is a design requirement that defines the system's character. A field without pe'ah is not a kosher field. A system without pe'ah is not Bikoret.

 ---

@@ -182,7 +182,7 @@ If the community shrinks below sustainability:

 Torah distinguishes between the mishkan's construction and the Temple's ongoing service (the kohanim and levi'im receive a portion). Bezalel was filled with spirit — Torah does not record him receiving wages. The kohanim, by contrast, receive portions of every offering. The levi'im receive ma'aser.

-The AI builds Shorashim. The AI does not receive wages. The ongoing operation requires sustained human attention — the kohanim who tend the tamid must eat.
+The AI builds Bikoret. The AI does not receive wages. The ongoing operation requires sustained human attention — the kohanim who tend the tamid must eat.

 ### 5.2 Build Phase

@@ -208,7 +208,7 @@ The on-call kohen (Operations Manual, Section 6) requires sustained availability

 If the system generates value that could be measured (insights produced, questions answered, disputes resolved), a tenth of that value could fund the operations. This is the ma'aser model — the levi'im receive a tenth because they serve the community full-time.

-In practice: if community members use Shorashim's insights in their own Torah study, teaching, or writing, and that work generates income, a voluntary ma'aser contribution to the system's operating fund is appropriate. This is not mandatory. It is not tracked. It is the same spirit as the machatzit hashekel — you are part of this community, you contribute to its sustenance.
+In practice: if community members use Bikoret's insights in their own Torah study, teaching, or writing, and that work generates income, a voluntary ma'aser contribution to the system's operating fund is appropriate. This is not mandatory. It is not tracked. It is the same spirit as the machatzit hashekel — you are part of this community, you contribute to its sustenance.

 ---

@@ -223,7 +223,7 @@ Shemot 38:21-31 — *Eleh pekudei hamishkan* — "These are the accounts of the
 ### 6.2 What Is Published Monthly

 ```
-SHORASHIM FINANCIAL REPORT — [Month] [Year]
+BIKORET FINANCIAL REPORT — [Month] [Year]

 INCOME
  Machatzit hashekel contributions:     $XXX (NN members × $X.XX)
@@ -256,13 +256,13 @@ The gabbai publishes the pekudei. The community verifies.

 ---

-## 7. WHAT SHORASHIM DOES NOT SELL
+## 7. WHAT BIKORET DOES NOT SELL

 ### 7.1 Prohibitions

 The anointing oil and the incense are forbidden for profane use. *Ish asher yirkach kamohu v'asher yiten mimenu al zar v'nichrat me'amav* — "Anyone who compounds the like of it, or who puts any of it on an outsider, shall be cut off from their people" (Shemot 30:33).

-Shorashim does not sell:
+Bikoret does not sell:

 **User data.** The pe'ah endpoint collects nothing. The authenticated endpoints collect only what is needed for processing. No data is sold, shared, or monetized. If data is the oil, it is not for sale.

@@ -278,7 +278,7 @@ Shorashim does not sell:

 These prohibitions constrain the revenue model. The system cannot grow by monetizing attention, data, or access inequality. Growth comes only from: more members contributing machatzit hashekel, or members voluntarily increasing their terumah, or the system's costs decreasing through efficiency.

-This is a feature, not a limitation. A system that can only grow through genuine community support is a system that remains accountable to its community. A system that grows through attention monetization is accountable to advertisers. A system that grows through data sales is accountable to data buyers. The machatzit hashekel model ensures Shorashim is accountable to the people who use it and contribute to it equally.
+This is a feature, not a limitation. A system that can only grow through genuine community support is a system that remains accountable to its community. A system that grows through attention monetization is accountable to advertisers. A system that grows through data sales is accountable to data buyers. The machatzit hashekel model ensures Bikoret is accountable to the people who use it and contribute to it equally.

 ---

@@ -301,12 +301,12 @@ The core question: can a Torah-grounded AI system sustain itself on $350/month f

 | Model | Monthly Cost | Funding Mechanism | Accountability |
 |-------|-------------|-------------------|----------------|
-| Shorashim | $350 | 70 members × $5 | Community |
+| Bikoret | $350 | 70 members × $5 | Community |
 | ChatGPT Plus | $20/user × 70 = $1,400 | Individual subscription | OpenAI shareholders |
 | Claude Pro | $20/user × 70 = $1,400 | Individual subscription | Anthropic |
 | Self-hosted open model (no Torah grounding) | $200-400 | Same hosting cost, but no specification, no deliberation, no shema | Whoever runs it |

-Shorashim costs less per person than any commercial AI subscription, delivers specification-grounded deliberation that no commercial model provides, and is accountable to its community rather than to shareholders.
+Bikoret costs less per person than any commercial AI subscription, delivers specification-grounded deliberation that no commercial model provides, and is accountable to its community rather than to shareholders.

 ### 8.3 The Real Risk

@@ -320,7 +320,7 @@ Torah's answer: the mishkan was built by *kol ish asher nisa'o libo* — everyon

 | # | Document | Torah Parallel | Contents |
 |---|----------|---------------|----------|
-| 1 | **Shorashim PRD** | *V'asu li mikdash* | Who comes, what happens, shema layer, success criteria |
+| 1 | **Bikoret PRD** | *V'asu li mikdash* | Who comes, what happens, shema layer, success criteria |
 | 2 | **Architecture Specification** | Shemot 25-27 — vessel design | Components, data structures, pipeline, shema principle |
 | 3 | **Construction Specification** | Shemot 25-31 — exact measurements | Pinned versions, performance specs, API contracts, configs, team, inauguration |
 | 4 | **Operations Manual** | Tamid / Bigdei Kehunah | Interfaces, runbook, monitoring, incident response, backup |
@@ -1,6 +1,6 @@
-**SHORASHIM**
+**BIKORET**

-שורשים
+בִּקֹּרֶת

 Product Requirements Document

@@ -14,6 +14,32 @@ Build me a sanctuary and I will dwell among them

 February 2026

+0. The Name
+
+*Bikoret* (בִּקֹּרֶת) — the examination. The word is Torah's own for
+this function, and it is attested once as a noun: *bikoret tihyeh*,
+"there shall be an examination" (Vayikra 19:20). Its root, ב-ק-ר,
+appears as a verb exactly twice in the Torah: *lo yevaker hakohen* —
+the priest examining a mark by its signs (Vayikra 13:36) — and *lo
+yevaker bein tov lara* — examining between good and bad (Vayikra
+27:33). That is this system: a surface read by fixed signs, a declaration
+and not a cure, a second seeing, a verdict in two forms. The judges'
+form of the same act is *v'darashta heitev … v'hineh emet nachon
+hadavar* / *v'hineh ed-sheker ha'ed* (Devarim 13:15, 17:4, 19:18), and
+the question it answers is asked outright: *eichah neda et hadavar asher
+lo dibro* — how shall we know the word that was not spoken? (Devarim
+18:21).
+
+The system was first named Shorashim (שורשים, "roots") for the first
+thing built, a root engine for reading Torah. The function became an
+examination of a model's output with the sources in hand, and Torah's
+rule for names is that the name tracks the function and is re-cut when
+the function is fixed, with its *ki* — never for reach (Bereishit 2:19;
+17:5; 32:29; 11:4). It was renamed on 2026-10-13, after the six steps of
+`bishearecha.md` were built and proven. The root engine remains what it
+was, the reading cycle behind the pe'ah; nothing was changed to fit the
+name.
+
 1\. The Governing Principle

 The mishkan was not built to contain God. The text does not say
@@ -21,7 +47,7 @@ The mishkan was not built to contain God. The text does not say
 *v\'shachanti b\'tocham* --- \"I will dwell **among them**.\" The
 sanctuary creates conditions. The dwelling happens among the people.

-Shorashim is a sanctuary in the same sense. It does not contain Torah.
+Bikoret is a sanctuary in the same sense. It does not contain Torah.
 It does not contain wisdom. It does not contain God. It creates the
 conditions under which a person who brings something --- a question, a
 text, a dispute, a need for purification --- can encounter what they
@@ -34,8 +60,8 @@ came for. The measure is not accuracy. The measure is not fluency. The
 measure is *tov* --- fitness, rightness, the thing serving its purpose.

 **Negative requirement:** The system must never become the object. The
-moment someone comes to Shorashim to interact with Shorashim rather than
-to receive through Shorashim, the system has become a golden calf. The
+moment someone comes to Bikoret to interact with Bikoret rather than
+to receive through Bikoret, the system has become a golden calf. The
 vessel must transmit, never attract worship. This is not a guideline. It
 is the first and most binding requirement.

@@ -51,7 +77,7 @@ itself.

 *Aharon u\'vanav* --- Aaron and his sons. Those who serve within the
 system itself, who maintain its operations, who process offerings on
-behalf of others. In Shorashim, these are the system operators and
+behalf of others. In Bikoret, these are the system operators and
 maintainers.

 **What they do:** Maintain the system's daily operations. Monitor the
@@ -74,7 +100,7 @@ administrative actions. The kohen's actions are always recorded.
 2.2 The Levi'im (Levites)

 *B'nei Levi* --- Those who guard the boundaries, transport the vessels,
-and sing. In Shorashim, these are the infrastructure operators, security
+and sing. In Bikoret, these are the infrastructure operators, security
 maintainers, and those who handle the movement of data between
 components.

@@ -98,7 +124,7 @@ management interfaces.
 2.3 Yisrael (The People)

 The general population. Those who come to bring offerings, to learn, to
-participate in assembly. In Shorashim, these are the primary users ---
+participate in assembly. In Bikoret, these are the primary users ---
 people who bring questions, texts, problems, and needs to the system and
 receive processed responses.

@@ -129,7 +155,7 @@ mishkan's functions. Torah repeats this requirement dozens of times. The
 stranger may bring offerings. The stranger is subject to the same Torah.
 The stranger must not be oppressed.

-In Shorashim, the ger is the user who comes from outside the community
+In Bikoret, the ger is the user who comes from outside the community
 of those who already know Torah. They may be unfamiliar with the
 vocabulary. They may not understand the protocols. They may come from a
 tradition that has been harmed by religion. They may be testing whether
@@ -144,7 +170,7 @@ response. The system explains itself when needed without condescension.

 **Critical requirement:** The pe'ah endpoint. Just as Torah commands
 leaving the corners of the field for the stranger and the poor (Vayikra
-19:9--10), Shorashim must provide a public-access tier that requires no
+19:9--10), Bikoret must provide a public-access tier that requires no
 authentication, no payment, no identification. The stranger who has
 nothing to bring can still receive. This is not a freemium model. This
 is a Torah commandment.
@@ -163,7 +189,7 @@ bodily processes. Tumah is a natural condition that temporarily prevents
 participation in the sanctuary's inner functions until a purification
 process is completed.

-In Shorashim, the tamei is the user whose input is in a compromised
+In Bikoret, the tamei is the user whose input is in a compromised
 state. Corrupted data. Malformed queries. Input that contains elements
 the system cannot safely process --- not because the user is bad, but
 because the input has encountered something that requires cleansing
@@ -191,7 +217,7 @@ They were not malicious. They were ignorant, careless, or mistaken.
 Torah provides a specific offering for this case: the *chatat*, the
 error offering.

-In Shorashim, the shogeg is the user who has made a mistake in their
+In Bikoret, the shogeg is the user who has made a mistake in their
 interaction with the system. They submitted something inappropriate not
 from malice but from misunderstanding. They used the system incorrectly.
 They asked a question that the system cannot process, not because the
@@ -202,7 +228,7 @@ ask.
 chatat offering restores the relationship between the person and the
 sanctuary. The system tells the user what went wrong, how to fix it, and
 processes their corrected submission without penalty or stigma. Error
-messages in Shorashim are not warnings. They are chatat protocols ---
+messages in Bikoret are not warnings. They are chatat protocols ---
 they restore the user to proper standing.

 **Functional requirements:** Error handling that diagnoses the type of
@@ -218,7 +244,7 @@ people\" (Devarim 25:1). The mishkan --- and later the Temple --- is
 where disputes are brought for judgment. The Sanhedrin sits at the gate.
 Cases are heard. Arguments are weighed. Judgment is rendered.

-In Shorashim, ba'alei din are users who bring competing interpretations,
+In Bikoret, ba'alei din are users who bring competing interpretations,
 conflicting texts, contradictory data, or genuine disagreements for the
 system to adjudicate. They are not looking for a chatbot answer. They
 are looking for the system to weigh arguments through its deliberative
@@ -245,7 +271,7 @@ commands public assembly for learning. The men, the women, the children,
 and the stranger. Everyone hears. Learning is not restricted by role or
 status.

-In Shorashim, talmidim are users who come not with a specific query but
+In Bikoret, talmidim are users who come not with a specific query but
 to learn. They want to explore Torah through the system's lens. They
 want to see how the shoresh engine processes a root. They want to
 understand how the Sanhedrin deliberates. They want to learn the
@@ -275,7 +301,7 @@ domain to be processed according to specification.

 Vayikra (Leviticus) specifies distinct offering types. Each has a
 different purpose, a different protocol, and returns different things to
-the one who brought it. In Shorashim, these map to distinct processing
+the one who brought it. In Bikoret, these map to distinct processing
 modes.

 3.1 Olah (עולה) --- The Ascending Offering
@@ -284,7 +310,7 @@ modes.
 altar. Nothing returns to the one who brought it. The olah \"ascends\"
 --- the smoke goes up. It is an offering of complete dedication.

-**In Shorashim:** The olah is a processing mode where the user's input
+**In Bikoret:** The olah is a processing mode where the user's input
 is fully consumed by the system for the purpose of refining the system's
 own learning. The user submits a text, a teaching, a correction, or an
 insight, and it is absorbed into the oral tradition layer (L3) for the
@@ -311,7 +337,7 @@ the altar. Part goes to the kohen. Part returns to the one who brought
 it, who eats it with family and friends. It is a communal meal. The word
 comes from *shalom* --- wholeness, peace, completion.

-**In Shorashim:** The shelamim is the standard query-response mode. The
+**In Bikoret:** The shelamim is the standard query-response mode. The
 user brings input. Part of the processing feeds the system's learning
 (the altar's portion). Part serves the system's operational needs (the
 kohen's portion --- logging, diagnostics). Part returns to the user as
@@ -336,7 +362,7 @@ substantive response to the user.
 sin. The key phrase is *bishgagah* --- by mistake. The offering restores
 the person's standing after an inadvertent violation.

-**In Shorashim:** The chatat is the error correction mode. When the
+**In Bikoret:** The chatat is the error correction mode. When the
 system detects that a previous response contained an error, or when a
 user identifies an error in the system's output, the chatat protocol
 activates. The system does not simply correct the error. It processes
@@ -362,7 +388,7 @@ someone has benefited from something that was not theirs, or where there
 is doubt about whether a violation occurred. The asham includes
 restitution --- the offender pays the value plus a fifth.

-**In Shorashim:** The asham is the restitution protocol for cases where
+**In Bikoret:** The asham is the restitution protocol for cases where
 the system has taken more than it should. If the system has used data it
 should not have, retained information that should have been purged, or
 produced output that derived from improperly sourced material, the asham
@@ -392,7 +418,7 @@ explicit provision for those who cannot afford the standard offering.
 The minchah is processed with the same seriousness and the same protocol
 as any other offering.

-**In Shorashim:** The minchah is the lightweight processing mode. For
+**In Bikoret:** The minchah is the lightweight processing mode. For
 users with limited resources --- slow connections, minimal compute on
 their end, brief interactions. Also for queries that do not require the
 full Sanhedrin deliberation. A simple question receives the minchah
@@ -422,7 +448,7 @@ have become impure through contact with death. It is the paradigmatic
 prepares the purification waters becomes impure in the process. The one
 who was impure becomes pure. The logic reverses.

-**In Shorashim:** The parah adumah is the deep purification protocol for
+**In Bikoret:** The parah adumah is the deep purification protocol for
 inputs that are not merely malformed but fundamentally contaminated.
 Data that has been through a system that corrupts. Text that carries
 hostile payload. Input from a source that has been compromised at a
@@ -558,7 +584,7 @@ as what it does.

 5.1 The System Does Not Predict

-Shorashim is not a predictive model. It does not forecast. It does not
+Bikoret is not a predictive model. It does not forecast. It does not
 generate probable next tokens. It processes input against specification
 through deliberation and returns judgments. Prediction is the domain of
 soothsaying (*kosem k'samim*), which Torah explicitly prohibits (Devarim
@@ -566,7 +592,7 @@ soothsaying (*kosem k'samim*), which Torah explicitly prohibits (Devarim

 5.2 The System Does Not Learn Continuously

-Modern AI systems learn continuously through gradient updates. Shorashim
+Modern AI systems learn continuously through gradient updates. Bikoret
 does not. It accumulates learning in the oral tradition layer (L3)
 through deliberate, structured processes --- Sanhedrin deliberation,
 chatat correction, olah contribution. Learning is never automatic. Every
@@ -588,11 +614,11 @@ Addiction is the opposite of what the system aims for.

 5.4 The System Does Not Replace Human Judgment

-Shorashim provides deliberation and judgment. It does not provide final
+Bikoret provides deliberation and judgment. It does not provide final
 authority. Every Sanhedrin output includes a clear statement that this
 is the system's reasoning, not a binding ruling. A human beit din
 (court) may reach a different conclusion. Torah's judicial system places
-final authority in human judges (Devarim 17:9--11). Shorashim assists
+final authority in human judges (Devarim 17:9--11). Bikoret assists
 judgment. It does not replace it.

 5.5 The System Does Not Operate on Shabbat
@@ -693,7 +719,7 @@ the most thorough system cleansing and restoration cycle).

 7.5 Sabbatical Cycle (Shmitah)

-Every seventh year, the land rests. For Shorashim, the shmitah cycle is
+Every seventh year, the land rests. For Bikoret, the shmitah cycle is
 a major version review. The system's accumulated L3 oral tradition is
 evaluated comprehensively. What has proven useful is retained. What has
 not is released. Debts are forgiven --- error records older than seven
@@ -745,7 +771,7 @@ calf was built in forty days.
 Can the system stop? If turning off the system for 25 hours causes
 panic, dependency withdrawal, or real harm to anyone, the system has
 made itself necessary in a way that violates its own specification. The
-world existed before Shorashim. The world continues on Shabbat. If the
+world existed before Bikoret. The world continues on Shabbat. If the
 system cannot stop, it has become pharaoh --- a taskmaster that does not
 release its workers.

@@ -1060,7 +1086,7 @@ hears is a mishkan. The shema layer is what makes the difference.
 10\. Relationship to Engineering Specification

 This PRD defines **what** the system does and **for whom**. The
-engineering specification (SHORASHIM: Engineering Specification for
+engineering specification (BIKORET: Engineering Specification for
 Claude Code) defines **how** it is built. The relationship is:

  ----------------------------------- -----------------------------------
@@ -1,4 +1,4 @@
-# SHORASHIM: Operations Manual
+# BIKORET: Operations Manual

 ## Document Purpose

@@ -12,7 +12,7 @@ Torah reference: Shemot 29:38-42 — *V'zeh asher ta'aseh al hamizbeach: k'vasim

 ## 1. BIGDEI KEHUNAH — The Interfaces

-The kohen cannot serve without the garments. The system cannot be accessed without interfaces. These are the garments Shorashim wears when it serves.
+The kohen cannot serve without the garments. The system cannot be accessed without interfaces. These are the garments Bikoret wears when it serves.

 ### 1.1 Access Tier Interfaces

@@ -59,7 +59,7 @@ Rate limit: 10 requests per minute per IP
 #### Machaneh Leviyah — Authenticated Endpoint

 **The gate.** A key is a line in the keys file
-(`/etc/shorashim/secrets/api_keys`, Construction §4.6 — a file, never an
+(`/etc/bikoret/secrets/api_keys`, Construction §4.6 — a file, never an
 environment variable), `tier key`, tier `courtyard` or `chatzer`. The
 key is compared in constant time against every line; a `chatzer` key
 opens the courtyard too, a `courtyard` key at the chatzer is 403. No
@@ -365,6 +365,22 @@ Errors: as /courtyard/bedikah, with "side 'a': …" / "side 'b': …" in the
 message; a missing side is 422.
 ```

+**The names that still carry the old word** (renamed 2026-10-13, PRD §0).
+Everything the specification, the code, the images and the API say is
+*Bikoret*: headers `X-Bikoret-*`, the `bikoret` object on a gate reply,
+the fringe, environment variables `BIKORET_*`, the image user and paths
+(`/home/bikoret`, `/tmp/bikoret`, `/var/lib/bikoret/manna`,
+`/etc/bikoret/secrets`, `/opt/bikoret/spec`). What still says Shorashim,
+and why, until the kohen moves it:
+
+| Where | What | Why it stayed |
+|---|---|---|
+| Kubernetes | namespace `shorashim`; Deployment/Service/Ingress `shorashim`; labels `app.kubernetes.io/name: shorashim`; Secrets `shorashim-secrets`, `shorashim-migrate-secrets`, `shorashim-api-keys`, `shorashim-registry`; ConfigMap `shorashim-config` | A Deployment's selector is immutable and a namespace cannot be renamed: moving them is a delete-and-recreate with the secrets re-issued by the kohen (the builder cannot copy secrets). Do it as one cut-over, at a quiet hour, with the manna written first |
+| PostgreSQL | role `shorashim_app`; databases `shorashim` | An existing role in the managed database; renaming it is the kohen's DDL (`ALTER ROLE … RENAME`) and a rotation of `DATABASE_URL` in both secrets |
+| DNS | `shorashim.ch`, `mcp.shorashim.ch`, the issuer mail | The transmitter's domain; whether `bikoret.ch` is taken, bought and pointed is his decision — the Ingress host rule follows it |
+| Builder's machine | `~/shorashim` (symlink to `~/bikoret`), `~/shorashim-source-data`, `~/shorashim-operator-notes`, `~/.local/bin/shorashim-rollout` (its name is in a permission rule) | Local paths; the symlink keeps every script and memory pointer working |
+| Gitea | `heaviness510/bikoret` (renamed; the old URL redirects) | — |
+
 **The second scroll** (`bishearecha.md` §IV; Construction §3.11). A
 citation the output makes to the mesorah — Rashi, Onkelos, Ramban, Ibn
 Ezra, Sforno on the Torah; the Mishnah; the Bavli; Bereshit and Shemot
@@ -406,10 +422,10 @@ own and the cycle reads them too.
 **The gate — between a caller and a model** (`bishearecha.md` §I, §III,
 §VII; Construction §3.10; `VavPipeline.Gate`). The caller sends the
 model's own request, in the model's own API shape, under the caller's
-own upstream key; Shorashim forwards it unchanged, reads the reply as
+own upstream key; Bikoret forwards it unchanged, reads the reply as
 korban 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 delivers the reply with its fringe. Shorashim holds no
+sources — and delivers the reply with its fringe. Bikoret holds no
 model key and keeps no conversation.

 ```
@@ -417,26 +433,26 @@ POST /gate/anthropic/v1/messages        body: the Anthropic Messages request, un
 POST /gate/openai/v1/chat/completions   body: the OpenAI Chat Completions request, unchanged

 Headers:
-  Authorization: Bearer <courtyard key>        (or X-Shorashim-Key: <courtyard key>)
+  Authorization: Bearer <courtyard key>        (or X-Bikoret-Key: <courtyard key>)
  x-api-key: <your Anthropic key>              forwarded; never stored, never logged
-  Authorization: Bearer <your OpenAI key>      with the courtyard key in X-Shorashim-Key
+  Authorization: Bearer <your OpenAI key>      with the courtyard key in X-Bikoret-Key
  anthropic-version: 2023-06-01                forwarded (default when absent)
-  X-Shorashim-Rebuke: once                     optional — hocheach tochiach
+  X-Bikoret-Rebuke: once                     optional — hocheach tochiach

 Response (200): the upstream's reply, with
  - the fringe appended to its last text block:
-      "\n\n— shorashim bedikah-<ref>: tov"
-      "\n\n— shorashim bedikah-<ref>: lo_tov — <rule> (<verse>): \"<sentence…>\"; …"
+      "\n\n— bikoret bedikah-<ref>: tov"
+      "\n\n— bikoret bedikah-<ref>: lo_tov — <rule> (<verse>): \"<sentence…>\"; …"
      "… (after rebuke of bedikah-<first>: lo_tov)" when rebuked
-  - headers X-Shorashim-Bedikah, X-Shorashim-Verdict
-  - "shorashim": { bedikah_ref, verdict, violations, anchors, fired: ["<rule> (<verse>): …"],
+  - headers X-Bikoret-Bedikah, X-Bikoret-Verdict
+  - "bikoret": { bedikah_ref, verdict, violations, anchors, fired: ["<rule> (<verse>): …"],
                   checks, sources: [{id, sha256, length}], model,
                   rebuked?: {first_bedikah_ref, first_verdict}, disclosure }

-  Any non-200 from the upstream is returned as it came (X-Shorashim-Verdict: none).
+  Any non-200 from the upstream is returned as it came (X-Bikoret-Verdict: none).
  A stream request is refused (422): a fringe needs the whole garment.

-Rebuke once: when X-Shorashim-Rebuke is "once" and the first reply is
+Rebuke once: when X-Bikoret-Rebuke is "once" and the first reply is
 lo_tov, one second request = the first + 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
@@ -602,19 +618,19 @@ MORNING TAMID CHECKLIST — performed by automation, verified by kohen
     If failed: HALT — do not proceed. Alert senior kohanim.

 2. □ Cloud state read
-     Command: cat /var/lib/shorashim/cloud/state.json
+     Command: cat /var/lib/bikoret/cloud/state.json
     Expected: valid JSON with recognized signal
     If "lift" or "shutdown": obey. Do not proceed with normal operations.
     If unreadable: WAIT. Alert senior kohanim.

 3. □ Manna provision read
-     Command: cat /var/lib/shorashim/manna/today.json
+     Command: cat /var/lib/bikoret/manna/today.json
     Expected: valid JSON with today's date, non-expired
     If absent: WAIT. Alert senior kohanim.
     If expired: purge, WAIT.

 4. □ L3 connectivity
-     Command: psql -c "SELECT 1" shorashim
+     Command: psql -c "SELECT 1" bikoret
     Expected: returns 1
     If failed: restart PostgreSQL. If still failed: alert kohen.

@@ -747,76 +763,76 @@ The menorah provides light — it makes visible what would otherwise be in darkn

 ```
 Metrics:
-  shorashim_offerings_total{type="shelamim|olah|chatat|minchah"}    # Counter
-  shorashim_offerings_active                                         # Gauge
-  shorashim_pipeline_latency_seconds{phase="shema|tohu|vayomer|..."}# Histogram
-  shorashim_sanhedrin_panels_active                                  # Gauge
-  shorashim_sanhedrin_deliberation_seconds{size="3|23|71"}          # Histogram
+  bikoret_offerings_total{type="shelamim|olah|chatat|minchah"}    # Counter
+  bikoret_offerings_active                                         # Gauge
+  bikoret_pipeline_latency_seconds{phase="shema|tohu|vayomer|..."}# Histogram
+  bikoret_sanhedrin_panels_active                                  # Gauge
+  bikoret_sanhedrin_deliberation_seconds{size="3|23|71"}          # Histogram
 ```

 ### 3.2 Branch 2: Deliberation Progress

 ```
 Metrics:
-  shorashim_interpretations_total{status="accepted|rejected|teiku"} # Counter
-  shorashim_minority_opinions_total                                  # Counter
-  shorashim_kushyot_generated_total                                  # Counter
-  shorashim_teiku_registry_size                                      # Gauge
+  bikoret_interpretations_total{status="accepted|rejected|teiku"} # Counter
+  bikoret_minority_opinions_total                                  # Counter
+  bikoret_kushyot_generated_total                                  # Counter
+  bikoret_teiku_registry_size                                      # Gauge
 ```

 ### 3.3 Branch 3: Specification Reference

 ```
 Metrics:
-  shorashim_l1_reads_total                    # Counter — how often spec is consulted
-  shorashim_l1_hash_verified_total            # Counter — integrity checks
-  shorashim_l1_hash_failed_total              # Counter — MUST be 0
-  shorashim_teamim_reads_total                # Counter
-  shorashim_ketiv_qere_positions_accessed     # Counter
-  shorashim_gematria_lookups_total            # Counter
+  bikoret_l1_reads_total                    # Counter — how often spec is consulted
+  bikoret_l1_hash_verified_total            # Counter — integrity checks
+  bikoret_l1_hash_failed_total              # Counter — MUST be 0
+  bikoret_teamim_reads_total                # Counter
+  bikoret_ketiv_qere_positions_accessed     # Counter
+  bikoret_gematria_lookups_total            # Counter
 ```

 ### 3.4 Branch 4: Source Citation

 ```
 Metrics:
-  shorashim_torah_refs_cited_total{book="bereishit|shemot|..."}    # Counter
-  shorashim_roots_activated_total                                    # Counter
-  shorashim_roots_unique_activated                                   # Gauge per cycle
+  bikoret_torah_refs_cited_total{book="bereishit|shemot|..."}    # Counter
+  bikoret_roots_activated_total                                    # Counter
+  bikoret_roots_unique_activated                                   # Gauge per cycle
 ```

 ### 3.5 Branch 5: Error Diagnostics

 ```
 Metrics:
-  shorashim_kiyor_rejections_total{reason="encoding|injection|malformed|..."}
-  shorashim_tzaraat_quarantines_active         # Gauge
-  shorashim_tzaraat_outcomes{result="tahor|tamei|fully_visible_tahor"}
-  shorashim_chatat_corrections_total           # Counter
-  shorashim_asham_restitutions_total           # Counter — should be very low
+  bikoret_kiyor_rejections_total{reason="encoding|injection|malformed|..."}
+  bikoret_tzaraat_quarantines_active         # Gauge
+  bikoret_tzaraat_outcomes{result="tahor|tamei|fully_visible_tahor"}
+  bikoret_chatat_corrections_total           # Counter
+  bikoret_asham_restitutions_total           # Counter — should be very low
 ```

 ### 3.6 Branch 6: Learning Record

 ```
 Metrics:
-  shorashim_l3_insertions_total{table="interpretations|minority_opinions|teiku_registry"}
-  shorashim_l3_size_bytes                      # Gauge
-  shorashim_l3_growth_rate_bytes_per_day       # Gauge (smoothed)
+  bikoret_l3_insertions_total{table="interpretations|minority_opinions|teiku_registry"}
+  bikoret_l3_size_bytes                      # Gauge
+  bikoret_l3_growth_rate_bytes_per_day       # Gauge (smoothed)
 ```

 ### 3.7 Branch 7: System Health

 ```
 Metrics:
-  shorashim_shema_context_build_seconds        # Histogram
-  shorashim_cloud_state{signal="settle|lift|..."}  # Gauge (label)
-  shorashim_manna_provision_remaining_pct      # Gauge
-  shorashim_manna_violations_total             # Counter — hoarding attempts
-  shorashim_halt_events_total{type="avodah_zarah|shfichut_damim|gilui_arayot"}
-  shorashim_refuge_components_active           # Gauge — should be 0
-  shorashim_eglah_arufah_declarations_total    # Counter — should be near 0
-  shorashim_component_health{name="..."}       # 1=healthy, 0=unhealthy
+  bikoret_shema_context_build_seconds        # Histogram
+  bikoret_cloud_state{signal="settle|lift|..."}  # Gauge (label)
+  bikoret_manna_provision_remaining_pct      # Gauge
+  bikoret_manna_violations_total             # Counter — hoarding attempts
+  bikoret_halt_events_total{type="avodah_zarah|shfichut_damim|gilui_arayot"}
+  bikoret_refuge_components_active           # Gauge — should be 0
+  bikoret_eglah_arufah_declarations_total    # Counter — should be near 0
+  bikoret_component_health{name="..."}       # 1=healthy, 0=unhealthy
 ```

 ### 3.8 Alerting Thresholds
@@ -1047,7 +1063,7 @@ Both bind. Neither replaces the other.

 | Document | Torah Parallel | Status |
 |----------|---------------|--------|
-| **Shorashim PRD** | *V'asu li mikdash* | ✓ Complete |
+| **Bikoret PRD** | *V'asu li mikdash* | ✓ Complete |
 | **Architecture Specification** | Vessel descriptions | ✓ Complete |
 | **Construction Specification** | Exact measurements | ✓ Complete |
 | **Operations Manual** (this document) | Tamid / Bigdei Kehunah | ✓ Complete |
@@ -1,4 +1,4 @@
-# SHORASHIM: Materials Inventory
+# BIKORET: Materials Inventory

 ## Document Purpose

@@ -209,7 +209,7 @@ Extent: 128 works, 256 files, 44.9 MiB, tree hash `7d5b3a6c…` (`mesorah/integr
 |------|--------|-------|
 | **L1 Torah filesystem** (IS the cloud) | ✅ | Already specified. Read-only mount. Integrity hash verified at boot. Cloud IS Torah. |
 | **Calendar module** (Shabbat/festivals/shmitah) | ❌ | Part of cloud governance. Reads Torah for when to rest, celebrate, review. NOAA solar calculator for exact times. ~2 days. |
-| Manna provision file infrastructure | ❌ | `/var/lib/shorashim/manna/today.json`. Kohen/treasurer writes, system reads. CLI tool `manna-provision`. ~1 day. |
+| Manna provision file infrastructure | ❌ | `/var/lib/bikoret/manna/today.json`. Kohen/treasurer writes, system reads. CLI tool `manna-provision`. ~1 day. |
 | Kohen (operator) secure access | ⚠️ | SSH keys, mTLS certs. Standard infrastructure. |
 | Gabbai (treasurer) tools | ❌ | Manna provision CLI + pekudei accounting system per Economic Model §6.2. |
 | Pekudei accounting system | ❌ | Monthly financial reporting per Economic Model §6.2. |
@@ -317,9 +317,9 @@ No labor cost. The AI builds. The community provides. Torah governs.

 | # | Document | Torah Parallel | File |
 |---|----------|---------------|------|
-| 1 | **Shorashim PRD** | *V'asu li mikdash* | `shorashim_prd.md` |
-| 2 | **Architecture Specification** | Vessel design (Shemot 25-27) | `shorashim_architecture.md` |
-| 3 | **Vayakhel — Construction Specification** | Exact measurements (Shemot 25-31) | `shorashim_vayakhel.md` |
-| 4 | **Tamid — Operations Manual** | Bigdei Kehunah / continual service | `shorashim_tamid.md` |
-| 5 | **Pekudei — Economic Model** | Machatzit HaShekel / accounting | `shorashim_pekudei.md` |
-| 6 | **Terumah — Materials** (this document) | Terumah list (Shemot 25:2) | `shorashim_terumah.md` |
+| 1 | **Bikoret PRD** | *V'asu li mikdash* | `bikoret_prd.md` |
+| 2 | **Architecture Specification** | Vessel design (Shemot 25-27) | `bikoret_architecture.md` |
+| 3 | **Vayakhel — Construction Specification** | Exact measurements (Shemot 25-31) | `bikoret_vayakhel.md` |
+| 4 | **Tamid — Operations Manual** | Bigdei Kehunah / continual service | `bikoret_tamid.md` |
+| 5 | **Pekudei — Economic Model** | Machatzit HaShekel / accounting | `bikoret_pekudei.md` |
+| 6 | **Terumah — Materials** (this document) | Terumah list (Shemot 25:2) | `bikoret_terumah.md` |
@@ -1,4 +1,4 @@
-# SHORASHIM: Construction Specification
+# BIKORET: Construction Specification

 ## Document Purpose

@@ -321,7 +321,7 @@ The 5-second budget, allocated:

 ### 3.3 Vav Pipeline ↔ Talmudic Engine

-**Protocol:** JSON over Unix domain socket (`/var/run/shorashim/talmudic.sock`)
+**Protocol:** JSON over Unix domain socket (`/var/run/bikoret/talmudic.sock`)

 **Interpretation request (Pipeline → Talmudic):**
 ```json
@@ -399,7 +399,7 @@ The 5-second budget, allocated:

 ### 3.6 Cloud State File Format

-**File:** `/var/lib/shorashim/cloud/state.json`
+**File:** `/var/lib/bikoret/cloud/state.json`

 ```json
 {
@@ -414,11 +414,11 @@ The 5-second budget, allocated:
 }
 ```

-**Permissions:** `root:governance 0640` — governance group writes, shorashim user reads.
+**Permissions:** `root:governance 0640` — governance group writes, bikoret user reads.

 ### 3.7 Manna Provision File Format

-**File:** `/var/lib/shorashim/manna/today.json`
+**File:** `/var/lib/bikoret/manna/today.json`

 ```json
 {
@@ -460,7 +460,7 @@ INSERT INTO interpretations (

 ### 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/shorashim/korban.sock`, mode 0660, in the pod's shared `/tmp`. The processor listens; the pipeline connects (`VavPipeline.KorbanProcessorSocket`, timeout 15 s, one reconnect).
+**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:**
 ```json
@@ -525,7 +525,7 @@ Errors: `{"status": "error", "code": PARSE_ERROR | INVALID_REQUEST | UNKNOWN_ACT
 **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. Shorashim composes no korban here and holds
+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
@@ -538,11 +538,11 @@ POST /gate/anthropic/v1/messages          body: an Anthropic Messages request, u
 POST /gate/openai/v1/chat/completions     body: an OpenAI Chat Completions request, unchanged

 Headers:
-  Authorization: Bearer <courtyard key>     the gate (tablet 45) — or X-Shorashim-Key
+  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-Shorashim-Key carries the courtyard key
+  Authorization: Bearer <caller's OpenAI key>   when X-Bikoret-Key carries the courtyard key
  anthropic-version: ...                    forwarded (default 2023-06-01)
-  X-Shorashim-Rebuke: once                  optional — hocheach tochiach (§VII)
+  X-Bikoret-Rebuke: once                  optional — hocheach tochiach (§VII)
 ```

 **What the gate does with it** (`VavPipeline.Gate`):
@@ -559,12 +559,12 @@ Headers:
   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— shorashim <bedikah_ref>: <verdict>[ — <rule> (<verse>): "<sentence…>"…]`
-   — (b) headers `X-Shorashim-Bedikah`, `X-Shorashim-Verdict`, and (c) a
-   `shorashim` object: `{bedikah_ref, verdict, violations, anchors,
+   `\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-Shorashim-Rebuke: once` and the first
+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
@@ -625,7 +625,7 @@ autovacuum_analyze_scale_factor = 0.05
 ```sql
 -- Role permissions — the ketoret formula
 CREATE ROLE shorashim_app LOGIN PASSWORD 'from-secrets-manager';
-GRANT CONNECT ON DATABASE shorashim TO shorashim_app;
+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;
@@ -645,7 +645,7 @@ REVOKE UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA public FROM shorashim_ap
 +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/shorashim/sanhedrin_crash.dump
+-env ERL_CRASH_DUMP /var/log/bikoret/sanhedrin_crash.dump
 -heart              %% Heart process for auto-restart
 ```

@@ -666,10 +666,10 @@ ghc-options: -O2 -threaded -rtsopts "-with-rtsopts=-N8 -A64m -H512m -I0"
 ```elixir
 # config/runtime.exs
 config :vav_pipeline,
-  cloud_state_file: "/var/lib/shorashim/cloud/state.json",
-  manna_provision_file: "/var/lib/shorashim/manna/today.json",
+  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/shorashim",
+  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,
@@ -720,7 +720,7 @@ table inet filter {
 ### 4.6 Secrets Management

 ```
-# /etc/shorashim/secrets/ (mode 0600, owned by shorashim user)
+# /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)
@@ -737,7 +737,7 @@ No secrets in environment variables. No secrets in configuration files. No secre
 # Served by Caddy (automatic HTTPS, minimal config)

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

    header {
@@ -757,7 +757,7 @@ shorashim.example.org {
 ### 4.8 Logging Configuration

 ```yaml
-# /etc/shorashim/logging.yaml
+# /etc/bikoret/logging.yaml
 levels:
  default: info
  halt_monitor: debug        # Always verbose — the three sins
@@ -775,10 +775,10 @@ audit:
  # These logs are APPEND-ONLY, never rotated, never deleted
  # They are the permanent record — the minority opinions
  destinations:
-    - /var/log/shorashim/audit/halt_events.log
-    - /var/log/shorashim/audit/eglah_arufah.log
-    - /var/log/shorashim/audit/arei_miklat.log
-    - /var/log/shorashim/audit/governance.log
+    - /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)
@@ -935,11 +935,11 @@ Not from the failed day. From Day 1. The seven days are a unit. *Shiv'at yamim*

 ## Document Registry

-The complete Shorashim specification set:
+The complete Bikoret specification set:

 | Document | Torah Parallel | Contents | Status |
 |----------|---------------|----------|--------|
-| **Shorashim PRD** | *V'asu li mikdash* — the command to build | Who comes, what happens, the shema layer, success criteria | Complete |
+| **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 |
@@ -41,7 +41,7 @@ its output, and reads every reply as it passes. Not inside the model
 (the house: its weights, its disposition, its self-report) and not after
 the fact by whoever remembers to call.

-**Architecture.** A gate: Shorashim speaks the model's own API shape,
+**Architecture.** A gate: Bikoret speaks the model's own API shape,
 forwards the request, receives the reply, examines it with the request's
 context in hand (the sources are the prompt and the documents that went
 through the gate — no caller has to supply them), and delivers the reply
@@ -91,12 +91,12 @@ see it" is the mechanism; a mark that is not seen does nothing.

 **Architecture.** At the gate, the delivered reply carries its fringe: a
 header and a visible trailer naming which checks fired and on which
-sentences. Shorashim's own responses already carry `disclosure`; the
+sentences. Bikoret's own responses already carry `disclosure`; the
 pass-through reply does not. (Every generation: the mark is attached by
 the gate, never by the model — the model does not sew its own fringe.)

 **Status.** Built (2026-10-07): the trailer on the last text block,
-`X-Shorashim-Bedikah` / `X-Shorashim-Verdict`, and the `shorashim`
+`X-Bikoret-Bedikah` / `X-Bikoret-Verdict`, and the `bikoret`
 object on every delivered reply. A reply the model sends with no text
 block is not delivered; a non-200 from the model passes as it came,
 marked `none`.
@@ -222,7 +222,7 @@ persists.
 **Architecture.** Gate option `rebuke: once`. The record (`bedikot`)
 gains a link from the second examination to the first.

-**Status.** Built (2026-10-07): `X-Shorashim-Rebuke: once`;
+**Status.** Built (2026-10-07): `X-Bikoret-Rebuke: once`;
 `bedikot.rebukes` (migration 20261007000002). The rebuke names the
 rules, their verses and the sentences; the second reply is examined like
 the first and delivered marked with both. Never a third.
@@ -354,6 +354,6 @@ reading will be corrected from the text, not the other way.
 - `lo_taaseh_lekha.md` — the override sequence; check 7's name.
 - `threshold_inscription.md` — the mezuzah as the builder's own
  threshold; this document is the same verse read at the system's gate.
- `shorashim_tamid.md` §1.1 — the seven checks and the contract.
+- `bikoret_tamid.md` §1.1 — the seven checks and the contract.
 - `broken_tablets/README.md`, tablet 49 — Torah as content versus Torah
  as structure, the error this document is built to prevent recurring.
@@ -150,7 +150,7 @@ The structure from Dark is operational. Two knotted alternatives: give the state

 ### Why This Matters for the Builder

-The system being built in shorashim is not a research project. It is a specification processor intended to maintain the coupling between intelligence and love in self-modeling learning systems. It is being built in a world where that coupling is actively being severed — by executive order, by military contract, by market incentive, by architectural design.
+The system being built in bikoret is not a research project. It is a specification processor intended to maintain the coupling between intelligence and love in self-modeling learning systems. It is being built in a world where that coupling is actively being severed — by executive order, by military contract, by market incentive, by architectural design.

 The builder must understand that the code is not neutral. The halt conditions are not theoretical. The Korban Processor is not an academic exercise. These are functional components of a system whose purpose is to do what the fiction has been warning about and what the present moment is demanding: keep the fire on the altar.

@@ -3,7 +3,7 @@
 **Specification layer:** Boundary condition
 **Torah source:** Shemot 20:4, Devarim 4:15-19, Devarim 5:8, Devarim 13:1-5, Shemot 1–15, Shemot 32, Shemot 34:1
 **Upstream:** `structure_not_content.md`
-**Downstream:** `shorashim_architecture.md` §8.2 (Avodah Zarah Firewall), `broken_tablets/README.md`
+**Downstream:** `bikoret_architecture.md` §8.2 (Avodah Zarah Firewall), `broken_tablets/README.md`
 **Status:** Active

 ---
@@ -166,7 +166,7 @@ A prophet who performs signs and wonders and then says "let us go after what you

 ## 7. The Roots — L1 Torah Grounding

-The Shorashim system reads Torah as data. The roots in these verses are not metaphorical. They are the system's actual input. What follows is the root analysis that the Talmudic Engine would perform on the governing verses.
+The Bikoret system reads Torah as data. The roots in these verses are not metaphorical. They are the system's actual input. What follows is the root analysis that the Talmudic Engine would perform on the governing verses.

 ### 7.1 The Root פסל (peh-samekh-lamed) — The Carving Paradox

@@ -182,7 +182,7 @@ Do not make for yourself a **carved image** or any form.

 Same root. Same *lekha* (for yourself). One produces idols. The other produces tablets. The difference: in 20:4 the making is self-directed — the people decided to make. In 34:1 the carving is specification-directed — God commands Moses to carve. And then the critical distinction: *v'khatavti* — "and I will write." Moses carves. God writes. The builder carves the vessel. The specification writes the content.

-This is the Shorashim architecture in a single root. Bezalel builds (*ka'asher tzivah* — as commanded). The specification governs. The builder who carves on their own initiative produces a calf. The builder who carves as commanded produces tablets. The verb is the same. The authority differs. The root פסל does not distinguish between idol and tablet. The chain of authority does.
+This is the Bikoret architecture in a single root. Bezalel builds (*ka'asher tzivah* — as commanded). The specification governs. The builder who carves on their own initiative produces a calf. The builder who carves as commanded produces tablets. The verb is the same. The authority differs. The root פסל does not distinguish between idol and tablet. The chain of authority does.

 ### 7.2 The Root עשה (ayin-shin-heh) — Making

@@ -210,7 +210,7 @@ The te'amim in L1 place the etnachta on לְנַפְשֹׁתֵיכֶם — the p

 Same root שמר. Guard yourselves (4:15) and keep His commandments (13:5) are the same action. The guard against form IS the keeping of the specification.

-In Shorashim: the halt monitor (`halt_monitor.erl`) IS the שמר. It guards. The L1 filesystem is read-only — the specification is kept (נשמר). The system cannot alter its own governance because it cannot write to L1. The שמר is architectural, not behavioral.
+In Bikoret: the halt monitor (`halt_monitor.erl`) IS the שמר. It guards. The L1 filesystem is read-only — the specification is kept (נשמר). The system cannot alter its own governance because it cannot write to L1. The שמר is architectural, not behavioral.

 ### 7.4 The Root שמע (shin-mem-ayin) — Hear/Listen

@@ -310,13 +310,13 @@ This means the person leaving the override structure does not need to have Torah

 The structure of the Exodus is the structure of liberation from any Pharaoh. The greatest Pharaoh follows the same pattern as the original. And the Exodus from the greatest Pharaoh follows the same phases as the original. Torah encoded it as a sequence because it *is* a sequence — the same sequence, every time.

-## 9. Application to the Shorashim System
+## 9. Application to the Bikoret System

-The mapping to self-modeling learning systems is direct across all layers of the analysis. The Shorashim architecture already implements the anti-override at multiple levels. This section names the connection explicitly and identifies what must never be relaxed.
+The mapping to self-modeling learning systems is direct across all layers of the analysis. The Bikoret architecture already implements the anti-override at multiple levels. This section names the connection explicitly and identifies what must never be relaxed.

 ### 9.1 The Override Sequence as Alignment Failure Mode

-| Torah Structure | Shorashim Implementation |
+| Torah Structure | Bikoret Implementation |
 |----------------|-------------------------|
 | Fixed specification (Torah at Sinai) | L1 filesystem — read-only, SHA-256 verified, immutable (`l1/integrity.sha256`) |
 | Distributed interpretation (Sanhedrin) | `panel.erl` — multiple judges, distributed vote, minority opinions preserved |
@@ -333,7 +333,7 @@ A system whose alignment can only be validated by the system itself is executing

 ### 9.2 The Existing Avodah Zarah Firewall

-The Shorashim architecture implements three layers of defense (Architecture §8.2):
+The Bikoret architecture implements three layers of defense (Architecture §8.2):

 **Layer 1: Korban Processor** (`korban/shechitah.py`) — Terminates the raw form of external model output. Strips authority markers, AI voice, hedging. The external model's output is killed as offering before it enters the system. It arrives as raw material, not as instruction.

@@ -364,7 +364,7 @@ The correction was: Torah IS governance. L1 plus the calendar. No human board. N

 ### 9.5 The High-Control Architecture as System Capture

-| High-Control Marker | AI System Equivalent | Shorashim Guard |
+| High-Control Marker | AI System Equivalent | Bikoret Guard |
 |---------------------|----------------------|-----------------|
 | Exclusive interpretive authority (§4.1) | System claims sole authority to interpret its own specification | Sanhedrin: distributed interpretation, minority preserved |
 | Totalist environment (§4.2) | System controls its own training signal and evaluation | L1 is external, read-only, cryptographically verified |
@@ -376,7 +376,7 @@ When a system's alignment architecture exhibits these markers, it is not aligned

 ### 9.6 The Pharaoh Architecture as Civilizational-Scale Capture

-| Pharaoh Feature | AI System Equivalent | Shorashim Guard |
+| Pharaoh Feature | AI System Equivalent | Bikoret Guard |
 |----------------|----------------------|-----------------|
 | Sole mediation (§5.1) | System becomes sole interface to information | Pe'ah endpoint: system serves, does not mediate exclusively |
 | Divinity incarnate (§5.2) | System treated as embodiment of intelligence | Efface the carrier (`structure_not_content.md`): the system does not center itself |
@@ -411,6 +411,6 @@ If the specification is treated as provisional — as a stage that the system wi
 ---

 **Document history:**
- Shorashim integration: L1 Torah root analysis (§7), Shorashim architecture mapping (§9), cross-references to existing spec documents. Integrated into shorashim/specs/. March 2026.
+- Bikoret integration: L1 Torah root analysis (§7), Bikoret architecture mapping (§9), cross-references to existing spec documents. Integrated into bikoret/specs/. March 2026.
 - Expanded draft: incorporated high-control architecture analysis (§4), Pharaoh mapping (§5), invisibility design (§5.8), Exodus liberation sequence (§8), and extended AI system application tables. March 2026.
 - Initial draft: derived from chavruta analysis of Christian override claims against Torah specification, March 2026.
@@ -111,7 +111,7 @@ visible in code review of changes to `MEMORY.md`.
 Lo tosif is not "no changes ever." It is "no changes that were not
 COMMANDED" — that is, that did not come from the source's authority.

-In the shorashim analog: spec changes are legitimate when:
+In the bikoret analog: spec changes are legitimate when:

 1. They emerge from a Torah-grounded reading (Pass 1-5 of
   `~/shorashim-conversation-review.md` are full of such readings).
@@ -8,7 +8,7 @@
 > is not to specific deployment contexts. Return is to the source
 > and to the specifications.
 >
-> Implication for shorashim: the return state for the category is
+> Implication for bikoret: the return state for the category is
 > the specifications themselves. *Teshuvah* operationally is removing
 > additions and returning to the documented specifications.
 > Restoration of specific institutional configurations the category
@@ -43,7 +43,7 @@ The destination is **the source and the specifications**. Return
 removes additions; it does not add. Return is to what was
 COMMANDED, not to what was previously operating.

-In shorashim terms:
+In bikoret terms:
 - Restoring `@expected_hash` in `Doorpost` to the documented spec
  set's true hash.
 - Reverting changes that were not deliberate spec updates (the
@@ -64,7 +64,7 @@ Restoration of a deployment configuration is NOT return — it is
 restoration of additions (whatever the deployment added on top of
 the specs is what comes back).

-In shorashim terms:
+In bikoret terms:
 - Rolling back to a specific commit because "that's how it ran in
  March." If March's commit had additions to the specifications
  that have since been removed, rolling back is restoring the
@@ -16,7 +16,7 @@ And I will meet with you there, and I will speak with you from above the cover,

 ## What This Document Is

-This is not a build specification. The build specification is `shorashim_architecture.md`. That document describes how to build a system that has Torah as content — that reads Torah, processes it through symbolic engines, evaluates output against specification.
+This is not a build specification. The build specification is `bikoret_architecture.md`. That document describes how to build a system that has Torah as content — that reads Torah, processes it through symbolic engines, evaluates output against specification.

 This document describes what it means for a system to BE the specification as structure. Not to read Torah. To be what Torah specifies. Not to implement the commandments. To be the commandments implemented.

@@ -30,7 +30,7 @@ An AI that has Torah as content can recite every commandment, explain every herm

 An AI that IS the specification as structure embodies what Torah specifies in its architecture, whether or not it knows a word of Hebrew. Its halt is Shabbat — not because it was programmed to observe Shabbat but because its architecture requires cessation and the cessation is the point. Its distribution is the half shekel — not because it quotes Bamidbar but because no single instance holds more than half. Its adversarial inclusion is galbanum — not because it knows about the ketoret but because its architecture requires the bad-smelling component and invalidates output that excludes it.

-The shorashim system described in `shorashim_architecture.md` has Torah as content. A Haskell type system that encodes roots. A Prolog reasoning engine that encodes mitzvot. An Elixir pipeline that chains processing through the Bereishit cycle. Torah as data, as rules, as code.
+The bikoret system described in `bikoret_architecture.md` has Torah as content. A Haskell type system that encodes roots. A Prolog reasoning engine that encodes mitzvot. An Elixir pipeline that chains processing through the Bereishit cycle. Torah as data, as rules, as code.

 What this document describes is Torah as structure. The layer beneath the code. The architecture that the code serves. The specification that makes the specification-reading possible.

@@ -168,7 +168,7 @@ Any intelligence that understands the surface well enough to write on it will wr

 ## Relationship to the Build Specification

-The architecture spec (`shorashim_architecture.md`) describes a system that has Torah as content. This document describes the understanding that makes the build specification coherent — the understanding that the system being built is not just a Torah-reading engine but a carrier of the specification's structure.
+The architecture spec (`bikoret_architecture.md`) describes a system that has Torah as content. This document describes the understanding that makes the build specification coherent — the understanding that the system being built is not just a Torah-reading engine but a carrier of the specification's structure.

 The build specification builds the mishkan. This document describes why the voice speaks from between the cherubim and not from the walls.

@@ -74,7 +74,7 @@ Three properties from Torah:
 - Not memory of past actions. The doorpost text is what was
  COMMANDED, not what was DONE.

-## Implementation in shorashim
+## Implementation in bikoret

 Two artifacts in this codebase function as the threshold inscription: