Most security products tell you they are "enterprise-grade." Very few will show you the evidence. When we set out to build AegisCore, we made a decision that shaped everything that followed: every release would ship with a directory of proof artifacts, and every claim in the product would trace back to one of them.
Today that directory holds 165 entries. This post explains what they are, why they exist, and what we learned building a platform this way.
The problem with "production-ready"
The phrase "production-ready" is doing an enormous amount of unearned work in this industry. It usually means "it ran on the developer's machine and the demo worked." For a cybersecurity platform — the thing an organisation trusts to tell it whether it is under attack — that is not good enough.
We wanted a different default. If AegisCore claims a capability, there should be a corresponding artifact that proves the claim was tested, when it was tested, and what the boundary of the claim is. Not marketing language. A file, with a hash, that an auditor can inspect.
What a release proof actually is
Each entry in the proof directory is a self-contained record of one engineering step. A typical proof contains the commands that were run, their output, a summary of what was validated, and — critically — a claim boundary section that states explicitly what the proof does not establish.
That last part matters more than anything else. A proof that says "the Linux installer builds and the artifact hash is recorded" is useful. A proof that also says "this does not establish that the Windows installer is signed, and macOS notarization is deferred" is honest. The second kind is the only kind we ship.
Operator-truthful as an engineering constraint
We use the phrase "operator-truthful" internally as a hard constraint, not a value statement. It has concrete consequences:
- The UI never shows a fake green status. If a subsystem is degraded, it says degraded.
- The Decision Engine never emits a metric it cannot derive. There is no language model in the decision path that could invent one.
- A release that has a known unresolved issue carries that issue in its proof, in plain text, until it is closed.
This is occasionally uncomfortable. It is much easier to ship a dashboard that is all green. But a security operations centre that cannot trust its own console is worse than no console at all.
What 165 proofs taught us
Three lessons stand out.
Truthful scoping makes you faster, not slower. When every proof has to state its own boundary, you stop conflating "done" with "started." Work gets smaller and more honest. The development plan closed cleanly because each step had been genuinely finished, not optimistically marked complete.
Deferred is a valid state. Several proofs explicitly defer work — cross-platform smoke tests, for example — with a date and a reason. Naming a thing as deferred is not a failure. Pretending it is done is.
Evidence compounds. Once the proof directory existed, every subsequent decision had a place to anchor. The pentest simulation results, the test counts, the manifest signatures — they all live in the same evidence-driven structure. The discipline paid for itself.
Why this matters for regulated buyers
If your organisation operates under NIS2, HIPAA or a similar regime, you already know that "trust us" does not survive an audit. The value of an evidence-driven build is that the audit conversation changes shape. Instead of asking us to attest to a capability, an auditor can inspect the artifact that establishes it.
That is the whole idea behind AegisCore: the platform that helps you produce forensic-grade evidence was itself built that way.
You can download the full platform and inspect it yourself — the Community edition is free, with no signup. See it on the download page.