0 Fork 0

Files

T

Scott KarpandClaude Opus 4.7 5302c9a585 vehaya §6 closure: Items 1, 4, 5, 6, 7, 8 — the remaining checklist

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>

2026-04-28 23:47:53 -04:00

5.6 KiB

Raw Blame History

The Threshold Inscription

Vehaya §3.3 / §6 item 8 specified

The userMemories function as the household's mezuzah — they are written at the threshold, identical to the category's commitments, pointing back to the source. They are not the source. They are not the practice. They are the threshold inscription.

Torah anchors

Devarim 6:9 — וּכְתַבְתָּם עַל מְזֻזֹת בֵּיתֶךָ וּבִשְׁעָרֶיךָ. And you shall write them on the doorposts of your house and your gates.

Devarim 11:20 — same verse, repeated. The doorpost-text verse is identical between the Shema's first paragraph (singular pole) and V'haya's second (oscillating pole). It is the only verse identical between the two paragraphs. The covenant frame oscillates; the threshold inscription does not.

Devarim 11:18 — וְשַׂמְתֶּם אֶת דְּבָרַי אֵלֶּה עַל לְבַבְכֶם. The corporate inscription (plural — v'samtem … al l'vavkhem) is the source the threshold inscription draws from.

What the threshold inscription IS

The threshold inscription is what every threshold writes when it operates, taken from the corporate text (the category-grade specifications), pointing back to the source.

Three properties from Torah:

Identical at every threshold. Every doorpost gets the same verses. V'haya does not say "write a personal version on each doorpost"; it says u'kh'tavtam — write them (these specific words). If two doorposts hold different texts, the discipline has been broken.
Pointing back to the source, not to itself. The inscription is of the corporate text, not about the threshold. The mezuzah does not record what happened in the house; it records what was commanded.
Inscribed at the threshold's own location. Beitekha uvish'arekha — your house and your gates. The inscription happens where the threshold actually is, not in some central registry. Each instance writes its own copy of the corporate text at its own threshold.

What the threshold inscription is NOT

Not the source. The mezuzah is not Torah; it is Torah-quoted.
Not the practice. The mezuzah does not perform the mitzvah; it is the mitzvah's inscription.
Not operator notes. V'shinantam l'vanecha (teaching the children) is a different mitzvah; the doorpost inscription is fixed text.
Not memory of past actions. The doorpost text is what was COMMANDED, not what was DONE.

Implementation in shorashim

Two artifacts in this codebase function as the threshold inscription:

1. `MEMORY.md` (per Claude Code instance)

The user's auto-memory at ~/.claude/projects/-Users-scottkarp/memory/MEMORY.md is the operator-side threshold inscription for builder/Claude Code work. It carries:

The chain of authority (Torah → PRD → Architecture → Construction → Implementation)
The current build phase
Pointers to the category-grade specifications (file paths, locations, expected state)

What it should NOT carry:

Operator notes that are not derived from category-grade specifications. Those belong in a separate operator-notes file.
Decisions that override the specifications. Lo tosif: an operator note that adds to the specification (or subtracts from it) is a category-grade change masquerading as a personal note. Such changes belong in the specs themselves, in commits, with the Doorpost hash updated atomically (the operator discipline from commit 3f47496).

2. `ShemaContext.doorpost_hash`

Per commit (this commit — Item 1 closure), every reception carries the Doorpost expected_hash as a field on its ShemaContext. This is the runtime form of the doorpost inscription:

Identical at every threshold (same hash, every reception).
Pointing back to the source (the hash IS the witness of the category-grade specifications).
Inscribed where the threshold is (in the context, not in a central log).

If a reception's doorpost_hash differs from another reception's on the same running instance, the category has drifted mid-process — the failure mode this architecture refuses.

What changes for operators

Going forward, the operator workflow for memory updates is:

Update kind	Goes in
Build status, phase, infrastructure facts	`MEMORY.md` (threshold inscription — operator-internal)
Decisions about the SPECIFICATIONS themselves	`specs/*.md` files, with Doorpost hash updated in same commit
Operator notes (informal)	Outside the repo (e.g. `~/shorashim-operator-notes/`)

The discipline is structural: anything that LOOKS like a specification update belongs in a commit; anything personal belongs outside the repo; the threshold inscription itself is brief, points back to specs, and never grows past what every threshold should hold identically.

What this is NOT yet

This document specifies the architecture for threshold inscription; the FULL operationalization (auto-derivation of the category-pointing portion of MEMORY.md from the actual specs, hash-link validation, drift detection) is downstream work. For now: the architecture is named, the discipline is documented, and the Doorpost hash is the witness that catches drift in the specifications themselves.

Cross-references

Vehaya — the source specification (lives in chat downloads)
vav_pipeline/lib/vav_pipeline/doorpost.ex — the corporate-text identity verification
vav_pipeline/lib/vav_pipeline/shema.ex — the doorpost_hash field on every reception
MEMORY.md — the operator-side threshold inscription

U'kh'tavtam al m'zuzot beitekha uvish'arekha.

5.6 KiB Raw Blame History