I wrote this and had codex make it better looking and understandable for regular humans
Reasoning Manager
Reasoning Manager is a working developer framework for managing reasoning as a bounded, evidence-preserving process.
Instead of storing only a final answer, it records why reasoning effort was allocated, which evidence supports or contradicts each branch, why branches were retired, and whether the surviving evidence is strong enough to permit endorsement.
The submitted implementation provides a deterministic controller, append-only evidence records, branch-lineage tracking, transition validation, artifact sealing, rollback checks, immutable scoring, and fail-closed execution. Judges can run its deterministic demonstration without an OpenAI API key or provider calls.
Its manager policy is:
Potential → Blockers → Next Discriminator
The project applies a security-research standard of proof to reasoning: preserve the target, assumptions, procedure, evidence, failures, and exact claim boundary so another person can inspect and reproduce what happened.
Inspiration
Reasoning Manager did not begin as an attempt to improve artificial intelligence. It began as an attempt to understand and improve my own reasoning.
Over many years, I developed a consistent way of approaching problems without consciously formalizing it. During an intensive collaboration with ChatGPT and Codex, that implicit process became explicit. What began as self-analysis developed into a structured reasoning architecture.
I recognized the same pattern in how I approached software engineering, security research, systems design, and scientific investigation. I was not only asking how to reason through a problem. I was repeatedly deciding which possibility deserved attention, what prevented confidence, and which observation or experiment would reduce the most uncertainty next.
That led to a different question from the one most reasoning systems emphasize.
Rather than asking:
How should a model reason?
Reasoning Manager asks:
How should a system decide where reasoning effort is spent?
The goal is to make that allocation explicit, bounded, reproducible, inspectable, and auditable.
What it does
Reasoning Manager constructs a bounded evidence tree rather than treating reasoning as one uninterrupted chain.
Each branch records:
- why reasoning effort was allocated;
- its potential value;
- the blockers preventing stronger confidence;
- the next discriminator that could reduce uncertainty;
- supporting and contradicting evidence;
- provenance and branch lineage;
- safety boundaries, budgets, and approvals;
- and why the branch remains active, is merged, or is retired.
Failed branches are preserved instead of erased. Contradiction becomes evidence that updates the tree. Exploration remains separate from endorsement, so a hypothesis can be worth investigating without being presented as a conclusion.
The proposed architecture gives bounded workers investigative tasks. The
deterministic controller—not the model—owns state transitions, permissions,
budgets, containment, stopping, rollback, evidence sealing, and publication.
Invalid actions fail closed, and NO-GO is a valid outcome when safety,
protocol, or evidence requirements are not satisfied.
For the Build Week demonstration, model workers are replaced by explicitly labeled fixed fixtures. This lets judges reproduce the controller and complete evidence lifecycle without credentials, API charges, model drift, or hidden provider state.
What works today
The submitted deterministic harness executes and tests:
- bounded branch-state management;
- append-only evidence preservation;
- branch-lineage and provenance tracking;
- controller-owned transition enforcement;
- invalid-transition rejection;
- request and artifact sealing;
- scoring and adjudication locks;
- identity-reveal gating;
- rollback and recovery checks;
- deterministic replay;
- and retained evidence for failure paths.
The demonstration is deliberately more than a visual mock-up. It runs the fixed-output lifecycle, produces inspectable artifacts, exercises both accepted and rejected paths, and verifies that invalid states cannot silently become favorable results.
How it was built
Reasoning Manager was developed through an iterative collaboration between myself, ChatGPT, and Codex.
Candidate workflows were proposed, frozen, challenged, attacked, tested, rewritten, and sometimes discarded. Codex served as both an implementation partner and an adversarial reviewer. Architectural decisions were converted into executable contracts and deterministic tests instead of being accepted on intuition alone.
The submitted Codex session primarily used GPT-5.6 (gpt-5.6-sol), together
with GPT-5.3 Codex Spark. Through Codex, GPT-5.6 contributed to:
- implementation;
- deterministic controller design;
- executable schemas and contracts;
- protocol consistency checks;
- adversarial review;
- reproducibility work;
- statistical planning;
- and evidence packaging.
The development process preserved negative results. When a proposed execution path failed its own integrity or scientific gate, that failure remained in the repository and changed the roadmap. This prevented a successful-looking demonstration from being substituted for evidence that the architecture improves model outcomes.
Challenges
The largest challenge was preventing the evaluation system from manufacturing false confidence.
It was not enough for the happy path to work. The system also had to ensure that:
- failed outputs remain visible;
- recorded evidence cannot be silently removed, replaced, or reordered;
- locked judgments cannot be overwritten;
- evaluator identities cannot be revealed before a result or exclusion is locked;
- safety enforcement remains outside model discretion;
- invalid state transitions are rejected;
- rollback can be checked independently;
- favorable evidence cannot override a protocol violation;
- and a demonstration cannot be mislabeled as scientific validation.
Several apparently promising paths were rejected by these gates. Preserving those failures made the system stronger and clarified the difference between a working controller and an untested research claim.
What I learned
The most important lesson was that reasoning quality may depend on more than improving individual reasoning steps. It may also depend on allocating effort: which branch deserves investigation, what blocks confidence, and which next question or experiment is most discriminating.
I learned that exploration and endorsement must remain separate. A hypothesis can be useful enough to investigate without being justified strongly enough to publish as a conclusion.
I also learned that negative results are not wasted work. Failed branches,
rejected designs, contradictory evidence, and NO-GO decisions exposed
weaknesses that favorable outputs alone would have hidden.
Building the controller showed me that prompts cannot enforce critical guarantees by themselves. Permissions, budgets, transitions, containment, evidence integrity, rollback, and publication boundaries require deterministic enforcement outside the model.
Finally, I learned to separate two achievements: building a working system and validating a scientific hypothesis. Reasoning Manager's deterministic lifecycle works and is reproducibly testable. Whether that lifecycle improves model outcomes is a separate question requiring controlled evaluation.
How judges can test it
The deterministic demonstration requires no OpenAI API key and performs no provider calls.
make bootstrap
PYTHONPATH=. .venv/bin/python scripts/run_minimal_interpretation_dry_run.py
make test
The short dry run should finish with passed=true. The full suite exercises the
controller, evidence integrity, scoring locks, replay behavior, containment
checks, and fail-closed paths. The repository README contains the complete setup,
environment, and reproduction instructions.
What comes next
The submitted implementation validates the deterministic orchestration and evidence lifecycle. Whether that lifecycle improves model outcomes remains a separate research question requiring controlled evaluation.
The planned evaluation is a blinded, resource-accounted comparison between a strong linear workflow and the checkpointed manager workflow using the same frozen model, task inputs, tools, and resource envelope. No improvement claim will be made unless that experiment passes its predeclared scientific and safety gates.
Built With
- Python
- JSON Schema
- RFC 8785 Canonical JSON
- Append-only JSONL evidence chains
- Deterministic orchestration
- Reproducible protocol design
- Codex
- GPT-5.6
- OpenAI reasoning-model workflow research
Reasoning Manager is a working system built to make reasoning inspectable and harder to misrepresent—and a research architecture designed to earn stronger claims through evidence rather than assumption.
Log in or sign up for Devpost to join the conversation.