Verifiable Proof Systems (VPS) uses a conceptual framework to separate computation, authority, and consequence at a single admission boundary. This approach addresses the gap where software proposes actions faster than humans can review them. This guide covers how to evaluate, verify, and implement proof infrastructure for autonomous systems in 2026.

How to Choose: Separating Good from Bad Options

Choosing proof infrastructure requires distinguishing between tools that merely log activity and those that enforce authority. A good solution separates the proposal from the permission. A bad option treats a passing unit test or a signed artifact from the proposing system as permission to act. Verifiable Proof Systems defines authority as bounded permission over a named object, under explicit limits. A good proposal does not create this authority. Instead, the infrastructure must independently establish it before any consequence occurs.

The Three-Plane Model

Effective infrastructure operates on three distinct planes. Plane A is the Proposal plane, which is untrusted and holds no authority over production state. Plane B is the Admission plane, a small, deterministic check of the attempt and its predicted effect. Plane C is the Execution plane, which is minimal and carries out only what Plane B authorized. If a vendor cannot clearly articulate this separation, their solution likely conflates computation with authority.

What to Ask: Specific Questions Before Committing

Before committing to any proof infrastructure, you must ask specific questions about the admission criteria. Does the system require independent evidence that was not produced by the proposer? Does it enforce bounded, single-use authority scoped to the predicted effect? Does it verify a workload identity and a separate human sponsor? These questions ensure that the system does not rely on model confidence or lagging runtime telemetry as permission.

Identity and Continuity

You must also ask about state and sequence continuity. The system must track the state of the authoritative object to ensure that the action is valid in the current context. Finally, ask how declared constraints are satisfied. If the system cannot prove that all five assurance conditions hold together at one boundary, it is not providing verifiable authority.

How to Verify: Checking Claims and Credentials

Verifying a claim requires looking at the durable decision record. Every decision at the boundary is recorded, including refusals. This record allows auditors to see not just what happened, but why it was allowed or denied. VPS maintains a public claim ledger containing 115 entries that document stated assumptions, explicit non-claims, and their respective falsifiers. This transparency allows you to verify the status of specific technical claims without relying on marketing language.

The Role of the Paper

The foundational work is documented in the paper CEAK-PRO 1.0, published with DOI 10.5281/zenodo.23092344. This paper is a conceptual working paper. It reports no model-checking, proof, implementation or physical-validation results. Statements about formal verification, runtime enforcement or future products describe research directions and design goals, not demonstrated properties of any product or system. You should verify any vendor's claims against their published evidence, not their promises.

How It Works: Process and Order

The process begins when a model, planner, tool, or person proposes an action. This proposal enters Plane A. The system then moves the attempt to Plane B, where a deterministic check occurs. This check evaluates the attempt against a fixed policy. If the check passes, the system issues a bounded, single-use authority. This authority is then passed to Plane C for execution. The entire process is designed to be fail-closed, meaning that if any part of the check fails, the action is refused and the refusal is recorded.

Custom Tools and Boundaries

VPS has created custom tools for defining system boundaries. These tools are written in DARKc, a formally verified fail-closed compiler and syntax. The AgenticX-DYE(TM) tool surfaces the points where boundaries are weak, drifted, or non-existent. This allows teams to identify gaps in their authority models before they become security incidents. The process is not fully automated; it is a fixed-fee assessment delivered by VPS.

What It Costs: Price Drivers

The cost of proof infrastructure is driven by the complexity of the system boundaries and the depth of the assessment. VPS offers a four-week, fixed-fee pilot on one of your systems. This pilot closes with a letter of intent if the criteria agreed in week one are met. The cost is not based on the number of actions processed, but on the rigor of the boundary definition and the verification of the admission logic. ROI is measured with each partner against a baseline agreed in week one.

Incident Cost Context

What Goes Wrong: Common Mistakes

The most common mistake is treating outputs as proof. Model confidence, a fluent explanation, or a passing unit test are testimony about a proposal. None of them admit the transition to consequence. Another mistake is relying on a safety filter the command passed. A filter is a heuristic, not a proof. If the system does not record refusals, you lose the ability to audit why an action was denied. This lack of visibility makes it impossible to improve the policy over time.

Boundary Drift

Boundary drift is another critical failure mode. Over time, the declared constraints may no longer match the actual state of the system. The AgenticX-DYE(TM) tool is designed to detect this drift. If you do not monitor the boundaries, you may find that your authority model is outdated. This leads to either false refusals or, worse, false admissions. Regular assessment is required to keep the boundaries aligned with reality.

Versus Alternatives: Comparison

Traditional security tools focus on perimeter defense and logging. They do not separate authority from computation. Runtime verification tools check properties during execution, but they often lack the bounded authority model. VPS differs by requiring five assurance conditions to hold together at one boundary. This is the core contribution of the CEAK-PRO 1.0 framework. The table below summarizes the differences.

For a Specific Situation: Agentic Systems

For teams deploying agentic systems that propose tool calls, database writes, or payments, the risk is highest. These actions are cheap to produce but expensive to undo. VPS is specifically designed for this context. The infrastructure ensures that a model's proposal does not automatically become a consequence. This is critical for financial systems, where a single unauthorized payment can have significant legal and financial implications. The fixed-fee pilot allows you to test this boundary on one of your systems without a long-term commitment.

Rules and Protections: Legal and Regulatory

Regulatory frameworks like the EU Cyber Resilience Act impose obligations on software providers. The main obligations apply from 11 December 2027. VPS is not a certifier or an accredited auditor. It produces evidence for requirements like AIUC-1 B006, D003, and D004. It helps teams prepare for an outside test or audit. VPS is not affiliated with AIUC. For legal advice, you should consult with a qualified attorney. VPS provides technical infrastructure, not legal protection.

Local Specifics: USA and Oregon

VPS is based in Florence, Oregon. This location is relevant for teams in the USA who prefer a domestic research partner. The local context includes access to university research partners in formal methods, runtime verification, and AI security. VPS is preparing an NSF SBIR/STTR Phase I proposal and is forming a team with a university research partner. This local collaboration model allows for open problems from the paper's evidence program to be addressed by academic groups.

Timing: When to Act

Timing is critical because the regulatory landscape is evolving. The EU Cyber Resilience Act obligations are approaching. Teams should begin their assessment now to ensure they are ready for the 2027 deadline. The four-week pilot is a short commitment that can be completed quickly. Delaying the assessment means operating with unverified authority boundaries. This increases the risk of an incident. Acting now allows you to establish a baseline and measure improvements over time.

Results Over Time: Long-Term Outcomes

Long-term results are measured by the reduction in boundary drift and the clarity of the decision record. Over time, the system should show fewer false refusals and a more accurate mapping of authority. The durable decision record allows for continuous improvement of the policy. You can analyze past refusals to understand why they occurred and adjust the constraints accordingly. This iterative process leads to a more robust and reliable system. The goal is not to eliminate all risk, but to make every decision verifiable and auditable.

Key Takeaways

• Authority is bounded permission over a named object, under explicit limits.
• A proposal is not permission, and permission is not the effect.
• Admission requires independent evidence, bounded authority, verified identity, continuous state, and declared constraints.
• Every decision at the boundary is recorded, including refusals.
• VPS uses a fixed-fee, four-week pilot to assess system boundaries.
• The AgenticX-DYE(TM) tool detects boundary drift and weak points.
• CEAK-PRO 1.0 is a conceptual working paper, not a product certification.
• Regulatory deadlines, such as the EU Cyber Resilience Act, make timing critical.

Frequently Asked Questions

What is verifiable authority?

Verifiable authority is bounded permission over a named object, under explicit limits, established independently of the proposer.

Does VPS provide legal advice?

No. VPS provides technical infrastructure and evidence for audits. It is not a law firm and does not provide legal advice.

Is the CEAK-PRO 1.0 paper a product?

No. It is a conceptual working paper. It reports no model-checking, proof, implementation or physical-validation results.

How long does the pilot take?

The pilot is a four-week, fixed-fee assessment on one of your systems.

What is the cost of an agentic incident?

Where is VPS located?

VPS is based in Florence, Oregon, USA.

Next Steps

To plan your assessment, to discuss a design-partner pilot. Verifiable Proof Systems is ready to help you establish verifiable authority for your autonomous systems.