MADADH is the work of a single Australian developer. No team. No VC. No shortcuts. Every line of architecture, every cryptographic decision, every test result on this site comes from one person who decided the problem was worth solving properly.
MADADH was designed and built by the founder of Madadah Systems — a sole trader based in Terrigal, New South Wales, Australia.
The engine was built from first principles. No existing framework was adapted. No open source security supervisor was forked. The architecture — the four-role supervision model, the USB authority binding, the fail-closed halt latch, the dual-token recovery ceremony — was designed from scratch to solve a problem that existing tools do not address.
The name MADADH comes from the Scottish Gaelic word for wolf. It was chosen deliberately. A wolf does not negotiate. It does not degrade gracefully. When it acts, it acts completely.
That is the design philosophy of this engine.
| Entity | Madadah Systems |
| Structure | Sole Trader |
| ABN | 44 103 797 283 |
| Location | Terrigal, New South Wales, Australia |
| Website | madadh.systems |
| Contact | contact@madadh.systems |
| Engine | MADADH v7.1 |
| Runtime | PowerShell 5.1 + Python 3.11, Windows |
| Jurisdiction | Australia |
| Dependencies | None — fully offline, no cloud, no external services |
These are not marketing statements. They are the constraints that shaped every technical decision in MADADH from the first line of code to the current production version.
Endpoint security products exist in abundance. They detect, alert, log, and report. Some of them block. Most of them fail gracefully — they degrade, they switch to a reduced mode, they keep running under broken conditions because uptime is valued above integrity.
MADADH was built because that model is wrong for a specific class of environment. There are systems where continued operation under broken trust is more dangerous than being offline. Where the correct answer to a compromised authority state is not an alert — it is a hard stop.
No commercial product offered that. Not with physical USB authority. Not with a fail-closed halt latch that survives reboot. Not with a dual-token recovery ceremony. Not offline, without a cloud dependency, deployable from an external SSD.
So it was built.
MADADH is relevant to any environment where these questions matter:
Who is authorised to let this system run? What happens if that authorisation cannot be verified? Can the system be forced back into operation by someone without the right physical credentials? Does a reboot clear the halt state?
If those questions are relevant to what you protect — defence systems, critical infrastructure, operational technology, high-security Windows endpoints, edge deployments — then MADADH is worth a conversation.
If uptime is more important than authority integrity in your environment, MADADH is not the right tool.
If you are evaluating MADADH for a defence, government, or critical infrastructure context, please include a brief description of your environment and what problem you are trying to solve. There is no sales process. There is no demo environment. If the architecture is relevant to what you protect, we will have a direct technical conversation.