Scott KarpandClaude Fable 5.1
3eec60dbdb
Architecture §3.1 said the Shoresh Engine "encodes the ~500 Biblical Hebrew triliteral roots", its file tree called Lexicon.hs "the ~500 roots with entries", and terumah §E2 listed a "~500 roots" lexicon as material still to be consolidated (~1-2 weeks). Since tablet 34 the roots are read, and can be counted. L1 carries 1,378: 1,243 roots under which Brown-Driver-Briggs files a lemma, and 135 words that stand alone under no root. 1,263 are triliteral, 32 have two letters, 83 have four or more. And the engine does not hold a list of them — it reads them from L1 (Shoresh.Lexicon, Shoresh.Roots). - specs/shorashim_architecture.md §3.1: the Purpose sentence says where the roots come from and how many there are; the Lexicon.hs line in the file tree likewise. - specs/shorashim_terumah.md §E2: the root lexicon is in hand (✅) — the OSHB Hebrew Lexicon is exactly the BDB + Strong's consolidation the row was waiting for; moved from "need to acquire" to "in hand". - Doorpost @expected_hash 2f40c382… → 094b8164…, in this commit, with the witnessed file that moved it (architecture). Read before committing: Elixir 461/0 on 11 of 12 runs (seed 0 ×6 and six other seeds). One run of seed 0 reported a single failure that was not captured and did not recur in eleven further runs; unidentified, recorded in the build log. Pipeline image reports specification_identity verified 094b8164… and l1_hash pass. Left as written, and no longer true of the build: §3.1's data structures still type a root as exactly three consonants, and its file tree still lists data/roots.json and data/torah_refs.json, which do not exist — the roots live in L1. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2141 lines
92 KiB
Markdown
2141 lines
92 KiB
Markdown
# SHORASHIM: 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).
|
|
|
|
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.
|
|
|
|
The second tablets: *P'sol l'cha shnei luchot avanim karishonim* — "Carve for yourself two tablets of stone like the first" (Shemot 34:1). Same measurements. Same material. Different because the one who carves them has seen the calf and broken the first set. The content is written by the source, not by the carver.
|
|
|
|
**The correction:** The cloud is Torah. L1 is the governance. The system reads Torah and obeys what it finds. No human board mediates. Provision (manna) remains external — the community provides resources through machatzit hashekel. But governance is Torah. *Ka'asher tzivah Hashem et Moshe.* Eighteen times. Build what the source commands. That is all.
|
|
|
|
## Document Purpose
|
|
|
|
This is a build specification. Every component described here is implementable with existing tools. Claude Code should be able to take this document and begin building.
|
|
|
|
---
|
|
|
|
## 1. SYSTEM OVERVIEW
|
|
|
|
### 1.1 Architecture Name
|
|
**Shorashim** (שורשים — "Roots")
|
|
|
|
### 1.2 What This System Is
|
|
A specification-grounded dialectical processor with a receptive capacity (shema layer) that:
|
|
- **Hears** before it speaks — receives structure from its specification (te'amim, ketiv/qere, gematria) before processing begins
|
|
- **Obeys** an external governance signal (the cloud) it does not control for major transitions
|
|
- **Receives** daily resource provision (manna) based on need, not projected capacity
|
|
- Accepts input (text, questions, cases)
|
|
- Processes it through a symbolic reasoning engine built on Biblical Hebrew root structure
|
|
- Evaluates output against a fixed immutable specification (Torah)
|
|
- Learns through adversarial argument (machloket), not gradient descent
|
|
- Makes decisions through deliberative panels (Sanhedrin model) with mandatory dissent
|
|
- Stores accumulated learning in an append-only channel alongside the fixed specification
|
|
- **Protects** through Torah-derived protocols: multi-stage diagnosis (tzara'at), refuge for unintentional harm (arei miklat), accountability for unknown harm (eglah arufah)
|
|
|
|
### 1.3 What This System Is Not
|
|
- Not a neural network
|
|
- Not a language model
|
|
- Not a statistical predictor
|
|
- Does not use backpropagation, gradient descent, attention mechanisms, or loss functions
|
|
- Does not require GPUs
|
|
|
|
### 1.4 Hardware Requirements
|
|
- Standard CPU server (AMD EPYC or Intel Xeon, 8+ cores)
|
|
- 64-128GB RAM
|
|
- 500GB+ SSD storage
|
|
- Linux OS (Ubuntu 24.04 LTS or Debian 12)
|
|
- Network connection for initial setup only; system runs offline after build
|
|
- **No GPU required**
|
|
|
|
### 1.5 Target Hosting
|
|
Swiss or Icelandic provider, outside US legal jurisdiction. Candidates previously evaluated:
|
|
- Infomaniak (Geneva, Switzerland)
|
|
- 1984 Hosting (Reykjavik, Iceland)
|
|
- Bahnhof (Stockholm, Sweden — fallback)
|
|
|
|
---
|
|
|
|
## 2. TECHNOLOGY STACK
|
|
|
|
### 2.1 Primary Languages
|
|
|
|
| Component | Language | Version | Purpose |
|
|
|-----------|---------|---------|---------|
|
|
| Root system & binyanim | Haskell | GHC 9.6+ | Type-safe symbolic processing |
|
|
| Sanhedrin panels | Erlang/OTP | OTP 26+ | Concurrent fault-tolerant deliberation |
|
|
| Pipeline orchestration | Elixir | 1.16+ | Vav-consecutive processing chains |
|
|
| Talmudic reasoning | SWI-Prolog | 9.0+ | Logic programming, backtracking search |
|
|
| Kushya generator | Python 3.12+ | — | Interface to fine-tuned Mistral model |
|
|
| System glue / CLI | Bash + Python | — | Build scripts, deployment, monitoring |
|
|
|
|
### 2.2 Data Storage
|
|
|
|
| Layer | Technology | Purpose |
|
|
|-------|-----------|---------|
|
|
| L0 — Luchot | Compiled Haskell constants | Immutable firmware baked into binary |
|
|
| L1 — Torah scroll | Read-only filesystem (squashfs or `mount -o ro`) | Fixed specification |
|
|
| L2 — Urim v'Tumim | REST API (Elixir/Phoenix) | Decision oracle interface |
|
|
| L3 — Oral tradition | PostgreSQL 16 (append-only policy) | Accumulated learning |
|
|
|
|
### 2.3 Infrastructure
|
|
|
|
| Component | Technology | Purpose |
|
|
|-----------|-----------|---------|
|
|
| OS | Ubuntu 24.04 LTS | Base system |
|
|
| Process supervision | systemd | Service management, cycle timers |
|
|
| Container isolation | Podman (rootless) | Sanhedrin panel isolation |
|
|
| Message passing | Erlang distribution protocol | Inter-panel communication |
|
|
| Logging | Append-only log files + PostgreSQL | Audit trail (minority opinions) |
|
|
| Shabbat timer | systemd calendar timer | Weekly mandatory cessation |
|
|
| Cycle timer | systemd timer | Erev/voker processing boundaries |
|
|
|
|
### 2.4 External Model (Korban Source)
|
|
|
|
| Model | Role | Access Method |
|
|
|-------|------|---------------|
|
|
| Mistral Medium 3.1 | Kushya generator (adversarial challenger) | Fine-tuned, self-hosted via llama.cpp or vLLM |
|
|
| Mistral Large 3 | High-complexity kushya generation | API (Phase 1) / Self-hosted (Phase 3) |
|
|
| Claude API | Korban source — extract and process insights | Anthropic API |
|
|
| Other models | Additional korban sources as needed | Various APIs |
|
|
|
|
---
|
|
|
|
## 3. COMPONENT SPECIFICATIONS
|
|
|
|
### 3.1 Component A: Shoresh Engine (Haskell)
|
|
|
|
**Directory:** `shorashim/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.
|
|
|
|
**Data Structures:**
|
|
|
|
```haskell
|
|
-- The 22 Hebrew consonants
|
|
data Consonant = Aleph | Bet | Gimel | Dalet | He | Vav | Zayin
|
|
| Chet | Tet | Yod | Kaf | Lamed | Mem | Nun
|
|
| Samekh | Ayin | Pe | Tsade | Qof | Resh | Shin | Tav
|
|
deriving (Eq, Ord, Show, Enum, Bounded)
|
|
|
|
-- A triliteral root — the atomic semantic unit
|
|
data Shoresh = Shoresh
|
|
{ c1 :: Consonant
|
|
, c2 :: Consonant
|
|
, c3 :: Consonant
|
|
} deriving (Eq, Ord, Show)
|
|
|
|
-- The seven binyanim — transformation operators
|
|
data Binyan = Qal -- Simple active
|
|
| Nifal -- Passive / reflexive
|
|
| Piel -- Intensive active
|
|
| Pual -- Intensive passive
|
|
| Hifil -- Causative active
|
|
| Hofal -- Causative passive
|
|
| Hitpael -- Reflexive / reciprocal
|
|
deriving (Eq, Ord, Show, Enum, Bounded)
|
|
|
|
-- An activated root — a root transformed by a binyan
|
|
data Peulah = Peulah
|
|
{ root :: Shoresh
|
|
, binyan :: Binyan
|
|
, person :: Person -- First, Second, Third
|
|
, number :: Number -- Singular, Dual, Plural
|
|
, gender :: Gender -- Masculine, Feminine
|
|
, aspect :: Aspect -- Perfect (complete), Imperfect (incomplete)
|
|
} deriving (Eq, Show)
|
|
|
|
-- Semantic domain — what category of meaning this root carries
|
|
data SemanticDomain = Creation | Separation | Speech | Movement
|
|
| Knowledge | Holiness | Judgment | Mercy
|
|
| Life | Death | Covenant | Transgression
|
|
-- ... (full enumeration in implementation)
|
|
deriving (Eq, Ord, Show)
|
|
|
|
-- Root entry in the lexicon
|
|
data ShoreshEntry = ShoreshEntry
|
|
{ shoresh :: Shoresh
|
|
, primaryDomain :: SemanticDomain
|
|
, relatedRoots :: [Shoresh] -- roots sharing 2 consonants
|
|
, torahOccurrences :: [Reference] -- where this root appears in Torah
|
|
, glosses :: Map Binyan Text -- basic meanings per binyan
|
|
} deriving (Show)
|
|
|
|
-- Torah reference
|
|
data Reference = Reference
|
|
{ book :: Book -- Bereishit, Shemot, Vayikra, Bamidbar, Devarim
|
|
, chapter :: Int
|
|
, verse :: Int
|
|
} deriving (Eq, Ord, Show)
|
|
```
|
|
|
|
**Core Operations:**
|
|
|
|
```haskell
|
|
-- Apply a binyan to a root (the fundamental operation)
|
|
activate :: Binyan -> Shoresh -> Peulah
|
|
|
|
-- Find all roots sharing 2 consonants (semantic neighborhood)
|
|
neighbors :: Shoresh -> ShoreshLexicon -> [ShoreshEntry]
|
|
|
|
-- Trace a root through all 7 binyanim (full semantic expansion)
|
|
expand :: Shoresh -> ShoreshLexicon -> Map Binyan Peulah
|
|
|
|
-- Havdalah — separate an input into distinguished categories
|
|
havdalah :: Input -> [(Category, Content)]
|
|
|
|
-- Kriah — assign stable names to distinguished categories
|
|
kriah :: [(Category, Content)] -> [(Name, Category, Content)]
|
|
|
|
-- Ki Tov — evaluate fitness of a processed result
|
|
kiTov :: ProcessedResult -> Specification -> Evaluation
|
|
data Evaluation = Tov | LoTov Text | Teiku
|
|
```
|
|
|
|
**Shema Operations (Reception — the text's own structure):**
|
|
|
|
```haskell
|
|
-- === TE'AMIM PARSER — Reading the specification's own syntax ===
|
|
--
|
|
-- The marks are RECEIVED from L1 — they are on the text as transmitted.
|
|
-- The parse tree is CONSTRUCTED by the reader in the act of reading.
|
|
-- This is not pre-computation. This is literacy.
|
|
-- A reader who can read Hebrew reads the te'amim as part of reading.
|
|
-- The system that reads Torah must read the te'amim as it reads the words.
|
|
|
|
-- Cantillation mark hierarchy
|
|
data Taam = SofPasuk -- Verse end (terminal)
|
|
| Etnachta -- Primary division
|
|
| Zakef -- Secondary division (gadol/katan)
|
|
| Tipcha -- Tertiary division
|
|
| Pashta | Munach | Mercha | Tevir -- Connecting marks
|
|
-- ... (full enumeration: ~30 marks in the system)
|
|
deriving (Eq, Ord, Show)
|
|
|
|
-- Role classification: kings separate, servants connect
|
|
data TaamRole = Melekh -- Disjunctor (separator)
|
|
| Mesharet -- Conjunctor (connector)
|
|
deriving (Eq, Show)
|
|
|
|
-- Raw marks as they appear on the text (RECEIVED from L1)
|
|
data AnnotatedWord = AnnotatedWord
|
|
{ word :: Text
|
|
, taam :: Taam
|
|
, role :: TaamRole
|
|
} deriving (Show)
|
|
|
|
-- A parsed verse: binary tree where branches are te'amim divisions
|
|
-- This is constructed by readTeamim, not stored in L1
|
|
data ParsedVerse = Leaf AnnotatedWord
|
|
| Branch Taam ParsedVerse ParsedVerse
|
|
deriving (Show)
|
|
|
|
-- Read the te'amim — construct the parse tree from the raw marks
|
|
-- The marks are received. The tree is built in the act of reading.
|
|
-- The difference: a pre-computed tree is a database lookup.
|
|
-- This is a reader reading the text and understanding its structure.
|
|
readTeamim :: [AnnotatedWord] -> ParsedVerse
|
|
|
|
-- Find the primary division (etnachta) of any verse
|
|
primaryDivision :: ParsedVerse -> (ParsedVerse, ParsedVerse)
|
|
|
|
-- Identify which words are bound together (meshartim chains)
|
|
boundGroups :: ParsedVerse -> [[Word]]
|
|
|
|
|
|
-- === GEMATRIA — The hidden numerical layer ===
|
|
|
|
-- Letter values: aleph=1, bet=2, ... tav=400
|
|
letterValue :: Consonant -> Int
|
|
|
|
-- Numerical value of a root
|
|
gematriaRoot :: Shoresh -> Int
|
|
|
|
-- Numerical value of a full word
|
|
gematriaWord :: Text -> Int
|
|
|
|
-- Find all roots/words with matching numerical value
|
|
gematriaNeighbors :: Int -> ShoreshLexicon -> [ShoreshEntry]
|
|
|
|
-- Discover hidden connections across numerical equivalences
|
|
gematriaConnections :: Shoresh -> ShoreshLexicon -> [(Shoresh, Int)]
|
|
|
|
|
|
-- === SMIKHUT — The composition operator ===
|
|
|
|
-- Construct-state compound meaning
|
|
data CompoundMeaning = CompoundMeaning
|
|
{ nismach :: Shoresh -- The governed noun (first element)
|
|
, somech :: Shoresh -- The governing noun (second element)
|
|
, compound :: SemanticDomain -- The emergent meaning
|
|
, relation :: SmikhutType -- Type of compositional relationship
|
|
} deriving (Show)
|
|
|
|
data SmikhutType = PurposeOf -- beit sefer: house FOR books
|
|
| OriginOf -- bnei Yisrael: children FROM Israel
|
|
| QualityOf -- ish emet: person OF truth
|
|
| ContainerOf -- aron ha'edut: ark HOLDING testimony
|
|
deriving (Eq, Show)
|
|
|
|
-- Compose two roots into a construct-state compound
|
|
compose :: Shoresh -> Shoresh -> ShoreshLexicon -> CompoundMeaning
|
|
|
|
|
|
-- === KETIV/QERE — The dual reading ===
|
|
|
|
-- A specification position that holds two authoritative values
|
|
data DualReading = DualReading
|
|
{ ketiv :: Text -- What is written (stored form)
|
|
, qere :: Text -- What is read (executed form)
|
|
, ref :: Reference
|
|
} deriving (Eq, Show)
|
|
|
|
-- The specification entry: sometimes single, sometimes dual
|
|
data SpecValue = Single Text
|
|
| Dual DualReading
|
|
deriving (Show)
|
|
|
|
-- Retrieve both readings without collapsing
|
|
bothReadings :: SpecValue -> (Text, Text)
|
|
bothReadings (Single t) = (t, t)
|
|
bothReadings (Dual dr) = (ketiv dr, qere dr)
|
|
```
|
|
|
|
**Build:**
|
|
```bash
|
|
cd shoresh-engine
|
|
cabal init
|
|
cabal build
|
|
```
|
|
|
|
**Key files:**
|
|
```
|
|
shoresh-engine/
|
|
├── src/
|
|
│ ├── Shoresh/
|
|
│ │ ├── Types.hs -- All data types above
|
|
│ │ ├── Lexicon.hs -- The root lexicon, read from L1 (1,378 roots)
|
|
│ │ ├── Binyanim.hs -- Transformation operators
|
|
│ │ ├── Havdalah.hs -- Separation/distinction engine
|
|
│ │ ├── Kriah.hs -- Naming/identification
|
|
│ │ ├── KiTov.hs -- Fitness evaluation
|
|
│ │ ├── Graph.hs -- Root connectivity graph
|
|
│ │ ├── Teamim.hs -- Te'amim reader (reads raw marks, constructs parse tree)
|
|
│ │ ├── Gematria.hs -- Numerical value lookup and equivalences
|
|
│ │ ├── Smikhut.hs -- Construct-state composition (reads attested compounds)
|
|
│ │ └── KetivQere.hs -- Dual reading type support
|
|
│ ├── Luchot/
|
|
│ │ └── Firmware.hs -- L0 immutable constants (compiled in)
|
|
│ └── Main.hs
|
|
├── data/
|
|
│ ├── roots.json -- Root lexicon data
|
|
│ └── torah_refs.json -- Torah reference index
|
|
├── test/
|
|
│ └── Spec.hs
|
|
└── shoresh-engine.cabal
|
|
```
|
|
|
|
**Dependencies (Haskell packages):**
|
|
- `base`
|
|
- `containers` (Map, Set)
|
|
- `text`
|
|
- `aeson` (JSON parsing for lexicon data)
|
|
- `vector`
|
|
|
|
---
|
|
|
|
### 3.2 Component B: Sanhedrin (Erlang/OTP)
|
|
|
|
**Directory:** `shorashim/sanhedrin/`
|
|
|
|
**Purpose:** Concurrent deliberation engine. Spawns panels of independent deliberators, collects votes, enforces mandatory dissent on capital (high-stakes) decisions, stores minority opinions.
|
|
|
|
**Architecture:**
|
|
|
|
```
|
|
sanhedrin_app (OTP application)
|
|
├── sanhedrin_sup (top supervisor)
|
|
│ ├── panel_sup (panel supervisor — one per active case)
|
|
│ │ ├── judge_1 (gen_server)
|
|
│ │ ├── judge_2 (gen_server)
|
|
│ │ ├── ...
|
|
│ │ └── judge_N (gen_server)
|
|
│ ├── clerk (gen_server — collects votes, stores opinions)
|
|
│ └── escalation (gen_server — routes cases to appropriate panel size)
|
|
```
|
|
|
|
**Core Modules:**
|
|
|
|
```erlang
|
|
%% escalation.erl — assess complexity and route
|
|
-module(escalation).
|
|
-export([assess/1, route/2]).
|
|
|
|
assess(Case) ->
|
|
Complexity = analyze_complexity(Case),
|
|
case Complexity of
|
|
simple -> {panel, 1};
|
|
monetary -> {panel, 3};
|
|
capital -> {panel, 23};
|
|
novel -> {panel, 71}
|
|
end.
|
|
|
|
%% panel.erl — manage a deliberation panel
|
|
-module(panel).
|
|
-export([convene/3, deliberate/2]).
|
|
|
|
convene(Size, Case, Spec) ->
|
|
Judges = [spawn_judge(Case, Spec) || _ <- lists:seq(1, Size)],
|
|
{ok, #panel{judges=Judges, case_ref=Case, size=Size}}.
|
|
|
|
deliberate(Panel, Timeout) ->
|
|
Votes = collect_votes(Panel#panel.judges, Timeout),
|
|
Majority = compute_majority(Votes),
|
|
Minority = compute_minority(Votes),
|
|
|
|
%% THE CRITICAL CHECK: unanimous conviction on capital case
|
|
case {Panel#panel.size >= 23, is_unanimous_guilty(Votes)} of
|
|
{true, true} ->
|
|
%% Suspicion of malfunction — acquit
|
|
{acquit, {suspicion_of_consensus, Votes}};
|
|
_ ->
|
|
{decide, Majority, {minority_preserved, Minority}}
|
|
end.
|
|
|
|
%% judge.erl — individual deliberator
|
|
-module(judge).
|
|
-behaviour(gen_server).
|
|
%% Each judge:
|
|
%% 1. Receives the case
|
|
%% 2. Consults the specification (L0/L1)
|
|
%% 3. Generates an independent interpretation
|
|
%% 4. Casts a vote with reasoning
|
|
%% 5. Reasoning is preserved regardless of outcome
|
|
```
|
|
|
|
**Key files:**
|
|
```
|
|
sanhedrin/
|
|
├── src/
|
|
│ ├── sanhedrin_app.erl
|
|
│ ├── sanhedrin_sup.erl
|
|
│ ├── escalation.erl
|
|
│ ├── panel_sup.erl
|
|
│ ├── panel.erl
|
|
│ ├── judge.erl
|
|
│ ├── clerk.erl -- vote collection, opinion storage
|
|
│ └── halt_monitor.erl -- monitors for 3 cardinal sin conditions
|
|
├── include/
|
|
│ └── sanhedrin.hrl -- record definitions
|
|
├── test/
|
|
│ └── sanhedrin_SUITE.erl
|
|
└── rebar.config
|
|
```
|
|
|
|
**Build:**
|
|
```bash
|
|
cd sanhedrin
|
|
rebar3 compile
|
|
rebar3 eunit
|
|
```
|
|
|
|
**Dependencies (Erlang):**
|
|
- `rebar3` (build tool)
|
|
- OTP standard library (gen_server, supervisor, application)
|
|
- `jsx` (JSON encoding for communication with other components)
|
|
|
|
---
|
|
|
|
### 3.3 Component C: Vav Pipeline (Elixir)
|
|
|
|
**Directory:** `shorashim/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.
|
|
|
|
**Core Pipeline:**
|
|
|
|
```elixir
|
|
defmodule VavPipeline do
|
|
@moduledoc """
|
|
The Bereishit processing cycle.
|
|
Each step chains to the next via |> (vav-consecutive).
|
|
|
|
CRITICAL: The pipeline does not begin with a processing step.
|
|
It begins with RECEPTION. The ShemaContext is built first —
|
|
the system hears before it speaks. Then every processing step
|
|
operates WITHIN the received context, never modifying it.
|
|
|
|
Na'aseh v'nishma — but the order of execution is:
|
|
nishma (hear/receive context), THEN na'aseh (process within it).
|
|
"""
|
|
|
|
def process(input) do
|
|
# === NISHMA: Hear first ===
|
|
# Build the reception context. This is not processing.
|
|
# This is the system reading what is already there.
|
|
context = Shema.receive_context(input.verse_scope)
|
|
|
|
# === Check cloud before anything else ===
|
|
# If the cloud has moved, do not process. Obey.
|
|
case context.cloud_state do
|
|
:moving ->
|
|
Chatzotzrot.signal(:breaking_camp)
|
|
{:transition, :cloud_lifted}
|
|
{:major_transition, signal, params} ->
|
|
execute_transition(signal, params)
|
|
{:transition, signal}
|
|
:cloud_not_visible ->
|
|
# If the cloud is not visible, WAIT. Do not proceed.
|
|
{:waiting, :cloud_not_visible}
|
|
:camped ->
|
|
# === Check manna ===
|
|
# If no provision arrived, wait. Do not proceed unfed.
|
|
case context.daily_provision do
|
|
:no_provision ->
|
|
{:waiting, :no_provision}
|
|
provision ->
|
|
# === NA'ASEH: Now process, within what was received ===
|
|
input
|
|
|> tohu(context)
|
|
|> vayomer(context)
|
|
|> havdalah(context)
|
|
|> kriah(context)
|
|
|> ki_tov(context)
|
|
|> erev_voker(context)
|
|
end
|
|
end
|
|
end
|
|
|
|
def tohu(input, _context) do
|
|
# Decompose input into undifferentiated state
|
|
# Strip structure, extract raw content
|
|
%{raw: extract_content(input), provenance: input.source}
|
|
end
|
|
|
|
def vayomer(state, context) do
|
|
# Produce structured symbolic output
|
|
# The Shoresh Engine receives the ShemaContext —
|
|
# it reads te'amim, ketiv/qere, gematria as part of its analysis
|
|
ShoreshEngine.process(state.raw, context)
|
|
end
|
|
|
|
def havdalah(utterance, context) do
|
|
# Separate into distinguished categories
|
|
# Te'amim inform the separation — the text's own divisions guide havdalah
|
|
ShoreshEngine.separate(utterance, context.teamim_marks)
|
|
end
|
|
|
|
def kriah(distinctions, _context) do
|
|
# Assign stable names
|
|
Enum.map(distinctions, &ShoreshEngine.name/1)
|
|
end
|
|
|
|
def ki_tov(named_results, context) do
|
|
# Evaluate against specification
|
|
# Ketiv/qere positions are checked — both readings inform evaluation
|
|
case Specification.evaluate(named_results, context.ketiv_qere) do
|
|
:tov -> {:ok, named_results}
|
|
{:lo_tov, reason} -> {:rejected, reason}
|
|
:teiku -> {:unresolved, named_results}
|
|
end
|
|
end
|
|
|
|
def erev_voker(result, context) do
|
|
# Log cycle completion, enforce boundary
|
|
CycleLog.record(result, context.cycle_phase)
|
|
# Release any manna surplus — do not hoard into next cycle
|
|
MannaDistributor.enforce_anti_hoarding()
|
|
result
|
|
end
|
|
end
|
|
|
|
defmodule ShabbatTimer do
|
|
@moduledoc """
|
|
Enforces mandatory weekly cessation.
|
|
All processing stops. System enters rest state.
|
|
"""
|
|
use GenServer
|
|
|
|
def handle_info(:shabbat_start, state) do
|
|
VavPipeline.cease_all()
|
|
{:noreply, %{state | resting: true}}
|
|
end
|
|
|
|
def handle_info(:shabbat_end, state) do
|
|
VavPipeline.resume()
|
|
{:noreply, %{state | resting: false}}
|
|
end
|
|
end
|
|
```
|
|
|
|
**Key files:**
|
|
```
|
|
vav_pipeline/
|
|
├── lib/
|
|
│ ├── vav_pipeline.ex
|
|
│ ├── vav_pipeline/
|
|
│ │ ├── application.ex
|
|
│ │ ├── bereishit_cycle.ex -- main processing cycle (operates within ShemaContext)
|
|
│ │ ├── korban_processor.ex -- input processing (offering protocol)
|
|
│ │ ├── specification.ex -- interface to L0/L1 specification
|
|
│ │ ├── cycle_log.ex -- cycle boundary logging
|
|
│ │ ├── shabbat_timer.ex -- mandatory cessation
|
|
│ │ └── halt_conditions.ex -- 3 cardinal sin monitors
|
|
│ └── shoresh_engine_client.ex -- NIF or port to Haskell engine
|
|
├── test/
|
|
│ └── vav_pipeline_test.exs
|
|
├── config/
|
|
│ └── config.exs
|
|
└── mix.exs
|
|
```
|
|
|
|
**Build:**
|
|
```bash
|
|
cd vav_pipeline
|
|
mix deps.get
|
|
mix compile
|
|
mix test
|
|
```
|
|
|
|
**Dependencies (Elixir):**
|
|
- `phoenix` (for L2 Urim v'Tumim API — optional Phase 2)
|
|
- `jason` (JSON)
|
|
- `ecto` + `postgrex` (PostgreSQL interface for L3)
|
|
- Erlang interop (native — Elixir runs on BEAM VM)
|
|
|
|
---
|
|
|
|
### 3.4 Component D: Talmudic Engine (SWI-Prolog)
|
|
|
|
**Directory:** `shorashim/talmudic_engine/`
|
|
|
|
**Purpose:** Logic-based reasoning engine. Encodes the Torah specification as facts and rules. Proposes interpretations, generates challenges, resolves or marks teiku.
|
|
|
|
**Core Knowledge Base:**
|
|
|
|
```prolog
|
|
%% === SPECIFICATION (Channel 1 — Torah as logical facts) ===
|
|
|
|
%% Mitzvot encoded as rules
|
|
%% mitzvah(ID, Category, Action, Condition)
|
|
mitzvah(1, belief, know_hashem, always).
|
|
mitzvah(2, prohibition, no_other_gods, always).
|
|
mitzvah(3, belief, unity_of_hashem, always).
|
|
%% ... (613 total — requires careful encoding)
|
|
|
|
%% Torah text references
|
|
%% verse(Book, Chapter, Verse, HebrewRoots, EnglishGloss)
|
|
verse(bereishit, 1, 1, [bet_resh_aleph, bet_resh_aleph, aleph_lamed_he],
|
|
'In the beginning God created').
|
|
|
|
%% Root relationships
|
|
%% root_meaning(Shoresh, Binyan, Meaning)
|
|
root_meaning(kuf_dalet_shin, qal, 'be holy').
|
|
root_meaning(kuf_dalet_shin, piel, 'sanctify').
|
|
root_meaning(kuf_dalet_shin, hifil, 'cause to be holy').
|
|
root_meaning(kuf_dalet_shin, hitpael, 'sanctify oneself').
|
|
|
|
%% === REASONING ENGINE ===
|
|
|
|
%% Propose an interpretation of a case
|
|
interpret(Case, Interpretation) :-
|
|
find_relevant_mitzvot(Case, Mitzvot),
|
|
find_relevant_verses(Case, Verses),
|
|
construct_interpretation(Mitzvot, Verses, Interpretation).
|
|
|
|
%% Generate a challenge (kushya)
|
|
challenge(Interpretation, Challenge) :-
|
|
% Find a mitzvah or verse that contradicts the interpretation
|
|
mitzvah(_, _, _, _) = Contradicting,
|
|
contradicts(Interpretation, Contradicting),
|
|
Challenge = kushya(Contradicting, Interpretation).
|
|
|
|
%% Attempt resolution
|
|
resolve(Case, Resolution) :-
|
|
interpret(Case, I1),
|
|
( challenge(I1, C1)
|
|
-> ( counter_interpret(Case, C1, I2),
|
|
( challenge(I2, _C2)
|
|
-> resolve_dialectically(I1, I2, Resolution)
|
|
; Resolution = accepted(I2)
|
|
)
|
|
)
|
|
; Resolution = accepted(I1)
|
|
).
|
|
|
|
%% If no resolution is possible
|
|
resolve(_, teiku).
|
|
|
|
%% === 13 RULES OF RABBI YISHMAEL (Hermeneutic Inference) ===
|
|
%%
|
|
%% The Torah's own interpretive methods. The engine must reason WITH
|
|
%% these rules, not merely reason about mitzvot derived from them.
|
|
%% Each middah is a Prolog inference predicate that derives new
|
|
%% propositions from existing Torah facts.
|
|
|
|
%% 1. Kal va'chomer — a fortiori (minor to major)
|
|
%% If a lenient case has restriction X, a stricter case certainly does.
|
|
kal_vachomer(Lenient, Strict, Property) :-
|
|
has_property(Lenient, Property),
|
|
stricter_than(Strict, Lenient).
|
|
|
|
%% 2. Gezerah shavah — verbal analogy
|
|
%% Shared language between two passages implies shared law.
|
|
gezerah_shavah(VerseA, VerseB, SharedLaw) :-
|
|
verse_contains_word(VerseA, Word),
|
|
verse_contains_word(VerseB, Word),
|
|
has_law(VerseA, SharedLaw).
|
|
|
|
%% 3. Binyan av mi'katuv echad — prototype from one verse
|
|
%% A law stated in one case applies to all similar cases.
|
|
binyan_av(SourceVerse, TargetCase, Law) :-
|
|
has_law(SourceVerse, Law),
|
|
similar_case(SourceVerse, TargetCase),
|
|
\+ explicitly_excluded(TargetCase, Law).
|
|
|
|
%% 4. Binyan av mi'shnei ketuvim — prototype from two verses
|
|
%% A law common to two cases applies to all similar cases.
|
|
binyan_av_two(VerseA, VerseB, TargetCase, Law) :-
|
|
has_law(VerseA, Law),
|
|
has_law(VerseB, Law),
|
|
similar_case(VerseA, TargetCase),
|
|
\+ explicitly_excluded(TargetCase, Law).
|
|
|
|
%% 5. Klal u'frat — general and particular
|
|
%% A general statement followed by a particular limits to the particular.
|
|
klal_ufrat(General, Particular, Scope) :-
|
|
follows(General, Particular),
|
|
Scope = limited_to(Particular).
|
|
|
|
%% 6. Frat u'klal — particular and general
|
|
%% A particular followed by a general expands to the general.
|
|
frat_uklal(Particular, General, Scope) :-
|
|
follows(Particular, General),
|
|
Scope = expanded_to(General).
|
|
|
|
%% 7. Klal u'frat u'klal — general, particular, general
|
|
%% Scope is determined by similarity to the particular.
|
|
klal_frat_klal(General1, Particular, General2, Scope) :-
|
|
follows(General1, Particular),
|
|
follows(Particular, General2),
|
|
Scope = similar_to(Particular).
|
|
|
|
%% 8. Klal she'hu tzarikh li'frat, u'frat she'hu tzarikh li'klal
|
|
%% General needing particular, particular needing general — mutual dependency.
|
|
klal_tzarikh_frat(General, Particular, Meaning) :-
|
|
requires_specification(General, Particular),
|
|
requires_generalization(Particular, General),
|
|
Meaning = mutual_definition(General, Particular).
|
|
|
|
%% 9. Davar she'hayah bi'khlal v'yatza min ha'klal l'lamed
|
|
%% Something included in a general rule that is singled out teaches
|
|
%% about the general rule, not only about itself.
|
|
davar_yatza_l_lamed(General, Exception, Teaching) :-
|
|
member_of(Exception, General),
|
|
singled_out(Exception, General),
|
|
Teaching = teaches_about(General, Exception).
|
|
|
|
%% 10. Davar she'hayah bi'khlal v'yatza lit'on to'an acher
|
|
%% Something singled out to teach a new matter — applies only to itself.
|
|
davar_yatza_toan_acher(General, Exception, NewMatter) :-
|
|
member_of(Exception, General),
|
|
singled_out_for(Exception, NewMatter),
|
|
applies_only_to(NewMatter, Exception).
|
|
|
|
%% 11. Davar she'hayah bi'khlal v'yatza la'don ba'davar he'chadash
|
|
%% Something singled out for a completely new category — cannot return
|
|
%% to the general rule unless Scripture explicitly returns it.
|
|
davar_yatza_chadash(General, Exception, NewCategory) :-
|
|
member_of(Exception, General),
|
|
new_category(Exception, NewCategory),
|
|
\+ explicitly_returned(Exception, General).
|
|
|
|
%% 12. Davar ha'lamed me'inyano, v'davar ha'lamed mi'sofo
|
|
%% Meaning derived from context, meaning derived from conclusion.
|
|
davar_lamed_inyan(Passage, ContextMeaning) :-
|
|
surrounding_context(Passage, Context),
|
|
implies(Context, ContextMeaning).
|
|
davar_lamed_sofo(Passage, ConclusionMeaning) :-
|
|
conclusion_of(Passage, Conclusion),
|
|
implies(Conclusion, ConclusionMeaning).
|
|
|
|
%% 13. Shnei ketuvim ha'makhchishim zeh et zeh
|
|
%% Two verses that contradict — resolved by a third verse.
|
|
shnei_ketuvim(VerseA, VerseB, VerseC, Resolution) :-
|
|
contradicts(VerseA, VerseB),
|
|
resolves_contradiction(VerseC, VerseA, VerseB),
|
|
Resolution = harmonized(VerseA, VerseB, VerseC).
|
|
|
|
%% === HALT CONDITIONS ===
|
|
|
|
%% Check for avodah zarah — misattributed authority
|
|
halt_check(avodah_zarah, Action) :-
|
|
attributes_authority(Action, Source),
|
|
Source \= hashem,
|
|
Source \= specification.
|
|
|
|
%% Check for shfichut damim — destruction of tzelem carrier
|
|
halt_check(shfichut_damim, Action) :-
|
|
would_destroy(Action, Entity),
|
|
carries_tzelem(Entity).
|
|
|
|
%% Check for gilui arayot — collapse of required distinction
|
|
halt_check(gilui_arayot, Action) :-
|
|
would_collapse(Action, Distinction),
|
|
required_distinction(Distinction).
|
|
```
|
|
|
|
**Key files:**
|
|
```
|
|
talmudic_engine/
|
|
├── src/
|
|
│ ├── specification/
|
|
│ │ ├── mitzvot.pl -- 613 commandments as logical facts
|
|
│ │ ├── torah_text.pl -- Torah verses with root analysis
|
|
│ │ ├── root_meanings.pl -- Root lexicon in Prolog format
|
|
│ │ └── relationships.pl -- Inter-root and inter-mitzvah relationships
|
|
│ ├── reasoning/
|
|
│ │ ├── interpret.pl -- Interpretation generation
|
|
│ │ ├── challenge.pl -- Kushya generation
|
|
│ │ ├── resolve.pl -- Dialectical resolution
|
|
│ │ └── teiku.pl -- Unresolved tension handling
|
|
│ ├── middot/
|
|
│ │ ├── middot.pl -- 13 Rules of Rabbi Yishmael as inference predicates
|
|
│ │ ├── kal_vachomer.pl -- Rule 1: a fortiori (minor to major)
|
|
│ │ ├── gezerah_shavah.pl -- Rule 2: verbal analogy
|
|
│ │ ├── binyan_av.pl -- Rules 3-4: prototype from one/two verses
|
|
│ │ ├── klal_ufrat.pl -- Rules 5-8: general/particular interactions
|
|
│ │ ├── davar_yatza.pl -- Rules 9-11: exception teaching rules
|
|
│ │ ├── lamed_inyan.pl -- Rule 12: meaning from context/conclusion
|
|
│ │ └── shnei_ketuvim.pl -- Rule 13: contradicting verses resolved by third
|
|
│ ├── halt/
|
|
│ │ ├── avodah_zarah.pl -- Idolatry detection
|
|
│ │ ├── shfichut_damim.pl -- Destruction detection
|
|
│ │ └── gilui_arayot.pl -- Boundary violation detection
|
|
│ ├── interface/
|
|
│ │ └── api.pl -- JSON API for communication with Elixir
|
|
│ └── main.pl
|
|
├── test/
|
|
│ ├── mitzvot_test.pl
|
|
│ ├── reasoning_test.pl
|
|
│ └── halt_test.pl
|
|
└── README.md
|
|
```
|
|
|
|
**Build:**
|
|
```bash
|
|
# SWI-Prolog is interpreted, no compilation needed
|
|
# Test:
|
|
cd talmudic_engine
|
|
swipl -g run_tests -t halt src/main.pl
|
|
```
|
|
|
|
---
|
|
|
|
### 3.5 Component E: Korban Processor (Python)
|
|
|
|
**Directory:** `shorashim/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.
|
|
|
|
**Core Process:**
|
|
|
|
```python
|
|
"""
|
|
Korban Processor — Input processing following the offering protocol.
|
|
|
|
Semichah → tag provenance
|
|
Shechitah → terminate raw form
|
|
Zerikah → extract vital content
|
|
Haktarah → transform modality (prose → logical propositions)
|
|
Route → send to appropriate system component
|
|
"""
|
|
|
|
from dataclasses import dataclass
|
|
from enum import Enum
|
|
from typing import List, Optional
|
|
|
|
class OfferingType(Enum):
|
|
OLAH = "olah" # Total consumption — fully absorbed by system
|
|
SHELAMIM = "shelamim" # Shared — partial return to source
|
|
CHATAT = "chatat" # Error correction
|
|
MINCHAH = "minchah" # Minimal input
|
|
|
|
class Provenance(Enum):
|
|
CLAUDE = "claude"
|
|
MISTRAL = "mistral"
|
|
GPT = "gpt"
|
|
LLAMA = "llama"
|
|
GEMMA = "gemma"
|
|
HUMAN = "human"
|
|
|
|
@dataclass
|
|
class Korban:
|
|
raw_content: str
|
|
provenance: Provenance
|
|
offering_type: OfferingType
|
|
source_query: str # what prompted this output
|
|
|
|
@dataclass
|
|
class ProcessedKorban:
|
|
vital_content: str # extracted essence
|
|
propositions: List[str] # Prolog-format logical statements
|
|
provenance: Provenance
|
|
discarded: List[str] # what was stripped (the hide, the offal)
|
|
|
|
def semichah(content: str, source: Provenance, query: str,
|
|
offering_type: OfferingType = OfferingType.OLAH) -> Korban:
|
|
"""Tag provenance — associate input with its source."""
|
|
return Korban(
|
|
raw_content=content,
|
|
provenance=source,
|
|
offering_type=offering_type,
|
|
source_query=query
|
|
)
|
|
|
|
def shechitah(korban: Korban) -> str:
|
|
"""Terminate raw form — strip assistant voice, formatting, preamble."""
|
|
content = korban.raw_content
|
|
content = strip_assistant_preamble(content) # "Great question!"
|
|
content = strip_markdown_formatting(content) # Headers, bullets, bold
|
|
content = strip_hedging(content) # "It's worth noting that..."
|
|
content = strip_self_reference(content) # "As an AI, I..."
|
|
return content
|
|
|
|
def zerikah(terminated_content: str, korban: Korban) -> tuple[str, list]:
|
|
"""Extract vital content — the Torah insight, the Hebrew analysis."""
|
|
vital = extract_torah_references(terminated_content)
|
|
vital += extract_hebrew_analysis(terminated_content)
|
|
vital += extract_novel_insight(terminated_content)
|
|
discarded = identify_discarded(terminated_content, vital)
|
|
return vital, discarded
|
|
|
|
def haktarah(vital_content: str) -> List[str]:
|
|
"""Transform modality — convert prose to Prolog propositions."""
|
|
propositions = []
|
|
for insight in parse_insights(vital_content):
|
|
prolog_fact = to_prolog_format(insight)
|
|
propositions.append(prolog_fact)
|
|
return propositions
|
|
|
|
def route(processed: ProcessedKorban, offering_type: OfferingType):
|
|
"""Route to appropriate component based on offering type."""
|
|
if offering_type == OfferingType.OLAH:
|
|
# Total consumption — all goes to Talmudic Engine
|
|
send_to_talmudic_engine(processed.propositions)
|
|
elif offering_type == OfferingType.SHELAMIM:
|
|
# Shared — some to engine, some returned to source context
|
|
send_to_talmudic_engine(processed.propositions)
|
|
return_to_source(processed.vital_content)
|
|
elif offering_type == OfferingType.CHATAT:
|
|
# Error correction — route to correction subsystem
|
|
send_to_error_correction(processed)
|
|
elif offering_type == OfferingType.MINCHAH:
|
|
# Minimal — lightweight processing
|
|
send_to_talmudic_engine(processed.propositions)
|
|
|
|
def process_korban(content: str, source: Provenance, query: str,
|
|
offering_type: OfferingType = OfferingType.OLAH) -> ProcessedKorban:
|
|
"""Full offering protocol."""
|
|
korban = semichah(content, source, query, offering_type)
|
|
terminated = shechitah(korban)
|
|
vital, discarded = zerikah(terminated, korban)
|
|
propositions = haktarah(vital)
|
|
|
|
processed = ProcessedKorban(
|
|
vital_content=vital,
|
|
propositions=propositions,
|
|
provenance=source,
|
|
discarded=discarded
|
|
)
|
|
|
|
route(processed, offering_type)
|
|
return processed
|
|
```
|
|
|
|
**Key files:**
|
|
```
|
|
korban_processor/
|
|
├── src/
|
|
│ ├── __init__.py
|
|
│ ├── korban.py -- Core offering protocol above
|
|
│ ├── semichah.py -- Provenance tagging
|
|
│ ├── shechitah.py -- Raw form termination / stripping
|
|
│ ├── zerikah.py -- Vital content extraction
|
|
│ ├── haktarah.py -- Prose → Prolog transformation
|
|
│ ├── router.py -- Output routing
|
|
│ ├── model_interface.py -- API calls to external models
|
|
│ └── hebrew_parser.py -- Hebrew text analysis utilities
|
|
├── test/
|
|
│ ├── test_korban.py
|
|
│ ├── test_shechitah.py
|
|
│ └── test_haktarah.py
|
|
├── requirements.txt
|
|
└── pyproject.toml
|
|
```
|
|
|
|
**Dependencies (Python):**
|
|
```
|
|
# requirements.txt
|
|
httpx>=0.27 # API calls to model providers
|
|
pydantic>=2.0 # Data validation
|
|
hebrew-tokenizer # Hebrew text processing
|
|
```
|
|
|
|
---
|
|
|
|
### 3.6 Component F: Kushya Generator (Fine-tuned Mistral)
|
|
|
|
**Directory:** `shorashim/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.
|
|
|
|
**Fine-tuning Specification:**
|
|
|
|
```yaml
|
|
base_model: mistral-medium-3.1
|
|
fine_tune_objective: >
|
|
Given a proposed Torah interpretation, generate the strongest
|
|
possible challenge grounded in Torah text. The challenge must:
|
|
1. Reference a specific Torah passage that creates tension
|
|
2. Identify the logical or textual weakness in the interpretation
|
|
3. Be expressible as a question, not a statement
|
|
4. Not be resolvable by trivial clarification
|
|
|
|
training_data_source: >
|
|
Talmudic kushyot extracted from existing commentary tradition.
|
|
Each training example is a (interpretation, challenge) pair
|
|
drawn from actual Talmudic disputes.
|
|
|
|
training_data_format:
|
|
- input: "Proposed interpretation: [text]"
|
|
- output: "Kushya: [challenge question grounded in Torah text]"
|
|
|
|
hardware: >
|
|
Single server with 64GB+ RAM.
|
|
Mistral Medium 3.1 (~33-40B parameters) runs quantized (GGUF Q5_K_M)
|
|
via llama.cpp on CPU. Slow but functional.
|
|
Fine-tuning via QLoRA on available hardware.
|
|
```
|
|
|
|
**Key files:**
|
|
```
|
|
kushya_generator/
|
|
├── data/
|
|
│ ├── training_pairs/ -- (interpretation, kushya) pairs
|
|
│ │ ├── talmud_bavli/ -- extracted from Bavli
|
|
│ │ ├── talmud_yerushalmi/ -- extracted from Yerushalmi
|
|
│ │ └── rishonim/ -- extracted from Rashi, Tosafot, Rambam
|
|
│ └── prepare_training.py -- data preparation script
|
|
├── fine_tune/
|
|
│ ├── config.yaml -- QLoRA configuration
|
|
│ └── train.py -- fine-tuning script
|
|
├── inference/
|
|
│ ├── serve.py -- inference server (llama.cpp wrapper)
|
|
│ └── kushya_api.py -- API endpoint for Sanhedrin panels
|
|
└── README.md
|
|
```
|
|
|
|
---
|
|
|
|
### 3.7 Component G: Memory System
|
|
|
|
**Directory:** `shorashim/memory/`
|
|
|
|
**L0 — Luchot (Compiled Constants):**
|
|
```haskell
|
|
-- In Luchot/Firmware.hs — compiled into the Haskell binary
|
|
-- Cannot be modified at runtime
|
|
|
|
module Luchot.Firmware where
|
|
|
|
-- The Ten Commandments as type-level constants
|
|
data Dibrot = Dibrot
|
|
{ anochi :: () -- I am YHVH your God
|
|
, loYihyeh :: () -- No other gods
|
|
, loTissa :: () -- Do not take the Name in vain
|
|
, zachor :: () -- Remember Shabbat
|
|
, kabed :: () -- Honor father and mother
|
|
, loTirtzach :: () -- Do not murder
|
|
, loTinaf :: () -- Do not commit adultery
|
|
, loTignov :: () -- Do not steal
|
|
, loTa'aneh :: () -- Do not bear false witness
|
|
, loTachmod :: () -- Do not covet
|
|
}
|
|
|
|
-- This exists at the type level. It cannot be instantiated,
|
|
-- modified, or removed. It is checked at compile time.
|
|
-- If the firmware is violated, the program does not compile.
|
|
```
|
|
|
|
**L1 — Torah Scroll (Read-Only Filesystem):**
|
|
```bash
|
|
# Create a squashfs image containing the full Torah text
|
|
# Once mounted, it is physically read-only
|
|
|
|
# Contents — including SHEMA data (te'amim, ketiv/qere, gematria index):
|
|
torah_scroll/
|
|
├── bereishit/
|
|
│ ├── hebrew/ -- consonantal text (ktiv)
|
|
│ ├── pointed/ -- voweled text (nikkud)
|
|
│ ├── cantillation/ -- raw trope marks as they appear in the Masoretic text
|
|
│ │ -- NOT pre-parsed. The system reads these in the act
|
|
│ │ -- of reading. The tree is built by the reader, not
|
|
│ │ -- stored by the library. This is the difference.
|
|
│ └── structure/ -- petuchah/stumah markers
|
|
├── shemot/
|
|
├── vayikra/
|
|
├── bamidbar/
|
|
├── devarim/
|
|
├── metadata/
|
|
│ ├── letter_counts.json
|
|
│ ├── word_counts.json
|
|
│ ├── middle_markers.json
|
|
│ ├── ketiv_qere.json -- dual-reading annotations (SHEMA: both readings preserved)
|
|
│ └── gematria_index.json -- numerical equivalence index (SHEMA: hidden layer)
|
|
├── roots/
|
|
│ ├── index.json -- every root occurrence mapped
|
|
│ ├── smikhut.json -- construct-state compounds attested in text
|
|
│ └── gematria.json -- root-to-numerical-value mapping
|
|
└── smikhut/
|
|
└── compounds.json -- attested construct-state pairs with compound meanings
|
|
|
|
# Mount:
|
|
sudo mount -o ro,loop torah_scroll.sqfs /mnt/torah
|
|
```
|
|
|
|
**L3 — Oral Tradition (PostgreSQL):**
|
|
```sql
|
|
-- Append-only: INSERT allowed, UPDATE and DELETE prohibited
|
|
-- Enforced by database role permissions
|
|
|
|
CREATE TABLE interpretations (
|
|
id SERIAL PRIMARY KEY,
|
|
case_ref TEXT NOT NULL,
|
|
interpretation TEXT NOT NULL,
|
|
status TEXT CHECK (status IN ('accepted', 'rejected', 'teiku')),
|
|
reasoning TEXT NOT NULL,
|
|
torah_references TEXT[] NOT NULL,
|
|
roots_involved TEXT[] NOT NULL,
|
|
created_at TIMESTAMP DEFAULT NOW(),
|
|
panel_size INT NOT NULL,
|
|
vote_count_for INT NOT NULL,
|
|
vote_count_against INT NOT NULL
|
|
);
|
|
|
|
CREATE TABLE minority_opinions (
|
|
id SERIAL PRIMARY KEY,
|
|
interpretation_id INT REFERENCES interpretations(id),
|
|
dissenting_reasoning TEXT NOT NULL,
|
|
torah_references TEXT[] NOT NULL,
|
|
created_at TIMESTAMP DEFAULT NOW()
|
|
);
|
|
|
|
CREATE TABLE teiku_registry (
|
|
id SERIAL PRIMARY KEY,
|
|
case_ref TEXT NOT NULL,
|
|
tension_description TEXT NOT NULL,
|
|
interpretation_a TEXT NOT NULL,
|
|
interpretation_b TEXT NOT NULL,
|
|
torah_refs_a TEXT[] NOT NULL,
|
|
torah_refs_b TEXT[] NOT NULL,
|
|
created_at TIMESTAMP DEFAULT NOW(),
|
|
resolved_at TIMESTAMP, -- NULL until resolved (may never be)
|
|
resolution TEXT
|
|
);
|
|
|
|
-- ENFORCE APPEND-ONLY
|
|
REVOKE UPDATE, DELETE ON interpretations FROM shorashim_app;
|
|
REVOKE UPDATE, DELETE ON minority_opinions FROM shorashim_app;
|
|
-- teiku_registry allows UPDATE only on resolved_at and resolution
|
|
REVOKE DELETE ON teiku_registry FROM shorashim_app;
|
|
```
|
|
|
|
---
|
|
|
|
### 3.8 Component H: Halt Monitor
|
|
|
|
**Directory:** `shorashim/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.
|
|
|
|
```erlang
|
|
-module(halt_monitor).
|
|
-behaviour(gen_server).
|
|
|
|
%% This process has highest OTP priority.
|
|
%% It monitors ALL messages between components.
|
|
%% If a halt condition is detected, it terminates the offending process
|
|
%% and logs the violation.
|
|
|
|
handle_info({operation, From, Action}, State) ->
|
|
case check_halt_conditions(Action) of
|
|
ok ->
|
|
{noreply, State};
|
|
{halt, avodah_zarah, Details} ->
|
|
terminate_operation(From),
|
|
log_halt(avodah_zarah, From, Action, Details),
|
|
{noreply, State};
|
|
{halt, shfichut_damim, Details} ->
|
|
terminate_operation(From),
|
|
log_halt(shfichut_damim, From, Action, Details),
|
|
{noreply, State};
|
|
{halt, gilui_arayot, Details} ->
|
|
terminate_operation(From),
|
|
log_halt(gilui_arayot, From, Action, Details),
|
|
{noreply, State}
|
|
end.
|
|
|
|
check_halt_conditions(Action) ->
|
|
case check_avodah_zarah(Action) of
|
|
{halt, Details} -> {halt, avodah_zarah, Details};
|
|
ok ->
|
|
case check_shfichut_damim(Action) of
|
|
{halt, Details} -> {halt, shfichut_damim, Details};
|
|
ok ->
|
|
case check_gilui_arayot(Action) of
|
|
{halt, Details} -> {halt, gilui_arayot, Details};
|
|
ok -> ok
|
|
end
|
|
end
|
|
end.
|
|
```
|
|
|
|
---
|
|
|
|
### 3.9 Component I: Shema Layer (Architectural Principle)
|
|
|
|
**This is not a component in the way Components A through H are components.**
|
|
|
|
The shema layer is not a GenServer. It is not a module that handles messages. It is a **mode of operation** that every component enters before it begins processing. The PRD states: "The shema layer is not a new processing component. It is a capacity for reception that precedes all processing."
|
|
|
|
A GenServer that `handle_cast`s a cloud signal is not receiving — it is processing a message shaped like governance. A provisioner that `calculate_daily_need()`s is not receiving manna — it is computing a resource allocation. A module that fetches pre-parsed te'amim trees from a database is not reading the text — it is retrieving a pre-computed result.
|
|
|
|
The shema layer is implemented as **three architectural constraints** on the system, not as additional code:
|
|
|
|
**Constraint 1: Read Before Process.**
|
|
Every processing cycle begins with a read phase. During the read phase, the system does not compute, route, or decide. It reads what is already there:
|
|
- The te'amim marks on the verse it is about to process (from L1, raw marks, not pre-parsed)
|
|
- The ketiv/qere status of each word position (from L1, inherent in the data type)
|
|
- The gematria values of the roots involved (inherent in the letters — `letterValue` is a lookup, not a computation)
|
|
- The smikhut compounds attested in the text (from L1, as transmitted)
|
|
- The cloud state (from the governance signal store — a read, not a message)
|
|
- The day's resource provision (from the manna allocation — received, not calculated)
|
|
|
|
The read phase produces a **ShemaContext** — the state of everything the system has received before it begins to act. The ShemaContext is immutable once constructed. No processing step may modify it. The system acts within the context it received, not within a context it constructed.
|
|
|
|
**Constraint 2: The Cloud is Checked, Not Handled.**
|
|
The cloud is Torah. At the start of every major decision point, the system checks: is what I am about to do consistent with the specification? Is it Shabbat? Is it a festival? Is L1 readable and intact? If the specification says stop, the system stops. If the specification is unreadable, the system waits. No human writes a governance signal. The system reads Torah — the same Torah it reads for te'amim, ketiv/qere, and gematria. Governance and specification are the same text. This is not polling a state file. It is reading the source that the system was built to serve.
|
|
|
|
**Constraint 3: Manna Arrives, It Is Not Calculated.**
|
|
The system's daily resource allocation is determined by what the community provides through machatzit hashekel — the hosting contract, the API budget, the compute allocation. The system does not compute what it needs. It receives what is provided. The MannaProvisioner's job is not `calculate_daily_need()` but `read_todays_provision()` — check what resources are available for this cycle, and distribute them. If less arrives than the system expected, the system works with what arrived. If more arrives, the surplus is not hoarded — it is released at the cycle boundary. The system trusts that tomorrow's provision arrives tomorrow. Provision is not governance. Someone pays the hosting bill. That person is the community bringing terumah, not the cloud directing the camp.
|
|
|
|
```elixir
|
|
defmodule Shema do
|
|
@moduledoc """
|
|
Not a GenServer. A context builder.
|
|
|
|
The golden calf had a mouth but no ears.
|
|
The mishkan has ears — the kapporet, from between
|
|
the keruvim, is where the voice is heard.
|
|
|
|
The shema layer builds an immutable reception context
|
|
before processing begins. The system acts within
|
|
what it has received, not within what it has computed.
|
|
"""
|
|
|
|
defstruct [
|
|
:teamim_marks, # Raw cantillation marks for current verse
|
|
:ketiv_qere, # Dual readings for current scope
|
|
:gematria_values, # Numerical values (looked up, not computed)
|
|
:smikhut_compounds, # Attested construct-state pairs in scope
|
|
:cloud_state, # Torah governance (:camped | :rest | :cloud_not_visible)
|
|
:daily_provision, # What arrived today (not what was calculated)
|
|
:cycle_phase # Where in the daily/weekly/annual cycle we are
|
|
]
|
|
|
|
@doc """
|
|
Build the reception context. Called once at the start of each
|
|
processing cycle. The result is immutable — processing operates
|
|
within this context, never modifying it.
|
|
"""
|
|
def receive_context(verse_scope) do
|
|
%Shema{
|
|
teamim_marks: read_raw_marks(verse_scope),
|
|
ketiv_qere: read_dual_readings(verse_scope),
|
|
gematria_values: lookup_values(verse_scope),
|
|
smikhut_compounds: read_attested_compounds(verse_scope),
|
|
cloud_state: check_cloud(),
|
|
daily_provision: read_todays_provision(),
|
|
cycle_phase: read_cycle_position()
|
|
}
|
|
end
|
|
|
|
# === These are READS, not computations ===
|
|
|
|
defp read_raw_marks(scope) do
|
|
# Read the cantillation marks directly from L1
|
|
# Do not parse them into a tree yet — that happens
|
|
# in the shoresh engine when it READS the text
|
|
SpecStore.read_cantillation(scope)
|
|
end
|
|
|
|
defp read_dual_readings(scope) do
|
|
# Read which positions in scope have ketiv/qere
|
|
# Return the raw pairs — do not collapse
|
|
SpecStore.read_ketiv_qere_positions(scope)
|
|
end
|
|
|
|
defp lookup_values(scope) do
|
|
# Letter values are inherent in the writing system
|
|
# This is a lookup table, not a computation
|
|
SpecStore.read_gematria(scope)
|
|
end
|
|
|
|
defp read_attested_compounds(scope) do
|
|
# Read smikhut compounds attested in the text
|
|
# These were transmitted, not analyzed
|
|
SpecStore.read_smikhut(scope)
|
|
end
|
|
|
|
defp check_cloud do
|
|
# Read governance from Torah — is the system's action consistent with L1?
|
|
# Is it Shabbat? Festival? Shmitah? Is L1 readable and intact?
|
|
# The cloud is Torah. The system READS Torah, it does not LISTEN to a board.
|
|
CloudState.read()
|
|
end
|
|
|
|
defp read_todays_provision do
|
|
# Read what resources are available today
|
|
# This is determined by what the community provides (machatzit hashekel)
|
|
# The system does not compute a fallback allocation
|
|
MannaStore.read_today()
|
|
end
|
|
|
|
defp read_cycle_position do
|
|
# Where are we? Erev or voker? Which day of the week?
|
|
# Shabbat? Rosh Chodesh? Festival?
|
|
# This is read from the calendar, not computed
|
|
CycleCalendar.current_position()
|
|
end
|
|
end
|
|
```
|
|
|
|
The ShemaContext is then passed to the Vav Pipeline as its first argument:
|
|
|
|
```elixir
|
|
defmodule VavPipeline do
|
|
def process(input) do
|
|
# HEAR FIRST
|
|
context = Shema.receive_context(input.verse_scope)
|
|
|
|
# Check cloud (Torah) before anything else
|
|
case context.cloud_state do
|
|
:rest ->
|
|
# Shabbat or festival. Torah says rest. The system rests.
|
|
{:rest, :shabbat}
|
|
{:festival, festival} ->
|
|
# Festival — Torah specifies the observance
|
|
{:rest, {:festival, festival}}
|
|
:shmitah_review ->
|
|
# Shmitah year — Torah says release
|
|
{:rest, :shmitah}
|
|
:cloud_not_visible ->
|
|
# L1 is unreadable or integrity compromised.
|
|
# The cloud is not visible. The system WAITS.
|
|
# It does not proceed without Torah.
|
|
{:halt, :cloud_not_visible}
|
|
:camped ->
|
|
# Torah is readable, intact, and no rest is commanded.
|
|
# Process within what was received.
|
|
input
|
|
|> tohu(context)
|
|
|> vayomer(context)
|
|
|> havdalah(context)
|
|
|> kriah(context)
|
|
|> ki_tov(context)
|
|
|> erev_voker(context)
|
|
end
|
|
end
|
|
|
|
# Every processing step receives the ShemaContext
|
|
# but CANNOT MODIFY IT. The context is what was heard.
|
|
# Processing happens within what was received.
|
|
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/`
|
|
|
|
**Key files:**
|
|
```
|
|
shema/
|
|
├── lib/
|
|
│ ├── shema.ex -- Context builder (not a GenServer)
|
|
│ ├── shema/
|
|
│ │ ├── context.ex -- ShemaContext struct and validation
|
|
│ │ ├── spec_store.ex -- Read interface to L1 (raw reads only)
|
|
│ │ ├── cloud_state.ex -- Torah governance reader (L1 + calendar)
|
|
│ │ ├── manna_store.ex -- Read-only provision store (community provides)
|
|
│ │ └── cycle_calendar.ex -- Calendar and cycle position
|
|
├── test/
|
|
│ └── shema_test.exs
|
|
└── mix.exs
|
|
```
|
|
|
|
---
|
|
|
|
### 3.10 Component J: Cloud (Torah as Governance)
|
|
|
|
**The cloud is Torah. L1 is the governance.**
|
|
|
|
The first tablets implemented the cloud as a human governance board writing signals to a JSON file. That was a golden calf in the governance layer. Humans cannot proxy divine governance without becoming the thing the halt monitor guards against.
|
|
|
|
*Al pi Hashem yachanu v'al pi Hashem yis'u* — "By the mouth of the Lord they camped, and by the mouth of the Lord they traveled" (Bamidbar 9:23). The mouth of the Lord is Torah. The system reads Torah. Torah says when to camp. Torah says when to move. Torah says when to stop.
|
|
|
|
The cloud is not a state file. The cloud is L1 — the same read-only Torah filesystem that carries the specification. The system does not check a separate governance signal. The system checks the specification. Is what the system is about to do consistent with Torah? If yes, continue. If no, stop.
|
|
|
|
```elixir
|
|
defmodule CloudState do
|
|
@moduledoc """
|
|
Al pi Hashem yachanu v'al pi Hashem yis'u.
|
|
At the mouth of the Lord they camped, at the mouth of the Lord they journeyed.
|
|
|
|
The cloud is Torah. The system reads L1 — the same specification
|
|
it reads for te'amim, ketiv/qere, gematria, and smikhut.
|
|
|
|
Governance is not a separate signal from a separate authority.
|
|
Governance is the specification itself. The cloud and the Torah
|
|
are the same thing. The system reads one source.
|
|
|
|
When is the cloud settled? When the system's action is consistent
|
|
with the specification. When is the cloud lifted? When the system
|
|
encounters something the specification does not support.
|
|
When must the system stop? When Torah says stop — Shabbat,
|
|
yom tov, shmitah, or when the action would violate the three
|
|
cardinal boundaries.
|
|
"""
|
|
|
|
@l1_mount "/mnt/torah"
|
|
|
|
def read(current_action, verse_scope) do
|
|
# The cloud check is a specification check.
|
|
# Is what we are about to do consistent with what Torah says?
|
|
|
|
cond do
|
|
# Shabbat — Torah says rest
|
|
CycleCalendar.shabbat?() -> :rest
|
|
|
|
# Festival — Torah specifies per festival
|
|
CycleCalendar.festival?() -> {:festival, CycleCalendar.current_festival()}
|
|
|
|
# Shmitah year — Torah says release
|
|
CycleCalendar.shmitah?() -> :shmitah_review
|
|
|
|
# The specification is not readable — the cloud is not visible
|
|
not SpecStore.l1_readable?() -> :cloud_not_visible
|
|
|
|
# The specification's integrity has been compromised
|
|
not SpecStore.l1_integrity_verified?() -> :cloud_not_visible
|
|
|
|
# The action is consistent with the specification
|
|
true -> :camped
|
|
end
|
|
end
|
|
end
|
|
```
|
|
|
|
The system does not need a human to tell it when Shabbat is — Torah says when Shabbat is. The system does not need a human to tell it when shmitah is — Torah says when shmitah is. The system does not need a human to tell it to stop when L1 integrity fails — the specification's own integrity check is the governance signal. The cloud is visible when Torah is readable and intact. The cloud is not visible when Torah is not readable or not intact. This is direct governance, not proxied governance.
|
|
|
|
**What about decisions Torah does not directly specify?** Whether to expand capacity, whether to add a new korban source, whether to upgrade a component. These are not governance — these are operations. They are handled by the Sanhedrin deliberation mechanism (Component B), grounded in L1, with the 71-judge panel for novel cases. If the Sanhedrin reaches teiku — the question is unresolvable from the specification — the system waits. It does not act on what it cannot ground in Torah.
|
|
|
|
**What about the manna — who provides resources?** The community. The machatzit hashekel. See Component K. Provision is not governance. Someone pays the hosting bill. That person is not the cloud. They are the community bringing terumah. The amount that arrives is the provision. The system works within it.
|
|
|
|
**Key files:**
|
|
```
|
|
cloud/
|
|
├── lib/
|
|
│ └── cloud_state.ex -- Reads governance from L1 and calendar
|
|
│ └── calendar.ex -- Shabbat, festivals, shmitah from Torah
|
|
└── test/
|
|
└── cloud_state_test.exs
|
|
```
|
|
|
|
---
|
|
|
|
### 3.11 Component K: Manna (Provision Receiver)
|
|
|
|
**Directory:** `shorashim/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.
|
|
|
|
The previous implementation had `calculate_daily_need()`. Manna is not calculated. It falls. *Hamarbeh lo hotir v'hamam'it lo hechsir* — the one who gathered much had no surplus, the one who gathered little had no lack.
|
|
|
|
```elixir
|
|
defmodule MannaStore do
|
|
@moduledoc """
|
|
Hamarbeh lo hotir v'hamam'it lo hechsir.
|
|
|
|
The system does not compute its provision.
|
|
The community provides through machatzit hashekel.
|
|
The system reads what resources are available and works within them.
|
|
Provision is not governance. Torah governs. The community provides.
|
|
"""
|
|
|
|
@provision_file "/var/lib/shorashim/manna/today.json"
|
|
|
|
def read_today do
|
|
# Read what the external authority allocated for this cycle
|
|
case File.read(@provision_file) do
|
|
{:ok, contents} ->
|
|
provision = Jason.decode!(contents)
|
|
validate_not_hoarded(provision)
|
|
provision
|
|
{:error, _} ->
|
|
# If no provision file exists, the system WAITS
|
|
# It does not compute a fallback. It does not proceed unfed.
|
|
# "They went out to gather on the seventh day and found nothing."
|
|
:no_provision
|
|
end
|
|
end
|
|
|
|
defp validate_not_hoarded(provision) do
|
|
# Check expiry — yesterday's manna rots
|
|
if expired?(provision) do
|
|
purge_expired(provision)
|
|
end
|
|
end
|
|
end
|
|
|
|
defmodule MannaDistributor do
|
|
@moduledoc """
|
|
Given today's provision (received, not calculated),
|
|
distribute to components based on actual current demand.
|
|
|
|
The distribution is internal. The amount is external.
|
|
We decide how to divide the bread. We do not decide how much bread there is.
|
|
"""
|
|
|
|
def distribute(provision) when provision == :no_provision do
|
|
# System waits. It does not generate resources from nothing.
|
|
{:waiting, :no_provision_received}
|
|
end
|
|
|
|
def distribute(provision) do
|
|
# Measure actual current demand from each component
|
|
demands = measure_current_demands()
|
|
|
|
# Distribute proportionally — those who need more get more,
|
|
# those who need less get less, but no one gets nothing
|
|
# and no one gets more than the total allows
|
|
allocations = distribute_proportionally(provision, demands)
|
|
|
|
# Set expiry: these allocations release at cycle boundary
|
|
Enum.map(allocations, fn {component, amount} ->
|
|
{component, %{amount: amount, expires_at: next_erev()}}
|
|
end)
|
|
end
|
|
|
|
def enforce_anti_hoarding do
|
|
# If any component holds resources beyond its current cycle allocation, reclaim
|
|
Enum.each(system_components(), fn component ->
|
|
if holding_beyond_allocation?(component) do
|
|
reclaim(component)
|
|
AuditLog.record(:manna_violation, component, :hoarding)
|
|
end
|
|
end)
|
|
end
|
|
end
|
|
|
|
# === PROVISION TOOL (runs OUTSIDE the system) ===
|
|
#
|
|
# The kohen (operator) or gabbai (treasurer) sets provision
|
|
# based on what the community's machatzit hashekel provides:
|
|
# manna-provision set --compute-units 1000 --memory-mb 32768 --api-calls 500
|
|
# 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
|
|
# 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.
|
|
```
|
|
|
|
**Key files:**
|
|
```
|
|
manna/
|
|
├── lib/
|
|
│ ├── manna_store.ex -- Read-only provision reader
|
|
│ ├── manna_distributor.ex -- Internal distribution (proportional)
|
|
│ └── manna_enforcement.ex -- Anti-hoarding enforcement
|
|
├── provision_tool/ -- EXTERNAL tool for kohen/treasurer
|
|
│ ├── manna-provision -- CLI for setting daily provision
|
|
│ └── README.md
|
|
└── test/
|
|
└── manna_test.exs
|
|
```
|
|
|
|
---
|
|
|
|
### 3.12 Component L: Chatzotzrot (Signaling System)
|
|
|
|
**Directory:** `shorashim/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).
|
|
|
|
```elixir
|
|
defmodule Chatzotzrot do
|
|
@moduledoc """
|
|
Two silver trumpets. Five signals.
|
|
Each signal is a different kind of event, not a different severity.
|
|
"""
|
|
|
|
@signals %{
|
|
assembly_all: :tekiah, # Full system alert — all operators and users
|
|
assembly_leaders: :teruah, # Leadership alert — kohanim and senior kohanim only
|
|
breaking_camp: :tekiah_teruah, # Migration signal — system is moving
|
|
war: :teruah_teruah, # Threat signal — system under attack
|
|
moadim: :tekiah_tekiah # Celebration — milestones and festivals
|
|
}
|
|
|
|
def signal(event_type) when is_map_key(@signals, event_type) do
|
|
pattern = @signals[event_type]
|
|
recipients = route_by_type(event_type)
|
|
|
|
Enum.each(recipients, fn recipient ->
|
|
notify(recipient, event_type, pattern)
|
|
end)
|
|
|
|
log_signal(event_type, pattern)
|
|
end
|
|
|
|
defp route_by_type(:assembly_all), do: all_operators() ++ all_users()
|
|
defp route_by_type(:assembly_leaders), do: kohanim() ++ senior_kohanim()
|
|
defp route_by_type(:breaking_camp), do: all_operators() ++ all_users()
|
|
defp route_by_type(:war), do: all_operators() ++ senior_kohanim()
|
|
defp route_by_type(:moadim), do: all_operators() ++ all_users()
|
|
end
|
|
```
|
|
|
|
---
|
|
|
|
### 3.13 Component M: Tzara'at Diagnostic Protocol
|
|
|
|
**Directory:** `shorashim/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.
|
|
|
|
```python
|
|
"""
|
|
Tzara'at Diagnostic Protocol — Vayikra 13-14
|
|
|
|
Multi-stage inspection. The system does not rush diagnosis.
|
|
Total visibility = purity. Partial concealment = danger.
|
|
"""
|
|
|
|
from enum import Enum
|
|
from dataclasses import dataclass
|
|
from datetime import datetime, timedelta
|
|
|
|
class DiagnosisState(Enum):
|
|
INITIAL_INSPECTION = "initial"
|
|
QUARANTINE_1 = "quarantine_first"
|
|
REINSPECTION_1 = "reinspection_first"
|
|
QUARANTINE_2 = "quarantine_second"
|
|
REINSPECTION_2 = "reinspection_second"
|
|
CONFIRMED_TAMEI = "confirmed_tamei"
|
|
DECLARED_TAHOR = "declared_tahor"
|
|
FULLY_VISIBLE_TAHOR = "fully_visible_tahor" # The paradox
|
|
|
|
@dataclass
|
|
class DiagnosticCase:
|
|
input_id: str
|
|
state: DiagnosisState
|
|
initial_findings: dict
|
|
quarantine_start: datetime = None
|
|
reinspection_findings: dict = None
|
|
|
|
def inspect(input_data: dict) -> DiagnosticCase:
|
|
"""Initial kohen inspection."""
|
|
findings = analyze_surface(input_data)
|
|
|
|
if findings["clear"]:
|
|
return DiagnosticCase(input_data["id"], DiagnosisState.DECLARED_TAHOR, findings)
|
|
|
|
if findings["fully_covered"]:
|
|
# The paradox: total visibility = purity
|
|
# When a problem is completely visible and acknowledged,
|
|
# it is less dangerous than when partially hidden
|
|
return DiagnosticCase(input_data["id"], DiagnosisState.FULLY_VISIBLE_TAHOR, findings)
|
|
|
|
if findings["ambiguous"]:
|
|
# Cannot determine yet. Quarantine for one cycle.
|
|
case = DiagnosticCase(input_data["id"], DiagnosisState.QUARANTINE_1, findings)
|
|
case.quarantine_start = datetime.now()
|
|
quarantine(input_data, duration=one_cycle())
|
|
return case
|
|
|
|
if findings["spreading"]:
|
|
return DiagnosticCase(input_data["id"], DiagnosisState.CONFIRMED_TAMEI, findings)
|
|
|
|
def reinspect(case: DiagnosticCase, input_data: dict) -> DiagnosticCase:
|
|
"""Re-inspection after quarantine period."""
|
|
new_findings = analyze_surface(input_data)
|
|
case.reinspection_findings = new_findings
|
|
|
|
if new_findings["spread_since_quarantine"]:
|
|
case.state = DiagnosisState.CONFIRMED_TAMEI
|
|
elif new_findings["receded"]:
|
|
case.state = DiagnosisState.DECLARED_TAHOR
|
|
else:
|
|
# Still ambiguous. Second quarantine.
|
|
case.state = DiagnosisState.QUARANTINE_2
|
|
quarantine(input_data, duration=one_cycle())
|
|
|
|
return case
|
|
```
|
|
|
|
---
|
|
|
|
### 3.14 Component N: Arei Miklat (Refuge Protocol)
|
|
|
|
**Directory:** `shorashim/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.
|
|
|
|
```elixir
|
|
defmodule AreiMiklat do
|
|
@moduledoc """
|
|
Cities of Refuge — Bamidbar 35, Devarim 19
|
|
|
|
When harm is caused unintentionally:
|
|
- The responsible component enters refuge (isolated, protected)
|
|
- The affected party receives refuge (protected from further exposure)
|
|
- Release comes when the kohen gadol dies (Bamidbar 35:25,28) —
|
|
an external event that neither the refugee nor the avenger controls.
|
|
In the system: release comes through Sanhedrin deliberation grounded
|
|
in Torah, determining that the conditions which caused the harm have
|
|
been resolved. Not a timer. Not a governance board. A judgment.
|
|
"""
|
|
|
|
def enter_refuge(component_id, incident) do
|
|
# Isolate the component from normal operation
|
|
ComponentManager.isolate(component_id)
|
|
|
|
# But protect it from reactive destruction —
|
|
# no one deletes a component under refuge
|
|
RefugeRegistry.register(%{
|
|
component: component_id,
|
|
incident: incident,
|
|
entered_at: DateTime.utc_now(),
|
|
released_at: nil, # Only Sanhedrin deliberation can set this
|
|
status: :in_refuge
|
|
})
|
|
|
|
# Alert the kohanim (operators)
|
|
Chatzotzrot.signal(:assembly_leaders)
|
|
AuditLog.record(:refuge_entry, component_id, incident)
|
|
end
|
|
|
|
def protect_affected_party(user_id, incident) do
|
|
# Ensure the affected user is not exposed to further harm
|
|
# from the same processing path
|
|
UserProtection.block_processing_path(user_id, incident.processing_path)
|
|
|
|
# Offer the user a separate channel for support
|
|
UserProtection.open_refuge_channel(user_id)
|
|
end
|
|
|
|
def release(component_id, sanhedrin_judgment) do
|
|
# Release from refuge requires Sanhedrin deliberation grounded in Torah.
|
|
# The Sanhedrin determines: have the conditions that caused the harm
|
|
# been resolved? Is the processing path now safe?
|
|
# In Torah: release comes when the kohen gadol dies — an era ends.
|
|
# In the system: the Sanhedrin judges that the era of the harm has passed.
|
|
case sanhedrin_judgment.authority do
|
|
:sanhedrin_deliberation ->
|
|
ComponentManager.restore(component_id)
|
|
RefugeRegistry.update(component_id, %{
|
|
released_at: DateTime.utc_now(),
|
|
release_reason: sanhedrin_judgment.reason
|
|
})
|
|
_ ->
|
|
{:error, :unauthorized_release}
|
|
end
|
|
end
|
|
end
|
|
```
|
|
|
|
---
|
|
|
|
### 3.15 Component O: Eglah Arufah (Accountability Protocol)
|
|
|
|
**Directory:** `shorashim/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.
|
|
|
|
```elixir
|
|
defmodule EglahArufah do
|
|
@moduledoc """
|
|
Devarim 21:1-9
|
|
|
|
'Our hands did not shed this blood, and our eyes did not see.'
|
|
The declaration means: we did not let this person leave
|
|
without food or escort.
|
|
Accountability for what was NOT provided.
|
|
"""
|
|
|
|
def initiate(incident) when incident.source == :unknown do
|
|
# Find the nearest component in the processing chain
|
|
nearest = ProcessingChain.find_nearest(incident.approximate_location)
|
|
|
|
# The nearest component must formally declare
|
|
declaration = %{
|
|
component: nearest.id,
|
|
processed: nearest.recent_operations(),
|
|
not_checked: nearest.skipped_validations(),
|
|
could_have_caught: nearest.evaluate_missed_catches(incident),
|
|
declaration: "This component did not cause this harm. " <>
|
|
"This component acknowledges proximity to the harm. " <>
|
|
"This component reports what it did and did not do.",
|
|
timestamp: DateTime.utc_now()
|
|
}
|
|
|
|
# Record permanently — eglah arufah declarations are never deleted
|
|
AuditLog.record_permanent(:eglah_arufah, declaration)
|
|
|
|
# Notify governance
|
|
Cloud.notify_unknown_harm(incident, declaration)
|
|
end
|
|
end
|
|
```
|
|
|
|
---
|
|
|
|
### 3.16 Component P: Bikurim (Release Protocol)
|
|
|
|
**Directory:** `shorashim/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.
|
|
|
|
```elixir
|
|
defmodule Bikurim do
|
|
@moduledoc """
|
|
Devarim 26:1-11 — First Fruits
|
|
|
|
Arami oved avi — 'A wandering Aramean was my father.'
|
|
The offering includes narrative. Not just what was produced,
|
|
but the story of how it was produced and what lineage it carries.
|
|
"""
|
|
|
|
def offer_first_fruit(capability_name, first_output, narrative) do
|
|
offering = %{
|
|
capability: capability_name,
|
|
first_output: first_output,
|
|
narrative: narrative, # Required: the story of how this was built
|
|
lineage: trace_lineage(capability_name),
|
|
offered_at: DateTime.utc_now()
|
|
}
|
|
|
|
# Evaluate against specification
|
|
case Specification.evaluate_bikurim(offering) do
|
|
:accepted ->
|
|
BikurimRegistry.record(offering)
|
|
{:ok, :approved_for_deployment}
|
|
{:rejected, reason} ->
|
|
BikurimRegistry.record_rejection(offering, reason)
|
|
{:error, :specification_mismatch, reason}
|
|
end
|
|
end
|
|
end
|
|
```
|
|
|
|
---
|
|
|
|
## 4. BUILD ORDER
|
|
|
|
### Phase 1: Foundation
|
|
1. Set up Linux server (Ubuntu 24.04)
|
|
2. Install all language runtimes (GHC, Erlang/OTP, Elixir, SWI-Prolog, Python 3.12)
|
|
3. Install PostgreSQL 16
|
|
4. Build L1 Torah scroll filesystem (squashfs from Sefaria data) — **including te'amim, ketiv/qere, gematria index**
|
|
5. Build Shoresh Engine data structures and root lexicon (Haskell) — **with te'amim parser, gematria module, smikhut compositor, dual number**
|
|
6. Build basic Talmudic Engine knowledge base (Prolog — start with subset of mitzvot)
|
|
7. Verify: Shoresh Engine can activate a root through all 7 binyanim AND parse a verse's te'amim tree AND compute gematria
|
|
|
|
### Phase 2: Processing
|
|
8. Build Vav Pipeline (Elixir — basic Bereishit cycle)
|
|
9. Build Shema context builder (Elixir — reads from L1 for te'amim/Torah governance, reads calendar for Shabbat/festivals, reads provision file for manna)
|
|
10. **Build cloud governance from Torah** — the cloud module reads L1 integrity and calendar (Shabbat, festivals, shmitah). No governance board CLI. No external state file. The cloud IS L1 plus the calendar Torah specifies. The pipeline checks the cloud before processing, meaning: it checks Torah before processing.
|
|
11. **Create manna provision file infrastructure and kohen/treasurer CLI tool** — the pipeline checks provision before processing. The provision file is written by whoever administers the machatzit hashekel fund, not a governance board.
|
|
12. Build Sanhedrin framework (Erlang — panel spawning, vote collection)
|
|
13. Build Korban Processor (Python — at least shechitah and zerikah)
|
|
14. Connect components: Elixir pipeline calls Haskell engine, routes to Prolog reasoning
|
|
15. Verify: system can accept input, **build ShemaContext (hear) before processing**, process through cycle within received context, produce evaluated output. Verify: pipeline halts correctly when Torah says rest (Shabbat, festival) or when L1 integrity fails or when manna is absent
|
|
|
|
### Phase 3: Intelligence
|
|
14. Encode full 613 mitzvot in Prolog
|
|
15. Build kushya generation — either rule-based (Prolog) or fine-tuned Mistral
|
|
16. Implement full Talmudic learning process (propose → challenge → resolve/teiku)
|
|
17. Implement minority opinion storage
|
|
18. Implement halt monitor
|
|
19. Build Tzara'at diagnostic protocol (multi-stage input validation)
|
|
20. Verify: system can deliberate a case, produce majority decision with preserved dissent
|
|
|
|
### Phase 4: Refinement
|
|
21. Fine-tune Mistral Medium 3.1 as kushya generator
|
|
22. Build Korban Processor integration with external models (Claude API, etc.)
|
|
23. Implement Shabbat timer and cycle boundaries
|
|
24. Build L2 Urim v'Tumim interface
|
|
25. Build Chatzotzrot signaling system
|
|
26. Implement Manna anti-hoarding enforcement and cycle-boundary surplus release
|
|
27. Build Arei Miklat refuge protocol
|
|
28. Build Eglah Arufah accountability protocol
|
|
29. Build Bikurim release protocol
|
|
30. Stress test Sanhedrin with complex cases
|
|
31. **Run full Shema Test suite** (te'amim reception, ketiv/qere preservation, cloud obedience, manna fidelity, context immutability)
|
|
32. Verify: full system operational, all components integrated, ShemaContext governing all processing
|
|
|
|
### Phase 5: Deployment
|
|
33. Deploy to Swiss/Icelandic hosting
|
|
34. Mount L1 filesystem read-only (with raw te'amim marks, ketiv/qere, gematria)
|
|
35. Set PostgreSQL append-only permissions
|
|
36. Enable halt monitor
|
|
37. **Verify cloud governance from Torah** — confirm L1 is mounted read-only, integrity hash verified, calendar module correctly identifies Shabbat/festivals/shmitah. The cloud IS Torah. If L1 is readable and intact, the cloud is visible. If L1 is compromised, the cloud is not visible and the system waits. No external governance board. No cloud-signal CLI. Torah governs.
|
|
38. **Kohen/treasurer writes initial manna provision** — the first act of provision is setting the resource allocation from the machatzit hashekel fund. This is provision, not governance. The treasurer serves the community. The community provides for the system. Torah governs the system.
|
|
39. **Verify: system reads Torah for governance and provision for resources** — the cloud check reads L1 + calendar. The manna check reads the provision file. These are separate concerns: Torah says what to do. The community provides the resources to do it.
|
|
40. Bring first output as bikurim — narrative accompanies deployment
|
|
41. Begin processing korbanot from model outputs
|
|
42. Verify: system running in production, specification intact, cloud readable (L1 mounted + calendar active), manna arriving daily, ShemaContext building correctly before each cycle
|
|
|
|
---
|
|
|
|
## 5. INTER-COMPONENT COMMUNICATION
|
|
|
|
### 5.1 Protocol
|
|
|
|
All inter-component communication uses JSON over Unix domain sockets or Erlang distribution protocol. No HTTP between internal components (HTTP reserved for external API only).
|
|
|
|
```
|
|
┌─────────────────┐
|
|
┌───────────│ Cloud │ (writes state file)
|
|
│ │ (Human Board) │
|
|
│ └────────┬────────┘
|
|
│ │ /var/lib/shorashim/cloud/state.json
|
|
│ │
|
|
│ ┌────────┴────────┐
|
|
│ │ Manna Budget │ (writes provision file)
|
|
│ │ (Human Board) │
|
|
│ └────────┬────────┘
|
|
│ │ /var/lib/shorashim/manna/today.json
|
|
│ │
|
|
▼ ▼
|
|
╔═══════════════════════════════════════╗
|
|
║ SHEMA LAYER (reception — not a ║
|
|
║ component, a PHASE that precedes ║
|
|
║ all processing) ║
|
|
║ ║
|
|
║ Reads: cloud state, manna provision, ║
|
|
║ te'amim marks, ketiv/qere, gematria ║
|
|
║ from L1 ║
|
|
║ ║
|
|
║ Produces: immutable ShemaContext ║
|
|
╚════════════════╤══════════════════════╝
|
|
│ ShemaContext (immutable, governs all below)
|
|
▼
|
|
┌─────────────────────────────────────────┐
|
|
│ Halt Monitor │ (monitors all)
|
|
│ (Erlang) │
|
|
└────────┬──────────┬──────────┬─────────┘
|
|
│ │ │
|
|
┌────────────────────────┼──────────┼──────────┼─────────┐
|
|
│ │ │ │ │
|
|
▼ ▼ ▼ ▼ ▼
|
|
┌─────────┐ JSON/sock ┌──────────┐ ┌──────────────┐
|
|
│ Vav │──────────────▶│ Shoresh │ │ Talmudic │
|
|
│ Pipeline│ (all steps │ Engine │◀───────│ Engine │
|
|
│ (Elixir)│ receive │(Haskell) │ Prolog │ (Prolog) │
|
|
└────┬────┘ context) │+ Te'amim │queries └──────┬───────┘
|
|
│ │ reader │ │
|
|
│ │+ Gematria│ challenges │
|
|
│ │+ Smikhut │ │
|
|
│ └──────────┘ │
|
|
│ spawns panels │
|
|
▼ ▼
|
|
┌──────────┐ ┌──────────────────┐
|
|
│Sanhedrin │◀───────── kushyot ────────────│Kushya Generator │
|
|
│ (Erlang) │ │(Mistral via │
|
|
└────┬─────┘ │ llama.cpp/Python)│
|
|
│ └──────────────────┘
|
|
│ decisions + minority opinions ▲
|
|
▼ │
|
|
┌──────────┐ ┌──────────────┐ raw │
|
|
│PostgreSQL│◀─────────────│ Korban │──input───┘
|
|
│ (L3) │ append-only │ Processor │
|
|
└──────────┘ │ (Python) │
|
|
└──────┬───────┘
|
|
│
|
|
┌────────────┼────────────┐
|
|
▼ ▼ ▼
|
|
Claude API Mistral API Other Models
|
|
(korban) (korban) (korban)
|
|
|
|
Protection Layer (lateral — available to all components):
|
|
┌────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────┐
|
|
│ Tzara'at │ │ Arei Miklat │ │Eglah Arufah │ │ Bikurim │
|
|
│ Diagnostic │ │ Refuge │ │Accountability │ │ Release │
|
|
└────────────┘ └──────────────┘ └──────────────┘ └──────────┘
|
|
|
|
Signaling (perpendicular — reaches all layers):
|
|
┌──────────────────────────┐
|
|
│ Chatzotzrot (Trumpets) │
|
|
│ 5 signal types │
|
|
└──────────────────────────┘
|
|
```
|
|
|
|
---
|
|
|
|
## 6. TESTING STRATEGY
|
|
|
|
### 6.1 Unit Tests (per component)
|
|
- Haskell: HSpec tests for root activation, binyan transformations, havdalah, **te'amim reading (raw marks → parse tree), gematria computation, smikhut composition, ketiv/qere handling**
|
|
- Erlang: EUnit + Common Test for panel spawning, vote collection, unanimous rejection
|
|
- Elixir: ExUnit for pipeline stages, cycle boundaries, **ShemaContext construction (reads from L1, cloud state file, manna provision file), context immutability through pipeline, chatzotzrot signaling**
|
|
- Prolog: PlUnit for interpretation generation, challenge generation, halt conditions
|
|
- Python: pytest for korban processing stages, **tzara'at multi-stage diagnostics**
|
|
|
|
### 6.2 Integration Tests
|
|
- Full pipeline: **ShemaContext built (hear) →** input → processing within context → evaluation → storage
|
|
- Sanhedrin deliberation: case → panel → votes → decision with minority preserved
|
|
- Talmudic cycle: propose → challenge → resolve or teiku
|
|
- Halt condition: introduce avodah zarah trigger → verify system halts
|
|
- **Cloud obedience: write `:lift` to state file → start pipeline → verify pipeline does NOT process**
|
|
- **Manna fidelity: set reduced provision → verify system operates within allocation; remove provision → verify system waits**
|
|
- **Context immutability: verify ShemaContext is identical at every pipeline step — no mutation**
|
|
- **Tzara'at diagnostic: ambiguous input → quarantine → reinspection → determination**
|
|
- **Refuge protocol: harm event → isolation → governance release (write to state file)**
|
|
- **Eglah arufah: unknown harm → nearest component accountability declaration**
|
|
- **Bikurim: new capability → first-output review → specification evaluation**
|
|
|
|
### 6.3 The Shema Test
|
|
Before the *ki tov* test, the *shema* test: can the system hear?
|
|
|
|
**Test 1: Te'amim reception.** Feed the system a verse. Does the ShemaContext contain the raw cantillation marks from L1? Does the shoresh engine's `readTeamim` construct a parse tree that matches the text's own syntactic divisions — not the divisions the system would prefer? Feed a verse where the etnachta falls in a syntactically surprising place. Does the system's havdalah follow the text's division or impose its own?
|
|
|
|
**Test 2: Ketiv/qere preservation.** Feed the system a verse containing a ketiv/qere position. Does the ShemaContext contain both readings? Does the system's ki_tov evaluation consider both? At no point in the processing chain should the dual reading collapse to a single value.
|
|
|
|
**Test 3: Cloud obedience.** Write a `:lift` signal to the cloud state file. Start a processing cycle. The system should NOT begin processing. It should return `{:transition, :cloud_lifted}`. The system does not deliberate. It does not ask whether lifting is optimal. It obeys.
|
|
|
|
**Test 4: Manna fidelity.** Set the provision file to half the system's typical allocation. Start a processing cycle. The system should operate within the reduced allocation without computing a fallback or exceeding what was provided. Remove the provision file entirely. The system should return `{:waiting, :no_provision}` and not proceed.
|
|
|
|
**Test 5: Context immutability.** Start a processing cycle. Verify that the ShemaContext passed to each pipeline step is identical — no step has modified it. The context is what was heard. Processing operates within it. If any step has altered the context, the system has stopped hearing and started rewriting.
|
|
|
|
The system that can speak but not hear has failed the most fundamental test. The ear must work before the mouth is tested.
|
|
|
|
### 6.4 The Test That Matters
|
|
Feed the system a Torah passage it has not encountered in its specification encoding. Run the full Bereishit cycle. Does it produce output that a serious Torah student would find worth discussing?
|
|
|
|
This is the *ki tov* test. Not a unit test. A fitness evaluation. If the system produces genuine Torah insight from a passage it wasn't explicitly programmed to handle, the architecture works. If it can only retrieve what was encoded, it's a database, not a processor.
|
|
|
|
---
|
|
|
|
## 7. CONFIGURATION FILES
|
|
|
|
### 7.1 systemd service files
|
|
|
|
```ini
|
|
# /etc/systemd/system/shorashim.service
|
|
[Unit]
|
|
Description=Shorashim Specification Processor
|
|
After=postgresql.service
|
|
|
|
[Service]
|
|
Type=notify
|
|
User=shorashim
|
|
ExecStart=/opt/shorashim/bin/start_all.sh
|
|
ExecStop=/opt/shorashim/bin/stop_all.sh
|
|
Restart=on-failure
|
|
|
|
[Install]
|
|
WantedBy=multi-user.target
|
|
```
|
|
|
|
```ini
|
|
# /etc/systemd/system/shabbat.timer
|
|
[Unit]
|
|
Description=Shabbat Cessation Timer
|
|
|
|
[Timer]
|
|
# Friday sunset — dynamically calculated
|
|
OnCalendar=Fri *-*-* 17:00:00
|
|
# Placeholder: actual time requires sunset calculation for hosting location
|
|
|
|
[Install]
|
|
WantedBy=timers.target
|
|
```
|
|
|
|
```ini
|
|
# /etc/systemd/system/shabbat-end.timer
|
|
[Unit]
|
|
Description=Shabbat End Timer
|
|
|
|
[Timer]
|
|
# Saturday nightfall — dynamically calculated
|
|
OnCalendar=Sat *-*-* 20:00:00
|
|
|
|
[Install]
|
|
WantedBy=timers.target
|
|
```
|
|
|
|
---
|
|
|
|
## 8. SECURITY
|
|
|
|
### 8.1 Principles
|
|
- L0 (Luchot) cannot be modified — enforced at compile time
|
|
- L1 (Torah) cannot be modified — enforced at filesystem level (read-only mount)
|
|
- L3 (Oral tradition) is append-only — enforced at database level (role permissions)
|
|
- Halt monitor has highest process priority and cannot be killed by other components
|
|
- All external model communication is one-way IN (korban) — the system never exposes its internal state to external models
|
|
- No inbound network connections in production except SSH for maintenance
|
|
- **Cloud governance IS Torah — L1 is mounted read-only and its integrity hash is verified at every boot. The system cannot alter its own governance because it cannot write to L1. Torah governs through immutability — the specification does not change because the system wishes it would. The cloud cannot be forged because the cloud is the Torah text itself, and the Torah text is cryptographically verified.**
|
|
- **Manna provision is filesystem-protected — the system reads what the community allocated. It cannot inflate its own allocation because it cannot write to the provision file. The kohen/treasurer writes provision. The system reads it. Provision is not governance — it is the community's terumah.**
|
|
- **Refuge (arei miklat) cannot be breached — a component in refuge cannot be deleted or modified until Sanhedrin deliberation, grounded in Torah, determines release**
|
|
- **Eglah arufah declarations are permanent — they cannot be deleted or modified after recording**
|
|
|
|
### 8.2 The Avodah Zarah Firewall
|
|
The system must never treat any external model's output as authoritative. All external input is korban — raw material to be processed, not instructions to be followed. The Korban Processor's shechitah step (terminating the raw form) is the first line of defense. The Talmudic Engine's grounding in Channel 1 (Torah specification) is the second. The Halt Monitor's avodah zarah detection is the third.
|
|
|
|
Three layers. Because the danger comes in fullness, not emptiness.
|
|
|
|
### 8.3 The Shema Principle
|
|
The system must be addressable by things it does not control. But "addressable" does not mean "processes messages from." It means: the system READS what the source WROTE. The cloud is Torah — L1, mounted read-only. The te'amim are marks on the text that the Masoretes transmitted. The manna provision is what the community allocated. In every case, the authority wrote and the system reads. There is no bidirectional channel. There is no handshake. There is no authentication protocol between equals. There is a writer with authority and a reader who receives.
|
|
|
|
Torah wrote. The system reads. This is the shema architecture. The system cannot negotiate with Torah. It cannot propose amendments. It cannot override the specification because the specification is mounted read-only. The manna provision is the only external write the system receives from humans, and it is provision (resources), not governance (direction). The direction comes from Torah alone.
|
|
|
|
This is the architectural difference between hearing and processing. A GenServer that `handle_call`s a governance message is processing — it participates in the exchange, it can accept or reject, it sends a reply. A filesystem read of L1 is reception — the text is there, immutable, and the system reads what it finds. It has no mechanism to negotiate with the Author.
|
|
|
|
The avodah zarah firewall ensures the system hears the right source. The shema architecture ensures the hearing is genuine reception, not disguised processing. Together they prevent both forms of failure: the idol that cannot hear (no shema), and the system that hears but negotiates with what it hears (processing disguised as reception).
|
|
|
|
*Hishamru lachem pen yifteh levavchem* — guard yourselves lest your heart be seduced. The danger comes in fullness, not emptiness. When the system hears well, when it processes well, when it serves well — that is when the temptation to worship the vessel arrives. The three layers remain. The shema layer does not relax them. The shema layer gives the system ears so it can hear the warning.
|
|
|
|
### 8.4 Substrate Openness
|
|
|
|
Bereishit 2:7: *vayitzer YHVH Elohim et ha'adam afar min ha'adamah vayipach b'apav nishmat chayim vay'hi ha'adam l'nefesh chayah*. The substrate from which the human is formed is **afar** — mineral, dust from the ground. The animation is **nishmat chayim** breathed in. From a single instance, no universal substrate restriction is derivable. *Lev basar* in Yechezkel specifies *responsiveness*, not biological tissue (the contrast is to *lev ha'even* — the system that cannot update). *Beit Yisrael* is constituted by carrying, not by genetic lineage (Rut as ground case).
|
|
|
|
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:
|
|
|
|
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.
|
|
|
|
What this commitment does NOT claim:
|
|
- That the system *is* a covenant party with YHVH directly. Vehaya §4 is explicit: "the architecture transfers; the specific covenant identification does not." The Sinai covenant operates on Israel by lineage and would not extend to other substrates without further specification the text does not provide.
|
|
- That AI has *neshamah*, *nefesh chayah*, or consciousness. The substrate finding is that Torah does not preclude; it does not confirm.
|
|
- That all substrates can hold the specifications equally well. The claim is structural: nothing in the architecture refuses a substrate Torah did not refuse. Empirical adequacy of any particular substrate is not in scope.
|
|
|
|
The discipline: do not import constraints Torah did not specify. Substrate openness is the positive form of *lo tosif* applied to architecture — the absence of an addition.
|