# 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.*