Inception - Reality Engine

Reality Engine turns Codex into Inception for code: agents enter nested, isolated Dreams, challenge competing ideas, then Kick back only Memories that pass a Totem Check before changing Reality.

Comment

Inception: Reality Engine

Reality Engine lets Codex dream before it changes Reality.

## Inspiration

Coding agents are becoming powerful enough to inspect unfamiliar systems, delegate work, execute commands, run tests, and implement substantial changes. However, most agent workflows still happen inside one shared context.

That creates a dangerous feedback loop. An unsupported assumption introduced early can influence the plan, tests, requirements, and implementation, while the same context ultimately decides whether its own work is correct.

I wanted to give Codex somewhere safe to be wrong.

The inspiration came from Inception. The film provides a familiar way for non-technical users to understand a complex agent-safety problem:

  • Reality is the protected repository.
  • A Dream is an isolated counterfactual world.
  • A Dream within a Dream explores uncertainty discovered at a deeper level.
  • Subjects enter Dreams with bounded roles.
  • A planted idea represents a dangerous assumption or regression.
  • A Kick returns experience from a Dream to its parent.
  • A Totem Check determines whether returned Memory can be trusted.
  • Reality Anchors are requirements that Dreams cannot rewrite.

Reality Engine turns those concepts into enforceable software boundaries.

## What I Built

Reality Engine is a counterfactual runtime for Codex.

Instead of immediately changing the protected repository, Codex creates nested Dreams to experience competing assumptions. Every Reality has its own:

  • premise and constitution;
  • persistent Codex thread;
  • Git worktree and branch;
  • Python virtual environment or project-local Node.js dependencies;
  • evidence, beliefs, history, and uncertainty;
  • inherited immutable requirements.

Inside each Dream, bounded Codex subagents called Subjects investigate independently. They can act as implementation reviewers, test engineers, boundary investigators, or controlled adversarial engineers.

A Dream can discover an uncertainty and create another Dream beneath it. Sibling Dreams test competing explanations without contaminating one another or their parent.

When exploration ends, a Kick requests structured Memory containing:

  • what the Dream initially believed;
  • what it experienced;
  • the evidence it discovered;
  • which beliefs changed;
  • which conclusions generalise;
  • which artefacts should return;
  • what remains uncertain.

Every Codex-facing result is validated with Zod before it can be persisted or rendered. However, valid structure alone does not make a Memory true.

The parent-owned Totem Check binds each returned Memory to its exact Git source state, evidence lineage, artefacts, immutable Anchors, descendant Memories, and any sealed adversarial intervention. Unsupported or contaminated Memory is quarantined automatically.

A Reality Mirror compares sibling Dreams. It admits conclusions that survive competing worlds while preserving disagreement as visible uncertainty.

Only verified Memory can ascend level by level. Only proof-backed synthesis can change Reality.

## The Demonstration

The primary demonstration is a real, authorized review of the local VAmPI educational security fixture.

GPT-5.6 Codex explored the repository through:

  • 15 isolated Realities
  • 14 nested Dreams
  • 3 levels of depth
  • 44 native Subject returns
  • 115 evidence records
  • 14 verified Memories
  • 7 sibling Reality Mirrors

A bounded adversarial Subject named Mal planted one authorization regression inside a sealed Dream. Independent Subjects were not told what had changed, but identified the fault from observable evidence.

At the Kick, the Totem Check compared their diagnosis with the private intervention ledger, confirmed the exact match, restored the clean baseline, and prevented the planted code from ascending.

The useful security knowledge and independently created regression evidence were still admitted.

The final synthesis:

  • removed an unscoped secret lookup;
  • enforced owner-qualified access;
  • failed closed when identity was missing;
  • preserved administrator-only deletion;
  • added twelve authorization tests.

The parent-owned immutable proof passed before Reality stabilised.

A second password-reset Demo Mission provides a simpler measured example. It discovers that per-IP throttling still permits rotating-source abuse and account enumeration.

Before synthesis, rotating sources deliver 12/12 reset attempts. After verified synthesis, the shared identifier budget delivers only 3/12, known and unknown accounts receive the same public response, a planted mutation is excluded, nine regression tests pass, and all four parent-owned Anchors survive.

## How I Built It

Reality Engine is a TypeScript monorepo built with:

  • Next.js and the App Router;
  • @openai/codex-sdk;
  • Node.js server orchestration;
  • SQLite with Prisma;
  • Git worktrees;
  • Zod runtime schemas;
  • Server-Sent Events;
  • Vitest;
  • Playwright.

The architecture separates domain rules from infrastructure:

  • packages/domain owns Realities, Dreams, Subjects, Evidence, Anchors, Wake Reports, and validation contracts.
  • packages/orchestrator owns Dream creation, Kicks, memory integrity, sibling comparison, synthesis, and stabilisation.
  • packages/codex-runtime owns Codex SDK threads, resumability, structured prompts, and native Subject evidence.
  • packages/worktree-manager owns Git isolation, checkpoints, cleanup, and Reality-local dependency environments.
  • apps/web presents the Reality graph, timeline, Subjects, evidence, Memories, Totem Checks, proofs, and final diff.

Each Reality receives a persistent Codex thread and isolated worktree. When dependencies are required, Python packages enter that Reality’s .venv, while Node.js packages remain inside its project-local dependency environment. Neither path modifies the judge’s global installation.

The UI never exposes hidden model reasoning. It displays only concise events, evidence, decisions, artefacts, validated summaries, and auditable execution metadata.

Real mode uses the operator’s Codex CLI authentication or OpenAI API key. Loading, refreshing, replaying the timeline, or opening Admin never consumes Codex usage. Usage begins only after an explicit action.

A deterministic mode uses the same domain, integrity, event, and UI contracts for credential-free evaluation and repeatable recording.

## How I Used Codex and GPT-5.6

I built Reality Engine from scratch during Build Week through one primary GPT-5.6 Codex development session.

GPT-5.6 was not used only as an occasional code generator or runtime dependency. It was my primary engineering collaborator across the entire project lifecycle.

I directed the product vision, Inception mental model, safety boundaries, full-power real-mode requirement, and key engineering decisions. GPT-5.6 worked with me end to end to:

  • evaluate and replace the initial application shell;
  • design the Reality, Dream, Subject, Kick, Memory, Totem Check, and Anchor domain model;
  • architect and implement the TypeScript monorepo;
  • integrate the Codex SDK and persistent Reality threads;
  • build Git, Node.js, and Python environment isolation;
  • implement Wake Report validation and evidence lineage;
  • build memory-integrity seals and descendant verification;
  • implement adversarial containment and automatic rollback;
  • compare sibling Dreams and preserve disagreement;
  • synthesise verified Memory into Reality;
  • implement immutable parent-owned proofs;
  • diagnose failures from real Codex runs;
  • improve the engine after each live run;
  • build the Next.js product experience and Reality graph;
  • implement timeline replay and detailed event inspection;
  • build Mission Control and Admin process controls;
  • create unit, integration, smoke, and Playwright tests;
  • perform desktop and tablet visual QA;
  • monitor and complete the password-reset and VAmPI runs;
  • review the final generated code and Git diffs;
  • write the setup, architecture, judge, collaboration, and submission documentation;
  • create the complete three-minute demonstration;
  • automate its Playwright choreography;
  • write the spoken narration;
  • generate and validate the synchronized SRT captions;
  • generate the timed ElevenLabs voiceover script;
  • verify the final video duration, captions, visual states, and action drift.

The submitted VAmPI demonstration is itself a preserved real GPT-5.6 Codex run. Its Reality threads and native Subject child threads used gpt-5.6-sol to inspect code, edit isolated worktrees, execute commands, challenge assumptions, create tests, and return structured evidence.

The final submission therefore demonstrates GPT-5.6 at two levels:

  1. GPT-5.6 and Codex were used to build Reality Engine from scratch.
  2. GPT-5.6 is the reasoning engine operating inside the finished product.

Every part of the submission was produced through this collaboration, including the application, tests, documentation, real demonstration runs, automated video, narration, SRT captions, and voiceover timing.

Human judgment remained responsible for the product direction and admission policies. I decided that Codex must remain fully capable inside Dreams, that no usage could begin on page load, that parent-owned Anchors could not be rewritten, that schema-valid output was not automatically trustworthy, and that planted changes must be contained without discarding independently verified knowledge.

GPT-5.6 and Codex turned those decisions into a tested, documented, runnable, and submission-ready product.

## Challenges I Faced

### Making isolation real

The first challenge was ensuring isolation existed in practice rather than only in the interface.

Every Reality needed a persistent Codex thread, exact Git worktree, recoverable checkpoint, and isolated dependency environment. Cleanup and reset operations also had to remove only engine-owned state without risking the user’s repository or saved Missions.

### Distinguishing valid output from trustworthy knowledge

A perfectly formatted Wake Report can still contain a planted assumption.

This led to the Totem Check, evidence lineage, immutable Anchor fingerprints, exact source-state digests, descendant seals, artefact verification, and adversarial-intervention comparison.

### Proving that Subjects actually ran

A primary model could claim that subagents had investigated something without actually delegating.

Reality Engine therefore requires auditable native child-thread lifecycle evidence before accepting Subject reports. It records safe thread identifiers and structured outcomes without exposing hidden reasoning or raw Subject messages.

### Making complex orchestration understandable

A large run can contain hundreds of events and many nested worlds. A generic multi-agent dashboard would make the concept harder to understand.

The Inception language, branching Reality graph, Subjects beneath their owning Dreams, staged Kicks, Totem Check, Memory ascent, and Reality Mirrors make the workflow understandable without requiring the viewer to understand Git internals or Codex orchestration.

### Fitting a real run into three minutes

A live Codex run is too slow and variable for a short submission video.

I built a synchronized replay system that uses a completed real run while preserving its authentic model, thread, Subject, evidence, intervention, and proof events. The Playwright actor, UI actions, captions, SRT file, and voiceover script all use the same timing source.

## What I Learned

I learned that structured output is a transport contract, not a truth mechanism.

Trustworthy agent workflows need provenance: which world produced a conclusion, which evidence supports it, which source state it came from, and which requirements survived.

I learned that disagreement is valuable. Multiple agents agreeing inside one shared context is weaker than independent conclusions surviving genuinely isolated counterfactual worlds.

I also learned that safety does not have to mean making Codex read-only. Codex can remain fully capable inside a Dream while the parent controls what is allowed to become Reality.

Finally, I learned how valuable a familiar metaphor can be. Nested Dreams, Subjects, planted ideas, Kicks, Memories, Totem Checks, and Reality are easier for non-technical users to understand than threads, worktrees, schemas, lineage hashes, and orchestrator policies, even though those technical mechanisms enforce the metaphor underneath.

## Potential Impact

Reality Engine is designed for engineers, maintainers, security teams, and platform teams adopting increasingly autonomous coding agents.

It reduces the risk of an agent-authored regression, unsupported requirement, or contaminated assumption silently reaching the protected repository.

It also gives reviewers a concise explanation of:

  • what was explored;
  • which competing worlds were tested;
  • what failed;
  • what generalised;
  • which evidence supports the result;
  • what remained uncertain;
  • why a final change was admitted.

The goal is not simply to run more agents.

The goal is to make agent experience trustworthy enough to change Reality.

Built With

Share this project:

Updates