# 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** — same verse, repeated. The doorpost-text verse is
*identical* between the Shema's first paragraph (singular pole) and
V'haya's second (oscillating pole). It is the only verse identical
between the two paragraphs. The covenant frame oscillates; the
threshold inscription 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.*