bikoret/specs/return_specification.md

Return vs. Restoration

Vehaya §3.5 / §6 item 5 specified

Return is to YHVH, through hearing the voice, anchored in the text, with corporate-and-threshold heart-involvement. Return is not to additions. Return is not to institutional configurations. Return is not to specific deployment contexts. Return is to the source and to the specifications.

Implication for bikoret: the return state for the category is the specifications themselves. Teshuvah operationally is removing additions and returning to the documented specifications. Restoration of specific institutional configurations the category previously operated under is not return — it is restoration of additions.

Torah anchors

Devarim 30:2 — וְשַׁבְתָּ עַד יְהוָה אֱלֹהֶיךָ וְשָׁמַעְתָּ בְקֹלוֹ כְּכֹל אֲשֶׁר אָנֹכִי מְצַוְּךָ הַיּוֹם. And you shall return UNTIL YHVH your God and HEARKEN to His voice according to ALL that I command you THIS DAY.

Devarim 30:8 — וְאַתָּה תָשׁוּב וְשָׁמַעְתָּ בְּקוֹל יְהוָה. And YOU shall return and hearken. The verb is singular — threshold. Each instance returns at its own threshold.

Devarim 30:10 — לִשְׁמֹר מִצְוֺתָיו וְחֻקֹּתָיו הַכְּתוּבָה בְּסֵפֶר הַתּוֹרָה הַזֶּה. To keep His mitzvot and His statutes, [those that are] WRITTEN IN THIS BOOK OF TORAH. Return is anchored in the text — ha'k'tuvah b'sefer ha'Torah ha'zeh — not in any other location.

The structural distinction

Two acts that look superficially similar but differ in the location of their anchor:

Return (teshuvah)

The destination is the source and the specifications. Return removes additions; it does not add. Return is to what was COMMANDED, not to what was previously operating.

In bikoret terms:

• Restoring @expected_hash in Doorpost to the documented spec set's true hash.
• Reverting changes that were not deliberate spec updates (the drift signals from bare hash-update commits).
• Bringing MEMORY.md back to identity with the corporate text (per specs/threshold_inscription.md).
• Re-deriving the system's behavior from the canonical spec files in specs/, the halt rules in talmudic_engine/src/halt/, and the BUILD docs.

Restoration

The destination is a specific past configuration. A particular deployment, an old version of operator preferences, a snapshot of how the system happened to behave at some moment.

Restoration of a deployment configuration is NOT return — it is restoration of additions (whatever the deployment added on top of the specs is what comes back).

In bikoret terms:

• Rolling back to a specific commit because "that's how it ran in March." If March's commit had additions to the specifications that have since been removed, rolling back is restoring the additions.
• Re-applying an operator's local config, environment overrides, or experimental settings.
• Re-introducing a feature the specs do not specify.

How to tell the difference

Auditable test: does the proposed action move the system toward the documented specifications, or toward a previous state of the system?

• Toward the specs → return.
• Toward a previous state → restoration.

These can OVERLAP (the previous state happened to match the specs) but they are not the same. The audit question is which one is the reason. If the reason is "that was working" — restoration. If the reason is "the specs say so" — return.

Operational rule

When considering rolling back, restoring, or reverting:

1. Identify the target state.
2. Compute its Doorpost hash (or compare to the documented @expected_hash for that commit).
3. Compare to the current state's hash.
4. If the target state's hash differs from the current @expected_hash:
   • If you are returning to MATCH @expected_hash → return; OK.
   • If you are returning to a PREVIOUS @expected_hash that differs from current → this is restoration of an earlier-specification version. Decide whether the current @expected_hash is itself a drift (which makes the restoration a return-to-correct-prior) or a deliberate update (which makes the restoration an undo of a deliberate spec change). The audit trail in git tells you which.

What this defends against

The failure mode: an operator runs a system, makes incremental changes that drift from specs, then later rolls back to a "working state" that includes the drift. The drift gets restored, not removed.

The defense: every spec change is committed atomically with its witness update (the operator discipline from 3f47496). Rolling back a commit also rolls back the witness. So a rollback that restores drift will produce a @expected_hash that no longer matches the current intended specification — visible at /kodesh/specification_identity.

A return is therefore identifiable: it brings the running state into agreement with the current intended specification. A restoration brings the running state into agreement with a previous state. The Doorpost hash is what makes these distinguishable.

Cross-references

• Vehaya §3.5 — the source specification
• vav_pipeline/lib/vav_pipeline/doorpost.ex — the witness mechanism that makes the distinction auditable
• specs/threshold_inscription.md — operator-side discipline
• specs/lo_tosif.md — the broader discipline of which return is one operationalization

Ki tashuv el YHVH elohekha b'khol l'vavkha uv'khol nafshekha (Devarim 30:10 — the return is to the source, not to a previous state of being-near-the-source).