Inspiration
Long-term human–AI collaboration does not usually fail because the AI forgot the words. It fails because it forgot what those words became.
Across research, product development, project management, editorial work, creative practice, operational procedures, and personal knowledge management, decisions change over time. Some information becomes current. Some becomes obsolete. Some ideas are rejected, replaced, or reopened for reconsideration.
An AI may retrieve every relevant sentence and still give the wrong answer if it no longer knows the decision state surrounding those sentences:
- Is this information still current?
- Was it replaced by a later decision?
- Was this idea rejected, and why?
- Is it merely being reconsidered, or has it actually been adopted again?
- Which source is authoritative: the original decision log, the final master, or a later summary?
I encountered this problem while managing long-running creative and publishing projects.
Old prices could reappear as current values. Lower-level edits could remain while the higher-level principle that governed them disappeared. A rejected passage could return without the reason it had been removed.
Creative and publishing work made this hidden failure especially visible because even a small loss of decision context can alter an entire work or workflow. But the problem is not limited to creative practice.
It appears anywhere a later decision depends on knowing not only what was recorded, but what became current, what became obsolete, what was rejected, what replaced it, and why.
Soki (想起) began from the hypothesis that many apparent memory failures are not failures to retain information. They are failures to preserve state, hierarchy, relationships, source authority, and decision rationale.
What it does
Soki is a decision-aware memory prototype for long-term human–AI collaboration.
Before answering, it resolves:
- the current state of each memory;
- superseded and rejected alternatives;
- relationships between decisions;
- higher-order principles that constrain lower-level choices;
- source authority;
- the rationale behind adoption, rejection, reopening, and re-adoption.
The prototype demonstrates three cases.
1. Current price resolution
Soki retrieves both current and obsolete prices. It uses explicit supersedes relationships and current-state information to answer with the valid prices while showing obsolete values as suppressed history.
2. Author-led literary revision
The author remains the creative subject and revises her own unpublished work.
Soki does not generate the work on her behalf. Instead, it recalls the work’s higher-level creative principle, practical revision rules, and a previous revision failure that became too explanatory. It then supports a revision direction that improves readability without flattening the work’s voice.
3. Rejected-candidate recovery
A previously rejected metaphor remains available in the decision history, together with its rejection reasons and replacement.
The user may explicitly reopen it for reconsideration, but reopening does not silently make it current. A separate, reasoned re-adopt event is required to replace the current decision.
Every correction is recorded with its reason and complete before-and-after state.
How we built it
Soki is a small Node.js web application with a deterministic decision-resolution core.
The resolver is divided into eight inspectable stages:
- validate the memory graph;
- retrieve relevant candidates;
- expand relationships;
- apply state rules;
- suppress invalid or superseded memories;
- resolve authority and conflicts;
- build a bounded decision packet;
- produce the final answer and reference explanation.
The deterministic core remains canonical. It decides which memories may be used, suppressed, or blocked.
An optional GPT-5.6 Responses API boundary may improve presentation and explain selected references, but it cannot override state, authority, rejection, supersession, stop conditions, or referenced-card IDs. Without an API key, all three demos remain fully operational in deterministic mode.
Corrections are stored as append-only JSONL events. Each event includes a reason and complete before-and-after snapshots. Events are replayed on startup, allowing state transitions to survive restarts without deleting rejected or obsolete history.
How Codex contributed
The project direction, problem definition, and design principles were defined by the author. Codex was used as an implementation partner and review assistant throughout development, materially expanding and hardening the initial scaffold.
It:
- separated the resolver into eight explicit stages;
- converted the product principles into deterministic invariants;
- implemented validation for broken references, malformed cards, invalid cycles, and cross-decision relationships;
- created append-only correction events with replay and atomicity checks;
- separated
reopenfromre-adopt; - strengthened the GPT-5.6 and HTTP boundary;
- redesigned the UI around selected, suppressed, and conflicting memories;
- added source reasons, correction history, and current-state visibility;
- expanded the test suite to 58 automated unit and HTTP integration tests;
- exercised all three demos through the running browser UI.
During final review, Codex also found an important authority-ordering bug: in an extreme conflict, a high-priority derived summary could outrank an original decision log.
The comparison order was corrected so that source authority is resolved before card priority.
That discovery directly reinforced the central product principle:
A summary must not overwrite the judgment recorded in its primary source.
Challenges
The main challenge was avoiding plausible but unsafe answers.
Simple retrieval ranking was not enough. A rejected memory could be lexically relevant. An obsolete value could match a question exactly. A derived summary could sound clearer than the original decision while carrying less authority.
The system therefore had to stop rather than guess when no current truth could be established, or when equal-authority current facts conflicted without an explicit relationship.
Another challenge was distinguishing reconsideration from adoption. Reopening a rejected idea had to preserve the current decision until the user explicitly approved a second state transition.
Accomplishments
- 58 automated tests passed, with 0 failures.
- All three demos were verified through the running browser UI.
- The application works without an API key in deterministic mode.
- The decision core, GPT boundary, UI, and correction history are separately inspectable.
- Codex’s contribution is visible in the Git history from the pre-Codex baseline through the completed implementation.
- No purchaser names, addresses, phone numbers, email addresses, bank details, or API keys are included in the demo data.
What we learned
Memory continuity is not primarily a storage-volume problem.
For long-running collaboration, an AI must preserve not only what was said, but:
- what became current;
- what became obsolete;
- what was rejected;
- what replaced what;
- which principles govern later choices;
- why a judgment was made;
- and what kind of user action is required to change it.
Creative work made one boundary especially clear: AI support becomes more valuable when it preserves human authorship rather than replacing it.
More broadly, the same principle applies wherever people remain responsible for consequential decisions. Soki is designed to preserve human decision authority across long-running collaboration.
It supports the continuity of judgment while leaving the final decision with the human.
What’s next
Future work includes:
- direct anchors back to original source logs;
- automated memory-card extraction with user review;
- branching decision histories;
- user-owned storage integrations such as Obsidian;
- permissions and retention controls;
- production-grade event storage, signatures, migration, and access control;
- broader evaluation of decision recovery across research, product development, project management, creative work, operations, and personal knowledge systems.
Log in or sign up for Devpost to join the conversation.