Titan — Verifiable Project Memory for Codex

Inspiration

I started Titan from a problem I repeatedly encountered in my own long-running projects: important decisions were scattered across chats, Obsidian notes, and source files.

During Build Week, I personally directed the product decisions, tested every major workflow, rejected approaches that overclaimed verification, and repeatedly rebuilt Auto Mode until it worked in a real Codex session.

AI coding agents are powerful, but long-running projects expose a recurring problem: important decisions become scattered across chats, Markdown files, old notes, and source code.

That creates several risks:

  • outdated guidance can be mistaken for current truth;
  • project constraints can be forgotten;
  • the wrong skill or method can be selected;
  • changes may be reported as complete without strong evidence;
  • durable project memory can be rewritten without human review.

Titan was created to give Codex the right project memory before it changes code, then verify what actually changed.

What Titan Does

Titan is a local-first project-memory and verification layer for Codex.

It can:

  • compile bounded context packs from project knowledge;
  • distinguish current, proposed, rejected, and superseded guidance;
  • select the right implementation skills;
  • import and synchronize Obsidian Markdown vaults;
  • observe real Git changes;
  • detect declared-versus-observed evidence mismatches;
  • require human review before durable memory is approved or exported;
  • automatically run a preflight and completion workflow through Auto Mode.

The core workflow is:

Prompt → Context → Skills → Work → Verify → Human Memory Review

How I Built It

Titan was built with Codex during OpenAI Build Week.

The project includes:

  • a TypeScript and Node.js backend;
  • SQLite persistence and full-text search;
  • an MCP server with 18 global tools;
  • bounded context compilation;
  • skill orchestration;
  • governed memory review;
  • Obsidian import and export;
  • Git-bound completion verification;
  • Codex hooks for preflight, tool-use checks, and completion checks;
  • a Windows x64 portable installer with bundled Node.js;
  • a public Judge Tour and Technical Inspector.

Auto Mode supports three context scopes:

  1. Registered workspace — global memory plus project-specific Vault memory.
  2. Unregistered project — global skills plus bounded local inspection and Git evidence.
  3. No project detected — global context only, without inventing project-specific facts.

The Hardest Challenges

Reliable Auto Mode activation

The hardest part was not creating another memory database. It was proving that Titan had actually entered the Codex workflow before the first edit, selected the skill itself, and verified the final Git evidence.

Several early trials failed, and I preserved those failures instead of presenting them as successful demonstrations.

Codex skills and hooks are separate mechanisms. Early versions allowed Codex to select a frontend skill directly without first creating a Titan context pack.

I added exact correlation between:

  • native session ID;
  • native turn ID;
  • context pack ID;
  • interaction ID;
  • hook event;
  • completion verification.

Titan only reports live activation when all evidence matches.

Honest verification

A caller can claim that files or tests changed, but those claims are not automatically trustworthy.

Titan now compares:

  • commits after the baseline;
  • staged changes;
  • unstaged changes;
  • untracked files;
  • declared files;
  • observed files;
  • patch and workspace fingerprints.

A mismatch produces FAIL / evidence_mismatch.

Test results remain explicitly marked as caller-supplied unless a trusted runner is introduced.

Avoiding overclaiming

Titan intentionally distinguishes:

  • integrity fingerprints from signatures;
  • observed changes from authorship;
  • caller-supplied tests from independently executed tests;
  • recorded Build Week evidence from a live hosted Codex session.

Warnings are preserved instead of being hidden or converted into false passes.

What I Learned

I learned that project memory must be governed, scoped, and traceable.

More context is not always better. The useful context is the smallest set of current, cited, task-relevant knowledge.

I also learned that verification should not only ask, “Did the tests pass?” It should ask:

  • What actually changed?
  • Did unexpected files appear?
  • Was the task scope preserved?
  • Were project constraints violated?
  • Is the completion claim supported by evidence?

Finally, I learned that humans should remain responsible for durable memory. Titan can propose knowledge, but it never automatically approves or exports it.

Results

The final Build Week release includes:

  • 402/402 backend tests passing;
  • 18 global Titan MCP tools;
  • 9 bounded public Atlas tools;
  • a deterministic 2,515-note stress fixture;
  • Git mismatch detection;
  • Auto Mode preflight and completion verification;
  • a portable Windows installer tested with a clean temporary profile;
  • zero automatic memory approval or export.

In the validated Auto Mode demonstration:

  • UserPromptSubmit was observed;
  • Titan created and injected the context;
  • frontend-responsive-ui was selected by Titan;
  • the first edit was observed;
  • Stop and the verifier were recorded;
  • completion was allowed;
  • local tests passed 2/2;
  • the final workspace contained zero !important declarations.

What Is Next

The next major feature is progressive verification for long-running tasks.

Titan will add bounded mid-task checkpoints that detect:

  • scope drift;
  • stale context;
  • unexpected files;
  • missing tests;
  • contradictory rules;
  • unsupported implementation claims.

This will help agents re-check their work during long tasks instead of waiting until the final response.

Built With

Share this project:

Updates