SignalReview: Governed Codex Module Factory

• 

  Governed Codex pipeline: specification, GPT-5.6 generation, AST guard, Docker validation, and sealed candidate.

• 

  Four-role evidence review grounded in the 30-index Quant Passport and visible uncertainty.

• 

  Read-only judge replay with Candidate, Tests, Validation, and Provenance evidence—without fresh inference or automatic deployment.

Inspiration

Sports intelligence teams often face two unsatisfactory choices: rigid analytical dashboards that are difficult to extend, or unrestricted AI systems that can produce persuasive conclusions and executable code without sufficient evidence, isolation, testing, or review.

We built SignalReview because we repeatedly saw polished analytical outputs hide missing evidence and unsupported assumptions. Our main Build Week decision was that generated code must never enter production simply because an LLM produced it or because its tests appeared green.

SignalReview was created as a third option: a production sports-intelligence environment where deterministic analytics, visible evidence diagnostics, structured multi-agent review, and generated software operate under explicit trust boundaries.

SignalReview existed before OpenAI Build Week. During the official submission period, we extended the existing product with the Governed Codex Module Factory: a workflow that converts a constrained analytical specification into an isolated, tested, auditable, and cryptographically identified candidate module.

The objective was not to let an LLM deploy code autonomously. The objective was to make AI-assisted software generation reviewable, reproducible, and safe enough to participate in a controlled engineering process.

What existed before Build Week

Before the Module Factory was introduced, SignalReview already included:

• a Daily Match Board;
• a deterministic 30-index Quant Passport;
• provider and artifact diagnostics;
• visible missing-data states;
• a four-role analytical review process;
• live/demo dashboard parity;
• Watchlist and Saved Debate workflows;
• account and subscription entitlement boundaries.

Canonical pre-Module-Factory baseline:

d1958d69037393efd0643612068b1ebb3976b2ae

What we built during OpenAI Build Week

During Build Week, SignalReview gained a complete governed analytics-module generation workflow:

1. An analyst submits a constrained objective or selects a quick-start template.
2. SignalReview converts the request into a strict AnalysisSpec.
3. The specification declares permitted inputs, outputs, metrics, tests, limitations, and responsible-use constraints.
4. Codex with GPT-5.6 generates only the declared implementation and test files inside an ephemeral workspace.
5. A schema validator rejects malformed or undeclared output.
6. An AST policy guard rejects forbidden imports, dynamic execution, filesystem access, network access, subprocess access, unsafe APIs, and global mutation.
7. The candidate is compiled, linted, and tested inside a non-root, networkless, read-only Docker validator with bounded resources.
8. Passing files and the canonical validation receipt are hashed into a content-addressed candidate bundle.
9. The candidate remains reviewable and requires explicit human-controlled integration.

The visible pipeline is:

Specification → Codex → AST Guard → Docker Validation → Sealed Candidate

A passing candidate is never automatically promoted into the live analytical path.

Canonical Build Week feature release:

94863b5ac2f9eb1a9d5b872c7d3692a46c6f6c03

The Build Week feature release is six commits ahead of the pre-Module-Factory baseline.

Repository-verifiable Evidence Pack

The public quick-start replay originally exposed the visible pipeline stages. We later added a repository-verifiable Evidence Pack so judges can inspect the engineering work behind those stages rather than relying on an animation alone.

After a recorded replay completes, the dashboard exposes four evidence layers:

• Candidate — the declared bundle contract and exact factory implementation;
• Tests — executable runtime and product-boundary contracts;
• Validation — AST policy, isolated Docker controls, compilation, Ruff, pytest, and SHA-256 sealing;
• Provenance — the recorded build, official Codex session, exact release commit, CI workflow, and immutable replay receipt.

The generated candidate bundle itself is not committed to Git. The Evidence Pack exposes the repository-verifiable implementation, executable contracts, validation controls, and immutable release anchors rather than presenting repository source as the generated candidate.

Evidence Pack release:

d124e30f2b4d5da34f1f38cc7e68dd10c39556f1

What SignalReview does

SignalReview is a premium sports-intelligence War Room for analysts who need to understand not only what an analytical system reports, but also:

• which evidence was available;
• which evidence was missing;
• which numerical claims were grounded;
• which assumptions were challenged;
• why confidence was preserved or reduced;
• whether an analytical artifact belongs to the selected fixture;
• whether generated analytical code passed its declared controls.

The main product combines:

• Daily Match Board;
• Match Intelligence;
• 30-index Quant Passport;
• Statistician review;
• Skeptic challenge;
• Upside Scout scenario analysis;
• Orchestrator adjudication;
• Provider Evidence diagnostics;
• Artifact Binding Integrity;
• Confidence Bands and Risk Flags;
• Watchlist and Saved Debate History;
• the Governed Codex Module Factory.

Missing or incompatible evidence is not silently replaced. States such as partial, path_missing, schema_mismatch, artifact_mismatch, input_blocked, and unavailable remain visible.

How we used Codex and GPT-5.6

Codex with GPT-5.6 participated in the project in two distinct ways.

Building the product

We used Codex to help implement and validate:

• Module Factory contracts;
• FastAPI asynchronous generation jobs;
• the dashboard validation pipeline;
• AST source-policy enforcement;
• isolated Docker validation;
• immutable artifact generation;
• entitlement enforcement;
• CI and browser acceptance checks;
• repository documentation and evidence integrity.

Changes were delivered as scoped, reviewable pull requests with executable contracts and rollback boundaries.

Inside the product

Codex also serves as the candidate-generation component of the Module Factory.

The worker operates inside an ephemeral workspace with a scrubbed environment and schema-constrained output. It receives no production credentials, provider secrets, payment credentials, customer data, or direct production access.

Generated candidates must handle:

• normal inputs;
• empty inputs;
• missing values;
• outliers;
• deterministic replay;
• output-contract validation;
• finite JSON-facing values;
• explicit assumptions and limitations;
• responsible-use restrictions.

This makes Codex a governed software-generation component rather than a decorative chatbot.

Public judge experience

The judge entry and submission-evidence route is:

https://signalreview.co/openai-build-week

The interactive no-cost quick-start replay is available in the public dashboard:

https://signalreview.co/dashboard

A judge can:

1. select Volatility Test;
2. run the no-cost recorded replay;
3. observe five sequential validation stages;
4. inspect Candidate, Tests, Validation, and Provenance;
5. open the exact source, executable contracts, release commit, CI workflow, and immutable SHA-256 replay receipt.

The recorded sequence represents:

1. constrained specification received;
2. Codex with GPT-5.6 candidate generation recorded;
3. AST policy guard passed;
4. isolated Docker validation passed;
5. reviewable candidate sealed.

The public quick starts require no account, checkout, subscription, or model credits. They perform no user-data writes and are explicitly presented as recorded release replays, not fresh Codex invocations.

Edited or custom requests return to the authenticated, server-authoritative Pro generation workflow. No replay or passing candidate can automatically promote code into production.

Architecture

Frontend

• Next.js App Router;
• React and TypeScript;
• shared DashboardParitySurface.tsx;
• server-side engine access through engineFetch;
• Supabase authentication and entitlement state;
• Tailwind CSS;
• Playwright browser acceptance.

Engine

• FastAPI and Python;
• Pydantic generation contracts;
• deterministic Quant Passport registry;
• evidence and provenance contracts;
• multi-agent reasoning boundaries;
• Codex Module Factory;
• AST source validation;
• isolated Docker execution;
• SHA-256 content-addressed artifacts.

Trust boundary

The generation worker:

• uses an ephemeral workspace;
• receives a scrubbed environment;
• is restricted to declared files;
• is restricted to schema-valid output;
• does not receive production secrets;
• does not execute inside the live match-analysis response path.

The validator uses:

• disabled network access;
• a read-only filesystem;
• non-root execution;
• bounded CPU and memory;
• bounded process count;
• dropped Linux capabilities;
• no-new-privileges;
• compilation, Ruff, and pytest.

Verified evidence

We deliberately exclude fabricated accuracy, ROI, productivity, and latency claims.

Repository and release evidence records include:

• 142 reasoning-provider contract cases passed;
• all 30 Quant Passport registry positions were preserved;
• three versioned Golden evidence fixtures published at least 25 supported indices while keeping unsupported indices explicitly visible as blocked;
• Golden calibration measured evidence convergence, not match-outcome accuracy;
• historical or projected evidence could preserve or lower confidence but could not raise it;
• the Build Week release passed TypeScript, lint, production build, engine tests, dashboard contracts, and self-hosted release gates;
• a Playwright visual audit covered 220 production screens with zero critical visual defects and zero public-navigation or dashboard-load failures.

Build Week release workflow:

29557322985

Production and judge-access verification

A recorded production acceptance run was executed against:

3f91bdf87e0ecbf6ff47d1a35192938c69f6783d

Production acceptance workflow:

29804111707

That workflow completed successfully and recorded:

• production deployment fingerprint verification;
• HTTP 200 for the OpenAI Build Week route;
• expected recorded-build and official-session identities;
• dashboard availability;
• no browser console or page errors;
• no fresh inference during the recorded replay.

The later repository-verifiable Evidence Pack release was merged as:

d124e30f2b4d5da34f1f38cc7e68dd10c39556f1

That release added the judge-facing Candidate, Tests, Validation, and Provenance inspection layers while preserving the recorded-replay truth boundary and the Pro gate for fresh custom generation.

Submission identity

RECORDED BUILD ID:

codex-build-8805a7789f915452fd5c87d4

OFFICIAL CODEX /FEEDBACK SESSION ID:

019f80ed-8d5c-74a2-8efc-ecdd9dcacc7b

These are separate identifiers.

The recorded build ID is an internal SignalReview build trace. It is not an OpenAI /feedback Session ID. The official /feedback Session ID was captured separately from the Codex thread.

Challenges we overcame

Separating existing product work from Build Week work

SignalReview existed before the event. We documented the exact baseline, Build Week feature release, pull requests, workflow run, production deployment, recorded build identity, and official Codex session identity.The hardest part was not generating code. It was proving, in a way a judge could inspect, that the public replay was honest, that the validation controls were real, and that recorded evidence was clearly separated from a fresh paid Codex invocation.

Preventing generated code from becoming a production risk

Codex generation was placed outside the live analysis path. Candidates pass schema validation, AST policy enforcement, and isolated runtime validation before they can be sealed.

Preventing evidence drift

Material numerical claims must bind to deterministic evidence references. Unsupported claims fail closed, while rejected and unresolved claims remain visible.

Turning a replay into verifiable engineering evidence

A sequence of green pipeline states is not sufficient proof by itself. We added the Evidence Pack so judges can inspect source, tests, validation controls, release anchors, and the replay receipt directly from the product.

Preserving public and commercial boundaries

The public judge experience is a read-only recorded replay. Fresh generation remains behind authentication, Pro entitlement, worker configuration, and server-side controls.

Maintaining a complete product experience

The result is not only a command-line prototype. The governed pipeline is represented through a production dashboard, visible stages, audit information, failure states, entitlement states, evidence inspection, and immutable candidate identity.

What we learned

The most important lesson was that constrained generation is only one part of trustworthy AI software engineering.

A strong production boundary also requires:

• explicit specifications;
• declared file contracts;
• deterministic tests;
• source-policy enforcement;
• isolated execution;
• immutable evidence;
• human-controlled promotion;
• honest public replay semantics.

We also learned that judge access must be designed as a product surface. A reproducible read-only replay can demonstrate a real engineering workflow without exposing credentials, bypassing commercial controls, or pretending to execute a fresh paid workflow.

We initially treated the visible five-stage pipeline as sufficient demonstration. During final review, we concluded that green interface states were not enough, so I added the Candidate, Tests, Validation, and Provenance Evidence Pack.

Finally, we learned that the interface itself should not be treated as the evidence. A trustworthy judge experience must connect visible states to inspectable source, executable contracts, CI records, release identities, and cryptographic receipts.

Potential impact

The target user is an analyst, analytics engineering team, research workflow, or data-driven content operation that needs to introduce new analytical methods without allowing generated code to bypass engineering governance.

The Governed Codex Module Factory creates a shorter and safer path from an analytical idea to a reviewable software artifact while preserving:

• deterministic contracts;
• missing-data disclosure;
• source-code policy checks;
• isolated execution;
• reproducible tests;
• cryptographic artifact identity;
• explicit human approval.

The value is not a promise of guaranteed accuracy or an unsupported time-saving percentage. The value is controlled acceleration with visible evidence.

Core Build Week pull requests

• #404 — isolated Codex Module Factory;
• #405 — Autonomous War Room product surface;
• #406 — production runtime import repair;
• #407 — English product localization;
• #408 — evidence-grounded adversarial review calibration;
• #410 — entitlement and release hardening.

Judge-access and evidence-integrity hardening

• #454 — separated the recorded build identity from the official Codex /feedback Session ID;
• #457 — made the three built-in quick starts available as no-cost recorded replays while preserving the Pro gate for edited and custom generation;
• #458 — added the repository-verifiable Evidence Pack with Candidate, Tests, Validation, and Provenance.

Responsible use

SignalReview is decision-support software.

It does not publish:

• guaranteed outcomes;
• sure-win claims;
• staking instructions;
• fabricated ROI;
• fabricated model accuracy;
• unsupported injuries or market movement;
• automatic deployment of generated modules.

Generated candidates remain reviewable artifacts. Confidence, provenance, missing evidence, Quant Passport diagnostics, and multi-agent outputs remain bounded analytical signals rather than certainty.

What is next

The next phase is to extend the same governance model to additional analytical domains, add richer reviewer approval workflows, expand deterministic module benchmarks, and let authorized users retain, compare, and reopen validated candidate modules without weakening the no-auto-promotion boundary.

Built With

• docker
• fastapi
• github-actions
• gpt-5.6
• next.js
• openai-codex
• playwright
• pydantic
• pytest
• python
• react
• render
• ruff
• supabase
• tailwind-css
• typescript
• vercel