0 Fork 0

Files

T

Scott KarpandClaude Fable 5.1 017a9b89d4 the name: Shorashim → Bikoret (בִּקֹּרֶת) — the specification

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>

2026-10-13 22:13:36 +00:00

7.1 KiB

Raw Permalink Blame History

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:

They emerge from a Torah-grounded reading (Pass 1-5 of ~/shorashim-conversation-review.md are full of such readings).
They are committed atomically with their witness update.
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).
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).

7.1 KiB Raw Permalink Blame History