bikoret/specs/shorashim_vayakhel.md

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": [...] and "smikhut": [...] 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)
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	Present in the source as paragraph milestones. Not carried into L1: the builder does not read them
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)

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

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

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

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

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

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

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

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

{
  "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, never accepts inbound)

Claude API korban request:

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

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

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

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

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

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

---

4. SHEMEN HAMISHCHAH — Production Configuration

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

4.1 PostgreSQL Configuration

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

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

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

# 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

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

# 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

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

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