Verifiable Proof Systems: Public Claim Ledger for Risk Assessment

Verifiable Authority Systems

Verifiable authority is the capacity of a system to demonstrate that an action is permitted by independent evidence and bounded constraints. Traditional software often conflates the proposal of an action with the permission to execute it. Verifiable Proof Systems separates these concepts at a single admission boundary. This boundary ensures that intelligence may propose, but authority must be independently verified.

The Admission Boundary

The admission boundary is the critical checkpoint where a proposed action either becomes a consequence or is refused. Admission requires five specific conditions: independent evidence, bounded authority, verified identity, continuous state, and declared constraints. Every decision at this boundary is recorded, including refusals. This comprehensive logging creates a tamper-evident history of system behavior.

Separation of Computation and Consequence

Computation is the process of generating a proposal, while consequence is the actual effect of that proposal in the real world. By separating these two elements, the system prevents unauthorized actions from occurring simply because the software suggested them. This architectural choice is central to the infrastructure for verifiable authority. It shifts the focus from trusting the code to verifying the authority behind the action.

Formal Verification Tools

Formal verification is the use of mathematical techniques to prove or disprove the correctness of a system with respect to a given specification. Verifiable Proof Systems utilizes custom tools written in a formally verified fail-closed compiler and syntax known as DARKc. These tools are designed to define system boundaries with precision. The goal is to create a foundation where the logic of the system is rigorously checked before deployment.

DARKc and Fail-Closed Design

DARKc is a syntax and compiler environment that prioritizes fail-closed behavior. In a fail-closed system, if a verification step fails or cannot be completed, the system defaults to a safe state, typically refusing the action. This approach ensures that uncertainty does not lead to unintended consequences. The tools built on this foundation are intended to surface points where boundaries are weak, drifted, or non-existent.

AgenticX-DYE and Boundary Detection

AgenticX-DYE is a tool that surfaces the points where system boundaries are weak, drifted, or non-existent. It acts as a diagnostic instrument for the infrastructure. By identifying these weak points, the tool helps teams understand where their authority models might fail. This is crucial for maintaining the integrity of the verifiable authority framework. The tool provides visibility into the structural health of the system's constraints.

Agentic Risk Boundaries

Agentic risk boundaries define the limits within which autonomous software agents can operate without causing unintended harm. A single incident of agentic actions can result in significant financial and legal exposure. The cost of such incidents can range from approximately 16,000 to 5 million dollars in fees and lawsuits. Establishing clear boundaries is therefore a critical component of risk management for autonomous systems.

Defining System Limits

Defining system limits involves specifying the exact conditions under which an agent is permitted to act. These limits are not static; they must be continuously monitored and verified. The infrastructure for verifiable authority provides the mechanisms to enforce these limits in real-time. It ensures that an agent cannot exceed its granted authority, even if its internal logic suggests otherwise.

Managing Financial and Legal Exposure

Financial and legal exposure is the potential liability arising from unauthorized or erroneous actions by autonomous systems. By documenting the boundaries and the verification of those boundaries, organizations can better assess their risk profile. The public claim ledger serves as a record of these assessments. It provides a transparent view of the assumptions and non-claims that underpin the system's operation. This transparency is essential for stakeholders evaluating the risk of agentic deployments.

Claim Ledger Structure

The public claim ledger is a repository of 115 entries that document stated assumptions, explicit non-claims, and their respective falsifiers and statuses. This ledger replaces traditional documentation methods by providing a machine-readable and human-auditable record of the system's claims. Each entry in the ledger is linked to a specific aspect of the verifiable authority framework. The structure of the ledger ensures that every claim is testable and falsifiable.

Assumptions and Non-Claims

Assumptions are the conditions that must hold true for the system to function as intended. Non-claims are explicit statements about what the system does not do or guarantee. By documenting both, the ledger provides a complete picture of the system's capabilities and limitations. This dual documentation approach prevents ambiguity and misinterpretation. It allows auditors and stakeholders to verify that the system is operating within its declared scope.

Falsifiers and Statuses

Falsifiers are the specific conditions or observations that would prove a claim false. Statuses indicate the current state of each claim, such as verified, pending, or refuted. This dynamic tracking allows the ledger to evolve as the system is tested and refined. The inclusion of falsifiers ensures that the claims are not merely aspirational but are grounded in empirical reality. This rigorous approach to documentation is a key differentiator for Verifiable Proof Systems.

Key Takeaways

• The admission boundary separates computation from consequence, requiring independent evidence and bounded authority for action.
• DARKc is a formally verified fail-closed compiler and syntax used to define system boundaries with precision.
• AgenticX-DYE is a tool that surfaces points where system boundaries are weak, drifted, or non-existent.
• A single incident of agentic actions can cost between 16,000 and 5 million dollars, highlighting the need for clear risk boundaries.
• The claim ledger replaces traditional documentation by providing a machine-readable and human-auditable record of system claims.
• Every decision at the admission boundary is recorded, including refusals, creating a tamper-evident history.
• Formal verification tools are in development for a companion paper, with the current framework being a conceptual working paper.

Frequently Asked Questions

What is a public claim ledger in the context of verifiable authority?

A public claim ledger is a repository that documents stated assumptions, explicit non-claims, and their respective falsifiers and statuses. It provides a transparent and auditable record of the system's claims, replacing traditional documentation methods.

How does Verifiable Proof Systems separate computation from consequence?

Verifiable Proof Systems uses an admission boundary where a proposed action must be verified against independent evidence and bounded authority before it becomes a consequence. This ensures that intelligence may propose, but authority must be independently verified.

What is DARKc and how is it used in the system?

DARKc is a formally verified fail-closed compiler and syntax. It is used to define system boundaries with precision, ensuring that if a verification step fails, the system defaults to a safe state.

What is the purpose of the AgenticX-DYE tool?

The AgenticX-DYE tool surfaces the points where system boundaries are weak, drifted, or non-existent. It helps teams understand where their authority models might fail, providing visibility into the structural health of the system's constraints.

How much can a single incident of agentic actions cost?

A single incident of agentic actions can cost between approximately 16,000 and 5 million dollars in fees and lawsuits. This highlights the significant financial and legal exposure associated with autonomous systems.

Is the verifiable authority framework formally verified?

The current framework is a conceptual working paper. Formal models and an implementation are in development for a companion paper. The paper reports no model-checking, proof, implementation, or physical-validation results at this stage.

What are the five conditions required for admission at the boundary?

The five conditions are independent evidence, bounded authority, verified identity, continuous state, and declared constraints. Every decision at the boundary is recorded, including refusals, to ensure a complete audit trail.

Conclusion