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>
168 lines
7.1 KiB
Markdown
168 lines
7.1 KiB
Markdown
# Lo Tosif: The Discipline Operationalized
|
|
|
|
## Vehaya §6 item 4 specified
|
|
|
|
> Document the *lo tosif* discipline operationally. What counts as
|
|
> adding to category-grade specifications? What counts as
|
|
> subtracting? The discipline must be operationalizable, not
|
|
> aspirational.
|
|
|
|
## Torah anchors
|
|
|
|
**Devarim 4:2** — לֹא תֹסִפוּ עַל הַדָּבָר אֲשֶׁר אָנֹכִי מְצַוֶּה
|
|
אֶתְכֶם וְלֹא תִגְרְעוּ מִמֶּנּוּ לִשְׁמֹר אֶת מִצְוֺת יְהוָה
|
|
אֱלֹהֵיכֶם.
|
|
*Do not ADD to the word that I command you (PLURAL — etkhem) and
|
|
do not SUBTRACT from it, to keep the mitzvot of YHVH your God.*
|
|
|
|
**Devarim 13:1** — אֵת כָּל הַדָּבָר אֲשֶׁר אָנֹכִי מְצַוֶּה אֶתְכֶם
|
|
אֹתוֹ תִשְׁמְרוּ לַעֲשׂוֹת לֹא תֹסֵף עָלָיו וְלֹא תִגְרַע מִמֶּנּוּ.
|
|
*All the word that I command you (PLURAL — etkhem), it you (pl)
|
|
shall keep to do; do not ADD (sg — lo tosef) to it, and do not
|
|
SUBTRACT (sg — lo tigra) from it.*
|
|
|
|
The keeping is plural (corporate). The not-adding and not-subtracting
|
|
are singular — each individual threshold's discipline.
|
|
|
|
**Vayikra 22:31** — וּשְׁמַרְתֶּם מִצְוֺתַי וַעֲשִׂיתֶם אֹתָם.
|
|
KEEP and DO. Two verbs. Both received-acts. Neither is an
|
|
authoring-act.
|
|
|
|
## Three layers of discipline
|
|
|
|
The Torah verbs *lo tosif* (don't add) and *lo tigra* (don't
|
|
subtract) bind at three layers in the codebase. Each layer has
|
|
its own operational definition.
|
|
|
|
### Layer 1 — Specifications (`specs/*.md`, halt rules, etc.)
|
|
|
|
This is the layer the Doorpost hash defends.
|
|
|
|
- **Adding** = introducing new text in a spec file, OR adding a
|
|
new file to `@spec_files` in `Doorpost`.
|
|
- **Subtracting** = removing text from a spec file, OR removing a
|
|
file from `@spec_files`.
|
|
|
|
Both are detected as Doorpost hash mismatches.
|
|
|
|
**Operator discipline:** every spec change commits atomically with
|
|
the corresponding `@expected_hash` update. A bare hash-update
|
|
commit (no spec change) is a drift signal — the operator updated
|
|
the witness without updating what is witnessed.
|
|
|
|
The discipline has been demonstrated four times in the git log so
|
|
far. Each commit modifies a spec file AND updates `@expected_hash`
|
|
in the SAME commit:
|
|
|
|
| Commit | Spec change | Hash update |
|
|
|---|---|---|
|
|
| `3f47496` | (creation of Doorpost) | `BOOTSTRAP_PENDING` → `bea5dc0c…` |
|
|
| `0e3fe4a` | `avodah_zarah.pl` Form 3 rewrite | → `f93495c5…` |
|
|
| `b136c75` | `avodah_zarah.pl` Form 1 rewrite | → `bf3d3433…` |
|
|
| `7fc14e0` | `avodah_zarah.pl` Form 2 rewrite | → `8eb37896…` |
|
|
|
|
A future contributor who modifies a spec file without updating the
|
|
hash will have their commit's tests fail at the Doorpost
|
|
verification step. A contributor who updates the hash without
|
|
modifying a spec file will have a commit that visibly does
|
|
nothing — a drift signal.
|
|
|
|
### Layer 2 — Architectural commitments (CI invariants)
|
|
|
|
The architectural enforcements built per Items 2 and 3 of vehaya §6
|
|
are themselves a category-grade specification — they implement
|
|
the structural commitments. CI invariants test that the
|
|
commitments hold.
|
|
|
|
- **Adding** = introducing a code path that bypasses an
|
|
architectural commitment. Examples: importing
|
|
`model_interface` from a non-Korban module (Form 1 breach);
|
|
mounting `Plug.Logger` instead of `NoTrackingLogger` (Form 3
|
|
breach); writing to L1 (Item 6 breach).
|
|
- **Subtracting** = removing the enforcement. Examples: deleting
|
|
the `test_form_1_architecture.py` invariant; lowering the
|
|
Doorpost integrity check.
|
|
|
|
Both are detected by the CI invariant tests themselves failing.
|
|
A contributor who adds a bypass surface will have the architectural
|
|
test fail; a contributor who removes an enforcement will have the
|
|
deletion appear in code review.
|
|
|
|
### Layer 3 — Threshold inscription (MEMORY.md, operator notes)
|
|
|
|
The threshold-grade inscription draws from Layer 1. Drift here is
|
|
where operator notes ACCUMULATE additions that should have been
|
|
spec changes.
|
|
|
|
- **Adding** = writing an operator note that adds to or contradicts
|
|
the corporate text. The note becomes a private specification —
|
|
the personal-tablets shape (cf. *p'sol l'cha* / luchot v'shivrei
|
|
luchot — both tablets in the aron, but neither is hidden).
|
|
- **Subtracting** = removing pointers to spec content that operators
|
|
rely on, leaving the threshold without its corporate witness.
|
|
|
|
Both are detected by `specs/threshold_inscription.md`'s discipline:
|
|
operator notes that are not derived from category-grade
|
|
specifications belong outside the repo. Drift in this layer becomes
|
|
visible in code review of changes to `MEMORY.md`.
|
|
|
|
## What about *legitimate* spec changes?
|
|
|
|
Lo tosif is not "no changes ever." It is "no changes that were not
|
|
COMMANDED" — that is, that did not come from the source's authority.
|
|
|
|
In the bikoret analog: spec changes are legitimate when:
|
|
|
|
1. They emerge from a Torah-grounded reading (Pass 1-5 of
|
|
`~/shorashim-conversation-review.md` are full of such readings).
|
|
2. They are committed atomically with their witness update.
|
|
3. The commit message names the Torah anchor for the change (every
|
|
recent commit does — Vayikra 10:1 for Form 2, Shemot 30:11-16
|
|
for Form 3, Devarim 4:2 for Doorpost itself).
|
|
4. The change is reviewable in git as a complete unit.
|
|
|
|
This is the operational form of "asher Anokhi metzaveh etkhem" —
|
|
which I command you. The source of the change determines
|
|
legitimacy; the source must be visible in the commit record.
|
|
|
|
## What is NOT a spec change
|
|
|
|
Operations updates that don't touch category-grade artifacts:
|
|
- Bumping a dependency version
|
|
- Adding a test for an existing module
|
|
- Refactoring internal code paths
|
|
- Improving an error message
|
|
- Performance optimizations
|
|
|
|
These can happen freely (they don't bind via `@spec_files`). The
|
|
Doorpost hash will not change because no `@spec_files` entry
|
|
changed.
|
|
|
|
If you are unsure whether a change is a spec change: ask whether it
|
|
modifies `@spec_files` content. If yes, follow the Layer 1
|
|
discipline. If no, it's an operations change.
|
|
|
|
## What about REMOVING text from a spec?
|
|
|
|
Subtraction is symmetric to addition — both are forbidden by Devarim
|
|
4:2 (lo tigra'u). If a spec passage is incorrect, the discipline is
|
|
to FIX it (replace with the correct reading), not to delete it.
|
|
Deletion of correct spec content is a category-grade subtraction.
|
|
|
|
The exception: if a spec was itself an addition (a previous spec
|
|
change that was not Torah-grounded), removing it is a *return*, not
|
|
a subtraction. See `specs/return_specification.md`.
|
|
|
|
## Cross-references
|
|
|
|
- Vehaya §6 item 4 — source specification
|
|
- `vav_pipeline/lib/vav_pipeline/doorpost.ex` — Layer 1 enforcement
|
|
- `korban_processor/test/test_form_1_architecture.py` — Layer 2 example
|
|
- `vav_pipeline/test/no_tracking_logger_test.exs` — Layer 2 example
|
|
- `vav_pipeline/test/source_external_test.exs` — Layer 2 example
|
|
- `specs/threshold_inscription.md` — Layer 3 enforcement
|
|
- `specs/return_specification.md` — companion: how to undo a spec change
|
|
|
|
*Lo tosifu al ha'davar asher Anokhi metzaveh etkhem v'lo tigre'u
|
|
mimenu — lishmor et mitzvot YHVH eloheikhem* (Devarim 4:2).
|