MADADH is a four-role hardware-bound supervision engine running natively on Windows. Every design decision prioritises fail-closed behaviour, physical authority, and deterministic state. There is no cloud. There is no network dependency. There is no software path that bypasses physical presence.
Continuously validates physical USB authority. Verifies volume label, WMI serial, and disk binding against enrolled constants. Performs cryptographic SHA-256 handshake against the master signing certificate. Acts as a forensic black box — intentionally not stopped on security halt. Continues running to record post-halt state.
Monitors runtime continuity of the supervision plane. Detects loss of control-plane coherence. If the watchdog supervisor fails to pulse within the defined window, the heartbeat triggers an immediate halt condition. No grace period. No retry. Absence of signal is treated as a fault.
Evaluates the health of the protected runtime and control-plane processes. Monitors for defined failure states including process absence, unexpected exits, and integrity drift. Reports health status to the bus for watchdog consumption. A single health failure condition is sufficient to trigger halt.
Handles local state exchange and event movement across the atomic file-based bus. All inter-role communication flows through the bus. No direct inter-process communication. No shared memory. No network socket. State is written atomically — write to temp, delete old, rename temp — ensuring no partial state is ever read.
The PowerShell 5.1 watchdog is the top-level supervisor. It owns role lifecycle — starting, monitoring, and stopping all four Python roles. It performs the integrity check on every cycle, consuming the SHA-256 manifest and comparing against live file hashes.
When a trust condition fails, the watchdog executes the halt sequence. It stops roles in order, writes the halt latch to the Master USB, persists the manifest SHA-256, and emits verified log events. No role is permitted to survive a halt except the Master Probe, which continues as a forensic recorder.
The watchdog does not fail open. If the halt latch cannot be written, the system does not proceed. Every exit path through the supervisor is accounted for.
| Property | Value |
|---|---|
| Runtime | PowerShell 5.1 — Windows native, no external dependencies |
| Role management | Process spawning with PID tracking and alive verification |
| Integrity check | SHA-256 manifest comparison on every supervisory cycle |
| Halt latch | Written to Master USB — persists across reboot |
| Log events | Structured, timestamped, UTC — watchdog.log |
| Halt verification | HALT_STOP_PHASE_VERIFIED + HALT_LATCH_PERSIST_VERIFIED required before SECURITY_HALT_COMPLETE |
| Portable root | E:\BRAIN (test) — external SSD (production) |
Every authority assertion in MADADH is cryptographically signed and verified. The trust chain runs from the physical USB through the signing certificate to the payload, bound by a monotonic counter and a freshness window. Replay is structurally impossible.
4859C5E9780B0D63951D01315E87B11EEEF8F016. Root CA and code signing certs distinguished. Correct key extracted via CNG-native RSA path.schema|ts_utc|timestamp|pid|root|master_present|drive|counter. Field order is fixed. Any deviation invalidates verification.560570C138EE7078, and volume serial F2B9E36B. Enrolled at 2026-03-08T05:27:01Z. Cannot be substituted.When a halt condition is triggered, the watchdog writes a halt latch file to the Master USB. This file contains a halt ID derived from the canonical string schema|halt_timestamp_utc|halt_reason, the manifest SHA-256 at the time of halt, and a UTC timestamp.
The latch survives system reboot, service restart, and process churn. It is stored on the physical Master USB — not on the host machine. If the host is rebooted without the Master USB present, the latch cannot be cleared.
Clearing the latch requires both physical tokens, a fresh cryptographically signed clearance, and successful verification against the enrolled Clearance USB hardware binding. No software path exists to clear the latch without physical presence.
| Field | Purpose |
|---|---|
| halt_id | SHA-256 of canonical halt string. Unique per halt event. |
| halt_timestamp_utc | UTC timestamp of halt. Bound to clearance freshness window. |
| halt_reason | Enumerated cause — authority failure, integrity failure, health failure. |
| manifest_sha256 | SHA-256 of the 10-file manifest at halt time. Persisted for signing station use. |
| instance_id | Machine-bound UUID. Clearance must match this instance. |
| latch path | D:\madadh_master\halt.latch — Master USB only. |
MADADH is designed to run from an external SSD. The entire engine — watchdog, roles, bus, logs, and manifest — lives on the external drive. The Master USB carries the cryptographic authority. Together they form a self-contained, portable security supervisor that can be deployed to any Windows host.
There is no installation. There is no registry dependency. There is no cloud activation. Plug in the external SSD and the Master USB, start the stack, and MADADH enforces from that moment forward.
Remove either device and the response is immediate and deterministic. The system halts. It stays halted. Authority must be physically re-established to resume.
| Component | Location |
|---|---|
| Engine root | External SSD — E:\BRAIN (test) / production SSD |
| Watchdog | E:\BRAIN\watchdog\watchdog.ps1 |
| Role scripts | E:\BRAIN\sentinel\ and E:\BRAIN\roles\ |
| Bus / IPC | E:\BRAIN\bus\ — atomic JSON files |
| Logs | E:\BRAIN\logs\watchdog.log |
| Master authority | D:\ — Master USB (volume label: MASTER) |
| Halt latch | D:\madadh_master\halt.latch |
| Clearance token | F:\ — Clearance USB (volume label: MADADH_CLEAR) |