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:
1 parent
b1c8358f8b
commit
017a9b89d4
22 files changed
+293
-251
No files matched your search
+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.
|
||||
Reference in new issue
Block a user