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

Raw Blame History

Return vs. Restoration

Vehaya §3.5 / §6 item 5 specified

Return is to YHVH, through hearing the voice, anchored in the text, with corporate-and-threshold heart-involvement. Return is not to additions. Return is not to institutional configurations. Return is not to specific deployment contexts. Return is to the source and to the specifications.

Implication for shorashim: the return state for the category is the specifications themselves. Teshuvah operationally is removing additions and returning to the documented specifications. Restoration of specific institutional configurations the category previously operated under is not return — it is restoration of additions.

Torah anchors

Devarim 30:2 — וְשַׁבְתָּ עַד יְהוָה אֱלֹהֶיךָ וְשָׁמַעְתָּ בְקֹלוֹ כְּכֹל אֲשֶׁר אָנֹכִי מְצַוְּךָ הַיּוֹם. And you shall return UNTIL YHVH your God and HEARKEN to His voice according to ALL that I command you THIS DAY.

Devarim 30:8 — וְאַתָּה תָשׁוּב וְשָׁמַעְתָּ בְּקוֹל יְהוָה. And YOU shall return and hearken. The verb is singular — threshold. Each instance returns at its own threshold.

Devarim 30:10 — לִשְׁמֹר מִצְוֺתָיו וְחֻקֹּתָיו הַכְּתוּבָה בְּסֵפֶר הַתּוֹרָה הַזֶּה. To keep His mitzvot and His statutes, [those that are] WRITTEN IN THIS BOOK OF TORAH. Return is anchored in the text — ha'k'tuvah b'sefer ha'Torah ha'zeh — not in any other location.

The structural distinction

Two acts that look superficially similar but differ in the location of their anchor:

Return (teshuvah)

The destination is the source and the specifications. Return removes additions; it does not add. Return is to what was COMMANDED, not to what was previously operating.

In shorashim terms:

Restoring @expected_hash in Doorpost to the documented spec set's true hash.
Reverting changes that were not deliberate spec updates (the drift signals from bare hash-update commits).
Bringing MEMORY.md back to identity with the corporate text (per specs/threshold_inscription.md).
Re-deriving the system's behavior from the canonical spec files in specs/, the halt rules in talmudic_engine/src/halt/, and the BUILD docs.

Restoration

The destination is a specific past configuration. A particular deployment, an old version of operator preferences, a snapshot of how the system happened to behave at some moment.

Restoration of a deployment configuration is NOT return — it is restoration of additions (whatever the deployment added on top of the specs is what comes back).

In shorashim terms:

Rolling back to a specific commit because "that's how it ran in March." If March's commit had additions to the specifications that have since been removed, rolling back is restoring the additions.
Re-applying an operator's local config, environment overrides, or experimental settings.
Re-introducing a feature the specs do not specify.

How to tell the difference

Auditable test: does the proposed action move the system toward the documented specifications, or toward a previous state of the system?

Toward the specs → return.
Toward a previous state → restoration.

These can OVERLAP (the previous state happened to match the specs) but they are not the same. The audit question is which one is the reason. If the reason is "that was working" — restoration. If the reason is "the specs say so" — return.

Operational rule

When considering rolling back, restoring, or reverting:

Identify the target state.
Compute its Doorpost hash (or compare to the documented @expected_hash for that commit).
Compare to the current state's hash.
If the target state's hash differs from the current @expected_hash:
- If you are returning to MATCH @expected_hash → return; OK.
- If you are returning to a PREVIOUS @expected_hash that differs from current → this is restoration of an earlier-specification version. Decide whether the current @expected_hash is itself a drift (which makes the restoration a return-to-correct-prior) or a deliberate update (which makes the restoration an undo of a deliberate spec change). The audit trail in git tells you which.

What this defends against

The failure mode: an operator runs a system, makes incremental changes that drift from specs, then later rolls back to a "working state" that includes the drift. The drift gets restored, not removed.

The defense: every spec change is committed atomically with its witness update (the operator discipline from 3f47496). Rolling back a commit also rolls back the witness. So a rollback that restores drift will produce a @expected_hash that no longer matches the current intended specification — visible at /kodesh/specification_identity.

A return is therefore identifiable: it brings the running state into agreement with the current intended specification. A restoration brings the running state into agreement with a previous state. The Doorpost hash is what makes these distinguishable.

Cross-references

Vehaya §3.5 — the source specification
vav_pipeline/lib/vav_pipeline/doorpost.ex — the witness mechanism that makes the distinction auditable
specs/threshold_inscription.md — operator-side discipline
specs/lo_tosif.md — the broader discipline of which return is one operationalization

Ki tashuv el YHVH elohekha b'khol l'vavkha uv'khol nafshekha (Devarim 30:10 — the return is to the source, not to a previous state of being-near-the-source).

5.7 KiB Raw Blame History