Executive Summary#

A structured pitch document for buyers, investors, and partners evaluating ANNIE. Reading time: ten minutes.

In one paragraph#

ANNIE is a verifiable safety kernel for autonomous AI agents — a structural barrier between what a model proposes and what a system actually does. We treat the language model as an unreliable probabilistic channel and place a deterministic, formally-specified safety gate between its output and the real world. Action records are anchored in a hash-chained ledger, supported hardware faults are measured against a microsecond response budget, and safety decisions are measured against a documented time budget. The architecture is designed against the same functional-safety patterns industrial control engineering has used for thirty years (ISO 13849-1, IEC 61508 family), applied to the new problem of autonomous AI execution. It exists because the cost of a wrong autonomous action — a misrouted transfer, a poisoned tensor, a hallucinated database command — is going up faster than guardrail-based AI safety can keep pace with.

Public evidence boundary#

This page describes the ANNIE product and architecture direction. The current public runnable MVP evidence is the Sovereign Loop Core repository at github.com/ABSatVPS/sovereign-loop-core. Its PUBLIC-STATUS.md file is the public implementation boundary for what is runnable and verified in the public MVP today. This page does not claim production certification, regulatory approval, or that the public MVP proves every ANNIE capability described here.

What this is, structurally#

ANNIE rests on four architectural pillars. The four are detailed individually in Concepts; the executive view is:

1. The Ledger of Reality — a hash-chained append-only event log. Every approved or rejected action is anchored; the chain is independently verifiable via the shipped annie verify tool. The log is a DAG, so rollback is structural — abandon a branch, return to the last sealed safe state.
2. Holographic Tombstones — a memory model that lets working sets exceed VRAM without breaking determinism. Evicted memory pages leave a 64-byte cryptographic witness; rehydration is bounded and traceable.
3. The Guillotine — a hardware-fault response path. When supported silicon reports a compute exception, ANNIE measures fault handling against a documented microsecond budget before the next authorized transition proceeds.
4. The Iron Lung — the discipline that holds the entire control path to a bounded-latency budget. No heap allocation, no unbounded locks, no garbage-collection pauses on the safety-decision path. Determinism turns from probabilistic into engineering-budget.

All four are wrapped in the formal-safety framing of ISO 13849-1 Category 3/4 architectural patterns. ANNIE is designed against those standards. It is not yet certified to them — that is a separate workstream documented honestly. The point of using this framework from the build stage is to make autonomous-agent risk legible in the same vocabulary reviewers already use for dangerous equipment, improving audit readiness without implying present certification.

What this does#

Concrete capabilities a buyer would put into a procurement document:

• Evidence-backed refusal. Out-of-policy agent intents are rejected by a formally specified kernel path, not by a probabilistic classifier or prompt heuristic. The decision is recorded, signed, and reproducible.
• Independent audit, no vendor cooperation required. The annie verify tool ships with every license. Customers and their auditors walk the ledger themselves and confirm structural integrity, monotonic ordering, signature presence, and known event kinds. We are deliberately not in the audit critical path.
• Framework-first evidence. Threats, diagnostics, timing budgets, safe-state behavior, and replay are described in the language already used for hazardous machinery and safety-related control systems.
• Bounded hardware-fault response. On supported AMD ROCm hardware, the hardware-fault response path is measured against a documented microsecond budget once the silicon raises an exception. Worst-case measured latency is published per release.
• Bounded control-loop latency. The safety-decision path completes inside a documented budget every iteration on supported platforms. Excursions are logged as soft faults and surfaced in Prometheus metrics.
• Post-quantum signed receipts. Every meaningful ledger entry carries an ML-DSA signature (NIST-standardized post-quantum cryptography). License files carry Ed25519 signatures. The cryptographic stack is documented and the algorithms are standard.
• Memory beyond VRAM, without losing determinism. The Holographic Tombstone mechanism scales agent working sets past local GPU memory without introducing null-pointer reasoning paths or unbounded read latencies. Rehydration is measured against a documented budget on supported platforms.

What this does NOT do#

The complementary half, equally important. We list these explicitly because the gap between what a system claims and what it actually covers is where most enterprise AI deployments fail.

• No language-model alignment work. ANNIE does not attempt to make the underlying LLM safer, more polite, or less prone to hallucination. It treats the model as a presumed-unreliable input source. If your problem is “the model says bad things,” ANNIE is the wrong layer; you want a fine-tuning vendor.
• No application-layer compensation. If your application takes a kernel-approved decision and misuses it downstream, ANNIE has done its job and your application has not. Side-effect rollback in external systems is outside our scope.
• No automatic certification. Designing against ISO 13849-1 patterns is architectural alignment, not a certificate. It may shorten the path to assessment by giving reviewers a familiar evidence structure, but customers who need an actual Notified Body assessment, CE/UKCA marking, or a documented safety case will need to factor in third-party certification cost separately.
• No protection against physical or side-channel attack. Hardware-level threat model (timing, power, electromagnetic) belongs to your deployment environment, not to ANNIE.
• No support for arbitrary deployment targets. ANNIE requires specific kernel scheduling configuration, CPU isolation, memory locking, and (currently) AMD ROCm hardware. Deployments without these will fail the startup self-check by design.
• No general-purpose AI framework. This is not an agent framework, not a model orchestrator, not a RAG pipeline, not a vector store. It is the safety kernel that sits underneath whatever you already use.
• No 5-minute install. If you are evaluating a weekend hackathon project, this is the wrong product. ANNIE is for teams that already know what their safety story needs to look like.

Who this is for#

Five named scenarios. If your use case maps onto one of these, the rest of this document is for you.

1. Fiduciary AI — financial automation where a single misrouted transfer is catastrophic#

The pain. Your fund or your bank is piloting agentic systems for trade routing, settlement, treasury operations, or customer-facing financial advice. Every wrong decision is auditable money loss with regulatory consequences. Your compliance officer wants a written safety case before the system can touch production. Your existing guardrails are LLM-based filters — and you know they fail in subtle ways your auditors will eventually find.

Why ANNIE fits. The kernel’s refusal logic is formally specified. Every transition is hash-chained and signed. Independent third-party audit does not require our cooperation. Your compliance officer gets the safety case they need, in vocabulary they recognize from non-AI control systems.

2. Industrial control — robotics and automation where bad commands move physical mass#

The pain. You operate or build industrial automation: a warehouse, a factory floor, a robotic surgical assistant, a process plant. The AI layer is on the operator-recommendation side today, but the move toward closing the loop — letting AI directly command actuators — is happening fast. You already understand ISO 13849-1 because you’ve shipped against it for decades on the non-AI side. You are looking for an AI safety kernel that speaks your language.

Why ANNIE fits. ANNIE is designed against the same body of standards your existing control systems are certified against. Architectural alignment with Category 3 / 4 dual-channel topology is the explicit design goal, not a marketing afterthought. The hardware-fault response path supports safe-state-on-fault; the deterministic-cadence control loop provides the diagnostic cadence. Your safety engineers will read the docs without needing translation.

3. Regulated medical, legal, and compliance-burdened automation#

The pain. Your industry requires every decision to be auditable, reproducible, and defensible after the fact. AI-augmented workflows are mandated to come; the regulators are catching up; you do not want to be the cautionary tale. Your CISO wants to know exactly what the AI was allowed to do, what it was prevented from doing, and how the record proves it.

Why ANNIE fits. The ledger is the record. The annie verify tool is the replay surface. The threat model is published and the boundaries are explicit. We do not claim certification we do not have; we present autonomous-agent risk in a standards-aware evidence structure your reviewers already recognize, including ISO/IEC 23894, ISO/IEC 42001, and ISO/IEC TR 5469:2024 on AI and functional safety.

4. Defense and critical-infrastructure operators#

The pain. Your threat model presumes adversaries. AI in your decision loop has to assume it will be probed, manipulated, and induced into unsafe outputs. Your safety story has to survive a forensic investigation. Off-the-shelf AI guardrails are an immediate non-starter because they presume cooperative inputs.

Why ANNIE fits. ANNIE treats the language model as untrusted by construction. Post-quantum signed receipts mean ledger evidence survives even adversaries that may eventually own quantum compute. Bare-metal resource sovereignty means the safety path is not interleaved with general-purpose workloads that may themselves be compromised. The hardware-fault response path is designed to stop the agent after a supported silicon fault is reported, before the next authorized transition proceeds.

5. Web3 protocol teams running autonomous transaction-execution agents#

The pain. Your protocol has an autonomous agent that can move significant on-chain value. A single bad transaction is irrecoverable. Your community needs to trust the agent without trusting you. Traditional Sybil-resistant and rate-limited approaches help, but they do not stop the agent from issuing a transaction it should not.

Why ANNIE fits. The agent can propose any transaction; the kernel decides what is allowed. Every approval and refusal is anchored in the ledger, with a signature anyone can verify. Independent verification means your community does not have to trust the operator — they can audit the chain of approvals themselves. The epistemic-firewall pattern — a deterministic monitor between an untrusted high-capability channel and an actuator surface — is exactly the structural model on-chain autonomous agents need.

Who this is NOT for#

Equally explicit. We would rather you discover this on this page than after a procurement cycle.

• You are evaluating AI tools for a demo or proof-of-concept. ANNIE has setup cost, configuration cost, and assumes operational maturity. If you are still in the “does the LLM do useful things at all” phase, the wrong layer.
• Your AI errors have low cost. Customer-service chatbots, content generation, ranking, suggestion engines, anything where the worst-case outcome is “the user clicks back.” Use simpler guardrails; reserve your engineering attention.
• You need infinite hardware flexibility. ANNIE currently targets AMD ROCm with specific kernel scheduling and memory-locking requirements. NVIDIA CUDA support, broader OS support, and cloud-managed deployments are on the roadmap but not shipping. If you cannot accept the current target, wait.
• You want a 5-minute install. This product expects you have an ops engineer or someone who can configure kernel scheduling and CPU isolation. The startup self-check will refuse to run if the host is misconfigured. That is a feature, not a bug — but it is the wrong feature if your team cannot meet it.
• You want a free open-source tool. ANNIE is a proprietary commercial product. The documentation is Apache-2.0; the kernel is not. We respect open source enough not to mislabel ourselves as it.
• You want managed-cloud SaaS. Today ANNIE is shipped as a binary you deploy on hardware you control. Managed-service offering is a future roadmap item, not a current product.

Product-track status vs. roadmap#

Honest status for the ANNIE product track. This table is not the public MVP implementation boundary; the public MVP boundary remains the Sovereign Loop Core PUBLIC-STATUS.md file.

The honest line: the core safety primitives are implemented in the ANNIE product track; deployment polish and broader target support are still being filled in.

Pricing and engagement#

We are in early-access pre-order. Pricing is not on the public site because every early customer is getting different terms based on deployment specifics. Two paths.

Standard pre-order#

For customers whose use case maps onto the named scenarios above, who can accept the current hardware target (AMD ROCm), and who want the shipping capability set as it exists today.

• One-off license, host-fingerprint bound.
• Includes the verification toolchain (annie verify) for independent audit.
• Includes release-notes access and the published per-release measurements.
• Standard pricing tier is offered on the call.

Hook: email preorder@verifiableproof.systems with a one-paragraph description of your deployment target (hardware, model, action surface). We reply within two business days with a deployment-fit assessment and a price.

Specialized configuration#

For customers who need any of the following:

• A deployment target ANNIE does not yet support (NVIDIA, ARM, multi-host).
• A capability not yet shipping (managed-service, clustering, hardened SaaS).
• A safety case written against a specific standard or regulator (industry-specific compliance work).
• An architectural variant the team is willing to fund (custom invariants, custom logic engine, third-party formal-method integration).
• Source-code escrow, custody arrangements, or any unusual contracting term.

Hook: email preorder@verifiableproof.systems with “Specialized” in the subject line, plus a description of what you need. Specialized engagements are scoped per-customer and priced against the actual work — we do not have a price sheet because we do not have a standard scope.

Both paths route through the same address; the subject-line tag determines triage.

Investors#

For capital partnership, strategic discussion, or board introductions:

invest@verifiableproof.systems

We share materials under NDA on request.

Why now#

Three converging pressures, all real and all happening this year:

1. Autonomous agent deployment is moving from demo to production. The companies who quietly piloted agentic systems in 2025 are deciding whether to put them on the critical path in 2026. The bar moves from “interesting” to “defensible.”
2. AI regulation is catching up. The EU AI Act is in force and becomes broadly applicable on 2026-08-02, with staged exceptions. ISO/IEC 42001 and ISO/IEC TR 5469:2024 are published. Harmonized standards work continues around this body of evidence. A vendor that built against functional-safety topology early is in a substantially stronger position than one assembling a compliance story after the fact.
3. The cost of a wrong autonomous action has been demonstrated. Multiple public incidents have shown what happens when a sufficiently capable agent makes a wrong call in a high-stakes setting. The buyers we talk to are no longer asking whether AI safety matters — they are asking what evidence we can give them that ours works.

If your roadmap intersects any of those three, the next twelve months are not a time to be running an unvalidated AI safety story.

How to engage, summary#

Engineering writing and design-decision long-form lives on the blog: blog.verifiableproof.systems.

ANNIE is offered by Verifiable Proof Systems. Founder: Adam B. Straughn.