Fortuna Mission Control: Trading Safety Gate

A fail-closed safety layer for AI-assisted trading workflows. If required operating evidence is stale or conflicting, consequential actions are blocked.

Comment

What is Fortuna Mission Control?

Fortuna Mission Control is a safety control layer for AI-assisted trading operations.

It is not a trading bot. It does not recommend trades, connect to a broker or place orders. Its job comes before execution: checking whether the required operating evidence can be trusted before consequential actions are allowed to proceed.

If evidence is stale, missing or contradictory, Fortuna does not guess. It classifies the situation, blocks the affected actions and leaves the final decision with a human.

Why I built this

Most financial AI products focus on finding opportunities, producing recommendations or automating more of the workflow.

I became interested in the opposite question:

How does an AI-assisted trading system know when it must stop?

In a consequential financial workflow, a confident answer based on unreliable evidence can be worse than no answer at all. I wanted to build a control layer where stopping is treated as correct system behaviour—not as a failure.

The underlying operational concept existed before Build Week. During Build Week, I used Codex with GPT-5.6 to separate that concept from the private system and build a new public demonstration using fictional scenarios, synthetic records, deterministic validation, acceptance tests and a judge-facing interface.

What Fortuna Mission Control does

Fortuna evaluates four mandatory pieces of evidence before consequential actions can proceed.

It demonstrates three operating states:

  • Normal: the required evidence is fresh and consistent.
  • Degraded: evidence is stale or incomplete, so consequential actions are blocked.
  • Manual Survival: authoritative evidence is unknown or conflicting, so automation gets out of the way entirely.

Even after new evidence arrives, Fortuna does not quietly restore authority or resume work. It only marks recovery as eligible for human review. The final decision always belongs to a person.

Try the Degraded scenario in the demo. One stale record is enough to lock all five consequential actions. It is intentionally strict.

How I built it

I built the public demonstration with Next.js, React, TypeScript, Tailwind CSS and a deterministic JavaScript evaluator.

Codex with GPT-5.6 helped me turn the safety concept into something testable. We worked through questions such as:

  • What exactly counts as fresh evidence?
  • What should happen when two sources disagree?
  • Can a missing result accidentally appear as a pass?
  • Should successful reconciliation automatically restore the previous state?
  • How can the public demo remain meaningful without revealing private information?

I made the key product and governance decisions: the operating states, evidence requirements, fail-closed policy, disclosure boundary, recovery rules and preservation of human final authority.

Codex accelerated the implementation, tests, interface, documentation and release preparation. GPT-5.6 helped examine how the rules interacted and identify places where a seemingly small recovery rule could create an unintended route back into automation.

The finished runtime is deliberately deterministic. It does not call an AI model, connect to a broker, prepare orders or make financial decisions. Codex and GPT-5.6 were used to design, build and verify the safety layer.

The hardest part

The hardest part was making “nothing happened” feel like a successful result.

When evidence is unreliable, stopping is the correct behaviour. But simply disabling a button is not enough. The interface must explain what failed, why actions are blocked and what evidence would be needed before a human could reconsider the situation.

The second challenge was the public disclosure boundary. I wanted the demonstration to remain credible without exposing private records, strategies, credentials or operational history. Everything visible in the public project is therefore fictional.

What I learned

Fail-closed behaviour is not merely error handling. It is a product feature.

A trustworthy control layer should explain:

  1. What evidence it checked.
  2. Which evidence cannot be trusted.
  3. What actions are now blocked.
  4. What is required for recovery.
  5. Who still holds final authority.

That problem turned out to be more interesting than simply asking an AI to generate another recommendation.

What comes next

The same pattern could support other consequential workflows, including compliance reviews, incident response, approvals and back-office operations—anywhere acting on unreliable evidence is worse than waiting.

My next step would be to make the evidence contracts configurable while preserving the essential guarantees: deterministic validation, fail-closed defaults and human final authority.

Built With

Share this project:

Updates