Model is replaceable. Context is replaceable. Thread is replaceable. Root persists.
Root Engineering is a context-engineering methodology for preserving validated project knowledge, decisions, constraints, learning, and source relationships around AI systems.
Root Engineering 1.0 — Rebirth extends the original idea: not only the model, but also the model's active conversation context can be treated as replaceable working memory. Ongoing long-horizon research now adds a further architectural conclusion: the current Chat/thread is also an execution resource, not the persistence authority for the project.
The Chat-native Rebirth adapter separates:
Thread / Chat Surface = current product-level execution container
Chat Transcript = human-visible history
Active Model Context = compactable working memory
Checkpoint = immediate resume state
Local ROOT = durable canonical project state
The current 1.0.0 adapter still works inside one Chat while that Chat remains viable. Automatic transparent thread rollover is a research direction, not a claimed 1.0.0 feature.
The goal is now:
Preserve project truth, compact working context when safe, continue the same human-facing Chat while it remains viable, and keep project identity independent of that thread.
Install Rebirth · Read the Rebirth architecture · Read the persistent-thread fusion contract · Review the benchmark · Read the detailed reference
The independent Persistent Project Thread experiment originally tested a stronger hypothesis:
If project truth is externalized and active model context can be repeatedly compacted, one ChatGPT thread can become a practically permanent project workspace.
The compaction findings themselves held:
- active-context compaction was repeatedly observed;
- the same conversation continued after compaction;
- older messages remained visible to the user;
- Local Root + Checkpoint could preserve project authority outside active model context.
But a later long-horizon observation falsified the permanent-single-thread conclusion. The human-visible thread continued to accumulate and the same Chat eventually became unavailable for continued work despite successful active-context compaction.
The exact internal cause is unknown. Root Engineering does not claim a specific message-count limit, transcript-token limit, UI limit, storage limit, retention-policy threshold, or private OpenAI implementation rule.
The supported architectural conclusion is:
PROJECT / AGENT IDENTITY
≠ THREAD
≠ HUMAN-VISIBLE TRANSCRIPT
≠ ACTIVE MODEL CONTEXT
≠ TOOL / MODEL RUNTIME
So the research question changes from:
How do we make one ChatGPT thread permanent?
to:
How do we make the project survive models, contexts, runtimes, and threads?
The failure is preserved as evidence in the experiment repository, while the surviving architecture continues here in Root Engineering.
→ Persistent Thread Fusion Contract
→ Long-horizon failure evidence
Rebirth calls its ChatGPT-native mode a Complete Chat Runtime — informally, a 완성형 Chat.
This is Root Engineering terminology, not an official OpenAI product name or feature claim. It is not a custom API client, CLI wrapper, coding-agent workspace, or external chat server. It is an operating pattern around one ordinary ChatGPT Chat:
one ordinary ChatGPT Chat
+ retained human-visible transcript
+ compactable active model context
+ chat-local ROOT
+ resumable CHECKPOINT
+ optional compact-time recovery mirror
= Complete Chat Runtime
The current Chat remains the workspace while viable. Context becomes maintainable. Root becomes the project memory.
Complete Chat Runtime should not be interpreted as a guarantee that one provider thread can exist forever. The long-horizon research now explicitly separates same-thread continuity from project continuity.
ordinary active work → Local ROOT only
압축해 / compact → synchronize configured latest recovery copy
백업해 / backup → one explicit backup without compaction
scheduled / idle / timer → disabled
background synchronization → disabled
Local state is persisted and verified before any external tool boundary. Optional backup failure is visible and recorded as pending; strict 백업하고 압축해 fails closed.
→ Explicit compact-time recovery policy
Root Engineering 0.x primarily solved cross-session continuity by keeping project state outside the model, with ChatGPT using Google Drive as a canonical store.
Rebirth adds a Chat-native runtime:
ordinary ChatGPT Chat
↓
/mnt/data/root-engineering/
↓
ROOT + knowledge owners + CHECKPOINT
↓
Persist → Verify → Synchronize configured recovery copy → Compact → Rehydrate
↓
continue the same Chat while viable
For the default ChatGPT Rebirth adapter:
- ChatGPT Project is not required.
- Google Drive is not required.
- Chat-local
/mnt/datais the primary current-runtime store when it is writable. - Google Drive, Git, and exported bundles become optional backup/recovery adapters.
runtime/CHECKPOINT.mdis a first-class owner for the current work-in-progress state.- the command
압축해/compactmeans save durable state → refresh checkpoint → verify → synchronize the configured recovery copy → compact → rehydrate, not merely "summarize the chat." - save failure blocks deliberate compaction.
Rebirth does not claim that /mnt/data survives every future runtime, that every ChatGPT thread exposes the same compaction trigger, or that successful compaction guarantees unlimited thread lifetime. Host-specific compaction paths are capability-gated and must be verified in their actual scope.
→ Root Engineering 1.0 Rebirth architecture
Root Engineering did not start as a methodology. I was using ChatGPT and Claude heavily — often pushing high-reasoning models until both plans hit their limits. ChatGPT Chat still gave me a separate surface to experiment with, so I started asking a different question: how much smarter could ordinary chat feel if I improved the external context instead of just spending more model?
That led to Markdown as manually maintained project memory. The first version was primitive: upload the MD files, talk with the model, replace the files when things changed. Even that was surprisingly powerful.
The next bottleneck was predictable: manually moving and replacing the MD files. Root Engineering formalized what should be read, verified, updated, preserved, and pruned.
Rebirth came from the next bottleneck: long-lived Chat threads themselves. Once human-visible transcript history, active model context, and durable Root state were treated as different resources, a new path appeared — preserve the Root, replace the active context, and keep the thread viable for longer.
The next long-horizon failure exposed one more boundary: the thread itself cannot be the permanent project object. That failure now drives the next research direction — project and agent continuity across replaceable execution sessions.
- Open the canonical Rebirth installer.
- Attach it to an ordinary ChatGPT Chat with a writable local workspace.
- Say: “Read the package and install it.”
- The installer verifies the chat-local workspace, creates the Local Root, and runs local consistency checks.
Korean users can use ROOT_ENGINEERING_REBIRTH_INSTALLER_KO.md.
Default local layout:
/mnt/data/root-engineering/
├── BOOT.md
├── ROOT.md
├── MANIFEST.json
├── knowledge/
│ ├── FOUNDATION.md
│ ├── CURRENT.md
│ ├── LEARNED.md
│ ├── OPERATIONAL.md
│ └── HISTORY.md
└── runtime/
├── CHECKPOINT.md
├── STATE.json
└── CAPABILITIES.json
The package includes explicit guards for local write verification, save-before-compact, capability-scoped compaction, context epochs, selective boot, Operational Memory, and Checkpoint-based rehydration.
Validation tools:
The existing Drive-native 0.x installer remains available for existing installations and as an external persistence/recovery path:
A Drive-based Root can be migrated into a Rebirth Local Root while preserving proven Project/Root identity. Large source documents do not need to be copied automatically; their Drive IDs/URLs may remain external evidence routes.
Install the repository's standalone root-engineering Skill with Codex's built-in installer:
$skill-installer install the skill from https://github.com/Valon-Jang/Root-Engineering/tree/main/installer/codex/root-engineering
The Claude adapter remains available for environments where Drive-backed Markdown persistence is the appropriate runtime:
User works in one primary Chat
↓
New durable state?
↓ yes
Patch the smallest correct Root owner
↓
Refresh CHECKPOINT when context maintenance is requested
↓
Verify writes
↓
Compact active model context only through a supported or verified path
↓
Rehydrate BOOT + CHECKPOINT + only required owners
↓
Continue the same Chat while viable
The 1.0.0 runtime does not yet hide provider-thread rollover behind one persistent project UI. At the architecture level, however, the project identity must not depend on the lifetime of the current Chat.
SAVE FAILURE = NO COMPACT
A compaction request is a state transaction. If required Root/Checkpoint persistence cannot be verified, Rebirth keeps the active context and stops instead of risking silent state loss.
ROOT / knowledge/* stores durable project truth.
runtime/CHECKPOINT.md stores the temporary resume state of the current work:
Current goal
Completed work relevant to resumption
Current transient state
Next actions
Pending blockers
Resume instruction
This prevents short-lived work progress from polluting long-term project knowledge while still allowing a compacted context — and, in future research, a replacement session — to resume from a bounded state.
Each confirmed compaction advances the runtime context epoch:
Epoch 0 → Epoch 1 → Epoch 2 → ...
This provides a measurable basis for long-horizon tests such as resume accuracy, decision retention, no-repeat behavior, latency/context trend, and quality loss across repeated compactions.
Future research can add a separate session/thread epoch rather than pretending context epochs alone describe the full lifecycle.
Rebirth deliberately does not invent private ChatGPT endpoints.
Priority order:
- Native supported compact action — only when the current host actually exposes one.
- Verified zero-output tool/sampling boundary — only when the same environment has demonstrated that behavior and success can be verified.
- Bounded diagnostic pressure — diagnosis only, small increments, immediate stop on success.
The related public experiment is maintained separately in persistent-project-thread. In the tested long-lived ChatGPT thread, trigger reduction reached a zero-output pass boundary after earlier oversized pressure experiments. That observation is environment-specific evidence, not a universal ChatGPT guarantee.
The same experiment later showed that successful active-context maintenance does not imply unlimited lifetime of the surrounding Chat thread.
- Think in Chat first. Turn a vague idea into a concrete one.
- Use Question-Driven Deepening. Ask only what can change the next decision.
- Persist useful state. Confirmed facts, decisions, constraints, important unresolved items, and verified lessons go to the correct Root owner.
- Keep transient work in Checkpoint. Do not turn every task-progress detail into durable knowledge.
- Compact safely when needed. Save → verify → synchronize the configured recovery copy → compact → rehydrate.
- Treat the current thread as a workspace, not the project identity. Do not let durable project truth exist only in the conversation surface.
- Use isolated execution environments where appropriate. Codex, agents, destructive tests, or security boundaries may still use separate execution threads.
- Feed verified results back into the Root.
Chat shapes the work. Execution tools perform isolated work. Root preserves truth. Checkpoint preserves immediate continuity.
The durable knowledge tree remains intentionally small:
ROOT
├── Foundation
├── Current Knowledge
├── Learned Knowledge
├── Operational Memory
└── History
- Foundation — stable purpose, principles, boundaries, Human Intent.
- Current Knowledge — currently valid facts, decisions, constraints, status, unresolved issues.
- Learned Knowledge — verified reusable methods and generalized lessons.
- Operational Memory — exact repeated-operation keys, failed-path constraints, verified hot paths, required evidence.
- History — superseded states that still matter for transition, rollback, or failure prevention.
Create additional children only when real independent retrieval/update patterns require them.
Navigate the Root. Do not dump the Root.
- Preserve selectively. Save only what materially improves future reasoning or execution.
- Keep one canonical current state. Do not duplicate current truth across competing owners.
- Separate project knowledge from models, active context, and provider threads. They are execution resources, not project authority.
- Separate durable Root from transient Checkpoint.
- Read selectively. Load only what the current task needs.
- Verify before persistence. Model inference must not silently become project fact.
- Reuse verified successful paths and preserve failed paths as constraints.
- Patch minimally and prune locally.
- Do not compact before required state is safely persisted.
- Do not equate context compaction with transcript compression or permanent thread lifetime.
The save gate remains:
Would losing this information materially increase the chance that a future AI must rediscover it, make a worse decision, or repeat a previous failure?
Loop Engineering improves the current run.
Root Engineering improves what survives the run.
Rebirth adds:
Context maintenance keeps the human-facing project thread viable for longer without making raw conversation history the project database. Thread-independent Root state keeps the research open beyond the lifetime of any one thread.
Project Atlas Benchmark v0.1 remains the original paired Root-vs-native continuity experiment.
It found early divergence when exact configuration scope and source provenance became important, while also showing that Root maintenance itself has non-trivial update/canonicalization cost. These are preliminary small-n manual observations, not statistical proof.
Inspect:
Rebirth adds two long-horizon benchmark directions:
- repeated
Persist → Checkpoint → Compact → Rehydratecycles inside one viable Chat, measuring state accuracy and degradation across context epochs; - future
Persist → Checkpoint → Replace Session → Rehydrateexperiments, measuring whether project/agent identity survives thread replacement without replaying the entire transcript.
Root Engineering is not a transcript archive and does not mean saving everything.
It does not prescribe one database, vector store, graph, or agent framework. Rebirth also does not claim that a ChatGPT-local filesystem is universally permanent, that compaction physically deletes transcript/provider records, or that one ChatGPT thread can be made permanent through context maintenance alone.
The methodology focuses on the knowledge and runtime lifecycle:
Acquire
→ Evaluate
→ Use
→ Verify
→ Persist Selectively
→ Checkpoint Transient Work
→ Compact Working Context When Safe
→ Replace execution/session surfaces when necessary and supported
→ Retrieve Selectively
→ Update / Prune
Transparent thread rollover remains research, not a current 1.0.0 production claim.
| Goal | Document |
|---|---|
| Install Rebirth in ordinary ChatGPT Chat | Rebirth installer |
| Rebirth 한글 설치 | Rebirth 한글 설치기 |
| Understand Rebirth architecture | Rebirth 1.0 architecture |
| Understand persistent-thread research integration | Persistent Thread Fusion Contract |
| Read the independent long-horizon experiment | Persistent Project Thread |
| Existing ChatGPT Drive installation | Legacy Drive installer |
| Install with Codex | Codex installer |
| Install with Claude + Drive | Claude installer |
| Detailed original methodology | Detailed reference |
| Review the original paired experiment | Project Atlas Benchmark |
Root Engineering 1.0.0 — Rebirth is the current Chat-native architecture.
Verified locally for the release package:
- Rebirth installer structural validator: PASS
- chat-local Root file creation: PASS
- identity read-back across canonical owners: PASS
- Checkpoint independent update: PASS
- save-failure compaction guard simulation: PASS
- context epoch increment only after simulated confirmation: PASS
Host-specific compaction remains capability-gated. The long-lived ChatGPT experiment provides evidence for a zero-output boundary fallback in that tested environment and also provides a falsifying long-horizon result: repeated active-context compaction did not make one ChatGPT thread indefinitely usable.
That limitation is treated as a current product/thread boundary, not as the end of the research. Root Engineering continues toward thread-replaceable project/agent continuity.
Open research includes:
- session/thread rollover behind one stable project identity;
- Root + Checkpoint rehydration into a fresh execution surface;
- human-view compression where raw history and rendered history are separate;
- transcript/event retrieval without full-history context loading;
- session epochs and thread-health signals;
- continuity across model/runtime/provider replacement.
These are research directions and are not claimed as completed 1.0.0 runtime features.
Useful contributions include:
- repeated-compaction experiments
- host compaction capability observations
- thread/session lifetime observations
- state-loss and recovery failure cases
- storage adapters
- benchmark designs and reproductions
- retrieval/pruning improvements
- model/runtime portability tests
- practical long-horizon case studies
Strong evidence is more valuable than additional terminology.
Except where otherwise noted, the methodology, documentation, installers, and benchmark materials in this repository are licensed under the Creative Commons Attribution 4.0 International License.
Copyright © 2026 Valon-Jang.
The transcript may remain. The active context may die. The thread may end. The checkpoint bridges transitions. The Root preserves truth. The same project continues.