MADADH-CAP-01  /  v1.0
Controlled External Use
madadh.systems
Fail-Closed | Portable | Local | Deterministic
Deterministic Fail-Closed Control System

When trust
breaks,
it stops.

MADADH enforces a single hard rule: when authority or integrity fails, the protected runtime halts deterministically. It stays halted. It does not resume until the correct physical authorities and cryptographic validation are present.

Portable Fail-Closed Offline Physical USB Authority No Software Override Windows Native Australian Built
Get in Touch View Evidence Pack
Authority Enforcement Active
Latch Persistence Verified
Dual-Physical Recovery Validated
Replay Protection Confirmed
Chaos and Soak Testing Passed
Portable — Runs from External SSD
Core Principle

MADADH is not a convenience layer. It is not a permissive orchestration system. It is a portable, fail-closed enforcement capability built for environments where continued execution under broken trust is unacceptable.

Most systems fail gracefully. They degrade, retry, and assume. MADADH does none of that. When a critical trust condition fails, the response is refusal. Persistent refusal. The system halts, records that halt in a durable latch, and holds that state until the correct physical and cryptographic conditions are satisfied by a human operator with the right tokens in hand. Deploy it anywhere. Carry it with you. The authority travels with the hardware.

What It Removes
01
Authority Ambiguity

Prevents a system from continuing because software assumes authority is still valid. Authority is continuously verified, not assumed.

02
Recovery Ambiguity

Prevents a system from resuming because a fault appears to have disappeared or a component has been reconnected. Recovery requires explicit validation.

03
State Ambiguity

Prevents a halted condition from being lost through reboot, restart, or process churn. The latch persists across all of these.

04
Operator Ambiguity

Removes dependence on memory, intent, or informal procedure as the basis for safe recovery. Recovery is explicit, ordered, and cryptographically bound.

Recovery Sequence

Stop. Stay stopped.
Prove you can restart.

Once a halt condition is entered, MADADH records and maintains a persistent latch state. That latch survives reboot, service restart, process churn, and reconnection of any device.

Return to operation requires two separate physical tokens and cryptographically signed clearance data bound to the specific machine, the specific halt event, and the current recovery window. Nothing else will do.

The master authority token alone is not sufficient. Both tokens must be present.

01Trust condition fails. Authority, integrity, or supervisory health breaks.
02Deterministic halt. Protected runtime stopped. No degraded mode.
03Latch established. Halt state recorded persistently. Survives reboot.
04System denied. Restart blocked regardless of device reconnection.
05Master token verified. Physical authority present and validated.
06Clearance token verified. Second physical authority confirmed.
07Signed clearance presented. Cryptographically bound to this instance, this halt, this window.
08Monotonic and temporal checks pass. Replay and stale authorization rejected.
09Latch cleared. Controlled restart permitted.
Verified Behavior

Not a claim.
A demonstrated result.

MADADH has been tested end-to-end under live conditions including chaos testing and extended soak runs. The following behaviors have been observed and evidenced, not assumed.

Live authority pull haltDeterministic halt on live removal of master authority token during operation.
Latch persistence across rebootHalt state survives full system reboot. Restart remains blocked on return.
Dual-physical recovery end-to-endFull recovery sequence validated with both physical tokens and signed clearance.
Single-token restart denialMaster authority token alone is insufficient. Restart correctly denied.
Replay attack resistancePreviously valid authorization rejected under monotonic and temporal controls.
Integrity failure haltDeterministic halt on runtime integrity verification failure.
Chaos and soak testingSystem behavior confirmed stable under extended runtime stress and injected fault conditions.
Stale clearance rejectionExpired or window-invalid clearance data correctly rejected. Restart denied.
Portable deployment verifiedEngine operates correctly from external SSD across multiple host machines.
View Full Evidence Pack →
Supervision Architecture

Four-role local
supervision model.

MADADH uses a local four-role architecture. State is exchanged through an atomic file-based bus. Supervisory logic is deterministic and locally self-contained. No remote orchestration. No cloud dependency. No ambiguity in decision flow.

RoleFunction
MasterValidates authority state and master control conditions on a continuous basis. Physical hardware token binding enforced throughout operation.
HeartbeatMonitors runtime continuity and expected supervisory presence. Detects loss of control-plane coherence.
HealthEvaluates protected runtime and control-plane health conditions. Triggers halt on defined failure states.
BridgeHandles local state exchange, event movement, and control communication across the local bus.
Full Architecture Detail →
Contact

If this is relevant
to what you protect

MADADH is built for environments where the critical question is not whether a system can keep running, but who is allowed to let it run again. If that is your problem, get in touch.

contact@madadh.systems