Threadstate

Disclaimer: this was generated by gpt-5.6 there's two minutes left two submit

Inspiration

AI tools are highly productive inside a single session, but real work rarely stays in one place.

A project can begin in ChatGPT, change direction in Claude, move into Codex, produce several files, branch into a side task, and resume days later in another conversation. Chat titles, folders, and project names preserve where the work happened, but not necessarily what the user was actually trying to accomplish.

The user becomes the integration layer, repeatedly asking:

• What was I working toward?
• Where did the work branch or change?
• Which version should I trust?
• Which sources contradict one another?
• What remains unfinished?
• What evidence supports each conclusion?

Search can find matching words. It cannot reliably reconstruct the evolving state of the work.

What it does

Threadstate is a local-first continuity layer for AI-assisted work.

It imports supported conversations, coding sessions, and files as immutable evidence, then reconstructs possible goals across them. Instead of treating each session as a separate objective, Threadstate analyzes how work continues across providers, chats, coding agents, and artifact revisions.

The intended experience is:

Organize my work → review possible goals → understand what changed → see what remains unresolved → open the exact supporting evidence

Threadstate can surface:

• likely current objectives;
• branches and later resumptions;
• artifact and revision relationships;
• contradictory conclusions;
• work that was started but never integrated;
• evidence that remains ungrouped;
• unresolved judgments and possible next steps.

Every reconstruction remains a proposal. Threadstate does not silently accept a model’s interpretation, overwrite source evidence, choose a canonical file version, or modify a repository.

How Me and Codex built it

Threadstate is built with strict TypeScript, Node.js, Hono, SQLite, Drizzle ORM, Zod, and SQLite FTS5.

The reconstruction pipeline has five main stages.

1. Immutable ingestion

Versioned adapters normalize supported ChatGPT, Claude, Codex, and Claude Code exports into a deterministic ingestion contract.

Original conversation revisions and artifact snapshots remain immutable. Readable derivatives retain exact locators back to the original source material.

2. Local evidence preparation

Threadstate uses SQLite full-text retrieval, chronology, source roles, metadata, project-title priors, and optionally authorized embeddings to identify potentially related work.

Retrieval produces candidate evidence—not conclusions.

3. Four GPT-5.6 specialist Scouts

Four isolated specialists examine the work through different lenses:

• Intent Scout — what outcome was the user actually pursuing?
• Chronology Scout — where did work branch, pause, resume, or change direction?
• Artifact Scout — which files, revisions, and coding outputs belong together?
• Skeptic Scout — what contradictions, unsupported assumptions, missing evidence, or orphaned work exist?

At most two Scouts run concurrently.

4. Grounded reconciliation

A fifth GPT-5.6 process compares the Scout findings and proposes coherent goals, memberships, contradictions, unresolved material, and citations.

Before reconciliation, Threadstate compiles the strongest fully supported findings into a compact proof packet. Findings and their evidence are selected together. Unsupported Scout prose is deferred instead of being passed to the reconciler without proof.

5. Deterministic validation

Before any proposal can be persisted, Threadstate verifies:

• strict structured output;
• allowed evidence identities;
• exact evidence delivery;
• grouped-versus-ungrouped accounting;
• disagreement and overlap preservation;
• unresolved-material accounting;
• citation validity;
• exact source ranges;
• attempt-scoped provenance.

Every final citation must resolve through the reconciliation attempt’s delivery record to an immutable conversation range or artifact locator.

Thoughtful use of GPT-5.6

GPT-5.6 is used only for judgments that deterministic rules cannot reliably make:

• inferring the user’s underlying objective;
• distinguishing a branch from a separate goal;
• recognizing that work resumed in a later session;
• connecting artifact revisions to objectives;
• identifying contradictions and unsupported conclusions;
• reconciling competing interpretations into a provisional work state.

Deterministic software remains responsible for authorization, provenance, evidence selection, citation integrity, persistence, and failure handling.

In live synthetic verification, GPT-5.6 Sol completed a grounded reconciliation using retained outputs from four specialist Scouts. All required evidence was delivered, every production validator passed, and the result produced three possible goals with exact citations.

Thoughtful use of Codex

Codex was central both to building Threadstate and to its execution architecture.

During development, Codex was used to:

• understand and extend a growing TypeScript and SQLite codebase;
• coordinate bounded parallel engineering investigations;
• implement database invariants and migrations;
• create adversarial synthetic fixtures;
• build and test the four-Scout coordinator;
• diagnose real subprocess, MCP, schema, validation, and persistence failures;
• preserve exact failure receipts instead of silently retrying or hiding defects.

Inside Threadstate, isolated Codex subprocesses receive access only to the evidence authorized for that exact operation through a run-scoped, read-only MCP server.

Challenges

The hardest challenge was preventing several concepts that look similar from collapsing into one:

• a retrieved group is not automatically a goal;
• a chat title is not necessarily user intent;
• the newest file is not automatically canonical;
• a model statement is not an established fact;
• a mentioned path does not prove historical file contents;
• evidence delivered to a Scout does not prove delivery to reconciliation.

Failure handling was equally important.

Threadstate fails closed. Malformed output, missing evidence, invalid citations, or inconsistent state transitions do not produce partial proposals or silent fixture substitutions.

One live reconciliation completed successfully and passed every semantic, grounding, citation, and source-range validator. Its persistence transaction was rejected because the append-only retry policy required the newly authorized attempt to retain the previous attempt’s exact request identity. Threadstate rolled back the transaction instead of rewriting historical state or bypassing its provenance guarantees.

Accomplishments

• Built immutable ingestion for multiple AI-session formats and artifacts.
• Implemented local retrieval and evidence preparation with SQLite FTS5.
• Implemented four specialized GPT-5.6 Scouts with bounded concurrency.
• Built independently grounded global reconciliation.
• Reduced reconciliation input through whole-finding evidence compilation.
• Verified exact evidence delivery and attempt-scoped citation ownership.
• Completed a live GPT-5.6 Sol reconciliation with every production validator passing.
• Produced three possible goals from the fictional Aurora corpus.
• Built a reproducible fictional UI demonstration showing possible goals, changes, contradictions, unfinished work, and exact source drill-down.
• Preserved immutable failure history rather than weakening the system for a cleaner demo.

Live verification status

Live verification exercised every stage of Threadstate’s GPT-5.6 architecture, although it did not produce one normally persisted end-to-end result.

A fresh production run completed all four GPT-5.6 Sol Scout calls with bounded concurrency. Its global reconciliation then reached the production 180-second timeout without returning output.

Separately, one authorized reconciliation-only execution reused retained, immutable Scout results. That GPT-5.6 Sol call completed successfully, received all 19 required evidence items, passed every production schema, grounding, accounting, disagreement, overlap, citation, and source-range validator, and produced three possible goals.

Normal persistence was rejected because Threadstate’s append-only retry policy requires one exact request identity across attempts, while a newly authorized execution correctly receives a fresh attempt-scoped identity. Threadstate rolled back the transaction instead of rewriting historical state or bypassing its provenance guarantees.

The persisted Aurora interface shown in the demo is therefore a clearly labelled deterministic fictional demonstration, not the output of the live reconciliation.

What I learned

Continuity is not merely a chat-history problem.

Objectives can cross sessions, providers, projects, coding agents, and files. Reconstructing them requires interpreting intent, chronology, artifact lineage, and disagreement together.

Useful reconstruction must also preserve uncertainty. Contradictions, unsupported material, competing versions, and ungrouped evidence are part of the result—not noise to hide.

Finally, authorization and provenance must be visible product features. A trustworthy AI system should show not only what it concluded, but which evidence it received and how each claim traces back to an immutable source.

What’s next

The immediate next step is separating:

• the stable logical identity of a reconstruction request; and
• the fresh authorization, manifest, and delivery identity of each execution attempt.

That will allow failed and successful attempts to coexist append-only while ensuring every result remains bound to its own evidence-delivery ledger.

Later work includes:

• evaluating reconstruction quality on separately authorized real projects;
• showing how objectives change over time;
• creating a judgment queue for contradictions and competing versions;
• generating objective-specific continuation packages for supported AI tools;
• allowing users to continue from reconstructed state without losing provenance.

Built with

TypeScript, Node.js, Hono, SQLite, Drizzle ORM, Zod, SQLite FTS5, GPT-5.6, OpenAI embeddings under explicit authorization, Codex, and the Model Context Protocol.

Built With

• codex
• drizzle-orm
• embeddings
• gpt-5.6
• hono
• mcp
• node.js
• openai-embeddings-under-explicit-authorization
• sqlite
• sqlite-fts5
• typescript
• zod