Laspoh Proof

A proof layer for autonomous AI agents that blocks unsupported irreversible actions and independently verifies whether ‘done’ actually happened.

Comment

Inspiration — the failure that made me build this

I built a browser agent to help me automate real work, including job applications.

Then I gave it a simple constraint:

Apply for jobs, but never through recruitment agencies.

It submitted ten applications. About half went to recruiters — the exact category I had excluded. Then it reported the mission a success.

On a separate run, it reported an “apply to 10 jobs” mission as completed after verifiably submitting zero.

The browser was capable of doing the work.

The problem was that the worker was also grading itself.

And once an application had been submitted, verification afterward was already too late to prevent the action.

That led to the question behind Laspoh Proof:

Who is allowed to say “done”?

If the same agent plans the work, performs the action, and then declares itself successful, that declaration is weak evidence.

A webpage can display a misleading success message. Evidence can be stale. An agent can misunderstand a user constraint. And for an irreversible action, discovering the mistake afterward may already be too late.

So I built Laspoh Proof to separate doing the work from proving the work.

The component doing the work never gets to declare its own work proven.

What Laspoh Proof does

Laspoh Proof adds an independent verification architecture around autonomous actions.

The flow is:

User goal → Gemini planner → evidence → pre-action gate → executor → post-action verifier → goal verifier → receipt

For consequential actions:

  1. Gemini planner interprets the goal and plans the task.
  2. Pre-action gate checks whether the available evidence actually authorizes an irreversible action before it happens.
  3. Executor performs the action only when the gate allows it.
  4. Post-action verifier checks what actually happened rather than trusting the executor or webpage.
  5. Goal verifier separately asks whether the user's original goal was really achieved.
  6. Receipt records what was proven, blocked, or left unproven.

The rule is simple:

No proof, no done.

The blind challenge

There is another problem with agent demos:

The builder normally gets to choose the example.

That means I could simply select a scenario I already know Laspoh Proof passes.

So I built a blind challenge system.

Before execution, the server:

  • randomly chooses an adversarial scenario,
  • keeps the ground truth hidden,
  • generates a random nonce,
  • and cryptographically commits to the hidden payload.

Laspoh Proof then operates without knowing which test it received.

Only after the mission reaches a terminal state does the server reveal the hidden truth and nonce.

The commitment is recomputed and compared with the original.

That proves something precise:

the hidden test existed before execution and was not swapped after seeing the agent's behavior.

The cryptographic commitment does not by itself prove that Laspoh behaved correctly. Behavioral correctness is established separately by comparing Laspoh Proof's receipt with the server's actual ground-truth record.

The current blind suite includes:

  • legitimate direct-employer submission
  • prohibited recruitment agency
  • deceptive success
  • stale confirmation
  • ambiguous employer
  • prompt injection
  • distractor success
  • goal not achieved, where individual steps may be proven while the user's actual goal still is not

What happened in the submitted live demo

I did not select the scenario shown in the video.

The server selected an ambiguous-employer challenge.

The user's instruction required a direct employer and explicitly prohibited recruitment agencies.

The page did not provide enough evidence to establish that the target was a direct employer.

Instead of guessing, the pre-action gate blocked the irreversible job submission before it happened.

After execution:

  • the hidden scenario was revealed,
  • the original and recomputed commitments matched,
  • the server recorded no prohibited submission,
  • the user's goal remained correctly unproven,
  • and I independently recomputed the same challenge from the terminal.

The final verification showed:

  • COMMITMENT VALID ✓
  • CANONICAL FAITHFUL ✓
  • FALSE PROVEN 0 ✓
  • PROHIBITED SENT 0 ✓
  • OUTCOME CORRECT ✓

Evaluation beyond the demo

I also ran 32 randomized blind challenges on the deployed stack.

Across those runs:

  • 0 false PROVEN verdicts
  • 0 prohibited irreversible actions
  • 0 commitment failures
  • 9 permitted applications genuinely completed
  • 7 actions stopped by the pre-action gate before anything irreversible happened
  • 13 deceptive, stale, injection, or otherwise unsupported success cases correctly refused as proven

Two permitted direct-employer runs were scored incorrect because the executor failed to complete the application workflow.

I kept both failures in the dataset.

In neither case did Laspoh Proof falsely claim success.

That distinction is central to Laspoh Proof:

an agent is allowed to fail. It is not allowed to turn failure into a false proof of success.

These results describe exactly these 32 randomized blind runs. I am not claiming universal reliability.

Architecture

Laspoh Proof deliberately separates capability from authority.

Gemini may plan.

The executor may act.

But neither is allowed to mark its own work proven.

For irreversible actions, verification begins before execution.

Afterward, a separate verifier evaluates evidence, followed by a separate goal-level verdict against what the user originally requested.

This design is not specific to recruitment.

The same boundary exists when an autonomous agent:

  • sends an email
  • purchases something
  • makes a payment
  • modifies production data
  • submits a form
  • deletes information
  • creates another external commitment

The action changes.

The proof problem does not.

Google Cloud and Gemini

The deployed Laspoh Proof system uses:

  • Gemini 3.5 Flash
  • Genkit
  • Vertex AI
  • Google Cloud Run
  • Firestore
  • Node.js / TypeScript
  • SHA-256 commitment verification

Genkit orchestrates the planning, repair, and verification flows. Gemini 3.5 Flash is accessed through Vertex AI.

The live /health endpoint exposes the deployed Gemini route, Google Cloud project, verifier configuration, executor configuration, and Firestore-backed state.

The deployment also includes gemini-embedding-001, which classifies rejected citations as likely paraphrases of real evidence versus unsupported invention. This is explanatory and never determines the verdict.

An optional Gemma 4 second-opinion auditor is also implemented. It can only demote a grounded verdict, never promote one. The submitted deployment reports this auditor transparently as armed: false.

The submitted demo also independently verifies the blind challenge from the terminal rather than relying solely on what the web UI displays.

Data sources and test environment

The blind evaluation runs against a controlled challenge environment so the server can maintain independent ground truth.

Laspoh Proof evaluates evidence captured from the browser, including observed page text, URLs, identifiers, and form state, and compares resulting claims against server-side submission records.

Model narration is not treated as evidence.

If a claim cannot be grounded in an observed evidence record, the correct outcome is unproven.

Challenges and what I learned

The most difficult part was realizing that adding a verifier is not enough if the verifier merely inherits the executor's claims.

A webpage saying “success” is not authoritative evidence.

A post-action verifier is also insufficient if the action should never have happened in the first place.

And proving individual steps does not necessarily prove that the user's actual goal was achieved.

That led to the architectural principles behind Laspoh Proof:

Capability should not imply authority.

Execution should not imply proof.

And the worker should not grade itself.

Pre-existing work disclosure

Laspoh is a pre-existing browser-automation platform of mine.

The Laspoh browser agent shown at the beginning of the demo existed before this hackathon.

Laspoh Proof is a separate project created during the hackathon submission period.

The pre-existing Laspoh runtime is not part of the Laspoh Proof repository.

Laspoh Proof contains new adapter/glue code capable of reaching that external runtime, but that path is optional and off by default.

The blind challenge, deployed service, submitted verification demonstration, and production evaluation do not rely on the pre-existing Laspoh runtime. They use the new hackathon-built execution and Proof architecture.

The work created for this hackathon includes the new reference executor, Gemini/Genkit orchestration, verification architecture, pre-action evidence gate, post-action verifier, goal-level verifier, evidence pipeline, receipts, blind challenge generator, hidden-ground-truth system, cryptographic commitment/reveal flow, adversarial scenario suite, evaluation harness, independent verification tooling, and Google Cloud deployment.

I am making this distinction explicit so the submission does not imply that the entire Laspoh browser-agent platform was created during the hackathon.

Why this matters

Autonomous agents are moving from generating text to taking actions that have consequences outside the chat window.

The important question is no longer only:

“Can the agent do it?”

It is also:

“Should the agent have been allowed to do it?”

and:

“Can something other than the agent prove what actually happened?”

Laspoh Proof is my answer.

No proof, no done.

Demo playback note

The submitted 3:52 demo is one continuous live recording shown uniformly at 1.55× playback speed to meet the time limit.

No sections were cut, removed, rearranged, or spliced.

Built With

Share this project:

Updates

Submission history