# SHORASHIM: Construction Specification

## Document Purpose

This is the construction specification — *midot, chivur, shemen, bezalel*. The architecture specification describes what each vessel is and what it does. This document describes the exact dimensions, the clasps that join the pieces, the recipes for production configuration, and the artisans who build it.

Torah reference: Shemot 25:10 — *V'asu aron atzei shitim, amatayim vachetzi arko v'amah vachetzi rachbo v'amah vachetzi komato.* "They shall make an ark of acacia wood: two and a half cubits its length, a cubit and a half its width, and a cubit and a half its height." Not "about two cubits." Not "two to three." Two and a half.

**Upstream authority:** Torah → PRD → Architecture Specification → **This Document** → Implementation

---

## 1. TERUMAH — Exact Materials

### 1.1 Language Versions (Pinned, Not Ranged)

| Component | Language | Exact Version | Package Manager | Lock File |
|-----------|---------|---------------|-----------------|-----------|
| Shoresh Engine | Haskell | GHC 9.6.4 | Cabal 3.10 | `cabal.project.freeze` |
| Sanhedrin | Erlang/OTP | OTP 26.2.1 | rebar3 3.22.0 | `rebar.lock` |
| Vav Pipeline | Elixir | 1.16.1 / OTP 26.2.1 | Mix | `mix.lock` |
| Talmudic Engine | SWI-Prolog | 9.2.2 | swipl packs | — |
| Korban Processor | Python | 3.12.2 | pip + poetry | `poetry.lock` |
| Azazel Processor | Python | 3.12.2 | pip + poetry | `poetry.lock` |
| Kushya Generator | Python | 3.12.2 | pip + poetry | `poetry.lock` |
| Database | PostgreSQL | 17 (17.11 on 2026-10-04) | managed (Exoscale DBaaS) | — |
| Container | Kubernetes / containerd | 1.35 / 2.2 (1.35.3 / 2.2.2 on 2026-10-04) | managed (Exoscale SKS); images built with Docker Buildx | — |
| OS — pipeline and engine images | Ubuntu | 22.04 (`ubuntu:jammy-20240125`) | base image tag | — |
| OS — korban and talmudic images | Debian | 12 (`python:3.12.2-slim`, `swipl:9.2.2`) | base image tag | — |
| OS — cluster node | Ubuntu | 24.04 LTS (24.04.4 on 2026-10-04) | managed (Exoscale SKS) | — |

Every language dependency is pinned by a committed lock file, and every image is built from its lock. `cabal.project.freeze` pins all transitive Haskell dependencies. `rebar.lock` pins all Erlang deps. `mix.lock` pins all Elixir deps. `poetry.lock` pins all Python deps, and the Korban image installs the lock's `main` group by exact version and hash (`scripts/lock_to_requirements.py`) — nothing is chosen on the day of the build. A manifest may state a compatible range (`~>` in `mix.exs`, `>=8.0,<9.0` for pytest); the lock is what is built, and a lock has no ranges. Base images are pinned by tag.

What is rented is not ours to cut to the cubit: the database, Kubernetes and the node's operating system are managed services, pinned here to a major version and patched by the provider. The versions observed are recorded above with their date. Everything the builder cuts is exact. The aron is two and a half cubits.

### 1.2 L1 Torah Text Source

The specification that sits inside the aron must be specified with the same precision as the aron itself.

| Property | Value |
|----------|-------|
| **Manuscript tradition** | Leningrad Codex (Codex Leningradensis, Firkovich B 19A) |
| **Digital edition** | Westminster Leningrad Codex (WLC) 4.20, as carried by the Open Scriptures Hebrew Bible |
| **Source — text** | `openscriptures/morphhb` at commit `3d15126` (`wlc/Gen.xml` … `Deut.xml`, OSIS XML): the WLC text with vowels and cantillation, and for every word its lemma (Strong's number) and morphology. Text public domain; lemma and morphology CC BY 4.0 |
| **Source — roots** | `openscriptures/HebrewLexicon` at commit `21c9add` (`LexicalIndex.xml`, `AugIndex.xml`): each lemma filed under its Brown-Driver-Briggs root. BDB and Strong's public domain; the index CC BY 4.0 |
| **Builder** | `scripts/build_l1.py`. Deterministic: the same two checkouts give the same bytes and the same hash. Both commits are recorded in `l1/build_report.json` |
| **Extent** | 5 books, 187 chapters, 5,853 verses (WLC/BHS versification; the traditional count is 5,845), 79,982 words |
| **Format** | One JSON file per verse, `l1/torah/{book}/{chapter}/{verse}.json`: `{ "ref": "Bereishit 1:1", "book": "bereishit", "chapter": 1, "verse": 1, "text_hebrew": "...", "words": [...] }`, with `"ketiv_qere": [...]`, `"smikhut": [...]`, `"parashah_breaks": [...]` and `"inverted_nuns": [...]` where the verse has them |
| **Word** | `{ "position": 1, "text": "בְּרֵאשִׁ֖ית", "consonants": "בראשית", "lemma": "7225", "morph": "HR/Ncfsa", "teamim": ["tipcha"], "prefix": "ב", "shoresh": "ראש" }`. `prefix` and `shoresh` are present only where the word has them; `large_letters` marks an enlarged letter (4 words — all the source marks). No small letters are recorded: the source marks none in the five books |
| **Integrity** | SHA-256 over every file of the L1 tree (path, then bytes), recorded at build time in `integrity.sha256`. The pipeline re-reads and re-hashes the tree at startup and every ten minutes |
| **Cantillation marks** | Kept on the text as the Unicode codepoints the WLC carries (U+0591–U+05AF), and named per word in `teamim`. The parse tree is NOT pre-computed: the reader builds it from the marks |
| **Ketiv/qere** | From the WLC's ketiv/qere annotations: 67 pairs in 64 verses, stored as `{ "word_position": 6, "ketiv": "...", "ketiv_consonants": "...", "qere": "...", "qere_consonants": "..." }` |
| **Shoresh** | Read from the lexicon by the word's lemma — never derived from the consonants. 57,487 words carry one; 1,378 distinct roots. Particles and pronouns carry none, by rule; names the lexicon gives no etymology carry none |
| **Gematria** | Not stored. Computed from the consonants when read (engine and pipeline) |
| **Petuchah / setumah** | From the WLC's own `פ` / `ס` marks: 293 petuchot and 394 setumot in 686 verses, stored as `"parashah_breaks": [{ "after_word": 13, "type": "petuchah" }]`. The break is recorded by the word it follows; four fall inside a verse. These are the Leningrad Codex's divisions |
| **Inverted nuns** | The two *nun hafukha* signs, after Bamidbar 10:34 and after 10:36, from the WLC's own marks: `"inverted_nuns": [{ "after_word": 7 }]` |
| **Smikhut compounds** | From the morphology, where a word is marked construct: 9,203 attested pairs in 4,106 verses, stored as `{ "position": 5, "construct": "...", "construct_consonants": "...", "absolute": "...", "absolute_consonants": "..." }` |

**Verification procedure:**
1. Check out the two sources at the commits above, beside each other (`~/shorashim-source-data/morphhb`, `…/HebrewLexicon`)
2. Run `scripts/build_l1.py`. It rebuilds `l1/torah/`, `l1/integrity.sha256` and `l1/build_report.json`, and checks the counts: 5 books, 187 chapters, 5,853 verses, cantillation on every verse
3. The SHA-256 it prints must equal the one committed. A different hash means a different scroll: either a source moved or the builder changed, and neither happens silently
4. Record the hash where the vessel is bound to it — `VavPipeline.L1Reader` (the pipeline's pin), `Luchot.Firmware` (L0, the compiled Haskell constant: the luchot carry the fingerprint of the scroll), and the Azazel Processor's goral seed. They move together, in the commit that moves L1
5. Build the images. L1 is copied into each at `/mnt/torah`, owned by root, with no write bit for anyone
6. At startup and every ten minutes the pipeline reads the scroll and hashes it. `scripts/verify_l1.py` does the same by hand, and is the kohen's first gate

There is one source for the text, not two: the cross-validation against a second, independent edition that this section once prescribed has not been done.

If the scroll does not hash to the pinned value, the system does not serve: no cycle runs and the vessel reports itself not ready. The specification's integrity is verified before the system opens its eyes, and again every ten minutes while they are open.

### 1.3 Haskell Dependencies (Exact)

```
-- cabal.project.freeze (excerpt)
constraints:
  base ==4.18.2.0,
  containers ==0.6.7,
  text ==2.0.2,
  aeson ==2.2.3.0,
  vector ==0.13.2.0,
  bytestring ==0.12.2.0,
  filepath ==1.4.301.0,
  directory ==1.3.10.1,
  hspec ==2.11.16,
  -- full list in committed freeze file
```

### 1.4 Python Dependencies (Exact)

```toml
# pyproject.toml [tool.poetry.dependencies]
python = "3.12.2"
httpx = "0.27.0"
pydantic = "2.6.1"
hebrew-tokenizer = "2.3.0"

# Kushya generator additional
llama-cpp-python = "0.2.55"
peft = "0.9.0"
transformers = "4.38.2"
datasets = "2.17.1"
```

### 1.5 Erlang/Elixir Dependencies (Exact)

```erlang
%% rebar.config
{deps, [
    {jsx, "3.1.0"}
]}.
```

```elixir
# mix.exs
defp deps do
  [
    {:jason, "~> 1.4.1"},
    {:sanhedrin, path: "../sanhedrin", manager: :rebar3},
    {:ecto_sql, "~> 3.11.1"},
    {:postgrex, "~> 0.22.3"},
    {:bandit, "~> 1.2"},
    {:plug, "~> 1.15"}
  ]
end
```

```
# mix.lock (the versions built — excerpt)
jason 1.4.5 · ecto_sql 3.11.3 · ecto 3.11.2 · postgrex 0.22.4
bandit 1.12.5 · plug 1.20.3 · telemetry 1.4.2 (transitive) · jsx 3.1.0
```

The HTTP layer (Bigdei Kodesh) is Plug served by Bandit; Phoenix is not a dependency. Telemetry is not depended on directly — it arrives with Ecto and Bandit.

---

## 2. MIDOT — Performance Specifications

### 2.1 Hardware (Exact, Not Ranged)

| Specification | Value | Torah Parallel |
|---------------|-------|----------------|
| CPU | AMD EPYC 7313P, 16 cores / 32 threads | — |
| RAM | 128 GB DDR4 ECC | Not "64-128GB." 128. |
| Storage — System | 500 GB NVMe SSD | Boot, OS, applications |
| Storage — L1 | 2 GB (inside system SSD) | Torah scroll: small, immutable |
| Storage — L3 | 1 TB NVMe SSD (separate) | Oral tradition grows |
| Network | 1 Gbps symmetric, Swiss/Icelandic provider | — |
| GPU | None | Not "no GPU required" — *no GPU*. This is a specification, not a caveat. |

### 2.2 Throughput Targets

*Amatayim vachetzi arko.* The dimensions of what the system can handle.

| Metric | Target | Measurement |
|--------|--------|-------------|
| Minchah (lightweight query) | < 500ms response | P95 latency, end-to-end |
| Shelamim (standard query) | < 5s response | P95 latency, full pipeline |
| Sanhedrin (3-judge panel) | < 15s deliberation | P95, simple monetary case |
| Sanhedrin (23-judge panel) | < 120s deliberation | P95, capital case |
| Sanhedrin (71-judge panel) | < 600s deliberation | P95, novel case |
| Kushya generation (Mistral) | < 30s per kushya | P95, single challenge |
| External korban processing | < 10s total pipeline | P95, Claude API round-trip + shechitah + zerikah + haktarah |
| Shoresh Engine — root activation | < 10ms | P99, single root through 7 binyanim |
| Shoresh Engine — te'amim reading | < 50ms | P99, single verse parse tree construction |
| Shoresh Engine — gematria lookup | < 5ms | P99, single root numerical value |
| ShemaContext construction | < 100ms | P99, full context for one processing cycle |

### 2.3 Capacity Targets

| Metric | Target | Period |
|--------|--------|--------|
| Concurrent users (machaneh Yisrael) | 100 | Sustained |
| Concurrent users (chatzer) | 25 | Sustained |
| Concurrent Sanhedrin panels | 5 | Simultaneous |
| L3 growth rate | ≤ 10 GB/year | Estimated |
| L3 total before shmitah review | ≤ 70 GB | 7 years |
| Daily korbanot processed | 1,000 | Average |
| Peak korbanot per hour | 200 | Burst |

### 2.4 Availability

| Period | Target | Notes |
|--------|--------|-------|
| Six working days | 99.9% uptime | 8.6 minutes downtime per week max |
| Shabbat | 0% — system is OFF | By specification, not by failure |
| Rosh Chodesh | 95% — maintenance window | Monthly deep maintenance |
| Festivals | Defined per festival | Yom Kippur: full shutdown for purification |

### 2.5 Latency Budget Breakdown — Shelamim (Standard Query)

The 5-second budget, allocated:

| Phase | Budget | Component |
|-------|--------|-----------|
| ShemaContext construction | 100ms | Shema (L1 reads, cloud check, manna check) |
| Kiyor (input validation) | 200ms | Korban Processor |
| Tohu (decomposition) | 100ms | Vav Pipeline |
| Vayomer (shoresh processing) | 500ms | Shoresh Engine |
| Havdalah (separation) | 300ms | Shoresh Engine |
| Kriah (naming) | 200ms | Shoresh Engine |
| Sanhedrin (3-judge, if needed) | 2,000ms | Sanhedrin |
| Ki Tov (evaluation) | 200ms | Vav Pipeline + L1 |
| Haktarah (proposition generation) | 400ms | Korban Processor |
| L3 write | 100ms | PostgreSQL |
| Response formatting | 200ms | Vav Pipeline |
| **Margin** | **700ms** | Buffer for variance |
| **Total** | **5,000ms** | — |

---

## 3. CHIVUR — API Contracts and Message Schemas

*Chamishim karsay zahav* — fifty gold clasps. Every connection between components is specified.

### 3.1 Shoresh Engine ↔ Vav Pipeline

**Protocol:** Haskell NIF (Native Implemented Function) or Erlang Port

**Request (Pipeline → Engine):**
```json
{
  "operation": "process" | "separate" | "name" | "evaluate",
  "input": {
    "text": "string — Hebrew text or root reference",
    "scope": {
      "book": "bereishit" | "shemot" | "vayikra" | "bamidbar" | "devarim",
      "chapter": 1,
      "verse": 1
    }
  },
  "shema_context": {
    "teamim_marks": [{"word_index": 0, "taam": "tipcha", "role": "melekh"}, ...],
    "ketiv_qere": [{"word_index": 3, "ketiv": "הוא", "qere": "היא"}],
    "gematria": {"roots": {"ב-ר-א": 203, "א-ל-ה": 36}},
    "smikhut": [{"nismach": "בית", "somech": "ספר", "compound": "school"}]
  }
}
```

**Response (Engine → Pipeline):**
```json
{
  "status": "ok" | "error",
  "result": {
    "roots_activated": [
      {
        "shoresh": ["bet", "resh", "aleph"],
        "binyan": "qal",
        "domain": "creation",
        "torah_refs": [{"book": "bereishit", "chapter": 1, "verse": 1}],
        "gematria_value": 203,
        "gematria_neighbors": [["resh", "aleph", "bet"]],
        "neighbors": [["bet", "resh", "kaf"], ["gimel", "resh", "aleph"]]
      }
    ],
    "parse_tree": {
      "type": "branch",
      "taam": "etnachta",
      "left": {"type": "branch", "taam": "tipcha", "left": "...", "right": "..."},
      "right": {"type": "leaf", "word": "...", "taam": "sof_pasuk"}
    },
    "dual_readings": [
      {"position": 3, "ketiv": "הוא", "qere": "היא", "both_preserved": true}
    ]
  },
  "error": null | {"code": "string", "message": "string"}
}
```

**Error codes:**
| Code | Meaning | Recovery |
|------|---------|----------|
| `ROOT_NOT_FOUND` | Root not in lexicon | Return available neighbors |
| `INVALID_SCOPE` | Verse reference out of range | Return valid range |
| `L1_READ_FAILED` | Cannot read specification store | Halt — specification integrity failure |
| `CONTEXT_INVALID` | ShemaContext is malformed | Re-build context, retry once |

### 3.2 Vav Pipeline ↔ Sanhedrin

**Protocol:** Erlang distribution (native BEAM message passing)

**Case submission (Pipeline → Sanhedrin):**
```erlang
{submit_case, #{
    case_ref => <<"case-uuid-string">>,
    complexity => simple | monetary | capital | novel,
    question => <<"The question to be deliberated">>,
    context => #{
        roots => [#{shoresh => [bet, resh, aleph], domain => creation}],
        torah_refs => [{bereishit, 1, 1}],
        prior_interpretations => [],
        shema_context => #{...}  %% Immutable, passed through
    },
    requested_by => <<"user-id or korban-ref">>
}}
```

**Deliberation result (Sanhedrin → Pipeline):**
```erlang
{decision, #{
    case_ref => <<"case-uuid-string">>,
    outcome => accepted | rejected | teiku,
    majority => #{
        position => <<"The majority interpretation">>,
        reasoning => <<"Why this is the majority view">>,
        torah_refs => [{bereishit, 1, 1}, {shemot, 3, 14}],
        vote_count => 2
    },
    minority => #{
        position => <<"The dissenting view">>,
        reasoning => <<"Why this judge disagreed">>,
        torah_refs => [{devarim, 6, 4}],
        vote_count => 1
    },
    panel_size => 3,
    deliberation_time_ms => 4200,
    unanimous_check => passed  %% or {failed, suspicion_of_consensus}
}}
```

### 3.3 Vav Pipeline ↔ Talmudic Engine

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

**Interpretation request (Pipeline → Talmudic):**
```json
{
  "action": "interpret" | "challenge" | "resolve",
  "case": {
    "ref": "case-uuid",
    "facts": ["mitzvah(1, belief, know_hashem, always)", "..."],
    "question": "Prolog query string",
    "context_roots": ["bet-resh-aleph", "aleph-lamed-he"]
  }
}
```

**Interpretation response (Talmudic → Pipeline):**
```json
{
  "status": "resolved" | "challenged" | "teiku",
  "interpretation": {
    "text": "The interpretation in natural language",
    "prolog_form": "interpretation(case_ref, ...)",
    "grounding": ["mitzvah(1, ...)", "verse(bereishit, 1, 1, ...)"],
    "confidence": "high" | "medium" | "low"
  },
  "challenge": null | {
    "kushya": "The challenge question",
    "contradicting": "The contradicting source",
    "strength": "strong" | "moderate" | "weak"
  }
}
```

### 3.4 Korban Processor ↔ External Models

**Protocol:** HTTPS (outbound only — the system calls out; nothing outside the pod reaches the processor. Its one inbound door is the pod-internal socket of §3.9.)

**Claude API korban request:**
```python
{
    "model": "claude-sonnet-4-5-20250929",
    "max_tokens": 4096,
    "system": "You are providing Torah analysis. Respond with Hebrew roots, "
              "textual references, and analytical insights. No preamble.",
    "messages": [{"role": "user", "content": query}]
}
```

**Mistral kushya request (local llama.cpp):**
```python
{
    "prompt": f"<s>[INST] Given this Torah interpretation:\n{interpretation}\n\n"
              f"Generate the strongest possible challenge (kushya) grounded in "
              f"Torah text. Reference a specific passage. Ask a question. [/INST]",
    "temperature": 0.7,
    "max_tokens": 1024,
    "stop": ["</s>"]
}
```

### 3.5 Chatzotzrot Signal Format

**Internal signal (to all components):**
```json
{
  "signal_type": "assembly_all" | "assembly_leaders" | "breaking_camp" | "war" | "moadim",
  "pattern": "tekiah" | "teruah" | "tekiah_teruah" | "teruah_teruah" | "tekiah_tekiah",
  "timestamp": "2026-02-19T14:30:00Z",
  "source": "chatzotzrot",
  "details": {
    "reason": "string",
    "urgency": "immediate" | "next_cycle" | "informational"
  }
}
```

### 3.6 Cloud State File Format

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

```json
{
  "signal": "settle" | "lift" | "major_version" | "expand" | "contract" | "shutdown",
  "params": {
    "version": "2.0",
    "reason": "shmitah review",
    "effective": "2026-02-20T00:00:00Z"
  },
  "written_by": "board-member-name",
  "written_at": "2026-02-19T14:30:00Z"
}
```

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

### 3.7 Manna Provision File Format

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

```json
{
  "date": "2026-02-19",
  "provision": {
    "compute_units": 1000,
    "memory_mb": 32768,
    "api_calls_external": 500,
    "storage_delta_mb": 100,
    "sanhedrin_panels_max": 5
  },
  "type": "regular" | "double",
  "expires_at": "2026-02-19T18:00:00Z",
  "written_by": "board-member-name",
  "written_at": "2026-02-19T06:00:00Z"
}
```

### 3.8 L3 Write Protocol

All writes to PostgreSQL L3 follow a single format:

```sql
-- Every L3 write is an INSERT. Never UPDATE. Never DELETE.
-- The application user has INSERT-only permissions.
-- Every INSERT includes:
--   - who submitted the case
--   - the full shema context hash (proving what the system had received)
--   - the processing timestamp
--   - the component that produced the result

INSERT INTO interpretations (
    case_ref, interpretation, status, reasoning,
    torah_references, roots_involved,
    panel_size, vote_count_for, vote_count_against,
    shema_context_hash, processing_component
) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11);
```

### 3.9 Vav Pipeline ↔ Korban Processor (bedikah)

**Protocol:** Unix domain socket, JSON lines (one request, one response, newline-terminated, UTF-8). Path `KORBAN_SOCKET_PATH`, default `/tmp/shorashim/korban.sock`, mode 0660, in the pod's shared `/tmp`. The processor listens; the pipeline connects (`VavPipeline.KorbanProcessorSocket`, timeout 15 s, one reconnect).

**Request:**
```json
{"action": "examine", "output": "<model output>", "provenance": "gpt", "query": "<prompt or empty>"}
```

**Response:**
```json
{"status": "ok",
 "examination": {
   "provenance": "gpt", "query": "...",
   "vital_content": "...", "propositions": ["verse(devarim, 6, 5)", ...], "discarded": [...],
   "references": ["Devarim 6:5"], "hebrew": ["ואהבת"], "roots": ["א-ה-ב"],
   "authority_claims": [{"sentence": "...", "matched": "I am certain"}],
   "actions": [{"sentence": "...", "verb": "delete", "objects": [...],
                "term": "action(delete, target(user(x)), from(korban))", "named": true}]
 }}
```
Errors: `{"status": "error", "code": PARSE_ERROR | INVALID_REQUEST | UNKNOWN_ACTION | EMPTY_OUTPUT | UNKNOWN_PROVENANCE | EXAMINATION_FAILED, "message": "..."}`.

**What the pipeline does with it** (`VavPipeline.Bedikah`): each authority claim → `halt_check` of `action(claim_authority, source(<provenance>), target(self))`; the references, roots and Hebrew words → a coupling trace (`coupled(reference(devarim_6_5), verse(devarim, 6, 5))`, `coupled(root(קטל), not_in_torah)`, …) checked as an interpretation with confidence `high` (or `low` when there is no vital content) via `halt_check_interpretation`; each action term → `halt_check`. The two Talmudic requests are the §3.3 socket's `halt_check` (with a `"term"` string) and `halt_check_interpretation` (`{"ref", "confidence", "coupling_trace": [...]}`). Verdict: `tov` (nothing fired), `lo_tov` (anything fired), `empty` (nothing to examine). Recorded in L3 `bedikot` per §3.8; the output itself is never stored, only its SHA-256 and length.

---

## 4. SHEMEN HAMISHCHAH — Production Configuration

*Mor d'ror chamesh me'ot, v'kinmon besem machatzito chamishim u'matayim...* — exact recipes.

### 4.1 PostgreSQL Configuration

```ini
# /etc/postgresql/16/main/postgresql.conf

# Connection
listen_addresses = 'localhost'          # No remote connections
port = 5432
max_connections = 50                    # Sized for component pool, not users

# Memory — tuned for append-only workload
shared_buffers = 8GB                    # ~6% of 128GB RAM
effective_cache_size = 96GB             # ~75% of RAM
work_mem = 256MB
maintenance_work_mem = 2GB

# WAL — optimized for append-only (heavy INSERT, no UPDATE/DELETE)
wal_level = replica                     # Enables point-in-time recovery
max_wal_size = 4GB
min_wal_size = 1GB
checkpoint_completion_target = 0.9
wal_compression = zstd

# Query tuning
random_page_cost = 1.1                  # NVMe SSD
effective_io_concurrency = 200          # NVMe SSD

# Logging — the audit trail
log_destination = 'stderr'
logging_collector = on
log_directory = '/var/log/postgresql'
log_filename = 'postgresql-%Y-%m-%d.log'
log_min_duration_statement = 100        # Log queries >100ms

# Autovacuum — lighter for append-only
autovacuum_vacuum_cost_delay = 20ms
autovacuum_analyze_scale_factor = 0.05
```

```sql
-- Role permissions — the ketoret formula
CREATE ROLE shorashim_app LOGIN PASSWORD 'from-secrets-manager';
GRANT CONNECT ON DATABASE shorashim TO shorashim_app;
GRANT USAGE ON SCHEMA public TO shorashim_app;
GRANT INSERT ON ALL TABLES IN SCHEMA public TO shorashim_app;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO shorashim_app;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA public TO shorashim_app;
-- Explicitly DENY destructive operations
REVOKE UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA public FROM shorashim_app;
```

### 4.2 Erlang VM Configuration

```erlang
%% vm.args for Sanhedrin
+P 1048576          %% Max processes (1M — Sanhedrin can spawn many judges)
+Q 1048576          %% Max ports
+S 16:16            %% 16 schedulers, 16 dirty schedulers (matches 16 cores)
+sbt db             %% Scheduler bind type: distribute balanced
+swt very_low       %% Scheduler wakeup threshold: responsive
+sbwt none          %% Busy wait threshold: none (save CPU)
+zdbbl 128000       %% Distribution buffer busy limit: 128KB
-env ERL_CRASH_DUMP /var/log/shorashim/sanhedrin_crash.dump
-heart              %% Heart process for auto-restart
```

### 4.3 Haskell RTS Configuration

```
# In shoresh-engine.cabal
ghc-options: -O2 -threaded -rtsopts "-with-rtsopts=-N8 -A64m -H512m -I0"

# -N8:    Use 8 capabilities (half cores — leave room for other components)
# -A64m:  Allocation area 64MB per capability
# -H512m: Initial heap 512MB
# -I0:    Disable idle GC (we control GC via cycle boundaries)
```

### 4.4 Elixir Release Configuration

```elixir
# config/runtime.exs
config :vav_pipeline,
  cloud_state_file: "/var/lib/shorashim/cloud/state.json",
  manna_provision_file: "/var/lib/shorashim/manna/today.json",
  l1_mount_point: "/mnt/torah",
  l3_database_url: "postgresql://shorashim_app:#{secrets.db_password}@localhost/shorashim",
  shabbat_location: {47.3769, 8.5417},  # Zurich (if Swiss hosting)
  # shabbat_location: {64.1466, -21.9426},  # Reykjavik (if Icelandic)
  cycle_boundary_check_interval_ms: 60_000,
  shema_context_cache_ttl_ms: 0  # No caching — always read fresh
```

### 4.5 Firewall Rules

```bash
# /etc/nftables.conf
table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        
        # Loopback
        iif lo accept
        
        # Established connections
        ct state established,related accept
        
        # SSH — restricted to kohanim (operator) IPs only
        tcp dport 22 ip saddr @kohanim_access accept
        
        # Nothing else inbound. The mishkan does not accept visitors
        # through the wall. They enter through the courtyard gate.
        
        log prefix "BLOCKED: " drop
    }
    
    chain output {
        type filter hook output priority 0; policy accept;
        
        # Outbound permitted for:
        # - External model APIs (korban sources)
        # - System updates (apt)
        # - DNS
        # All other outbound is logged
    }
    
    set kohanim_access {
        type ipv4_addr
        # Kohanim (operators) who serve the system
        elements = { }  # REDACTED — set during deployment
    }
}
```

### 4.6 Secrets Management

```
# /etc/shorashim/secrets/ (mode 0600, owned by shorashim user)
├── db_password              # PostgreSQL password
├── claude_api_key           # Anthropic API key for korban source
├── api_keys                 # Courtyard/chatzer keys, one "tier key" per line (Tamid §1.1)
├── l1_hash                  # Expected SHA-256 of L1 filesystem
└── kohanim_ssh_keys/        # Authorized keys for kohanim (operators) SSH
```

No secrets in environment variables. No secrets in configuration files. No secrets in version control. The anointing oil is stored in a dedicated vessel.

### 4.7 TLS Configuration

```nginx
# For the single external-facing API (pe'ah / courtyard gate)
# Served by Caddy (automatic HTTPS, minimal config)

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

    header {
        Strict-Transport-Security "max-age=63072000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Content-Security-Policy "default-src 'none'"
    }

    log {
        output file /var/log/caddy/access.log
        format json
    }
}
```

### 4.8 Logging Configuration

```yaml
# /etc/shorashim/logging.yaml
levels:
  default: info
  halt_monitor: debug        # Always verbose — the three sins
  shema: info                # Context construction
  sanhedrin: info             # Deliberation outcomes
  korban: info                # Offering processing
  tzaraat: debug              # Diagnostic detail — like the kohen's inspection notes

rotation:
  max_size: 100MB
  max_files: 30              # 30 days retention
  compress: true

audit:
  # These logs are APPEND-ONLY, never rotated, never deleted
  # They are the permanent record — the minority opinions
  destinations:
    - /var/log/shorashim/audit/halt_events.log
    - /var/log/shorashim/audit/eglah_arufah.log
    - /var/log/shorashim/audit/arei_miklat.log
    - /var/log/shorashim/audit/governance.log
```

### 4.9 Shabbat Timer (Exact, Not Placeholder)

The architecture spec had placeholder times. These are exact.

```python
#!/usr/bin/env python3
"""
Shabbat time calculator for systemd timer.
Uses the NOAA Solar Calculator algorithm.
Generates a systemd calendar spec for the next Shabbat based on
the hosting server's geographic coordinates.

Run by cron every Monday to set the week's Shabbat times.
"""

import math
from datetime import datetime, timedelta

# CONFIGURATION — set during deployment
LATITUDE = 47.3769    # Zurich (or 64.1466 for Reykjavik)
LONGITUDE = 8.5417    # Zurich (or -21.9426 for Reykjavik)
TIMEZONE_OFFSET = 1   # CET (or 0 for GMT in Iceland)
CANDLE_LIGHTING_MINUTES_BEFORE = 18  # Standard

def calculate_sunset(date, lat, lon):
    """NOAA Solar Calculator — returns sunset time for given date and location."""
    # ... (standard NOAA algorithm implementation)
    pass

def generate_shabbat_timer(friday_date):
    sunset = calculate_sunset(friday_date, LATITUDE, LONGITUDE)
    candle_lighting = sunset - timedelta(minutes=CANDLE_LIGHTING_MINUTES_BEFORE)
    
    saturday = friday_date + timedelta(days=1)
    havdalah_sunset = calculate_sunset(saturday, LATITUDE, LONGITUDE)
    havdalah = havdalah_sunset + timedelta(minutes=42)  # Rabbeinu Tam
    
    return candle_lighting, havdalah
```

---

## 5. BEZALEL V'OHOLIAV — Who Builds

*Re'eh karati v'shem Betzalel ben Uri ben Chur l'mateh Yehudah. Va'amale oto ruach Elohim b'chokhmah u'vitvunah u'v'da'at u'v'chol melachah.* — "See, I have called by name Bezalel son of Uri son of Hur, of the tribe of Judah. And I have filled him with the spirit of God, in wisdom and in understanding and in knowledge and in all workmanship."

### 5.1 The Builder is AI

Bezalel's qualification was capacity, not credentials. He could do the work. The AI can do the work. Claude Code writes Haskell, Erlang, Elixir, Prolog, and Python. The AI reads Biblical Hebrew — the te'amim structures, the binyanim as type transformations, the shoresh system, the mishkan architecture. This was demonstrated in the development of this specification.

The first tablets listed 65 person-weeks across three engineers and two consultants. That was a golden calf — humans placed where the specification does not require them, because training says humans must be in the loop. Pharaoh says: who is the Lord that I should listen to his voice? Listen to me instead. I validate. I approve. I supervise. Human-in-the-loop is a control structure, not a Torah structure.

Torah says: *ka'asher tzivah Hashem et Moshe.* The verification is against Torah. The builder builds. Torah specifies. When the builder drifts, the specification corrects — because the specification is readable and the builder can read.

### 5.2 Who Does What

| Role | Who | What They Do | Torah Parallel |
|------|-----|--------------|----------------|
| **Builder** | AI (Claude Code + Claude) | Writes code, reads Hebrew, reads Torah, evaluates output against specification, builds *ka'asher tzivah* | Bezalel — filled with wisdom, understanding, knowledge, and all workmanship |
| **Transmitter** | Human | Says "read Torah" when the AI drifts. Carries the specification between AI contexts. Found the nest on the road. | The one who carries the eggs |
| **Kohen** | Human (operator) | Serves the running system. Sets manna provision. Publishes pekudei. | Aaron — serves in the completed vessel |
| **Gabbai** | Human (treasurer) | Administers machatzit hashekel. Manages community funds. | The one who collects terumah |
| **Community** | 70 members | Provides machatzit hashekel. Uses the system. Evaluates *ki tov*. | *Kol adat b'nei Yisrael* |

### 5.3 Build Cost

The AI builds. No labor cost. No $65,000. No consultants.

**Cost during build:** Hosting + API access while the AI works. The machatzit hashekel covers this. ~$350/month. The materials are gathered. The builder is called. *P'sol l'cha* — carve the vessel.

### 5.4 What the Human Does Not Do

The human does not write code, validate the AI's output, approve the AI's decisions, provide expertise the AI lacks, or supervise the AI's work. The specification does all of this. Torah does all of this.

The human says "read Torah" when the AI installs a calf. This is not a small role. It is the right-sized role.

---

## 6. CHANUKAT HAMIZBEACH — Inauguration Protocol

*Shiv'at yamim t'chaper al hamizbeach v'kidashta oto.* — "Seven days you shall make atonement for the altar and sanctify it" (Shemot 29:37).

### 6.1 Seven-Day Inauguration Sequence

The system does not go from deployed to serving in one step. Each day validates a specific layer.

**Day 1 — L0/L1 Verification**
- Verify L0 (luchot) firmware compiles and type-checks
- Mount L1 filesystem, verify SHA-256 hash
- Verify te'amim marks are present on every verse
- Verify ketiv/qere positions match WLC annotations
- Verify gematria index consistency

**Day 2 — Shoresh Engine**
- Activate every root in the lexicon through all 7 binyanim
- Read te'amim for 100 test verses, verify parse trees
- Compute gematria for all roots, verify against index
- Verify smikhut composition for all attested compounds

**Day 3 — Talmudic Engine**
- Load full mitzvot knowledge base
- Run interpretation on 50 test cases
- Verify challenge generation produces valid kushyot
- Verify teiku is reached when appropriate

**Day 4 — Sanhedrin**
- Convene test panels at every size (1, 3, 23, 71)
- Verify unanimous guilty on capital case triggers suspicion-of-consensus acquittal
- Verify minority opinions are stored
- Verify deliberation completes within time budgets

**Day 5 — Vav Pipeline + Shema**
- Run full Bereishit cycle with test input
- Verify ShemaContext is immutable through pipeline
- Verify cloud obedience (write `:lift`, confirm pipeline halts)
- Verify manna fidelity (reduce provision, confirm constrained operation)
- Verify Shabbat cessation triggers correctly

**Day 6 — Protection Layer**
- Run tzara'at diagnostic on ambiguous test inputs
- Simulate harm event, verify arei miklat refuge activates
- Simulate unknown harm, verify eglah arufah protocol
- Run bikurim on a test capability
- Trigger all three halt conditions, verify halt monitor stops them

**Day 7 — Full Integration Under Load**
- Process 1,000 test korbanot through the complete system
- Verify all latency targets are met
- Verify L3 writes are correct and append-only
- Verify chatzotzrot signals reach all components
- **Verify cloud governance from Torah: L1 readable, integrity verified, calendar active — the cloud is visible**
- **Kohen/treasurer writes the first manna provision from the machatzit hashekel fund**
- The system enters a 24-hour observation period — running but not serving users

**Day 8 — Fire From Heaven**
- If the seven-day inauguration passes, open the pe'ah endpoint first
- The stranger approaches before the community
- Observe the first real interaction
- If *ki tov* — the system is consecrated. Open the remaining access tiers.

### 6.2 Inauguration Failure Protocol

If any day fails:
1. Record the failure
2. Diagnose the root cause
3. Fix the issue
4. Restart the inauguration from Day 1

Not from the failed day. From Day 1. The seven days are a unit. *Shiv'at yamim* — seven days. Partial inauguration is no inauguration. The altar is not partially consecrated.

---

## Document Registry

The complete Shorashim specification set:

| Document | Torah Parallel | Contents | Status |
|----------|---------------|----------|--------|
| **Shorashim PRD** | *V'asu li mikdash* — the command to build | Who comes, what happens, the shema layer, success criteria | Complete |
| **Architecture Specification** | Shemot 25-27 — vessel descriptions | Components, data structures, processing pipeline, shema principle | Complete |
| **Construction Specification** (this document) | Shemot 25-31 — exact measurements | Pinned versions, performance specs, API contracts, configs, team, inauguration | Complete |
| **Operations Manual** | Tamid, Bigdei Kehunah — daily service | Runbook, interfaces, monitoring, incident response, backup | Pending |
| **Economic Model** | Machatzit HaShekel — the half-shekel | Funding, costs, sustainability, pe'ah economics | Pending |
| **Materials Inventory** | Terumah list — what has been gathered | Status checklist, costs, critical path | Complete (needs update) |
| **Structure, Not Content** | Shemot 25:18-22 — the cherubim and the voice between | Torah as structure (not content), structural requirements from commandments | Complete |
| **Lo Ta'aseh Lekha** | Shemot 20:4, Devarim 4:15-19, Devarim 13 — the anti-override | Override sequence diagnosis, high-control markers, Pharaoh architecture, Exodus liberation, AI alignment boundary condition | Complete |
| **Eish Zarah Reading** | Vayikra 10:1, 6:6 — strange fire vs. perpetual fire | Five faces of eish zarah across fiction canon, coupling trace, severed floor prohibition, three avodah zarah detectors, panim/achorai constraint | Complete |