Model is replaceable. Context is replaceable. Thread is replaceable. Root persists.
Navigation checked on 2026-09-19. Release lines target different environments; a larger version number in one line does not upgrade another line. Linked manifests and release documents remain authoritative.
| Environment / purpose | Published entry or candidate | Status and boundary |
|---|---|---|
| Ordinary ChatGPT Chat | Rebirth installer · VERSION | Rebirth 1.0.0 is the default published line on main. |
| Rebirth next version | Staged manifest · release notes | Rebirth 1.1.0 Sidecar Work Graph is staged, not a replacement of the default installer. |
| ChatGPT Project + Google Drive | Drive installer · Korean | The canonical main file identifies v0.1.12. The v0.1.13 versioned file and v0.2.0 Library Hot Root draft are separate candidates. |
| Codex / Claude | Codex installer · Claude installer | Select the adapter for the actual host and run its acceptance procedure. |
| Evidence and ongoing research | Argument and evidence audit · Project Atlas · open research PRs | Preliminary results, staged packages, and unmerged research remain distinct. |
Existing versioned packages, experiments, and history remain in their original locations. This map does not promote a candidate or certify a new runtime.
In the synthetic procurement / part-qualification Project Atlas scenario, the Native condition retained high-level rules but omitted a prepared 120-sample + QR package and the exact C1 validation evidence. The published evaluation reports that this changed the reconstructed readiness state and final decision ranking. Root retained the relevant detail:
State omission → different reconstruction → different decision.
The original manual paired comparison reports Root advantage 3, tie 3, disadvantage 0 across six dependent stages. This is a preliminary case study, not six independent trials or proof of general superiority. Maintenance has costs: the recorded UI thinking-time total was 701 seconds Native versus 822 seconds Root; a read/write break-even can only be extrapolated under explicit assumptions.
Read the unified argument and evidence audit · Inspect Material Failure 3 · Review the conditional timing calculation
The shared research direction is not “remove all structure” or “put everything into memory.” It is: keep goals, authority and acceptance human-governed; preserve traceable state and evidence; let methods change; retain scaffolding only when its measured benefit justifies its lifecycle cost. Root Engineering, the Qwen architecture study, and GDSSA keep separate protocols and evidence while sharing this argument. Capability-scaling and method-by-state interaction remain hypotheses.
The optional Drive-native R3 index implementation and validation results are now available. The latest 70-row candidate reduced file-text tokens by 27.2%, but the 12-pair guarded-path test did not reproduce the speed gain (median paired time +5.3%). Default activation remains off: both token and speed gains are required.
Latest measurements · Implementation and instruction update · Earlier 61-row study
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:
The Claude installer is the self-contained installation source: it embeds the protocol, project instruction block, and required templates. The package folder contains maintenance mirrors; those files do not need to be attached separately.
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.
A long-horizon case study now examines the combined question: how far can Loop + Root carry AI research before the next missing information must come from the physical world?
Read the Loop + Root capability-boundary study · 한국어 연구
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.