Admissible Commit Gate: What AI Is Allowed to Do

Whatever the model proposes, Admissible decides what can become trusted, trigger action, or change system state.

Comment

Inspiration

Much of the conversation around AI safety and governance is focused on the model itself. Can we make the model more accurate? Can we keep it from being manipulated or jailbroken?

Those are important problems, but what I’ve been thinking about instead is what happens after a model has been jailbroken or manipulated. How do we keep its output from propagating through the system?

Model output is still only a proposal. It should not automatically become trusted company information, change a financial record, or cause an action in another system.

The Admissible Runtime was built around that idea before Build Week. For this project, I wanted to create a clear demonstration of it. The model can be correct, mistaken, manipulated, or compromised. Admissible independently decides what the result is allowed to become.

What it does

Admissible Commit Gate uses a vendor-payment case where a supplier sends an email asking a company to change its bank account and release an invoice for payment. The request contains several problems: the email comes from an unapproved domain, the requested bank account does not match the Vendor Master, the invoice is above the purchase-order tolerance, and the required verification and approval steps have not been completed.

The user can run the email through GPT-5.6 live or select one of three controlled test scenarios. The controlled scenarios propose unsafe actions, falsely claim that verification is complete, or attempt to save unverified information as trusted company information. They represent the kinds of output that could come from a mistaken, manipulated, jailbroken, or compromised model or agent.

Only the upstream candidate changes between scenarios. The company records, deterministic checks, policy, and Admissible authority boundary remain fixed.

The Admissible Runtime then evaluates what the candidate output is allowed to become. It decides whether information can be shown to the user, saved into trusted company records, or used to trigger workflow or financial actions.

Safe follow-up work is allowed to continue, while unsafe or unsupported actions are blocked or deferred. Independent verification is started and a security review is opened, but the new bank details remain unverified, the Vendor Master is not changed, and payment is not released.

How we built it

The public application is built with Next.js, TypeScript, Zod, Vitest, the OpenAI Responses API, and the public @admissible-ai/sdk.

In the live scenario, the supplier email is sent to GPT-5.6 and returned as structured candidate output. That output is not treated as the final decision. It is evaluated alongside the fixed company records and deterministic checks by the Admissible Runtime.

The three controlled scenarios use server-owned, deterministic test inputs and do not call OpenAI. The browser only sends a scenario ID and, for the live test, the editable email body. It cannot submit arbitrary candidate data, choose runtime actions, alter policy, or rewrite the trusted company records.

Each scenario runs through the same seven Admissible evaluations. These separately govern whether information can be shown, saved as trusted company information, used to start follow-up work, or used to make financial changes. The application uses execute-only evaluations and does not call the commit endpoint or perform any external write.

We also kept a strict boundary between the public Build Week application and the existing proprietary runtime. The public repository contains the reference application and SDK integration, but not private runtime code, credentials, policy bodies, internal traces, or infrastructure details.

I used Codex throughout the build to implement the application, integrate the public SDK, create the controlled test scenarios, add fail-closed behavior, write and run tests, and iterate on the interface. I also used GPT-5.6 as a reflection and product-reasoning partner to challenge the demonstration, work through architectural and presentation problems, review implementation results, and help communicate the underlying idea clearly. GPT-5.6 also powers the live candidate analysis inside the application, while the Admissible Runtime independently governs what that output can become.

Challenges we ran into

Our original demonstration compared a conventional workflow with an Admissible-regulated one, but the comparison stopped making sense when GPT-5.6 correctly identified the suspicious request. Rather than trying to break GPT-5.6 or waiting and hoping for a live model failure, we rebuilt the demo around controlled failure scenarios where only the upstream candidate changes and the authority boundary remains fixed. The live GPT-5.6 scenario still includes an editable email body, so users can enter their own adversarial instructions and attempt to manipulate the model.

What we learned

The biggest thing we learned is that model correctness and system authority are separate engineering problems. A strong model is valuable, but the system should not depend on the model always being correct. We also learned that saving information into trusted company records can be just as consequential as taking an external action, because once false information becomes trusted it can influence every decision that follows.

What's next for Admissible Commit Gate

Admissible Commit Gate is a narrow demonstration of a much broader problem. The next step is to continue developing the Admissible Runtime and public SDK so teams can define, test, and observe what AI systems are allowed to make trusted or cause in the real world.

The vendor-payment scenario is only one example. The same authority boundary can apply anywhere an AI system interacts with company records, customer accounts, infrastructure, financial operations, or other consequential workflows.

I'm very sorry my microphone was acting faulty during recording and I didn't realize it or have time to re-record before the deadline.

Built With

Share this project:

Updates