Why the learning part never decides
Phorvex has exactly one component that learns. It is an attacker, and it is walled off from every decision.
When a security product moves production workloads on its own, the first question from any operator is fair: what exactly is making that call, and can I check it?
A deterministic core
The decision core is deterministic. The same inputs always produce the same decision, and every decision, taken or not, is written to an audit record with its reasons. There is no language model in the decision path and nothing that improvises in production.
That property is what makes a postmortem possible. If Phorvex moved a workload at 03:12, you can replay that tick from its inputs and get the same answer.
The part that learns
We do use reinforcement learning, but on the other side. The RL red-team is a learning attacker whose only job is to break the defender before a real adversary does. It attacks the live defender around the clock.
It has found two real structural weaknesses in the decision core so far. Both are fixed. Each fix went through human review, landed as an auditable, regression-gated change, and was re-verified.
The attacker is allowed to learn. The defender is required to be explainable.
Why the wall
The red-team has no path into decisions. Its findings become fixes only through people. This separation is deliberate: it means your security team has one decision-maker to audit, one learning system to sandbox, and one boundary between them to verify.
- Reproducible: replay any decision from its inputs.
- Explainable: every move has a recorded reason.
- Frozen and regression-gated: the core cannot drift on its own.
Get the next one when it lands.
No schedule. We write when there is something proven to say.