CADi · Network and security response
Did the response cause unnecessary disruption?
Examine security-response decisions and their costs, including disruption to legitimate users, alongside the threats your existing tools detect.
Bring us a problem, a suspected opportunity or a result that does not add up. We can explore how CADi IPv could help, starting with your question and the evidence available.
Get in touchCADi IPv does not inspect packets, does not sit inline in your traffic path, and does not replace your firewall, your intrusion detection, your endpoint or network detection tooling, or your SIEM. Those answer what is happening. This is the layer beneath them.
It governs the moment after: when your organisation decides what to do about something a detector has flagged. It consumes those decisions in the response-orchestration path, measured in seconds to minutes - never the packet path measured in microseconds.
Over-blocking takes out legitimate traffic, real customers and, regularly, production itself. Almost nobody measures it, because the alternative you did not take is never written down. CADi IPv writes it down.
That makes the response two-sided for the first time: evidence for why something was stopped, and evidence for why something was allowed. Both are decisions the organisation answers for.
The robustness gate is built to be enforcing rather than advisory: at the CADi HotPath stage, a decision the analysis finds too fragile is held for a human rather than taken autonomously. At the earlier two stages the same verdict is evidenced rather than enforced - and either way the record shows what it was, and why.
For each response, what the alternative would plausibly have cost. The unpriced half of the security ledger, written down at the moment of the decision rather than argued about afterwards.
The policy each response was taken under, the causal rationale, and a hash-chained, replayable trace - ready for a post-incident review, an auditor or an insurer.
How sure the analysis is, and how ready the decision was to be automated. Conflating those two is how response automation usually goes wrong.
Functions taking response decisions at volume, under automation, where a disproportionate response costs as much as a missed one.
Providers who take response decisions on a customer's behalf and carry a contractual obligation to evidence them.
Every CADi engagement can deepen from arm's length to inside the decision. Offline historical analysis: you export your past response decisions, with no connection to your live systems at all, and the CADi Causal Engine analyses them as a batch - a governance diagnosis on your own incidents, changing nothing you do.
CADi SideCar: a live one-way feed, evidencing each response as it is taken while your systems run exactly as before. CADi HotPath: your orchestration layer asks CADi and waits before it acts, so a fragile response can be held for a human. No customer runs CADi IPv at that stage today; products earn their way to it.
CADi is in production - its engines are live in the cloud - with nine UK patent applications pending. CADi IPv evidences the response decision, and is built to govern it at the CADi HotPath stage that no customer runs today; it does not detect threats, and it does not guarantee a security or regulatory outcome.
The causal maths is rigorously implemented and validated against injected, synthetic and real ingested data. It runs on a declared expert model of the decision domain, so results are analytical approximation, stated as such; live-outcome validation is a deployment step against a client's own outcomes. The engine does not currently model an adversary who adapts to the governance policy - we state that openly rather than wait to be asked.