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