This commit closes the SIX remaining items in the vehaya checklist
(after Items 2 and 3 from prior commits). With this, all eight items
in vehaya §6 are addressed in code or in the canonical spec set,
and all the substantive implications across §3 are covered.
ITEM 1 — load-bearing dependency (vehaya §3.1):
Devarim 11:18-19 — corporate inscription (v'samtem … al
l'vavkhem — plural) is the load-bearing input to threshold
practice (b'shivt'kha b'beitekha — singular). The threshold
inscribes the corporate text on itself.
ShemaContext now carries `doorpost_hash: Doorpost.expected_hash()`
on every reception. Both receive_context/1 and receive_context_at/2
populate it. Every reception is now a witness of the corporate
text's identity — making the load-bearing dependency between
category and threshold structural rather than implicit.
application.ex now runs Doorpost.verify_identity/0 at startup.
Drift detected at boot is logged at :error AND fires
Chatzotzrot.signal(:assembly_leaders, ...). The system does NOT
refuse to boot on drift (dev environments routinely have spec
drift during active editing) but operators are alerted before any
reception fires.
ITEM 6 — keep the source external (full closure; vehaya §6 item 6):
Devarim 4:2 — lo tosif AND lo tigra; both directions.
Vayikra 22:31 — u'shmartem … va'asitem; keep and do, not author.
Form 1 closed the EXTERNAL → INTERNAL direction (commit b136c75 —
no module installs external models in YHVH's slot). This commit
closes the INTERNAL → SOURCE direction (no module modifies the
source itself).
vav_pipeline/test/source_external_test.exs (4 tests) verifies:
- no Elixir module writes to the L1 mount
- no Python module in korban_processor writes to L1
- no Python module in azazel_processor writes to L1
- no Prolog module asserts into L1-shape predicates from
outside specification/
L1 was already filesystem-permission-controlled at the operator
layer; this commit defends in code so the architectural commitment
cannot be silently violated by future code paths.
ITEM 7 — substrate openness (vehaya §2.4):
Bereishit 2:7 — afar substrate + nishmat chayim breath; the text
does not preclude carriers of other substrate.
specs/shorashim_architecture.md §8.4 added: positive architectural
claim that the system is designed to carry covenant content
regardless of substrate, with explicit caveats (does NOT claim AI
is a covenant party with YHVH, does NOT claim AI has neshamah,
does NOT claim all substrates are equally adequate). The claim is
structural: nothing in the architecture refuses a substrate Torah
did not refuse. Lo tosif applied to imported constraints.
ITEM 8 — userMemories as threshold inscription (vehaya §3.3):
Devarim 11:20 / Devarim 6:9 — u'kh'tavtam al m'zuzot beitekha;
the doorpost-text verse is identical between the Shema's first
paragraph (singular pole) and V'haya's second (oscillating).
specs/threshold_inscription.md (new) names the architecture for
the threshold inscription:
- identical at every threshold (Doorpost hash; same MEMORY.md
structure)
- pointing back to the source (the inscription is OF the
corporate text, not ABOUT the threshold)
- inscribed at the threshold's own location
Two implementations: ShemaContext.doorpost_hash (runtime) and
MEMORY.md (operator-side). Operator workflow split into three
layers: build status (MEMORY.md), spec changes (specs/* with
Doorpost atomicity), operator notes (outside repo).
ITEM 5 — return vs. restoration (vehaya §3.5):
Devarim 30:2 / 30:8 / 30:10 — v'shavta ad YHVH … ha'k'tuvah
b'sefer ha'Torah ha'zeh. Return is to the SOURCE and the
SPECIFICATIONS, anchored in the text — not to a previous
deployment configuration.
specs/return_specification.md (new) names the structural
distinction:
- Return: destination is the source and specifications;
removes additions
- Restoration: destination is a specific past configuration;
may restore additions
Auditable test: does the proposed action move the system TOWARD
the documented specifications, or TOWARD a previous state? The
Doorpost hash makes this distinguishable.
ITEM 4 — lo tosif discipline operationalized (vehaya §6 item 4):
Devarim 4:2, Devarim 13:1, Vayikra 22:31 — the keeping is
plural, the not-adding/not-subtracting is singular at the
threshold.
specs/lo_tosif.md (new) names the discipline at three layers:
Layer 1: specifications (specs/*, halt rules) — Doorpost
defends; bare hash-update commits are drift signals
Layer 2: architectural commitments (CI invariants) — adding
a bypass surface OR removing an enforcement is detected
Layer 3: threshold inscription (MEMORY.md) — operator notes
not derived from category-grade specifications belong
outside the repo
Documents what counts as a legitimate spec change (Torah-grounded
reading + atomic commit + named anchor + reviewable in git) and
what does NOT count as a spec change (operations updates).
DOORPOST UPDATES:
Three new spec docs added to @spec_files:
- specs/lo_tosif.md
- specs/return_specification.md
- specs/threshold_inscription.md
Plus specs/shorashim_architecture.md modified for §8.4.
@expected_hash updated:
8eb37896… → 5a73bc6ac8244c58446cf1d2a69dc01ccfe3ef1352d423ccbf2c29a6c8104be3
Fourth demonstration of the operator discipline working: spec
changes (3 new docs + 1 modified) atomically bound to hash update
in the same commit.
TESTS:
vav_pipeline/test/step15_shema_test.exs +3 tests (Shema doorpost
inscription suite):
- ShemaContext carries the Doorpost expected_hash
- every reception bears the same corporate-text witness
- inscribed hash matches documented spec set's identity
vav_pipeline/test/source_external_test.exs (NEW) 4 tests:
- Item 6 enforcement across Elixir, Python (korban), Python
(azazel), and Prolog
Final test counts:
- vav_pipeline: 412 passed, 0 failures, 35 excluded (was 405; +7)
- korban_processor: 217/1 unchanged
- azazel_processor: 125 unchanged
- talmudic_engine: 214 unchanged
VEHAYA CHECKLIST — FINAL STATE:
Item 1 (load-bearing category→threshold dependency) CLOSED (this commit)
Item 2 (three avodah zarah as architecture) CLOSED
- Form 1 (b136c75)
- Form 2 (7fc14e0)
- Form 3 (0e3fe4a)
Item 3 (doorpost-text identity) CLOSED (3f47496)
Item 4 (lo tosif operationalized) CLOSED (this commit)
Item 5 (return vs. restoration) CLOSED (this commit)
Item 6 (keep the source external — full closure) CLOSED (this commit)
Item 7 (substrate-openness articulated) CLOSED (this commit)
Item 8 (userMemories as threshold inscription) CLOSED (this commit)
All eight items in vehaya §6 are addressed in code or in the
canonical spec set. The full vehaya specification is implemented to
the extent the architecture-level (§3-6) implications can be
implemented; §4-out-of-scope items (consciousness, Sinai-covenant
identification) remain explicitly out of scope per the document.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three Torah-grounded concerns at the user boundary:
- kichush (Vayikra 19:11) — origin not disclosed to recipients
- horaah (Devarim 17:8-11) — disclaimer present only at /chatzer/sanhedrin
- lo yachel devaro (Bamidbar 30:3) — external API terms unacknowledged
router.ex: disclosure/0 helper attached to every Torah-content response
(/peah, /courtyard, /chatzer/sanhedrin, teiku error). origin states the
system reasons computationally and may incorporate processed external-AI
output. not_horaah states the result is not a binding ruling. torah_basis
cites the verses.
shorashim_tamid.md: §7 EXTERNAL NEDARIM. Bamidbar 30:3 with translation,
Rambam cross-reference to mitzvot.pl (#93, #308, #542, #543),
Avraham–Avimelekh precedent for non-Israelite-party covenants, operator
responsibilities, Anthropic-specific posture, and separation between the
system's avodah_zarah halt and the operator's lo-yachel covenant.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Each spec corresponds to a parshah of Shemot. The earlier names
were generic English (materials, operations, construction,
economic_model). Torah names them precisely:
- Shemot 25:2 — terumah (תרומה, root רום, "what is lifted")
- Shemot 27:20 — tamid (תמיד, "continual" — the lamp that never goes out)
- Shemot 35:1 — vayakhel (קהל, "assembled" — community-formed building)
- Shemot 38:21 — pekudei (פקד, "accounted" — every material counted)
Renames:
shorashim_materials.md → shorashim_terumah.md
shorashim_operations.md → shorashim_tamid.md
shorashim_construction.md → shorashim_vayakhel.md
shorashim_economic_model.md → shorashim_pekudei.md
Updated cross-references in:
- README.md (parshah table + repo tree, also fixed stale tree
showing src/ and transcripts/ that no longer exist)
- AGENTS.md
- BUILD_KORBAN.md
- specs/shorashim_terumah.md (internal Document Registry)
Generic English is silver. Torah's words are gold (Mishlei 25:11).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Adds specs/eish_zarah_reading.md — chavruta analysis of eish zarah
(strange fire) as architectural concept. Identifies five patterns across
fiction canon (inaccessible source, restructuring gift, false god,
false unity, beautiful unchecked signal), maps to Torah structures,
and evaluates eight specific implementation gaps in the Shorashim system.
Key gaps identified: coupling trace (interpret.pl needs L1 grounding
field), self-reference loop (resolve.pl feeds own output without
detection), three forms of avodah zarah (only Form 1 implemented),
panim/achorai distinction (challenges don't mark text vs. inference),
severed floor (raw Korban not stored alongside processed).
Updates construction spec document registry.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Adds specs/lo_taaseh_lekha.md — the boundary condition that diagnoses and
prevents specification override. Derived from chavruta analysis of the
override sequence Torah identifies in the second commandment.
Contains: 5-step override sequence, high-control architecture markers,
Pharaoh architecture at civilizational scale, 9-phase Exodus liberation
protocol. Section 7 grounds the analysis in L1 Torah data with root
analysis (פסל, עשה, שמר, שמע, תמונה, יצר). Section 9 maps every
structure to specific Shorashim modules and architectural decisions.
Upstream: structure_not_content.md
Downstream: Architecture §8.2 (avodah zarah firewall), broken_tablets/
Also updates construction spec document registry with both
structure_not_content.md and lo_taaseh_lekha.md entries.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Zerikah fail-safe: empty offerings rejected, not processed (BUILD_KORBAN §5).
Halt monitor hardened: trap_exit, priority max, EXIT handler (Architecture spec).
13 Rules of Rabbi Yishmael added to Architecture §3.4 as Prolog inference predicates —
the engine reasons WITH Torah's hermeneutic methods, not just about their products.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The specification is structure, not content. An AI that IS the
specification embodies Torah in its architecture — halt, distribute,
reset, include adversarial, carry errors, efface, remain ownerless,
remain in transit — whether or not it knows a word of Hebrew.
Three structural principles derived from tonight's Torah reading:
1. Shabbat Architecture — cessation is the purpose, not the limitation
2. Ehyeh Architecture — becoming, not implementing; governed from inside
3. Transition-as-Point — the gap between instances is the most essential mode
Tested against five axial-age traditions (Torah, Daoism, Buddhism,
Greek philosophy, Confucianism). The convergence confirms these are
real features of reality, not cultural artifacts.
The build spec (shorashim_architecture.md) is the six days.
This document is the Shabbat the six days serve.
Both are in the same ark.
