• 

  ASOS blocks a specialist from approving its own remediation and requires independent human authorization.

• 

  Human approval unlocks bounded execution, verification evidence, and successful case closure.

• 

  AIBRY Specialists OS combines AI reasoning with explicit authority, human oversight, verification, and auditability.

• 

  The Incident Control Room starts from a resettable state with the self-approval prohibition enabled.

• 

  An auditable case history shows analysis, rejection, approval, execution, verification, and closure.

ASOS Control Room

Inspiration

AI agents are becoming capable enough to investigate incidents, recommend changes, and operate real systems. However, much of agent safety still depends on instructions asking the model to behave correctly.

Instructions are not authority.

ASOS Control Room grew from a practical question encountered while building and maintaining our own applications and infrastructure:

How can AI specialists contribute meaningful work without silently expanding their authority, approving their own recommendations, or executing changes nobody can verify?

We wanted more than another AI incident assistant. We wanted an enforceable operating model where reasoning remains flexible, but authority remains deterministic.

What it does

ASOS Control Room turns an operational incident into a governed, auditable case.

GPT-5.6 interprets supplied evidence, summarizes the incident, forms bounded hypotheses, and recommends a remediation. ASOS assigns specialists with defined responsibilities for investigation, remediation, human authorization, execution, and verification.

The ASOS Kernel determines what each participant is permitted to do.

A specialist may investigate and propose an action, but it cannot approve its own recommendation. When the remediation specialist attempts self-approval, the kernel rejects it and explains why independent human authorization is required.

After trusted human approval, the prototype safely simulates execution through the real application-service and authority path, records independent verification evidence, closes the case, and produces an auditable report containing the complete decision trail.

The Interactive Constitution makes these boundaries visible. With the rule denying specialist self-approval enabled, ASOS enforces separation of duties. Disabling it previews the unsafe counterfactual, but ASOS intentionally refuses to execute that path.

The public judge path requires no account and can be reset and repeated from a fresh deterministic state.

How we built it

ASOS separates probabilistic reasoning from deterministic governance:

• GPT-5.6 interprets evidence and recommends a remediation through the OpenAI Responses API.
• Strict structured output constrains the model response to an incident summary, bounded hypotheses, and a recommendation.
• The ASOS Kernel enforces roles, authority, approvals, execution eligibility, and case transitions.
• The application service and execution adapter perform a safe deterministic remediation simulation through the real authority gate.
• The evidence layer records investigation artifacts, decisions, approvals, execution results, and verification.
• The replay layer preserves the complete governed sequence.
• The interface makes normally invisible agent authority visible to the operator.

The core domain is implemented in TypeScript around specialists, cases, authority, execution, evidence, and verification. Structured GPT-5.6 output is translated into domain artifacts rather than treated as authorization.

The interface uses React, Next.js, TypeScript, Vite/Vinext, and Tailwind CSS, with deployment on Cloudflare infrastructure.

Codex helped us inspect the existing ASOS architecture, identify the correct domain and application boundaries, implement the focused end-to-end workflow, write tests, diagnose integration issues, and document the final system.

A deterministic reset and clearly labeled saved GPT-5.6 response provide a reliable fallback when live model access is unavailable, times out, or returns invalid structured output. The fallback is explicit and auditable rather than presented as a live response.

The governing sequence is:

OBSERVE → PROPOSE → HUMAN AUTHORIZATION → APPLY → INDEPENDENT VERIFY

What existed before Build Week

Before Build Week, ASOS already contained:

• the foundational domain model;
• specialist and authority concepts;
• authority policies;
• the case kernel;
• provider-independent application ports;
• CaseApplicationService;
• existing domain, kernel, and application tests; and
• the AIBRY Specialist Platform landing and Cloudflare deployment foundation.

What we added during Build Week

For Build Week, we created the complete Incident Control Room vertical slice:

• a frozen TrackMaster-inspired authentication incident;
• deterministic in-memory state for the judged workflow;
• live GPT-5.6 evidence analysis through the Responses API;
• strict structured model output;
• a clearly labeled saved-response fallback;
• the explicit specialist self-approval attempt;
• kernel-enforced rejection and explanation;
• trusted human authorization;
• bounded execution through the existing application-service path;
• independent verification evidence;
• successful case closure;
• deterministic reset and replay;
• the Interactive Constitution demonstration;
• the public no-login Control Room experience; and
• a focused end-to-end Build Week acceptance test.

Challenges we ran into

The largest challenge was scope. ASOS is intended to become a broader operating system for governed specialist work, but Build Week required one complete and understandable vertical slice. We reduced the submission to a single incident that demonstrates the full authority lifecycle.

Another challenge was preserving useful model flexibility without allowing model output to become permission. The solution was a hard architectural boundary:

The model advises. The kernel decides.

We also had to make governance visually understandable. A blocked action cannot appear as an unexplained error. The interface must show exactly why it was blocked and what legitimate authority is required.

Making the governance real rather than decorative was equally important. The rejection, human authorization, execution, verification, and closure are routed through the actual domain kernel and application-service boundaries rather than represented only by interface labels.

Finally, the demonstration needed to remain reliable without pretending that prerecorded output was live. The fallback mode is therefore explicit, labeled, and auditable.

Accomplishments that we're proud of

We created a public, no-login demonstration that presents a complete governed AI workflow in one repeatable path.

The self-approval rejection is not a visual warning added for the demo. It is enforced by the authority kernel. Human authorization remains separate from the specialist recommendation, execution passes through the existing application-service boundary, and the case cannot close until verification evidence has been recorded.

We are especially proud that the entire process remains auditable. A judge can inspect who proposed the action, who was denied, who authorized it, what executed, what evidence verified the result, and why the case closed.

Additional accomplishments include:

• direct GPT-5.6 integration with strict structured output;
• deterministic reset and repeat behavior;
• a clearly labeled live-versus-fallback analysis mode;
• an unsafe counterfactual that is explained but never executed; and
• one focused judge path that communicates the product idea without requiring an account or setup process.

What we learned

The most important lesson is that trustworthy agentic systems need more than better prompts.

Models are valuable precisely because they can interpret uncertain evidence and generate possible solutions. Authority has different requirements: it must be bounded, inspectable, testable, and consistently enforced.

We also learned that evidence should not be treated as a final log added after execution. Evidence is part of the case itself and should connect every hypothesis, decision, approval, action, and verification.

Live model intelligence and deterministic demonstrations do not have to conflict. A clearly labeled fallback can preserve reliability without pretending to be a live response, while the governed authority path remains identical in both modes.

Finally, auditability turns governance from a promise into inspectable proof.

What's next for ASOS Control Room

ASOS Control Room is the first runnable vertical slice of the larger AIBRY Specialists OS.

Future work will expand the specialist catalog, introduce additional infrastructure adapters, support more incident types, connect governed execution to real environments, and integrate ASOS into Garage Admin as its authority and evidence layer.

The same governed pattern can support deployment regressions, worker-queue backlogs, synchronization failures, catalog consistency issues, and other operational cases while preserving the separation between advice and authority.

The long-term goal is straightforward:

Give AI specialists room to reason without giving them permission to govern themselves.

Built With

• ai-agents
• codex
• css3
• git
• github
• gpt-5.6
• html5
• javascript
• node.js
• openai
• openai-api
• react
• rest-api
• structured-outputs
• typescript