Context without boundaries
Unbounded chat history and retrieval can bury the current job in irrelevant context and increase accidental data exposure.
Owlhoot · AI completion assurance
Make AI completion claims verifiable.
Provably Done is a private-preview assurance layer for AI coding workflows. It is designed to tie completion claims to scoped evidence and withhold an Owlhoot verdict when required checks are missing.
The enforcement engine remains private. The open verifier makes the public verification boundary inspectable.
The assurance gap
AI workflows produce abundant activity. Completion claims remain difficult to verify.
Orchestration moves work, observability records events, and governance states rules. Owlhoot is developing a separate evidence-based decision point for completion claims.
Activity without proof
A trace can show that an agent took actions. It does not by itself establish that required evidence exists or that the output is correct.
Policies without decision criteria
Rules written only in prose are difficult to evaluate consistently. Assurance requires explicit requirements and reviewable evidence.
Provably Done · private preview
Separate the completion claim from the evidence used to evaluate it.
Provably Done is designed as an assurance layer around consequential agent work: declare scope, collect evidence, evaluate configured requirements, and produce a separately verifiable result.
Current state: private preview; production deployment is not available.
Durable work record
Relevant decisions, requirements, and evidence can remain queryable beyond a single chat session.
Context control
Task-relevant context can be selected deliberately, with access to additional context recorded.
Evidence checks
Configured artifacts can be integrity-checked and associated with the declared work before an Owlhoot verdict is issued.
Separate verification
A completion result can be checked separately from the agent's own narrative.
Assurance boundary
The completion claim and the verification result are separate.
In Owlhoot's model, agent narration can request a completion verdict; a separate verification path evaluates the supplied evidence.
Declare
Define the job, completion criteria, and evidence required.
Collect
Capture evidence produced by the workflow and associate it with the declared job.
Evaluate
Check whether required evidence is present and passes the configured integrity checks.
Verify
Produce a result that can be checked separately from the agent's own summary.
Required check missing or invalid → Owlhoot verdict withheld
Local SQLite assurance ledger Configured work records, evidence references, and verification outcomes remain reviewable outside the agent's narrative.
Reproducible public proof
Inspect the verification boundary yourself.
The public repository demonstrates the verification side without publishing the private enforcement or issuance implementation.
The signed demo and listed evidence verify against the separately supplied demo trust root.
A bundle signed by a key absent from the separately supplied demo trust root returns INCOMPLETE.
Changed signed fields or changed evidence bytes are refused.
Open verifier
Verification is separate from the private enforcement engine.
The verifier checks a signed certificate and its listed evidence against the issuer trust root supplied to that invocation. It does not determine who controls that trust-root file, issue certificates, or determine whether the agent's underlying business output is correct.
PUBLIC TEST OUTCOMES
Pinned dev-pass fixture PASS
Demo key absent from supplied trust root INCOMPLETE
Tamper regression cases FAILA narrow, inspectable verification contract.
The public verifier checks the following boundaries and intentionally makes no broader correctness claim.
| Boundary | Public verifier behavior |
|---|---|
| Pinned issuer | The signing key must be present in the separately supplied issuer trust root. |
| Signature | The signed certificate payload must verify against that issuer key. |
| Evidence integrity | Listed evidence files must match their signed SHA-256 hashes and byte lengths. |
| Evidence inventory | Required evidence types and the aggregate evidence inventory must match the signed certificate. |
| Portable paths | Evidence references must be safe relative paths contained inside the bundle directory. |
A verifier PASS establishes only that the supplied bundle satisfied the verifier's declared cryptographic and evidence-integrity checks against the trust root supplied to that invocation. Treat PASS as a trust decision only when that trust root is selected and controlled outside the claimant or agent boundary. PASS does not establish that the underlying output is correct, complete in the real world, bug-free, suitable, compliant, production-ready, or independently certified. The fixtures are development examples, not production certificates or a third-party audit.
Who it is for
For teams where false “done” is expensive.
The strongest fit is accountable operators of consequential AI workflows: teams that need evidence stronger than a transcript.
If an AI system reported completion without sufficient evidence, who would be affected—and who would need to explain it?
- Coding agents shipping production work
- AI platform teams and infrastructure builders
- Security, data operations, and compliance workflows
- Regulated or audited operations where evidence matters
Current focus
Make the narrow claim reproducible before expanding it.
Owlhoot is concentrating on a private-preview completion-assurance boundary and a public verifier. Additional capabilities will be announced only after security review and benchmark evidence support them.
Validate the boundary
Work with design partners to test the assurance model before making production claims.
Keep verification inspectable
Publish the verification format, examples, refusal cases, and automated regression tests.
Earn stronger claims
Do not publish broader capability claims until reproducible evidence supports them.
Declared evidence can be checked; agent prose alone is insufficient.
Design-partner access
Bring us a workflow where an unsupported completion claim has a real cost.
Owlhoot is looking for teams using coding agents in accountable workflows. Describe only the workflow category and high-level business impact; do not submit operational or security details.
Provably Done is private-preview software. Production deployment is not available.
Straight answers
Underclaim. Verify. Then earn the stronger claim.
A trust product should be explicit about what is implemented, what has passed, and what is still gated. That standard applies to Owlhoot too.
What is Provably Done?
Provably Done is Owlhoot's private-preview assurance layer for AI coding workflows. It is designed to connect declared completion requirements, supplied evidence, an Owlhoot verdict, and a separately verifiable result.
Is Provably Done just certificate software?
No. A certificate is the portable receipt. Provably Done is the assurance workflow intended to connect declared requirements, evidence checks, and that separately verifiable result.
How is this different from agent observability?
Observability records what happened. Provably Done is designed to evaluate whether the evidence configured for a declared job is present before Owlhoot issues its verdict. Traces can contribute evidence; they are not authority by themselves.
What does a public verifier PASS mean?
PASS means the supplied bundle satisfied the public verifier's declared cryptographic and evidence-integrity checks against the trust root supplied to that invocation. Treat PASS as a trust decision only when that trust root is selected and controlled outside the claimant or agent boundary. PASS does not establish that the underlying output is correct, complete in the real world, bug-free, suitable, compliant, production-ready, or independently certified.
Does Provably Done guarantee bug-free work?
No. Novel failures can still exist, and no verification result guarantees bug-free output. The system can evaluate only the requirements and evidence checks that were actually configured.
Is production deployment available?
Not yet. Provably Done is in private preview. The public repository demonstrates the verification boundary; production deployment and issuer controls remain under validation.
What can I inspect today?
The AuditGrade Verifier repository includes public demo bundles, refusal cases, automated tests, and the preview certificate format. The private enforcement and issuance implementation is not included.
Founder note
Built for work where “looks right” is not enough.
AI coding agents can produce useful work and still report completion without sufficient evidence. In consequential workflows, that gap costs time, money, and trust.
I spent 12+ years building financial reporting and planning systems where errors had real consequences. The durable lesson was to design controls into the workflow, not rely on more manual checking.
Owlhoot applies that principle to AI agent work: evidence over assurances, explicit limitations, and completion claims that can be checked separately from the agent's narrative.