Your AI agent said "done." What would prove it?

AI-assisted disclosure: I used AI tools to help edit this article and the
open-source project it describes. The architecture, tests, deployment evidence,
and claim boundaries were reviewed against the public repository and live
service before publication.

I created this piece of content for the purposes of entering the All Things
Agentic Hackathon.

An autonomous agent can produce a confident status update long before the work
is actually complete. A deployment command can exit successfully while the
public endpoint still fails. A marketplace can display an opportunity that the
authoritative issue has already closed. A generated report can look finished
while one required source is stale.

The problem is not that language models cannot reason. The problem is that
“done” is a state transition, and state transitions need evidence.

I built Proofline to test a
simple pattern: let the model interpret the task, but make a deterministic gate
decide whether the evidence is sufficient.

Separate interpretation from acceptance

Proofline divides the workflow into two layers.

The agent layer uses Gemini 3.6 Flash and Google Agent Development Kit to:

1. interpret the task contract;
2. identify the requirements that need proof;
3. explain missing or contradictory evidence;
4. call a narrowly scoped evaluation tool.

The verification layer then applies explicit rules. It does not ask the model
whether the task feels complete. It evaluates structured evidence and returns
one of four states:

• NEEDS_EVIDENCE — at least one requirement lacks fresh authoritative proof;
• CONFLICT — authoritative sources contradict one another;
• APPROVAL_REQUIRED — the evidence is complete, but the next action has an external side effect;
• READY — every requirement is satisfied and no approval gate remains.

That split matters. The model remains useful where language and context are
messy, while the acceptance boundary stays inspectable and testable.

Make evidence a first-class object

Each evidence item carries more than a sentence saying something worked. It
records the requirement it supports, its source, whether that source is
authoritative, when it was observed, and the value that was actually returned.

A deployment claim, for example, should not be supported by “the command
succeeded.” Better evidence is an external HTTP response from the deployed URL,
the active revision identifier, and a timestamp inside the allowed freshness
window.

The same rule applies outside infrastructure. If a payment platform reports a
test balance, it cannot prove live revenue. If a bounty marketplace says an
issue is open but the repository says it is closed, the authoritative issue
wins and the conflict should stop the workflow.

Hash the decision packet

Once the gate evaluates the evidence, Proofline serializes the result in a
canonical order and computes a SHA-256 packet hash. The hash does not make a
weak claim true. It makes the exact decision inputs and output tamper-evident.

This is useful when an agent runs asynchronously. A reviewer can verify that
the packet being approved is the same packet the gate evaluated. If any
requirement, evidence item, timestamp, or decision changes, the hash changes.

Keep external actions behind a human boundary

Evidence can prove that a form is complete; it cannot decide whether a person
wants to submit a legally binding entry, publish a message, or spend money.
Proofline therefore treats those actions as a separate approval state.

This prevents a common automation mistake: combining technical readiness with
permission to act. The agent can prepare everything and prove that preparation,
but the final side effect remains explicit.

Prove the architecture with a live path

The public demonstration runs as a Google ADK application on Cloud Run. An
external request can discover the proofline app, create a real ADK session,
invoke Gemini, and call the deterministic evaluation tool. The repository also
contains a credential-free test path so the safety boundary can be inspected
without cloud access.

The deployed demo currently uses in-memory state. Firestore and Pub/Sub are
documented extension points for durable packets and asynchronous rechecks; they
are not presented as active components. That distinction is intentional:
architecture diagrams should separate what is live from what is planned.

A practical checklist

Before allowing an agent to declare a real task complete, ask:

1. What exact requirement is being satisfied?
2. Which source is authoritative for that requirement?
3. Is the observation fresh enough for the decision?
4. What happens when two authoritative sources disagree?
5. Can the decision be reproduced from structured inputs?
6. Does the next step create an external side effect?
7. Can a reviewer distinguish deployed components from planned ones?

If those questions do not have explicit answers, the agent probably has a
status message, not proof.

You can inspect the implementation, tests, architecture, and deployment
evidence in the public Proofline repository,
watch the 2:53 live demonstration, or verify the
Cloud Run application discovery endpoint.

---

If you want an external evidence audit for a launch or automation, RELAUNCH DEPT. offers a USD 59 evidence audit and a USD 249 implementation sprint. These are operational services, not legal, tax, or financial advice.