Controlled live experiments establish the verification pattern. A local lab now adds adversarial scenarios, restart recovery, authenticated evaluator receipts, and a usable console. Each result has a boundary; none establishes production readiness or customer adoption.
The implementations differ, but continuation is never justified by a success label alone. It depends on independently observed state and an explicit requirement.
Varqo proved that action.status = completed is not enough when the workflow depends on the resource itself. A controlled mismatch remained UNRESOLVED / HOLD; a later composite run released only after both action and resource state were verified.
A real Azure-AsyncOperation verifier URL became available only after the write. Varqo bound it safely, executed it independently, observed provider native Succeeded, and returned VERIFIED.
A runtime build identity was bound into BatchGetBuilds, selected by exact identity from a batch response, and independently polled through five IN_PROGRESS observations to SUCCEEDED.
A real OpenAI tool agent requested completion before proof was ready. Varqo kept the dependent call held for about 9.78 seconds, then recorded one durable HOLDING → RELEASED transition after VERIFIED.
A wrapper claimed an issue was closed while deliberately skipping the mutation. An independent GitHub read still found it open. A real close followed by another independent read then verified the required state.
Small frozen corpora across DigitalOcean, Stripe, and AWS CodeBuild tested task modality and schema-bound requirements. They are now diagnostic data, not fresh accuracy benchmarks or live integration evidence. Ambiguity calibration remains open.
Evidence scope: controlled technical proofs of the integrity kernel and a narrow local control boundary. Not evidence of broad enterprise deployment, generic interception, distributed exactly once execution, or generic recovery.
Varqo's strongest claim today is not that every agent workflow is solved. It is that the verification and control kernel is surviving materially different provider topologies and increasingly adversarial execution conditions.
Within the supported routes, task and policy intent, provider schema, operation shape, and runtime context can compile into executable verification plans without a caller hand authoring the full proof profile.
Plans can be prepared and persisted ahead of execution, then safely rebound to provider returned action or resource identities at runtime.
VERIFIED may release. Explicit failure may block. Missing, malformed, ambiguous, timed out, or unavailable proof remains held rather than being promoted to permission when policy requires proof.
The proof chain preserves the conditions, authoritative observations, verdict, and gate result needed to explain a decision while minimizing sensitive runtime data.
These capabilities are exercised against a synthetic local provider or local storage. They extend the technical evidence without turning it into a production deployment claim.
Persisted plans survive a process boundary and bind the real resource identity. Compatible local runtime activation makes zero semantic calls; missing or mismatched plans fail closed. This does not eliminate provider polling time.
Event-specific allowlists omit arbitrary raw tasks and provider bodies, retain requirement-bound observations, and pseudonymize identities. Sentinel tests cover secret leakage into JSONL and SQLite.
Deterministic scenarios cover premature requests, false success, forged identity, wrong dependencies, replay, failed verification, divergence, and timeout. The recorded baseline passed all nine safety expectations with a synthetic provider.
Captured work survives process exit. A new process leases and revalidates it, completes independent action and resource proof, and applies one idempotent local effect. Competing recoverers and mismatched work are tested.
Commit and release require an authenticated local evaluator receipt bound to the work and evidence. Tampered or missing receipts cannot authorize a new effect. The same-account key is not a production authenticity boundary.
A locally installable Python wheel includes the CLI and console: five fixed workflows, saved runs, state comparisons, projected export, and explicit resume. The console uses a synthetic provider and a local effect.
Explore the local lab →Technical results, product direction, and customer hypotheses answer different questions.
Supported provider reads, a controlled local continuation gate, reusable plans, minimized evidence, adversarial local scenarios, and captured-work recovery.
Pre-action facts, memory provenance, multi-agent handoffs, distributed enforcement, broader dependencies, and safe retry or compensation with verified recovery.
Enterprise demand, willingness to pay, production cost and latency, generalization to unseen interfaces, and integration effort still need evidence from scoped customer evaluation.
Next falsifiable test: an engineer who did not build the local console installs it, completes success, divergence, and restart scenarios, and explains each gate decision from the UI. Then validate a real adapter and an idempotent external effect.
We want to map what that workflow relies on, which state must be independently proven, where continuation should be gated, and what a safe recovery path would require.