bikoret/specs/shorashim_architecture.md

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 ~500 Biblical Hebrew triliteral roots and seven binyanim as a typed functional system.

Data Structures:

-- 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:

-- 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):

-- === 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:

cd shoresh-engine
cabal init
cabal build

Key files:

shoresh-engine/
├── src/
│   ├── Shoresh/
│   │   ├── Types.hs          -- All data types above
│   │   ├── Lexicon.hs        -- The ~500 roots with entries
│   │   ├── 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:

%% 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:

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:

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:

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:

%% === 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:

# 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:

"""
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
swipl-ffi>=0.1     # Python-Prolog interface (or pyswip)
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:

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):

-- 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):

# 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):

-- 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.

-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_casts 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.

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:

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.

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.

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).

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.

"""
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.

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.

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.

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

# /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

# /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

# /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_calls 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.