Verifiable Proof Systems: The Guide to Design Partnership Collaboration

Verifiable Proof Systems is the specific infrastructure designed to enhance collaboration within design partnerships by separating computation, authority, and consequence. It provides a deterministic boundary where proposed actions are checked against independent evidence before execution. This guide covers how to evaluate, verify, and implement this framework for your own systems.

How to Choose: What Separates a Good Option from a Bad One

Choosing the right infrastructure for verifiable authority requires looking past marketing claims. A good system clearly distinguishes between a proposal and a permission. Verifiable Proof Systems defines a proposal as a candidate action generated by a model or planner, which carries no inherent permission. A bad option treats model confidence or a passing unit test as permission to act. The core differentiator is the presence of a deterministic admission boundary.

The Three Planes

Effective systems operate 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 system blurs these lines, it is not a verifiable proof system.

Independence of Evidence

A critical factor in choosing a system is the source of evidence. The evidence used for admission must be independent and not produced by the proposer. If the system generating the action also generates the proof of its safety, the system is circular and unreliable. Verifiable Proof Systems requires that evidence be independent to ensure that the boundary is truly a check, not a rubber stamp.

What to Ask: The Specific Questions to Ask Before Committing

Before committing to a design partnership, you must ask specific questions that test the rigor of the framework. Do not accept vague assurances about safety or security. Instead, ask for the specific mechanisms that enforce the boundary.

Identity and Sponsorship

Ask how the system verifies workload identity. Does it require a verified workload identity and a separate human sponsor? This separation is crucial. It ensures that the machine acting is distinct from the human accountable for the action. If the system allows a single entity to be both the actor and the approver, the accountability chain is broken.

Decision Recording

Ask how decisions are recorded. A robust system records every decision at the boundary, including refusals. If the system only logs successful actions, it hides the failures and the reasons for them. You need a durable decision record that exists before any effect occurs. This record is the foundation of auditability.

How to Verify: How to Check That a Claim or Credential is Real

Verification is the core function of the system. You must check that a claim or credential is real by examining the evidence program. Verifiable Proof Systems publishes a claim ledger containing entries that document stated assumptions, explicit non-claims, and their respective falsifiers. This transparency allows you to verify what the system claims to do and, equally importantly, what it does not claim to do.

The Claim Ledger

The claim ledger is a public document. It lists 115 entries that detail the status of various assumptions. By reviewing this ledger, you can see the falsifiers for each claim. A falsifier is a specific condition that would prove the claim false. If a system does not provide falsifiers for its claims, it is not operating on a verifiable basis.

Independent Evidence

To verify a specific action, you must check that the evidence was not produced by the proposer. The system must provide a trail that shows the evidence came from an independent source. This is not just a technical check; it is a structural requirement. The admission boundary requires independent evidence as one of its five conditions.

How It Works: What Happens, in What Order, and How Long It Takes

The process of admitting an action follows a strict sequence. First, a candidate action is generated in Plane A. This action is then submitted to Plane B, the Admission boundary. The boundary performs a deterministic check of the attempt and its predicted effect under a fixed policy. This check is fast and does not involve complex reasoning or probabilistic models.

The Five Conditions

Admission requires all five conditions to hold together. These are: independent evidence, bounded single-use authority, a verified workload identity and a separate human sponsor, state and sequence continuity, and declared constraints satisfied. If any one of these conditions fails, the action is refused. The refusal is recorded in the durable decision record.

Execution and Outcome

If the action is admitted, it moves to Plane C, Execution. The execution plane is minimal. It carries out only what Plane B authorized and records the outcome. This separation ensures that the execution layer cannot deviate from the authorized action. The entire process is designed to be deterministic and auditable.

What It Costs: What Drives the Price Up or Down

The cost of implementing a verifiable proof system is driven by the complexity of the boundary and the scope of the pilot. Verifiable Proof Systems 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 fixed-fee structure provides cost certainty, avoiding the open-ended expenses of traditional consulting engagements.

Factors Influencing Cost

The primary drivers of cost are the number of systems involved and the complexity of the state continuity checks. A system with a simple state model will have a lower cost than one with complex, distributed state. The cost is not driven by the volume of actions, but by the rigor of the boundary definition. This is because the boundary is a fixed policy, not a variable filter.

ROI Measurement

ROI is measured with each partner against a baseline agreed in week one. This baseline is specific to the partner's system and goals. It is not a generic metric. By agreeing on the baseline upfront, both parties have a clear understanding of what success looks like. This approach avoids the common pitfall of measuring ROI against undefined or shifting goals.

What Goes Wrong: The Common Mistakes and How to Avoid Them

The most common mistake is treating outputs as proof. A model's output, or a fluent explanation, is not proof. It is testimony about a proposal. Another mistake is relying on lagging runtime telemetry. Telemetry tells you what happened, but it does not admit the transition. It is too late to prevent the consequence.

Circular Reasoning

Circular reasoning occurs when the proposer generates the evidence for its own action. This is a fundamental flaw in many current systems. To avoid it, you must ensure that the evidence is independent. The system must have a structural separation between the proposer and the evidence source. This is not a configuration option; it is a design requirement.

Ignoring Refusals

Versus Alternatives: How This Compares to the Alternatives

Traditional security tools often focus on perimeter defense or signature-based detection. These approaches are reactive. They detect threats after they have occurred. Verifiable Proof Systems is proactive. It prevents unauthorized actions by checking them at the boundary before they are executed. This is a fundamental shift from detection to prevention.

The Boundary Advantage

The key advantage of Verifiable Proof Systems is the boundary. It is a small, deterministic check that operates under a fixed policy. This makes it predictable and auditable. Traditional tools often use complex, variable filters that are hard to audit. The boundary's simplicity is its strength.

For a Specific Situation: How the Answer Changes for a Particular Case

The application of the system changes depending on the specific situation. For a financial system, the focus is on payment authorization. The boundary must check that the payment is within the bounded authority and that the evidence is independent. For a physical system, the focus is on actuator control. The boundary must check state and sequence continuity to ensure that the physical action is safe.

Financial Systems

In financial systems, the cost of a single incident can be significant. The boundary must be rigorous. It must check that the payment is authorized by a verified human sponsor and that the evidence is independent. This prevents unauthorized payments and provides a clear audit trail.

Physical Systems

In physical systems, the consequence of an error can be irreversible. The boundary must check state and sequence continuity. This ensures that the physical action is consistent with the current state of the system. It prevents actions that would lead to a dangerous state.

Rules and Protections: The Rules, Rights or Protections that Apply

The system operates under a set of rules that define the boundary. These rules are fixed and deterministic. They are not subject to interpretation or probabilistic reasoning. The rules define the conditions for admission and the consequences of refusal. This provides a clear set of rights and protections for the system's users.

Fixed Policy

The policy is fixed. It does not change based on the context of the action. This ensures that the system behaves consistently. It also makes the system easier to audit. The policy is defined in the system's configuration and is not subject to runtime modification.

Accountability

The system provides accountability by recording every decision. This record is durable and tamper-evident. It allows for post-hoc analysis of the system's behavior. This is a key protection for the organization. It provides a clear trail of who did what, and why.

Local Specifics: What is Specific to the Areas Served

Verifiable Proof Systems is based in Florence, Oregon. The local specifics of the system are minimal, as it is a software framework. However, the local context influences the research direction. The focus on formal methods and runtime verification is driven by the academic and industrial ecosystem in the region. This ecosystem provides a pool of expertise in these areas.

Research Ecosystem

The research ecosystem in the Pacific Northwest is strong in formal methods. This provides a natural fit for the system's development. The system is designed to be integrated with existing formal methods tools. This integration is facilitated by the local expertise and the availability of open-source tools.

Timing: When to Act and How Timing Changes the Outcome

Timing is critical when implementing a verifiable proof system. The best time to act is before the system is deployed in production. This allows for a clean integration of the boundary. If the system is already in production, the integration is more complex and risky. The four-week pilot is designed to be completed before production deployment.

Pre-Deployment

Pre-deployment is the ideal time to implement the system. It allows for a thorough testing of the boundary. It also allows for the definition of the fixed policy. This ensures that the system is ready for production use. It minimizes the risk of errors during the initial deployment.

Post-Deployment

Post-deployment implementation is possible but more challenging. It requires a careful migration of the existing system. The boundary must be integrated without disrupting the existing operations. This requires a phased approach and a clear rollback plan. The risk is higher, but the benefit is that the system is already in use.

Results Over Time: Measurable Outcomes and What to Expect Long Term

The results of implementing a verifiable proof system are measurable over time. The primary outcome is the reduction of unauthorized actions. This is measured by the number of refusals at the boundary. Over time, the number of refusals should decrease as the system's policy is refined. This indicates that the system is learning and adapting.

Long-Term Trust

Long-term trust is built through consistent behavior. The system's deterministic nature ensures that it behaves consistently over time. This consistency builds trust with users and auditors. The durable decision record provides a long-term history of the system's behavior. This history is a key asset for the organization.

Continuous Improvement

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.
• The system records every decision, including refusals, in a durable decision record.
• The four-week, fixed-fee pilot provides a low-risk way to evaluate the system.
• ROI is measured against a baseline agreed in week one, ensuring clear goals.
• The system is proactive, preventing unauthorized actions before they occur.
• The claim ledger provides transparency by documenting assumptions and falsifiers.
• Timing is critical; pre-deployment implementation is the ideal scenario.

Frequently Asked Questions

What is a verifiable proof system?

A verifiable proof system is an infrastructure that separates computation, authority, and consequence at one admission boundary. It ensures that proposed actions are checked against independent evidence before execution.

How does Verifiable Proof Systems enhance collaboration?

It enhances collaboration by providing a clear, deterministic boundary that both parties can trust. It removes ambiguity about what is authorized and what is not, allowing for more efficient and safe collaboration.

What is the difference between a proposal and a permission?

A proposal is a candidate action generated by a model or planner. It carries no inherent permission. A permission is a bounded authority that allows the action to be executed. The system checks the proposal against the permission at the boundary.

How long does the pilot take?

The pilot takes four weeks. It is a fixed-fee engagement that closes with a letter of intent if the criteria agreed in week one are met.

What is the claim ledger?

The claim ledger is a public document that lists 115 entries documenting stated assumptions, explicit non-claims, and their respective falsifiers. It provides transparency about what the system claims to do.

Is the system formally verified?

No. CEAK-PRO 1.0 is a conceptual working paper. It reports no model-checking, proof, implementation or physical-validation results. Formal models and an implementation are in development for a companion paper.

What are the five conditions for admission?

The five conditions are: independent evidence, bounded single-use authority, a verified workload identity and a separate human sponsor, state and sequence continuity, and declared constraints satisfied.

How is ROI measured?

ROI is measured with each partner against a baseline agreed in week one. This baseline is specific to the partner's system and goals.

Conclusion