● Incident · backup automation compromised

A restore candidate has been found.

The backup platform has answered

Everything checks out.

Should you trust it?

H33 reconstructs the trust boundary

H33 decision · restore candidate 09:50
REFUSED

Integrity intact
≠ authority intact.

The bytes are fine. The authority that produced them was not.

● The attacker tries to move the boundary

Four attempts. Boundary unchanged.

An attacker can create evidence.

They cannot force evidence
to become authority.

Evidence is everywhere. Authority is scarce.

Attackers can produce valid signatures, valid timestamps, valid files and valid credentials. Every one of those facts can be true at the moment a recovery decision is made. H33 determines whether those facts are allowed to change what is trusted.

A backup platform answers can this be restored? — integrity, retention, an anomaly scan. It cannot answer should this return to production?, because that depends on whether the authority that produced it was still trustworthy at the time. Only one of those questions decides whether the incident restarts on restore.

What the engine concluded

Restore candidates, classified from the derived boundary and the authority lineage.

Where this fits

The decision above rests on H33-74, the portable evidence primitive — a proof that travels with the decision, so an auditor, insurer or regulator can recompute why something was accepted or refused instead of taking it on trust. The same governance boundary appears across the estate: Agent-008 decides whether an autonomous agent's action may produce a governed consequence, HATS continuously attests whether identity and authority have changed, and cyber insurance is where it stops being academic — an insurer paying a claim needs to know which restored state was authorised, not merely which files came back.

Related: the H33 trust stack · Proof Lab · APQC governed migration demo