# Gate AI Workflow Acceptance on Mandatory Checks > Source: > Published: 2026-10-12 02:54:37+00:00 An agent can configure most of a workflow correctly and still leave a required approval broken. If your evaluation reports only an average score, that failure can disappear inside an encouraging number. OpenAI's October 6 publication, [Advancing computer use with Ironclad](https://openai.com/index/advancing-computer-use-with-ironclad/), makes this a concrete engineering problem. The researchers worked with practitioners to define 11 tasks across legal, commercial and procurement work, with 8 to 50 evaluation criteria per task. OpenAI reports mean rubric scores of 55.0% for GPT-6 Astra at Max reasoning and 41.6% for GPT-5.6 Sol at High reasoning. Those averages describe criteria met, not the percentage of workflows completed perfectly. The reported 19.2 versus 37.0 minutes per attempt are simulated estimates, not measured customer savings. The results cover those 11 research tasks, not every Ironclad workflow. The implementation lesson I take from this is to separate a score that measures progress from the conditions that permit a workflow to be used. The design below is my proposed pattern, not a description of Ironclad's implementation. Suppose a fictional purchasing policy requires Finance approval for amounts strictly above USD 10,000, excluding tax. A real owner would need to confirm those details; they should not be invented by the agent. Represent the amount in cents for this example, so the boundary is 1,000,000. Then define observable cases: The last two cases are additional proposed requirements. They need agreement before implementation. Their purpose is to expose ambiguity rather than turn an assumption into policy. Attach the accepted cases to a configuration version. A passing observation from yesterday's configuration should not authorize today's changed one. A rubric can measure helpful labels, document quality and configuration details. Maintain that score for comparisons and debugging. Separately keep an explicit set of mandatory check IDs selected by the process owner. Here is a small Python gate for observations collected by a trusted test runner. It accepts only explicit passes with an evidence reference for the requested version. Missing, stale or inconclusive observations remain unverified. ``` python def acceptance(required, observations, version): if not required: raise ValueError("Define mandatory checks before evaluation") failed = [] unverified = [] for check_id in sorted(required): row = observations.get(check_id) if (not row or row.get("version") != version or not row.get("evidence")): unverified.append(check_id) elif row.get("status") == "fail": failed.append(check_id) elif row.get("status") != "pass": unverified.append(check_id) return { "ready": not failed and not unverified, "failed": failed, "unverified": unverified, } ``` There is deliberately no aggregate score in this decision. A high score for optional checks cannot cancel a failed mandatory check. Both failed and unverified conditions prevent `ready` from becoming true, while remaining distinct in the report. For example, these are synthetic fixtures demonstrating the gate's behavior, not evidence from a real workflow: ``` required = {"above_threshold", "missing_amount"} observations = { "above_threshold": { "status": "pass", "version": "config-7", "evidence": "fixture:above-threshold", } } result = acceptance(required, observations, "config-7") assert result["ready"] is False assert result["unverified"] == ["missing_amount"] ``` An empty required set raises an error because an accidentally empty checklist should not produce a passing result. An unexpected status also remains unverified. This function assumes the input mapping follows the shown schema; validate untrusted input at the boundary before calling it. The gate above checks references and statuses. It does not prove that a referenced artifact exists or that the result is true. If the same agent can invent observations or rewrite the mandatory set, the gate offers little assurance. Have a separate test controller submit known requests in a safe environment and read the resulting route or approval state. Save the request ID, tested configuration version, input, expected outcome, actual outcome and supporting evidence. Check that the evidence reference resolves to the observation for that exact case and version before passing it to the gate. Use screenshots when visual context matters, but capture the actual result state too. A screenshot of a rule in an editor establishes what the configuration looks like. A routed test request establishes something different: how that configuration behaved for a particular input. Preserve failures as reproducible cases. "The agent missed some steps" is difficult to debug. "Increasing a saved request from 900,000 to 1,100,000 cents did not trigger Finance review" describes an input transition and an observable defect. After a configuration change, collect fresh observations for the mandatory cases. Do not reuse an old pass solely because the visible form looks unchanged. Approval routing may depend on fields, conditions or later edits that the screenshot does not reveal. For a first pilot, a small mandatory suite is more useful than a large collection of vague checks. Add cases when the owner identifies another requirement or a failure reveals a missing boundary. Track the broader rubric alongside it so you can see improvements that do not yet justify acceptance. Also record the human effort required to reach an accepted result: preparation, review, repair and repeated tests. Keep those measurements separate from model execution time and from the simulated timing in the research. OpenAI's publication explicitly retains a role for human oversight in complex contracting. This proposed gate does not remove that responsibility. It gives the responsible person a clearer view of what passed, what failed and what nobody has verified yet. Start with one workflow, one agreed version of its rules and a few meaningful cases. A reliable acceptance decision begins with a precise definition of what the finished system must do.