bikoret/specs/lo_tosif.md

# 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 shorashim 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).