Infrastructure for verifiable authority.

Verifiable Proof Systems

Software now proposes consequential actions faster than anyone can review them. A proposal is not permission, and permission is not the effect.

Verifiable Proof Systems is building the boundary where a proposed action either becomes a consequence or is refused. Admission requires independent evidence, bounded authority, verified identity, continuous state and declared constraints, and every decision at the boundary is recorded, refusals included.

Intelligence may propose. Authority must be independently established.

Paper CEAK-PRO 1.0 DOI 10.5281/zenodo.23092344 Published

Research and SBIR/STTR collaboration

Three ways to work with VPS

Working with VPS

  • Design partners

    A four-week, fixed-fee pilot on one of your systems, closing with a letter of intent if the criteria agreed in week one are met.

    See the pilot
  • Research partners

    Open problems from the paper's evidence program, for university groups in formal methods, runtime verification and AI security.

    See the research agenda
  • SBIR/STTR teams

    VPS is preparing an NSF SBIR/STTR Phase I proposal and is forming a team with a university research partner.

    See collaboration models

Outputs are not proof.

The problem

Models now propose tool calls, database writes, payments and setpoint changes. A candidate action is cheap to produce. Its consequence can be expensive, or impossible to undo.

Often treated as permission today

  • Model confidence, or a fluent explanation
  • A passing unit test
  • A signed artifact from the proposing system
  • Lagging runtime telemetry
  • A safety filter the command passed

Each of these is testimony about a proposal. None of them admits the transition.

Computation is not authority. Authority is not consequence.

The approach

  • Computation

    Generating a candidate action, whether by a model, a planner, a filter or a person. It carries no permission and no effect.

  • Authority

    Bounded permission over a named object, under explicit limits. A good proposal does not create it.

  • Consequence

    A change to authoritative state, or to a physical actuator. Logging an intent is not one.

One boundary, three planes

  1. Plane A, Proposal. Untrusted. Models, planners, tools and people propose. It holds no authority over production state or a plant.

  2. Plane B, Admission. A small, deterministic check of the attempt and its predicted effect, under a fixed policy.

  3. Plane C, Execution. Minimal. It carries out only what Plane B authorized, and records the outcome.

Admission requires all five, together

  1. Independent evidence, not produced by the proposer
  2. Bounded, single-use authority, scoped to the predicted effect
  3. A verified workload identity and a separate human sponsor
  4. State and sequence continuity
  5. Declared constraints satisfied

Commit also requires a durable decision record before any effect. Rejected attempts are recorded too.

No action without authority. No authority without evidence.

Defined in the paper, sections 4 to 7.

What is new, and what exists today

Claims and evidence

Established, and not claimed as new

  • Control barrier functions
  • Runtime assurance (the Simplex pattern)
  • Object and linear capabilities
  • Proof-carrying code
  • Tamper-evident logs
  • Pre-action gates for agent tool calls

The contribution

  • Requiring five assurance conditions to hold together at one consequential boundary.
  • The lifecycle around the commit: a decision record before any effect, a recoverable commit, and an audit of rejected attempts as well as committed ones.

Status

Status of VPS research outputs, October 2026
ItemStatusAccess
Conceptual paper, CEAK-PRO 1.0Published 2 October 2026Public, CC BY 4.0
Claim ledger: 115 entries (every claim, stated assumption and explicit non-claim), each with its basis, a falsifier and a status Published with the paperPublic
Bounded TLA+ lifecycle model, and a SPARK reference implementation of admission logic In developmentCompanion paper
Working implementation and test results InternalDesign partners, under mutual NDA

The paper reports no model-checking, proof or implementation results. Those will be published in a companion paper, with witnesses showing that each checked path was actually exercised. Where the paper cites IEC 61511, the NIST AI Risk Management Framework or the EU AI Act, it does so as motivation, not as a claim of certification or compliance.

Signed is not true. Hashed is not trusted. Auditable is not correct.

Four weeks, one system, a fixed fee

Design-partner pilot

  • $5,000 fixed fee
  • Four weeks
  • Mutual NDA

How it runs

  1. Week 1. Scope one system, such as an agent workflow with tool access, or a codebase. Agree the success criteria in writing.
  2. Weeks 2 and 3. Assess which claims about the system are supported, what supports them, where the evidence stops, and where a proposal can reach a consequence with no admission check.
  3. Week 4. Report and walkthrough, with findings ranked by what to fix first.

At the end, if the criteria agreed in week one were met, we ask for a letter of intent for follow-on work.

Who it fits

  • AI platform teams. Agents with tool access, where a proposed action becomes a production change.
  • Technical due diligence. Claims about a codebase, checked against what can be observed in it.
  • Regulated software. Teams preparing for the EU Cyber Resilience Act, whose main obligations apply from 11 December 2027.

What you receive

  • Current-state findings
  • Evidence inventory
  • Contradiction register
  • Unknowns register
  • Risk and dependency findings
  • Stabilization priorities
  • Executive view
  • Technical view

The assessment does not certify a system, predict its future behavior, or turn incomplete evidence into confidence. It gives you a defensible starting point.

VPS is taking a small number of design partners this quarter.

Discuss a pilot

Research partners and SBIR/STTR

Research

The paper is deliberately conceptual. Its evidence program is where we want university collaborators.

Computation Is Not Authority, Authority Is Not Consequence: A Conceptual Framework for the Consequential-Transition Boundary

Adam B. Straughn Verifiable Proof Systems Version 1.0 Conceptual working paper (preprint) Zenodo, 2 October 2026 CC BY 4.0

The paper separates three roles that deployed systems often conflate: computation (candidate generation), authority (bounded permission on a designated object) and consequence (a change to authoritative state, or actuation). It requires five assurance conditions to hold jointly at one consequential-transition boundary, and states ten invariants as claims, with a safety-case structure, an assumption register and a claim ledger. It reports no model-checking, proof or implementation results.

Cite this paper

Text citation
Straughn, A. B. (2026). Computation is not authority, authority is not consequence: A conceptual framework for the consequential-transition boundary (Version 1.0) [Preprint]. Zenodo. https://doi.org/10.5281/zenodo.23092344
BibTeX
@misc{straughn2026ceakpro,
  author    = {Straughn, Adam B.},
  title     = {Computation Is Not Authority, Authority Is Not Consequence: A Conceptual Framework for the Consequential-Transition Boundary},
  year      = {2026},
  version   = {1.0},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.23092344},
  url       = {https://doi.org/10.5281/zenodo.23092344},
  note      = {Conceptual working paper (preprint)}
}

Open problems we want to work on with university groups

  1. Model checking with reachability witnesses. Bounded lifecycle models whose results come with evidence that admission, reservation, authorization and execution states were actually reached, and that injected faults are detected.
  2. Non-circular contracts for an admission monitor. SPARK 2014 contracts whose postconditions do not follow from their preconditions alone.
  3. Adversarial evaluation of admission. Prompt-injection, replay and time-of-check-to-time-of-use attacks against single-use authority and state-bound admission, reported as independent evidence.
  4. Runtime monitors from temporal and deontic specifications. Monitors that feed admit or deny decisions at a consequential boundary.
  5. Soundness of predicted-effect evaluation. Conservative abstractions and certificate checking for the predicted-effect manifest.
  6. Continuous-control adapters. Control-barrier-function filtering under sensor noise, latency and solver degradation.
  7. Independent receipt verification. Verifiers for audit chains that include rejected attempts.

SBIR/STTR collaboration

VPS is preparing an NSF SBIR/STTR Phase I proposal in trustworthy AI for the 2027 cycle, and is forming a team with a university research partner.

Ways to collaborate

  • STTR. A university co-principal investigator, with the research institution performing a defined share of the work.
  • SBIR subaward. A scoped research package performed by a university group under a VPS-led award.
  • Letter of collaboration. For a proposal, before any funded work.

We agree intellectual-property and publication terms before work starts, including review windows for papers, so collaborators can publish.

Propose a collaboration

Public record and partner dataroom

Access

Everything VPS has published is public and linked from this page. Material for design partners, research partners and investors is shared in a private dataroom, by invitation, one person at a time.

Partner dataroom

  • Design partners. Pilot materials and agreement templates, after a mutual NDA is signed.
  • Research and SBIR/STTR partners. Collaboration models and templates.
  • Investors. Investor materials.

Dataroom access on request.

Request dataroom access

Founder

I came to this problem through operations, audits, compliance, and environments where mistakes had immediate real-world consequences.

Vps did not begin by asking what increasingly intelligent systems could do. It began by asking what no system should be permitted to make consequential without evidence, bounded authority, and an independently enforceable decision boundary.

Adam B. Straughn

Founder, Verifiable Proof Systems