Verifiable Proof Systems: The Guide to Design Partnership Authority

Verifiable Proof Systems is the infrastructure designed to enhance collaboration within design partnerships by separating computation, authority, and consequence. It provides a boundary where proposed actions are checked against independent evidence before execution. This guide covers how to choose, verify, and implement verifiable authority systems for agentic workflows.

How to Choose a Verifiable System

Choosing the right infrastructure requires distinguishing between testimony and proof. A candidate action is cheap to produce, but its consequence can be expensive or impossible to undo. Many systems treat model confidence or passing unit tests as permission. These are merely testimony about a proposal. They do not admit the transition to a consequential state.

Verifiable Proof Systems separates three distinct planes: computation, authority, and consequence. Computation generates the candidate action. Authority is bounded permission over a named object. Consequence is the actual change to authoritative state. A good system ensures that a good proposal does not create authority. It requires independent evidence, not produced by the proposer, to establish that authority.

Defining the Core Components

Authority is bounded permission over a named object, under explicit limits. It is not created by the quality of the proposal. Consequence is a change to authoritative state, or to a physical actuator. Logging an intent is not a consequence. The system must distinguish between these three to prevent unauthorized actions.

Questions to Ask Before Committing

Before integrating a verifiable authority system, you must ask specific questions about the admission criteria. Does the system require independent evidence? Is the authority bounded and single-use? Does it verify the workload identity and a separate human sponsor? These questions determine if the system can handle the complexity of agentic actions.

You should also ask about the decision record. Does the system record every decision at the boundary, including refusals? A durable decision record is required before any effect. If the system only logs successful actions, it lacks the auditability needed for high-stakes environments. The system must show where the evidence stops.

How to Verify Claims and Credentials

Verification in this context means checking that a claim or credential is real and valid. The National Institute of Standards and Technology describes a growing ecosystem around verifiable digital credentials. These credentials allow for the verification of identity and authority without relying on the proposer's word. The system must use independent evidence to verify the state and sequence continuity.

How the Admission Boundary Works

The system operates on a single boundary with three planes. Plane A is the Proposal plane, which is untrusted. Models, planners, tools, and people propose actions here. It holds 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. It carries out only what Plane B authorized and records the outcome. Admission requires five conditions to hold together: independent evidence, bounded single-use authority, verified workload identity, state and sequence continuity, and declared constraints satisfied. If any condition fails, the action is refused and recorded.

The Role of the Human Sponsor

A verified workload identity and a separate human sponsor are required for admission. This ensures that there is a human accountable for the authority granted. The sponsor does not propose the action but verifies the identity and constraints. This separation prevents the model from self-authorizing its actions.

Cost Drivers and Pricing Models

The cost of implementing verifiable authority infrastructure is driven by the complexity of the system and the scope of the pilot. Verifiable Proof Systems offers a four-week, fixed-fee pilot for design partners. This pilot focuses on one of your systems and closes with a letter of intent if the criteria agreed in week one are met. The fixed-fee model provides predictability for partners evaluating the technology.

Common Mistakes and How to Avoid Them

A common mistake is treating outputs as proof. A passing unit test or a signed artifact from the proposing system is not proof of authority. These are testimony about a proposal. To avoid this, ensure that the system requires independent evidence. Another mistake is assuming that a safety filter the command passed is sufficient. A safety filter is not the same as an admission boundary.

Teams often fail to record refusals. If the system only logs successful actions, it creates a blind spot in the audit trail. Every decision at the boundary must be recorded, including refusals. This ensures that the system can be reviewed for patterns of attempted unauthorized actions. It also helps in identifying where the evidence stops.

Comparison with Alternative Approaches

Traditional security models often rely on perimeter defense and access control lists. These models do not address the specific challenge of agentic actions, where the proposer is the same entity as the executor. Verifiable Proof Systems introduces a distinct admission boundary that separates these roles. This approach is different from standard runtime verification, which may not require independent evidence.

Application in Specific Scenarios

In financial services, the system can verify that a payment proposal has independent evidence of funds and authority. The Financial Crimes Enforcement Network and other agencies are issuing FAQs on the use of state-issued mobile driver's licenses. These credentials can be used to verify identity in the admission process. The system ensures that the payment is only executed if all five conditions are met.

In healthcare, the system can verify that a treatment proposal has the necessary authority and evidence. Cross-sector collaboration is promoted as a route to improving health and health equity. The system can integrate with integrated care systems to ensure that actions are authorized and recorded. This helps in maintaining trust and accountability in sensitive environments.

Rules and Protections for Partners

Design partners are protected by the explicit non-claims in the public claim ledger. The ledger documents what the system does not claim to do. This prevents misunderstandings about the capabilities of the research. The system is a conceptual working paper, and it reports no model-checking, proof, or implementation results. Partners should understand that the system is in the research phase.

The rules for the admission boundary are fixed and deterministic. This ensures that the system behaves predictably. The policy is not changed by the proposer. This protects the partner from unexpected changes in the system's behavior. The system makes changes detectable and records each decision.

Local and Regional Specifics

Verifiable Proof Systems is based in Florence, Oregon. The local context includes a strong research community and a focus on formal methods. The system is designed to work in distributed environments, which is relevant for partners in different regions. The use of verifiable digital credentials is supported by various government agencies, including the NIST. This ensures that the system can integrate with existing identity frameworks. according to Digital Identities Getting

Regional regulations may affect the use of verifiable credentials. For example, the EU Cyber Resilience Act has specific obligations that apply from 11 December 2027. The system can help teams prepare for these requirements by producing evidence for specific requirements. It is not a compliance tool, but it provides the evidence needed for audits.

Timing and Implementation Windows

The timing of implementation is critical for design partners. The four-week pilot is designed to provide a quick assessment of the system's fit. The criteria agreed in week one determine if the pilot closes with a letter of intent. This allows partners to make a decision based on concrete evidence. The timing of the pilot should align with the partner's development cycle.

As regulations evolve, the timing of adoption becomes more important. The EU Cyber Resilience Act and other regulations are setting new standards for software security. Implementing verifiable authority systems now can help partners stay ahead of these requirements. The system is designed to be adaptable to future regulatory changes.

Long-Term Results and Outcomes

Long-term results are measured against a baseline agreed in week one. The system aims to reduce the risk of unauthorized actions by ensuring that all decisions are recorded and verified. Over time, the system can help partners build a culture of verifiable authority. This culture ensures that all actions are backed by independent evidence. The system makes changes detectable and shows where the evidence stops.

Key Takeaways

• Verifiable Proof Systems separates computation, authority, and consequence at one admission boundary.
• Authority is bounded permission over a named object, under explicit limits.
• Admission requires five conditions: independent evidence, bounded authority, verified identity, state continuity, and declared constraints.
• The system records every decision at the boundary, including refusals.
• A four-week, fixed-fee pilot is available for design partners.
• The system is a conceptual working paper and reports no model-checking or proof results.
• Custom tools written in DARKc surface points where boundaries are weak or non-existent.
• The system helps teams prepare for outside tests or audits by producing evidence.

Frequently Asked Questions

What is the primary function of Verifiable Proof Systems?

Verifiable Proof Systems is infrastructure for verifiable authority. It builds the boundary where a proposed action either becomes a consequence or is refused.

How does the system ensure that a proposal is not treated as permission?

The system requires independent evidence, not produced by the proposer, to establish authority. A good proposal does not create authority.

What are the five conditions required for admission?

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

Does the system record refusals?

Yes, every decision at the boundary is recorded, including refusals. This ensures a complete audit trail.

What is the cost of the pilot?

The pilot is a four-week, fixed-fee engagement. The specific fee is agreed upon with the design partner.

Is the system formally verified?

The paper is a conceptual working paper. It reports no model-checking, proof, or implementation results. Formal models and an implementation are in development for a companion paper.

How does the system handle human sponsorship?

A verified workload identity and a separate human sponsor are required for admission. The sponsor verifies the identity and constraints but does not propose the action.

What is the role of the public claim ledger?

The public claim ledger documents stated assumptions, explicit non-claims, and their respective falsifiers and statuses. It allows third parties to verify the boundaries of the research.

Conclusion

Verifiable Proof Systems provides a robust framework for enhancing collaboration within design partnerships. By separating computation, authority, and consequence, it ensures that all actions are backed by independent evidence. The system is a research initiative that aims to publish future companion papers with model-checking and proof results. To discuss a design-partner pilot, . according to Frequently Asked Questions