Decisium Partners - Mission Control Module

From governed evidence to accountable action.

Comment

Inspiration

Commercial teams often have plenty of dashboards but no reliable path from a signal to an accountable decision. I built Mission Control, a module of wider system - Decisium Partners, to close that gap without allowing AI to invent evidence, approve its own recommendation or overstep human authority.

What it does

Mission Control converts a synthetic commercial risk into a governed mission. It presents traceable evidence, generates a bounded advisory, keeps approval with authorized humans, requires the receiving role to accept the handoff, tracks execution and outcome, and records every transition in a hash-chained audit trail.

The verified judge journey moves through:

  • Signal and mission creation
  • Governed evidence
  • Structured AI advisory
  • Human disposition and decision submission
  • Two authorized approvals
  • Handoff creation and recipient acceptance
  • Execution and outcome recording
  • Audit verification ending at OUTCOME_RECORDED

How this fits into the larger system

Mission Control is the focused, judge-safe submission surface of a broader in-development Decisium Partners Commercial Decision Operating System. The full system is being built to connect multiple commercial signals, governed evidence sources, decision workflows, execution handoffs, outcomes and organizational learning.

This Build Week submission intentionally demonstrates one complete governed decision journey rather than presenting the unfinished wider platform. It is a real working slice of the broader architecture, not a disconnected mini-app, and it should not be interpreted as the full extent of the system.

How it was built

The submission extends an existing full-system Mission Control architecture rather than replacing it with a disconnected demo. The judge build uses a dependency-free same-origin portal, a Python application API, SQLite, role and authority controls, governed evidence, deterministic commercial analysis, an explicit provider abstraction, human decisions and approvals, accepted handoffs, execution, outcomes and append-only audit events.

The provider boundary includes a deterministic fixture implementation and an OpenAI Responses API implementation with strict JSON Schema. Live mode is explicit and fails closed; it never silently falls back to fixture output.

How GPT-5.6 is used

The GPT-5.6 provider contract receives only a canonical evidence envelope and a permitted action list. It must return a structured advisory containing risk summary and level, known evidence references, missing evidence, options and trade-offs, one permitted recommended action, confidence and requires_human_approval=true.

Unknown evidence IDs, unsupported actions, malformed output and incomplete responses are rejected. The model cannot approve, accept a handoff, execute, record an outcome or mutate workflow state.

The verified release uses deterministic fixture mode for reproducible judging. No successful live GPT-5.6 response is claimed.

How Codex was used

Codex helped inspect the canonical system, identify the actual advisory seam, implement the provider abstraction and Responses API contract, remove silent fallback, add authority and schema tests, create a reproducible judge portal, run clean-folder and browser validation, verify sanitization, build the release archive and checksum, and prepare the submission documentation.

The core builder decisions remained human-owned: retain the full-system architecture, reject the retired mini-application path, use synthetic public data, keep AI advisory only, require two authorized human approvals, require explicit handoff acceptance and state all limitations honestly.

Primary Codex /feedback Session ID:

019f80a7-7fa7-78a0-b4dc-5b2edb6773b9

Challenges

The main challenges were separating pre-existing system depth from Build Week work, converting a broad internal architecture into a public-safe package, constraining model output with evidence and schema, preserving segregation of duties, creating a runtime that does not depend on package-registry access, and proving reproducibility from a clean extracted archive.

Accomplishments

  • Implemented explicit fixture and OpenAI Responses API provider boundaries.
  • Removed silent fixture fallback from live mode.
  • Added evidence-ID, allowed-action, confidence and human-authority validation.
  • Preserved human decisions, two-person approval, accepted handoff, execution, outcome and audit boundaries.
  • Built a dependency-free same-origin judge portal.
  • Passed 80 backend and authority tests.
  • Passed three consecutive fixture journeys ending at OUTCOME_RECORDED.
  • Passed clean-folder startup and browser journey validation with 19 audit events and no console or page errors.
  • Passed archive inventory and checksum verification.
  • Scanned the public release with zero restricted-term and zero sensitive-configuration findings.

What I learned

Useful AI systems need explicit evidence, action and authority boundaries. A focused judge path can reveal the value of a larger operating system without pretending the whole platform was built during the event. Reproducibility, sanitization and truthful failure handling are product features.

What's next

Future work includes owner-authorized live provider validation, approved source adapters, enterprise identity, managed configuration and observability, public hosting, and broader outcome evaluation across additional mission templates.

Testing instructions

Important: do not open portal/index.html directly. The portal is a same-origin application and must be started through the included local server so its CSS, JavaScript and API routes load correctly.

Requirements: Python 3.11 or newer. The verified judge path requires no API key and no third-party Python packages.

From the extracted release root:

python scripts/reset_demo.py
python scripts/run_demo.py

Then open:

http://127.0.0.1:8765/

Run the tests:

python scripts/run_tests.py

Run three deterministic end-to-end journeys:

python scripts/run_three_journeys.py

Verified results:

  • 80 tests passed
  • 3 of 3 fixture journeys passed
  • final workflow state: OUTCOME_RECORDED
  • mission state: COMPLETED
  • audit chain valid

Known limitations

The verified default is fixture mode. Production SSO, managed configuration storage, external business connectors, public hosting, production certification and enterprise-scale validation are outside this release. Synthetic values demonstrate workflow governance, not production business truth.

Built With

Share this project:

Updates