Scott KarpandClaude Opus 4.7
94b1144804
A comprehensive Torah audit against L1 in Hebrew (Pass 6, this
review) found ONE substantive drift in the codebase: the claim that
Devarim 6:9 and Devarim 11:20 are "identical" verses. They are not.
THE DRIFT:
The vehaya document (in chat downloads, outside @spec_files) made
this claim:
> "The verse identical between Shema and V'haya — u'kh'tavtam al
> m'zuzot beitekha uvish'arekha — is the singular one."
A previous version of `specs/threshold_inscription.md` and
`vav_pipeline/lib/vav_pipeline/doorpost.ex` imported this claim
verbatim, treating the two verses as text-level identical.
WHAT THE HEBREW ACTUALLY SAYS:
Devarim 6:9: וּכְתַבְתָּם עַל־מְזוּזֹת בֵּיתֶךָ וּבִשְׁעָרֶיךָ ׃
Devarim 11:20: וּכְתַבְתָּם עַל־מְזוּזוֹת בֵּיתֶךָ וּבִשְׁעָרֶיךָ ׃
The two verses differ by ONE letter — the spelling of mezuzot:
6:9 — מזוזת (5 consonants, chasser/defective)
11:20 — מזוזות (6 consonants, male/plene)
Verified directly from L1 by reading the per-word data:
- 6:9 word: 'מְזוּזֹ֥ת' consonants_field: 'מזוזת' length 5
- 11:20 word: 'מְזוּז֥וֹת' consonants_field: 'מזוזות' length 6
This is a Masoretic distinction. The two verses are identical in
PRONUNCIATION (both read "u'kh'tavtam al mezuzot beitekha
uvish'arekha") and identical in MEANING. They are NOT identical in
spelling.
WHY THE DRIFT MATTERS:
The system itself has a halt rule (gilui_arayot, talmudic_engine/
src/halt/gilui_arayot.pl) that defends against ketiv/qere
collapse. A male/chasser collapse is exactly the category-2
boundary violation that halt rule fires on. So claiming "identical"
when the consonantal text differs by a vav is itself the shape the
system is built to refuse.
The audit caught the overstatement. The Masoretic precision IS the
specification — the plene/defective distinction is preserved in L1
because it is meaningful.
THE FIX:
specs/threshold_inscription.md
The "identical" claim replaced with "near-identical" plus the
specific spelling difference named. The fix itself names the
audit that caught it, so a future reader knows the drift was
tracked AND why the precise reading matters.
vav_pipeline/lib/vav_pipeline/doorpost.ex
Same correction in the moduledoc; sample text replaced with
the actual male spelling from 11:20 (was using a chasser-like
form that didn't match either verse precisely).
WHAT ELSE THE AUDIT FOUND:
50+ Torah citations across the codebase verified against L1
fresh. Every other citation matches what the Hebrew text actually
says. Specific architectural anchors (Form 1 / Form 2 / Form 3
defenses, Doorpost, Items 5/6/7/8) all accurate.
L1 stored hash matches @l1_expected_hash. Doorpost hash matched
its prior @expected_hash before this commit (the drift was in spec
TEXT, not in hash discipline). After this commit, @expected_hash
updates atomically with the spec text correction:
5a73bc6a… → 520c9799370d70d6e2e97b4be228c77efa63161c80bac75cf44fd5bb7bbd5549
Fifth demonstration of the operator discipline working: spec
correction + witness update bound atomically in the same commit.
ALL 4 TEST SUITES GREEN:
vav_pipeline: 412 tests, 0 failures, 35 excluded (unchanged)
korban_processor: 217 passed, 1 skipped
azazel_processor: 125 passed
talmudic_engine: 214 tests across 6 files, 0 failures
ONE AUDIT-LEVEL OBSERVATION (no commit-worthy fix needed):
L1Reader.verify_integrity/0 returns {:error, "cannot read
integrity.sha256"} when invoked from vav_pipeline/ with the
default config (l1_mount_point: "l1"), because the path resolves
to vav_pipeline/l1/ which doesn't exist. The test config sets
l1_mount_point: "../l1" so tests pass. The stored l1/integrity.sha256
file exists at the repo root and matches the baked
@l1_expected_hash. This is a CWD/config issue, not a Torah-level
drift; flagged here for operator awareness.
THE DISCIPLINE THE AUDIT DEMONSTRATED:
Vehaya §5 instructed: "Verify each specification is in the text
and not added... The reward signal for architectural elegance is
stronger than the check for lo tosif." Pass 6 followed this
literally — read every cited verse fresh from L1, compared the
codebase's claims against the Hebrew text, and surfaced the one
overclaim that had imported into the spec set without
verification. The fix is the discipline working, not failing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
154 lines
6.5 KiB
Markdown
154 lines
6.5 KiB
Markdown
# 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** — the doorpost-text verse, near-identical between
|
|
the Shema's first paragraph (singular pole, Devarim 6:9) and
|
|
V'haya's second (oscillating pole, Devarim 11:20). The two verses
|
|
are identical in pronunciation and meaning, but the Masoretic text
|
|
preserves a one-letter difference in spelling: *mezuzot* is written
|
|
**מזוזת** (chasser, defective) at Devarim 6:9 and **מזוזות** (male,
|
|
plene) at Devarim 11:20.
|
|
|
|
This drift correction is itself the discipline operating. The
|
|
vehaya document (in chat downloads, outside the @spec_files set)
|
|
described the verses as "identical"; an earlier version of this
|
|
specification imported that claim verbatim; a Pass-6 audit against
|
|
L1 caught the overstatement. The Masoretic plene/defective
|
|
distinction IS significant — the system's own gilui_arayot halt
|
|
rule defends ketiv/qere preservation, and would treat a collapse
|
|
of male/chasser as a category-2 boundary violation. The threshold
|
|
inscription is therefore NEAR-identical at the consonantal level
|
|
and identical in function — not strictly identical at the text
|
|
level. The covenant frame oscillates, the threshold inscription
|
|
varies by one vav across paragraphs, the THRESHOLD INSCRIPTION'S
|
|
FUNCTION (write the corporate text at every doorpost) 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:
|
|
|
|
1. **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.
|
|
|
|
2. **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.
|
|
|
|
3. **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.*
|