Surface · Output
The answer
The visible result looks right or wrong. Most evaluation stops here.
Observed result“The task completed.”
But what changed around the model, and can the result be trusted?
Independent AI lab
EXPLORE FAILURE.Enjoy progress.
Open tools for exploring local AI and the systems around it, and for keeping what happens when they fail.
Building local?
This is an open invitation to people experimenting with AI on hardware they control.
Give it a real job.
See what actually happened.
Your hardware. Your models. Find out what they can do.
Harness Workbench runs a local model and coding agent on a real job, checks the result independently, and keeps the setup that worked.
“Done” is a claim.
Check it.
One real job, independently checked.
01 / JobGive the agent a real task
02 / RunOn your hardware
03 / ProveIndependent checks
04 / KeepSave a Recipe
Receipt / Tool interference
Verification at release
534automated tests · zero runtime dependencies
Why this exists
The more useful work you can do with local models, the more autonomy you have.
A smaller model that works for your needs lets you put your own hardware to use, choose your tools, and keep everyday compute close to home. You can experiment, learn, and keep working on your own terms.
Harness Workbench exists to help you explore that possibility: find out what works locally, understand its limits, and keep building on it. Freedom to compute becomes more useful when you know what you can actually do with it.
Built around the freedom to compute: choose your tools, inspect your results, and build on what you learn.
Local AI, on your terms.
Give your local model and coding agent a real job. Harness Workbench checks the result independently, keeps the evidence, and saves a Recipe you can run again. The agent saying “done” doesn’t earn a pass.
Python 3.11–3.14 · Linux + macOS · Apache 2.0 · Very experimental
Release evidence: v0.2.0 public release · Documentation, platforms and dependencies. The 534-test count comes from that release’s test suite.
The model is only one part of the system.
This is the path the lab is building toward.
A useful result can still become untrustworthy or unusable as the layers around it change. EXPLORE FAILURE works progressively deeper.
Deeper · Harness
What shaped the answer
Instructions, tools, context, state, and verification determine what the model could actually do.
Public instrument · Available nowHarness Workbench
Give a model a real job, check what actually happened, and keep the setup that worked.
Deeper still · Evidence
Why the claim deserves trust
A result should carry its sources, uncertainty, provenance, and unresolved support.
In development · UnreleasedPortable proof
The claim can travel without pretending its uncertainty disappeared.
Deepest · Continuity
Whether the work can continue
Methods, tools, evidence, and working state must survive the original provider and environment.
In development · UnreleasedThe downloadable research lab
Reopen the research as working practice, not merely as a report.
Build locally. Explore freely.
Keep the work local. Borrow the compute when needed.
Local AI gives you the freedom to choose your models, protect your data, and work on your terms. When you need more capacity, use rented compute while keeping control of the work.
Work Engine · Exploring the idea · Unreleased
Persistent foundation
Local hardware
Private data, durable state, and everyday work.
Control layer
Work Engine
Routes work and preserves its history across environments.
Temporary capacity
Rented compute
Additional scale for workloads that need it.
Building the path.
EXPLORE FAILURE is working toward a future where you choose your models, control your data, and keep the work you build. Start locally, borrow compute when needed, and carry your progress with you as tools and providers change.
Decide where work runs without moving the entire working environment.
Preserve files, context, tools, and progress as work moves between machines.
Record what left, where it ran, what changed, and what came back.
My wife made
me add this
me add this
Local first. Freedom to explore.
Keep control of your work & The freedom to decide what comes next.
About the lab
What is EXPLORE FAILURE?
EXPLORE FAILURE is an independent AI lab building public tools and experiments around AI systems, local computation, evidence, and continuity of work.
Who runs the lab?
EXPLORE FAILURE is an independent, one-person AI lab founded by Garrett Davis in 2026.
What does the lab study?
The lab studies local AI systems and develops tools that support computational independence, local ownership, and the freedom to work without permanent dependence on a single provider.
Why focus on local AI?
Local AI protects the freedom to compute on your own terms, with ownership of your data, models, and working environment.
Why combine local and rented compute?
Local compute provides ownership and independence. Rented compute adds scale when needed, without making permanent dependence the default.
How can I follow or contribute?
Follow ongoing experiments on X and inspect public tools on GitHub. Focused issues, tests, documentation, and technical conversation are welcome.
Harness Workbench
What can I do with Harness Workbench?
Give a local model a real job, see what actually happened, and keep the setup that worked. Today that means one coding Reality Check: a local agent fixes a Python bug, Workbench checks the result independently, and saves a Recipe you can rerun.
What do I need to try it?
Python 3.11–3.14 on Linux or macOS, Ollama running gpt-oss:20b with enough memory, and Pi 0.84.1 with Node 22.22.3. Workbench doesn’t install these or download models for you. Then run hwb try coding/python-bug-fix.
What do I get after a run?
A verdict, the facts behind it, the files that changed, a sealed run record, and a Recipe to try again. If it didn’t pass, it tells you why, and it lists what it couldn’t see.
Can I use it with my own project?
Yes, through the experiment engine underneath. Any command can be a workload, and you can preserve attempts, introduce faults, and compare runs. Experimental builders also let you give your own tasks and checks to Pi, OpenCode, and Hermes.
What is a Reality Check?
One recognizable job with clear success conditions, run on your setup and checked independently. The first one asks a local coding agent to fix a Python bug in a throwaway practice project.
Why not just trust the agent?
Because “done” is a claim. Workbench checks that the tests failed before the repair and passed after it, that only the permitted file changed, that the agent actually ran the required test before and after its edit, and that the record is intact.
What do the verdicts mean?
PASS: every required fact is established. PARTIAL: the repair went green, but another required condition failed. FAIL: trustworthy evidence shows the repair didn’t work. INVALID: the setup or evidence can’t support a verdict. That’s a setup failure, not a failed repair.
What is a Recipe?
Your saved setup: configuration, task, fixture, tests, and a rerun command. Only the model selection is meant to be edited. Changes to anything else are detected and rejected. Rerunning tries the same setup again; it doesn’t promise identical behavior.
What is a harness?
Everything around the model: instructions, tools, context, state, retries, guardrails, memory, verification, and the code that connects them. It shapes what the model can actually do.
Is this a model benchmark?
No. A pass is evidence that this setup did this job. It isn’t a model-quality score or proof of general coding ability. Run it again to see how consistent the result is.
Does it require an AI model?
The Reality Check does. The engine doesn’t: deterministic workloads, like the included flaky example, take the model out so you can study retries, tool failures, and evidence capture without model randomness.
Which agents and runtimes does it support?
The Reality Check supports Pi with Ollama only. Experimental builders support Pi, OpenCode, and Hermes. Experimental measurement covers Claude Code, Codex CLI, DeepSeek Harness, Hermes Agent, and Pi. More runtimes and tracing integrations are planned. Local models come first; hosted APIs work through supported routes and may cost money.
What is available now?
v0.2.0, a signed public GitHub release with a wheel, source archive, checksums, and a release-conformance record. It includes one coding Reality Check plus the experiment engine. It isn’t on PyPI.
How experimental is it?
Very. It’s early, built by one person, and setup can be rough. Known v0.2.0 issue: if your copy of gpt-oss:20b differs from the one the profile expects, the check returns INVALID before the agent starts. A fix is in development.
What’s coming next?
The Lab, a local web interface for runs, proof, and Recipes (prototype, unreleased). Also planned: built-in harness support, compare-and-stress-test, tool-use inspection, and shareable Proof Cards. These are directions, not current features.
Does a sealed record prove what happened?
It proves the saved files haven’t changed since the run. It doesn’t prove every external effect was observed.
Is it a security sandbox?
No. Commands, features, and Recipes run with your permissions, so only run ones you trust. Running locally also doesn’t make every connected tool or provider local; check the route you chose.
What platforms does it support?
CPython 3.11–3.14 on Linux and macOS. Windows isn’t supported yet; it’s being considered once the main features work.
Is it open source?
Yes. It’s Apache 2.0 and developed publicly on GitHub.
How can I contribute?
Try it, and bring back a clear reproduction when something breaks. Focused fixes, docs, and tests are welcome for best-effort review. Larger changes should start with an issue. It’s solo-maintained, with no support SLA.
Portable proof
In development · Unreleased
What is Portable Proof?
Portable Proof is an idea in development for keeping a claim connected to its sources, provenance, uncertainty, and unresolved questions as it moves between tools and people.
What would travel with a claim?
The aim is to preserve the supporting sources, how the claim was reached, the conditions it depends on, and what remains uncertain or unsupported. The format and tooling are still being developed.
Would it prove that an answer is correct?
No. A portable record would make the support and limitations easier to inspect. It would not turn an uncertain claim into a fact or replace checking the underlying evidence.
Can I use Portable Proof today?
There is no public release linked here yet. This section describes the direction being developed, not an available tool or a finished proof system.
The downloadable research lab
In development · Unreleased
What is the downloadable research lab?
It is a direction in development for packaging the methods, tools, evidence, and working state behind a project so someone can reopen the work and continue it.
How would it differ from a report or repository?
The goal is to preserve more than conclusions or source code: how the work was done, what it depended on, what was observed, and where to continue. The packaging approach is still being explored.
How does it connect to Harness Workbench and Portable Proof?
Harness Workbench preserves what happened during controlled runs. Portable Proof aims to keep claims connected to their support. The downloadable lab aims to bring methods, evidence, and working state together so the work can continue. This is a direction, not a released integration.
Is there a lab I can download now?
Not yet. There is no downloadable lab release linked on this site. Harness Workbench is the public release available now; the downloadable lab remains in development.
Work Engine
Exploring the idea · Unreleased
What is the Work Engine?
Work Engine is an idea being explored for coordinating work across local hardware and rented compute while preserving its state, history, and evidence. It is not a released orchestration tool.
Why start locally and borrow compute?
The aim is to keep everyday work and its persistent foundation on hardware you control, with the option to use outside capacity for larger workloads. You would decide which work and data can leave your machine.
What should come back with the results?
The goal is to bring back the outputs, updated working state, and a record of what ran, where it ran, and what changed. Preserving that continuity is part of the idea being explored, not a capability available here today.
Can I use the Work Engine now?
Not yet. There is no public Work Engine release linked on this site. The diagram describes the intended direction; supported providers, integrations, and a release date have not been announced here.