bikoret/specs/threshold_inscription.md

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 bikoret

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.