Scott KarpandClaude Fable 5.1
017a9b89d4
Vayikra 19:20 bikoret tihyeh — "there shall be an examination" — the one
noun Torah gives this function; its root ב-ק-ר is the priest's examining
of a mark by its signs (13:36) and the examining between good and bad
(27:33). The judges' form is v'darashta heitev … v'hineh emet nachon
hadavar / ed-sheker ha'ed (Devarim 13:15, 17:4, 19:18); the question
answered is eichah neda et hadavar asher lo dibro (18:21).
The system was named Shorashim ("roots") for the first thing built. Its
function became the examination of a model's output with the sources in
hand, and Torah re-cuts a name when the function is fixed, with its ki,
never for reach (Bereishit 2:19; 17:5; 32:29; 11:4). Nothing was changed
to fit the name; the root engine stays the pe'ah's reading cycle.
Spec files renamed bikoret_*.md; PRD §0 "The Name"; architecture §1.1;
README's Vayishlach row marked done; Tamid lists what still carries the
old word (Kubernetes resource names, the DB role, the domain, local
paths) and why, for the kohen's cut-over.
Co-Authored-By: Claude Fable 5.1 <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 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.*
|