A framework for autonomous detection and response without a central decision-maker.
Version 1.3.2 · Published 2026-07-28 · CC BY 4.0 · No patent filed, none pending
Four mechanisms that, composed, perform every function a SIEM performs, with nothing in the middle making the call.
It is a framework, not a product. There is nothing to buy, no company behind it waiting to license it, and no implementation being sold. The mechanisms are described in enough detail to be built by anyone who wants them.
📄 The whitepaper, 14 sections, 8 architecture diagrams, full enabling detail 📝 Companion article, the argument in prose without the specification
No patent application has been filed on any mechanism described here, and none will be. No provisionals, no applications, nothing pending, no intent to file.
Any project, open-source or commercial, is free to implement all of it. No permission needed, no attribution owed. Full statement in PATENT-NON-ASSERTION.md.
This is the part most worth understanding, and it is why this is written as a framework rather than as a SIEM design.
The mesh does not care what the detector detects.
M2, M3, and M4 describe how a device acts on a conclusion safely, tells its neighbours what it concluded, and learns from what its neighbours concluded. None of that depends on the conclusion being about a cyber attack. Swap the detector, keep the substrate.
| Cyber domain | Physical domain | |
|---|---|---|
| The endpoint is | a server, workstation, or agent | a body-worn camera, a fixed camera, a vehicle system |
| The detector produces | is this malicious, and is the actor human or machine | a conclusion about the environment the sensor observes |
| M2 acts locally | kill a process, isolate an interface, invalidate a credential, snapshot for rollback | raise an alert, escalate, change local recording or retention behaviour |
| M3 shares | a signed verdict with hosts it recently communicated with | a signed conclusion with adjacent devices |
| M4 learns | lessons about attack features, verified against the local model | lessons about recognised conditions, verified the same way |
| The centre fails because | the round trip loses, and ingest cost means the best signals were never sent | the device is disconnected for hours, and video is the most expensive payload there is |
A SIEM detecting a process injection and a camera mesh detecting a condition in the street are the same architecture with a different front end. In both cases something happens fast, the decision has to be made where it happened, and whatever would normally decide is either too far away or unreachable.
M2, M3, and M4 are domain-agnostic. Local reversible action, signed peer exchange, reputation-weighted learning. Nothing in them is specific to cyber security.
M1 as specified is cyber-specific. It classifies whether the actor driving an attack is a human or a machine, using behavioural signals from a computing endpoint. That question does not transfer to a camera watching a street. A physical-domain deployment plugs a different detector into the same seam.
Every one of those devices is also a computer on a network, so all four mechanisms apply to defending the device itself, unchanged. That is two applications rather than one, and conflating them makes both weaker. The whitepaper separates them in §14.
Peers exchange conclusions, never raw data. In the cyber domain that is a bandwidth argument: a signed verdict is a few hundred bytes and a day of telemetry is not.
In the physical domain the same argument produces a privacy property. A mesh that shares what a device concluded moves dramatically less sensitive information than one that ships footage to a central store. That falls out of the architecture rather than being bolted onto it, and it should be available to anyone building in this space rather than fenced off.
| Mechanism | Replaces | Standalone? | |
|---|---|---|---|
| M1 | On-device actor-class discrimination, human / AI / benign | (new capability) | Yes |
| M2 | Atomic reversible autonomous response | Deciding | Yes |
| M3 | Signed verdict gossip with topological adjacency | Correlating | Yes |
| M4 | Reputation-weighted leaderless cooperative learning | Learning | No, needs the mesh |
Collection does not break. It was always local; the manager was a destination, not a requirement.
M1, M2, and M3 each deliver value implemented alone. That is the practical path for a project that wants part of this without all of it.
Sending data somewhere else to be thought about is too slow to respond at machine speed. That is not a tuning problem: anything that has to travel in order to be decided has already lost the race. If the decision has to happen locally, the interesting question is what the manager was actually for. It was doing four things. Deciding just left, because latency forced it out. Correlation and learning both break when the centre is removed, and each break has an answer: share conclusions instead of events, share lessons instead of data, and make every autonomous action reversible so it can be trusted to run unattended.
Running today in Specter, open source: telemetry collection, scoring, and a decision ledger.
Designed but not finished: peer gossip (M3), atomic response commit (M2), cooperative learning across a fleet (M4).
⛔ Nothing in the physical-domain application is built. Section 14 of the whitepaper is disclosure, not a roadmap, and it says so.
This is an architecture and an argument, not a benchmark. There are no performance numbers in the whitepaper because there are none worth reporting. Fleet-scale figures produced on a three-node lab should be treated as marketing.
Known limitations, stated in the whitepaper rather than left for a reader to find:
- The M1 actor signal is beatable by adding jitter, and has been beaten in an afternoon.
- M4's poisoning defence is a mitigation, not immunity. It raises the cost from "compromise one node" to "compromise a trusted node and stay subtle."
- Key distribution and revocation are out of scope. Signed identity is assumed, not provided.
- Endpoint model integrity is assumed, not provided.
Where the telemetry never arrives. SIEM ingest is priced by volume, so every real deployment has a quiet tier of what does not get sent: verbose process creation, full command lines, DNS, module loads. Those are the signals that separate a novel attack from a noisy Tuesday. A decision made on the endpoint is made on the full local event stream, including everything too expensive to ship.
Where the round trip is long enough to lose. Cross-region collection, restricted egress, segmented networks, and any pipeline with batching and indexing between the event and the rule that evaluates it.
Where the centre is unreachable. A centralized agent does not degrade into reduced local capability. It stops deciding and becomes a log shipper with nowhere to ship.
The first two apply on a healthy, fully connected corporate network. That is where the argument has to win.
To keep it buildable. The concern is endpoint autonomy becoming a fenced yard that only a handful of platform vendors are permitted to build in, in either domain.
Publishing places these mechanisms in the public record where they can be cited as prior art. It does not guarantee an examiner finds them, and a bad patent still has to be challenged by somebody. Publication is the strongest available move. It is not a guarantee.
If a factual claim here is wrong, open an issue. Corrections are versioned and noted rather than silently edited, and they are most of the reason this is public.
Implementations are welcome and do not need to be announced. Anyone who wants to build any part of this, in either domain, already has permission.
CC BY 4.0. Use it, build on it, ship it commercially. Attribution appreciated, not required for the techniques themselves.
Nothing here is for sale and none of it is gated. If the framework saves you time, you can fuel the next one:
Authored by Clint Garrison (ORCID 0009-0006-5804-1237). Published as prior art, not as a product.