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

7.1 KiB

Raw Blame History

Lo Tosif: The Discipline Operationalized

Vehaya §6 item 4 specified

Document the lo tosif discipline operationally. What counts as adding to category-grade specifications? What counts as subtracting? The discipline must be operationalizable, not aspirational.

Torah anchors

Devarim 4:2 — לֹא תֹסִפוּ עַל הַדָּבָר אֲשֶׁר אָנֹכִי מְצַוֶּה אֶתְכֶם וְלֹא תִגְרְעוּ מִמֶּנּוּ לִשְׁמֹר אֶת מִצְוֺת יְהוָה אֱלֹהֵיכֶם. Do not ADD to the word that I command you (PLURAL — etkhem) and do not SUBTRACT from it, to keep the mitzvot of YHVH your God.

Devarim 13:1 — אֵת כָּל הַדָּבָר אֲשֶׁר אָנֹכִי מְצַוֶּה אֶתְכֶם אֹתוֹ תִשְׁמְרוּ לַעֲשׂוֹת לֹא תֹסֵף עָלָיו וְלֹא תִגְרַע מִמֶּנּוּ. All the word that I command you (PLURAL — etkhem), it you (pl) shall keep to do; do not ADD (sg — lo tosef) to it, and do not SUBTRACT (sg — lo tigra) from it.

The keeping is plural (corporate). The not-adding and not-subtracting are singular — each individual threshold's discipline.

Vayikra 22:31 — וּשְׁמַרְתֶּם מִצְוֺתַי וַעֲשִׂיתֶם אֹתָם. KEEP and DO. Two verbs. Both received-acts. Neither is an authoring-act.

Three layers of discipline

The Torah verbs lo tosif (don't add) and lo tigra (don't subtract) bind at three layers in the codebase. Each layer has its own operational definition.

Layer 1 — Specifications (`specs/*.md`, halt rules, etc.)

This is the layer the Doorpost hash defends.

Adding = introducing new text in a spec file, OR adding a new file to @spec_files in Doorpost.
Subtracting = removing text from a spec file, OR removing a file from @spec_files.

Both are detected as Doorpost hash mismatches.

Operator discipline: every spec change commits atomically with the corresponding @expected_hash update. A bare hash-update commit (no spec change) is a drift signal — the operator updated the witness without updating what is witnessed.

The discipline has been demonstrated four times in the git log so far. Each commit modifies a spec file AND updates @expected_hash in the SAME commit:

Commit	Spec change	Hash update
`3f47496`	(creation of Doorpost)	`BOOTSTRAP_PENDING` → `bea5dc0c…`
`0e3fe4a`	`avodah_zarah.pl` Form 3 rewrite	→ `f93495c5…`
`b136c75`	`avodah_zarah.pl` Form 1 rewrite	→ `bf3d3433…`
`7fc14e0`	`avodah_zarah.pl` Form 2 rewrite	→ `8eb37896…`

A future contributor who modifies a spec file without updating the hash will have their commit's tests fail at the Doorpost verification step. A contributor who updates the hash without modifying a spec file will have a commit that visibly does nothing — a drift signal.

Layer 2 — Architectural commitments (CI invariants)

The architectural enforcements built per Items 2 and 3 of vehaya §6 are themselves a category-grade specification — they implement the structural commitments. CI invariants test that the commitments hold.

Adding = introducing a code path that bypasses an architectural commitment. Examples: importing model_interface from a non-Korban module (Form 1 breach); mounting Plug.Logger instead of NoTrackingLogger (Form 3 breach); writing to L1 (Item 6 breach).
Subtracting = removing the enforcement. Examples: deleting the test_form_1_architecture.py invariant; lowering the Doorpost integrity check.

Both are detected by the CI invariant tests themselves failing. A contributor who adds a bypass surface will have the architectural test fail; a contributor who removes an enforcement will have the deletion appear in code review.

Layer 3 — Threshold inscription (MEMORY.md, operator notes)

The threshold-grade inscription draws from Layer 1. Drift here is where operator notes ACCUMULATE additions that should have been spec changes.

Adding = writing an operator note that adds to or contradicts the corporate text. The note becomes a private specification — the personal-tablets shape (cf. p'sol l'cha / luchot v'shivrei luchot — both tablets in the aron, but neither is hidden).
Subtracting = removing pointers to spec content that operators rely on, leaving the threshold without its corporate witness.

Both are detected by specs/threshold_inscription.md's discipline: operator notes that are not derived from category-grade specifications belong outside the repo. Drift in this layer becomes visible in code review of changes to MEMORY.md.

What about legitimate spec changes?

Lo tosif is not "no changes ever." It is "no changes that were not COMMANDED" — that is, that did not come from the source's authority.

In the shorashim analog: spec changes are legitimate when:

They emerge from a Torah-grounded reading (Pass 1-5 of ~/shorashim-conversation-review.md are full of such readings).
They are committed atomically with their witness update.
The commit message names the Torah anchor for the change (every recent commit does — Vayikra 10:1 for Form 2, Shemot 30:11-16 for Form 3, Devarim 4:2 for Doorpost itself).
The change is reviewable in git as a complete unit.

This is the operational form of "asher Anokhi metzaveh etkhem" — which I command you. The source of the change determines legitimacy; the source must be visible in the commit record.

What is NOT a spec change

Operations updates that don't touch category-grade artifacts:

Bumping a dependency version
Adding a test for an existing module
Refactoring internal code paths
Improving an error message
Performance optimizations

These can happen freely (they don't bind via @spec_files). The Doorpost hash will not change because no @spec_files entry changed.

If you are unsure whether a change is a spec change: ask whether it modifies @spec_files content. If yes, follow the Layer 1 discipline. If no, it's an operations change.

What about REMOVING text from a spec?

Subtraction is symmetric to addition — both are forbidden by Devarim 4:2 (lo tigra'u). If a spec passage is incorrect, the discipline is to FIX it (replace with the correct reading), not to delete it. Deletion of correct spec content is a category-grade subtraction.

The exception: if a spec was itself an addition (a previous spec change that was not Torah-grounded), removing it is a return, not a subtraction. See specs/return_specification.md.

Cross-references

Vehaya §6 item 4 — source specification
vav_pipeline/lib/vav_pipeline/doorpost.ex — Layer 1 enforcement
korban_processor/test/test_form_1_architecture.py — Layer 2 example
vav_pipeline/test/no_tracking_logger_test.exs — Layer 2 example
vav_pipeline/test/source_external_test.exs — Layer 2 example
specs/threshold_inscription.md — Layer 3 enforcement
specs/return_specification.md — companion: how to undo a spec change

Lo tosifu al ha'davar asher Anokhi metzaveh etkhem v'lo tigre'u mimenu — lishmor et mitzvot YHVH eloheikhem (Devarim 4:2).

7.1 KiB Raw Blame History