BOSAI — The Control Plane for AI Work

Inspiration

Large language models are becoming increasingly capable of understanding incidents, analyzing evidence, and recommending actions. However, recommendation is not authorization.

In real organizations, AI should not be able to execute changes simply because it produced a convincing answer.

We built BOSAI because we believe AI needs a control plane: a governed layer that separates intelligence from operational authority, requires explicit human approval, verifies every action, and produces verifiable evidence of what actually happened.

Instead of asking “Can AI do this?”, BOSAI asks:

“Should this be allowed, under what conditions, and how do we prove exactly what happened?”

⸻

What it does

BOSAI is a governed control plane for AI-assisted work.

For OpenAI Build Week we built a complete, judge-testable workflow around a fictional operational incident using synthetic data.

The demonstration intentionally separates AI reasoning from execution authority.

GPT-5.6 (or a clearly disclosed deterministic fallback) analyzes bounded evidence and proposes exactly one allow-listed recommendation.

That recommendation is NOT AUTHORIZED until BOSAI completes the governed workflow.

The platform:

validates the exact requested scope;
performs a deterministic no-mutation dry run;
requires explicit human approval;
issues a five-minute single-use execution permit;
executes exactly one allow-listed action;
independently reads back the resulting state;
generates a downloadable audit packet from the actual workflow history.

Throughout the process, GPT-5.6 never gains execution authority.

The model can diagnose.

BOSAI decides whether execution is permitted.

This makes the boundary between AI intelligence and operational governance explicit and observable.

⸻

How we built it

The Build Week implementation is built with:

Next.js
React
TypeScript
Zod
OpenAI Responses API
Node.js cryptography
HMAC-SHA256 workflow signing
Vitest
ESLint

The application uses a strict server-side adapter for GPT-5.6 and includes a fully disclosed deterministic fallback so judges can complete the entire workflow even without a live provider call.

The public judging environment is deployed on OVHcloud inside Docker behind an authenticated Caddy HTTPS reverse proxy with security headers.

Secrets never live inside the repository, and the application remains isolated from production systems.

Everything shown during judging runs against signed synthetic state.

No customer data.

No production integrations.

No hidden execution.

⸻

How Codex was used

Codex was our primary engineering environment throughout the Build Week.

It was used to inspect and understand the repository, design architecture, implement governed workflows, build UI components, develop APIs, write TypeScript code, create validation contracts, improve state management, debug complex issues, execute repository-wide refactoring, strengthen security boundaries, generate tests, validate deployment packages, and assist with technical documentation.

Human decisions remained responsible for every architectural choice, product decision, security boundary, governance rule, and any operation capable of affecting external systems.

Codex accelerated implementation.

Humans retained authority.

⸻

How GPT-5.6 is used

GPT-5.6 is used exclusively for structured operational diagnosis.

Given bounded evidence, the model produces:

evidence-backed observations;
bounded hypotheses;
uncertainty;
missing information;
risk assessment;
exactly one allow-listed recommendation.

Its output is treated as untrusted diagnostic input.

Before anything can continue, BOSAI validates the response against strict policies using:

JSON Schema structured output;
Zod validation;
configured-model verification;
allow-listed actions;
bounded resources;
bounded durations;
rate limiting;
fail-closed behavior;
server-only execution.

The model cannot:

approve actions;
issue permits;
expand scope;
bypass governance;
execute operations.

⸻

Challenges we ran into

The hardest challenge was demonstrating meaningful AI capabilities without allowing the AI to become the authority.

Instead of giving the model more power, we built stronger governance around it.

Another challenge was creating something judges could actually experience instead of reading about.

We designed a guided Judge Mode that allows reviewers to complete the entire governed workflow in only a few minutes while clearly observing every governance checkpoint.

We also invested significant effort into deterministic behavior, synthetic data, reproducible execution, deployment hardening, audit generation, and automated quality validation so the project could be reliably evaluated.

⸻

Accomplishments that we’re proud of

Building a complete governed workflow from AI diagnosis to verified audit evidence.
Clearly separating AI recommendation from operational authority.
Implementing explicit Human Approval before execution.
Creating five-minute single-use execution permits.
Preventing replay and stale-state execution through signed workflow envelopes.
Performing independent post-execution readback before declaring success.
Generating downloadable audit evidence from actual workflow events.
Delivering a public judge environment that remains isolated from production.
Supporting both GPT-5.6 and a deterministic disclosed fallback while preserving identical governance behavior.
Maintaining automated quality gates including linting, type checking, testing, packaging, and deployment validation.

⸻

What we learned

Building trustworthy AI systems is less about making models smarter and more about designing safe execution protocols.

Human approval becomes meaningful only when it is tied to an exact scope.

Audit logs become valuable only when they are generated from observed system behavior rather than assumptions.

Dry runs, single-use permits, independent verification, and evidence-based audit records transform governance from documentation into executable software.

We also learned that deterministic fallbacks should be explicit, transparent, and never presented as live AI output.

Clear provenance builds trust.

⸻

What’s next for BOSAI

The Build Week project intentionally focuses on one fictional operational scenario using synthetic data.

Our next objective is to evolve the same governance protocol into a reusable control plane capable of supervising AI-assisted execution across multiple business domains while preserving: