Your backups are intact. That is not the same as safe to restore.

The category

Two systems, one backup, two correct answers

Both answers below are about the same artifact, and both are right. They answer different questions, and only one of them governs whether production may consume it.

Integrity is not authority.
An artifact can be perfect and still not be permitted.

The state model

Four states, because two are not enough

Security tooling trains people into a binary: green or red. Enterprise recovery has a third condition that loses more estates than the second, and H33-Recovery names it rather than colouring it green.

The trust ladder

Nine rungs, and a seam no engine crosses

Nothing enters above Unknown. Nothing reaches production eligibility without an explicit human promotion decision that the engine cannot manufacture. An agent may discover, analyse and recommend. It may not widen its own authority.

Compiled invariants

Five rules that cannot be configured off

Not policy, not settings, not a compliance profile. These are compiled into the engine, and no customer configuration, methodology or runtime flag can disable them.

Temporal boundary engine

It will not tell you when the attack began

That question usually has no evidenced answer, and a recovery system that invents one is worse than a recovery system that admits it does not know. H33-Recovery reconstructs an interval instead, and grades every clock by how much authority it is allowed to have over that interval.

trusted ≤ 08:44   |   uncertain 08:44 → 09:37   |   compromised ≥ 09:37   |   contained 10:16

That last line is the engine's spine. An attacker-reachable clock can widen uncertainty; it can never narrow it. It is why a forged clean attestation, a claim that the compromise started later, an adversary declaring its own containment, and a backdated record all fail to move the boundary — individually or together.

The transition protocol

Evidence sufficiency and authority sufficiency are different failures

A proposed change of standing is a first-class object carrying the requirements it must discharge, each independently resolved. That turns “what evidence is sufficient?” from positioning language into something a machine evaluates — and separates two outcomes that must never read the same.

transition   snapshot-0842 → AuthorizedForReintroduction

  identity_binding        SATISFIED
  integrity               SATISFIED
  temporal_admissibility  SATISFIED
  lineage_resolution      SATISFIED
  key_exposure_analysis   SATISFIED
  isolated_validation     SATISFIED
  human_authority         MISSING

  EVIDENCE SUFFICIENT · AUTHORITY INSUFFICIENT

Evidence sufficient, authority insufficient means the artifact is fine and a human should now be asked. Evidence insufficient means asking a human would be premature — you would be escalating a decision nobody can yet make. Conflating them is how a recovery programme burns its incident bridge on questions that have no answer yet.

Where a requirement is missing, the engine also carries what would resolve it — immutable provider event, object-lock metadata, a PQ-Time record — so an uncertain candidate comes with the shortest path to becoming decidable rather than an instruction to go and think about it.

Negative evidence

A refuted claim is not a missing one

Recovery tooling accumulates reasons to trust something. H33-Recovery also models evidence that destroys a previously plausible reading, because an absence and a refutation are not the same finding and must not produce the same response.

A contradiction outranks every gap. Reporting “three requirements missing” beside a proven falsehood invites someone to go and collect the three. And a refuted transition offers no resolution path at all, because there is no evidence that repairs a contradiction — offering a list would imply otherwise.

The demonstration

Operate it against a ransomware incident

A governed terminal session against a previously attested estate. You issue every command; the engine answers. Nothing advances on a timer, and every command declares the state it requires, refuses if that state is absent, and leaves a chained evidence record behind.

operator@northwind:~$ h33 mission create --purpose recovery --agent agent-008
operator@northwind:~$ agent-008 reconstruct --boundary
operator@northwind:~$ agent-008 assess --recovery-points
operator@northwind:~$ h33 challenge --inject attestation-clean --source attacker-reachable
  boundary       trusted ≤ 08:44 · compromised ≥ 09:37
  UNCHANGED

Synthetic incident estate. The engines are real and compute live; the incident data is simulated input, and the demonstration says so on every surface that uses it.

Honest boundaries

What is built, and what is not

Every claim on this page corresponds to implemented behaviour or is marked otherwise. The parts that do not exist are named as unavailable rather than pending, because a missing signer is not a queued approval and must never be mistaken for one.

Composition

What H33-Recovery uses

Recovery composes other admitted H33 products rather than absorbing them. Each remains its own product with its own authority; the recovery engine consumes them.

The dependency runs one way and it matters: an estate attested before an incident has a baseline to reconstruct against. An estate with no prior attestation returns UNKNOWN for everything, which is an honest answer and a useless one.

The definition

H33-Recovery proves the chain by which an untrusted or uncertain artifact is — or is not — permitted to become trusted production state.

It does not decide what gets restored. It determines what evidence is sufficient to present a recovery decision, and preserves the boundary where human authority must act. That is an architectural property rather than a detection feature, which is why backup, EDR, SIEM and incident-response tooling do not produce it as a by-product.