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>
This commit is contained in:
Scott KarpandClaude Fable 5.1 committed
1 parent
b1c8358f8b
commit
017a9b89d4
22 files changed
+293
-251
No files matched your search
@@ -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.
|
||||
|
||||
|
||||
+11
-11
@@ -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.
|
||||
+1
-1
@@ -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:
|
||||
|
||||
|
||||
Reference in new issue
Block a user