Decision Room

Inspiration

Freelancers, consultants, and small agencies regularly receive contracts containing clauses that sound reasonable but create serious practical risks. Terms such as “unlimited revisions,” “until fully satisfied,” and “at no additional cost” can lead to scope creep, unpredictable workloads, and payment disputes. Most contract-analysis tools provide only one response. I wanted to build something more rigorous: a system where one perspective proposes an analysis, another actively challenges it, and a final role resolves any remaining disagreement. That idea became Decision Room, a structured contract-clause review workflow powered directly by Codex CLI.

What it does

Decision Room accepts a contract clause as plain text and runs a three-role critique loop: Drafter identifies risks, explains their practical impact, and proposes improved wording. Adversary stress-tests the Drafter’s analysis and either approves or rejects it. If rejected, the Drafter receives the criticism and produces a revised assessment. The loop continues for up to three rounds. If disagreement remains, Arbiter evaluates both sides and makes the final decision. Every round is saved as structured JSON, including the original clause, risk verdict, revised wording, objections, approval status, and final summary. A static Next.js interface then presents the transcript as a visual deliberation between the three roles. Decision Room is intended as an analytical aid for freelancers and small businesses, not as a replacement for professional legal advice.

How we built it

The project has two main components. Codex CLI skill The review workflow is implemented as a project-local Codex skill with: A PowerShell orchestration script Separate prompts for Drafter, Adversary, and Arbiter JSON schemas that enforce structured output for every role Retry logic supporting up to three review rounds An Arbiter escalation path for unresolved disagreements Each role is executed through codex exec, using the user’s existing authenticated Codex session. The project does not call the OpenAI API directly and does not require an OPENAI_API_KEY. Static transcript viewer The interface is built with: Next.js React TypeScript Tailwind CSS Framer Motion The frontend reads the generated JSON transcript from the public directory and displays each round in the existing Decision Room layout. The browser remains static and does not store credentials or launch Codex directly.

Challenges we ran into

One major challenge was moving from an API-driven Next.js application to a CLI-driven architecture. The original design expected the browser to send a request to a server route. In the new design, Codex CLI performs the analysis and the frontend only displays the result. Another challenge was keeping role outputs predictable. Natural-language model responses are flexible, but the interface requires stable fields. I solved this by giving each role its own JSON schema and requiring Codex to return schema-compliant output. PowerShell introduced several implementation details as well. I had to correctly serialize nested transcript data, prevent CLI status output from contaminating role results, preserve UTF-8 text without a byte-order mark, and handle Windows execution-policy restrictions. Finally, the retry loop needed clear stopping rules. The workflow now stops early when the Adversary approves, retries rejected assessments up to the configured limit, and invokes the Arbiter only when the final round remains unresolved.

Accomplishments that we're proud of

Replaced direct API usage with an authenticated Codex CLI workflow Built a complete Drafter → Adversary → Arbiter review loop Added up to three rounds of adversarial revision Enforced structured role outputs with JSON schemas Generated a complete round-by-round transcript Preserved the original animated Decision Room interface Removed the need for a separate API key Passed TypeScript checks, linting, production build, and an end-to-end Codex run

What I learned

I learned that Codex CLI can be used as more than an interactive coding assistant. Its non-interactive execution mode, structured-output schemas, and authenticated session make it possible to build repeatable local AI workflows without embedding a separate API credential in the application. I also learned that multi-role systems need more than different role names. Each role needs a distinct responsibility, explicit decision rules, and structured information passed between rounds. The Adversary must have meaningful authority to reject weak analysis, while the Arbiter must only appear when an actual disagreement remains. Most importantly, I learned that separating AI execution from presentation can simplify security. Codex handles the analysis locally through the CLI, while the frontend remains a credential-free transcript viewer.

What's next for Decision Room

Submitting clauses directly from the interface through a secure local companion process Reviewing complete .docx and PDF contracts Saving and comparing previous review sessions Highlighting risky phrases inside the original clause Supporting configurable review perspectives and jurisdictions Adding macOS and Linux runners Exporting review reports as PDF or Word documents

Built With

• cli
• codex
• css
• framer
• github
• html
• javascript
• json
• motion
• next.js
• node.js
• openai
• powershell
• react
• schema
• tailwind
• typescript