-
-
verdict pass example
-
logo
Inspiration
An agent says the task is complete.
That sentence is useful, but it is still only a claim.
As coding agents become capable of working for longer, taking more actions, and operating with less supervision, the main question is no longer only what can the model do? It is also:
- What was actually authorized?
- What scope was the agent allowed to change?
- What happened in the real workspace?
- Which checks were run?
- Can the final state be reconstructed independently?
- Does the evidence support the agent’s completion claim?
Most agent systems focus on increasing capability. I built Admissible to make that capability governable.
The core idea is simple:
The model proposes. The owner authorizes. Admissible verifies what actually happened.
What it does
Admissible is a local governed-delegation and verification layer for long-running coding agents.
The operator enters a goal. The system turns that goal into a structured mission defining the workspace, required behavior, verification procedure, execution limits, and stopping conditions. The operator reviews and authorizes that contract before execution begins.
The coding agent then works autonomously inside the authorized mission. When it reports completion, Admissible does not simply trust the final message. It captures the resulting Git state, workspace state, checkpoints, command results, and behavioral evidence, then reconstructs an owner-facing verdict independently from the agent’s narrative.
A run can therefore end in two very different states:
- Accepted: the final workspace and evidence support the authorized mission.
- Refused: the agent claims success, but the observed result does not satisfy the required behavior.
In the Build Week demonstration, the mission is to add deterministic incident replay to a local incident-response application. Given the same event log, the application must reconstruct the same final incident state every time.
The agent first reports that the work is complete. But the replayed incident should be RESOLVED, while the application reconstructs it as OPEN. Admissible refuses the run.
The mission is then repaired and executed again. This time the expected behavior, tests, Git state, and captured evidence agree, so Admissible presents an evidence-backed accepted result.
How I built it
The final product is a local browser experience backed by a governed execution pipeline:
Browser UI
→ authenticated loopback product service
→ product launcher and frozen authorization contract
→ governed native coding-agent execution
→ checkpoint, Git, workspace, and behavioral evidence
→ independent read model
→ authoritative accepted/refused result
The main components are:
- Mission composition: turns an operator goal into a reviewable structured contract.
- Owner authorization: freezes the exact mission identity and execution boundary before launch.
- Governed launcher: starts the coding agent only after the required authority and backend checks succeed.
- Evidence capture: records checkpoints, command outcomes, workspace material, Git state, and behavioral verification.
- Independent reconstruction: produces the final verdict from persisted evidence rather than from the agent’s final response.
- Browser result surface: shows the mission, execution state, evidence, refusal reason, and accepted result in one coherent operator workflow.
- Recovery path: allows a failed or refused execution to be corrected and rerun without silently changing the original authority model.
Admissible is implemented primarily in Python, with a local HTML/CSS/JavaScript interface. The demonstrated incident application and its verification path use Git, Node.js, npm, and deterministic tests. The product runs locally and exposes its UI and service only on loopback interfaces.
How I used Codex and GPT-5.6
Codex was used throughout the Build Week implementation as an engineering collaborator: inspecting the repository, implementing bounded product slices, writing and repairing tests, checking authority invariants, reviewing failure reports, and validating the final end-to-end path.
GPT-5.6 was used in the final submission-hardening session to perform an adversarial repository audit, identify that the public branch still exposed the old product, rewrite the judge-facing documentation, repair wheel packaging for the browser assets, and verify the installed product from a fresh environment.
The final hardening pass produced:
- a correct Admissible-focused README;
- a root MIT license;
- installable browser assets;
- a judge-facing provider-free smoke path;
- 11 quick product tests passing;
- 74 broader product and authority tests passing without invoking a provider.
What was built during OpenAI Build Week
Admissible began before Build Week as a research thesis, benchmark schemas, and early governed-execution experiments.
Between July 13 and July 21, I turned that foundation into the product shown in the demo. The Build Week work added or meaningfully extended:
- bounded governed execution;
- the delegated gate and native executor;
- frozen mission and owner-authorization contracts;
- checkpoint and evidence capture;
- independent evidence reconstruction;
- the authenticated loopback product service;
- the product launcher;
- the browser compose-and-authorize workflow;
- the browser result-and-evidence workflow;
- the verified incident-replay mission;
- governed recovery and rerun behavior;
- final consistency between behavioral verification and backend authority;
- fresh-clone packaging, testing, and submission documentation.
Historical Agent OS, early V0 controllers, benchmark materials, and regression fixtures remain in the repository for provenance and test coverage, but they are not the judge-facing execution path.
Challenges I ran into
Preserving autonomy without removing authority
The easiest safe system would ask a human to approve every action. It would also destroy the main benefit of an autonomous coding agent.
The harder problem was to authorize a sufficiently precise mission once, allow the agent to work independently inside it, and stop only when execution crossed a meaningful authority boundary or the evidence no longer supported completion.
Keeping different kinds of truth separate
A model response, an authorization decision, a process exit code, a Git commit, a test result, and the actual runtime behavior are not interchangeable.
Many failures came from treating one of those layers as proof of another. Admissible stores and presents them separately, then reconstructs the final disposition from the evidence that matters for the authorized mission.
Recovery after real failures
Long-running execution exposed problems that short demos rarely show: stale identities, interrupted processes, malformed outputs, backend drift, inconsistent checkpoints, path-length failures on Windows, and runs that needed repair after a valid refusal.
The recovery path had to remain fail-closed without losing the mission or silently broadening the authority granted to the agent.
Making the repository judgeable
The final product existed locally before it was actually ready to submit. The public branch still showed an older Agent OS prototype, the root documentation contradicted the demo, and the built wheel omitted the browser assets.
The final audit caught those problems. The product was then rebuilt, installed into a fresh environment, launched without a provider, and verified through both a quick judge path and a broader deterministic test selection.
Accomplishments that I am proud of
- A complete operator experience rather than only a protocol or technical proof of concept.
- A real coding-agent run that can be refused even after the agent reports success.
- A corrected rerun that is accepted only when behavioral and repository evidence agree.
- A frozen authorization contract separating model proposal from owner authority.
- Independent reconstruction of the final verdict from persisted evidence.
- A provider-free judge path that launches the installed UI and verifies the product without creating a governed run.
- 74 focused product and authority tests passing without invoking a provider.
What I learned
The strongest lesson was that completion is an evidence question.
The agent saying “done” is valuable context, but it cannot be the final authority. The resulting files, tests, Git state, runtime behavior, and persisted receipts must support that conclusion.
I also learned that governance does not have to mean constant interruption. High autonomy and explicit authority are compatible when the mission, evidence requirements, and stopping conditions are defined before execution.
Finally, stronger models do not make execution boundaries less important. They make them more important, because a more capable agent can take more consequential actions before a human notices that its assumptions or final claim were wrong.
Current limitations
Admissible is currently verified primarily on Windows. Real governed execution requires a compatible local coding-agent executable and environment-specific authorization inputs.
The current system is not an operating-system sandbox, and processes running as the same local user are not treated as a cryptographically hostile boundary. Admissible does not claim to make arbitrary agent output correct. It provides explicit authority, bounded execution contracts, persisted evidence, recovery, and an independent basis for accepting or refusing completion.
What's next
The next step is to make Admissible a reusable evaluation and execution layer across coding-agent environments.
Planned work includes portable execution backends, richer authority policies, stronger sandboxing, adversarial long-run scenarios, comparative evaluation across models, and AdmissibleBench: a benchmark for measuring whether agentic systems can complete complex work under identical authority and evidence requirements.
The broader goal is to push agent capability forward while preserving a reliable answer to a simple question:
What was actually accomplished, and what evidence supports that conclusion?
Log in or sign up for Devpost to join the conversation.