Verifiable Proof Systems (VPS) helps design partners track and measure pilot success by establishing a deterministic admission boundary that records every decision, including refusals. This guide covers how VPS separates computation from authority, defines pilot metrics, and structures audit trail documentation for autonomous infrastructure projects.

Verifiable Proof Systems Architecture

Verifiable Proof Systems is a research initiative focused on developing infrastructure for verifiable authority. The core problem it addresses is that software now proposes consequential actions faster than anyone can review them. A proposal is not permission, and permission is not the effect. VPS builds the boundary where a proposed action either becomes a consequence or is refused. according to Digital Identities Getting

The Three Planes Model

The architecture relies on a strict separation of duties across three planes. Plane A is the Proposal plane, which is untrusted. Models, planners, tools, and people propose actions here, but they hold no authority over production state. Plane B is the Admission plane, which performs a small, deterministic check of the attempt and its predicted effect under a fixed policy. Plane C is the Execution plane, which is minimal and carries out only what Plane B authorized, recording the outcome.

This separation ensures that computation is not authority. Authority is not consequence. Computation generates a candidate action, whether by a model, a planner, a filter, or a person. It carries no permission and no effect. Authority is bounded permission over a named object, under explicit limits. A good proposal does not create it. Consequence is a change to authoritative state, or to a physical actuator. Logging an intent is not one.

Admission Requirements

Admission at the boundary requires five conditions to hold together. First, independent evidence, not produced by the proposer. Second, bounded, single-use authority, scoped to the predicted effect. Third, a verified workload identity and a separate human sponsor. Fourth, state and sequence continuity. Fifth, declared constraints satisfied. Commit also requires a durable decision record before any effect. Rejected attempts are recorded too. This framework is detailed in the published conceptual working paper CEAK-PRO 1.0, available at Verifiable Proof Systems.

Pilot Project Metrics and Baselines

For design partners, the pilot is a four-week, fixed-fee engagement on one of your systems. The goal is to close with a letter of intent if the criteria agreed in week one are met. Measuring success requires moving beyond vague sentiment to specific, verifiable data points. ROI is measured with each partner against a baseline agreed in week one.

Defining the Baseline

Before the pilot begins, the team must capture the real picture. The process map and collected data must reflect how the process works now, not just how it is documented to work. Reliable, relevant data helps the team understand how a process truly works and where to improve. This baseline serves as the control group for all subsequent measurements.

Tracking Boundary Integrity

VPS uses custom tools to define system boundaries. Written in a formally verified fail-closed compiler and syntax called DARKc, the AgenticX-DYE(TM) tool surfaces the points where boundaries are weak, drifted, or non-existent. This is critical because a single incident of agentic actions can cost significant fees and lawsuits. By tracking where the evidence stops, partners can identify gaps in their authority models before they become operational failures.

Success Criteria

Success is not defined by the absence of errors, but by the presence of verifiable proof. The pilot evaluates whether the admission boundary correctly refuses unauthorized actions and admits authorized ones. It measures the latency of the deterministic check and the completeness of the decision record. If the criteria agreed in week one are met, the pilot closes with a letter of intent. This approach ensures that the pilot is a reality check, not a sales demo.

Audit Trail Documentation and Evidence

Documentation is the primary output of the VPS pilot. The system records every decision at the boundary, including refusals. This creates a durable decision record that serves as evidence for future audits. The documentation is not just a log of actions, but a proof of authority.

Structure of the Decision Record

Each entry in the decision record includes the proposed action, the evidence presented, the authority granted, and the final decision. The record is tamper-evident, meaning that any attempt to alter it is detectable. However, tamper-evident does not mean tamper-proof. Auditable does not mean correct. The record shows where the evidence stops, allowing auditors to verify the logic of the decision.

Integration with External Standards

Smart Contract Tools

VPS also offers smart contract tools that integrate with the admission boundary. These tools allow partners to encode their policies in a verifiable format. The smart contracts execute only when the admission boundary grants authority. This ensures that the logic of the policy is enforced at the point of execution, not just at the point of proposal.

Key Takeaways

• Verifiable Proof Systems separates computation, authority, and consequence at one admission boundary.
• Admission requires five conditions: independent evidence, bounded authority, verified identity, state continuity, and declared constraints.
• Pilot success is measured against a baseline agreed in week one, not against vague goals.
• The AgenticX-DYE(TM) tool surfaces points where boundaries are weak, drifted, or non-existent.
• Every decision, including refusals, is recorded in a durable decision record.
• The documentation is tamper-evident and auditable, but not tamper-proof or automatically correct.
• VPS is a research initiative, not a commercial service provider, and does not claim certification or compliance.

Frequently Asked Questions

What is a verifiable proof system?

A verifiable proof system is a protocol in which one or more provers try to convince another party, called the verifier, that the provers possess certain true knowledge, often with the goal of revealing no further details about this knowledge. In the context of VPS, it refers to the infrastructure that verifies authority before allowing a consequential action.

How does VPS measure pilot success?

VPS measures pilot success by comparing the system's behavior against a baseline agreed in week one. The pilot is a four-week, fixed-fee engagement that closes with a letter of intent if the criteria are met. Success is defined by the correct admission or refusal of actions at the boundary.

What is the difference between authority and consequence?

Authority is bounded permission over a named object, under explicit limits. Consequence is a change to authoritative state, or to a physical actuator. Authority does not automatically lead to consequence; it must be admitted at the boundary.

Does VPS guarantee security?

No. VPS does not guarantee security, safety, or the prevention of all unauthorized actions. It finds and documents gaps, records each decision, and makes changes detectable. The system is designed to be fail-closed, but it is not unhackable or tamper-proof.

What is the role of the human sponsor?

The human sponsor is a verified identity that is separate from the workload identity. The sponsor provides the bounded authority for the action. This ensures that there is a human accountable for the decision, even if the action is proposed by a model.

Can VPS be used for smart contracts?

Yes. VPS offers smart contract tools that integrate with the admission boundary. These tools allow partners to encode their policies in a verifiable format, ensuring that the logic of the policy is enforced at the point of execution.

Conclusion

Verifiable Proof Systems provides a rigorous framework for design partners to track and measure the success of pilot projects. By separating computation, authority, and consequence, VPS ensures that every decision is verifiable and auditable. The pilot is a reality check that helps partners identify gaps in their authority models before they become operational failures. To discuss a design-partner pilot, .