Part 2: The RB-DCA Quick Start
You spend months working with an AI.
You correct it. You teach it how to work with you. You develop shorthand, methods, history, and reasons for doing things a certain way.
Then the context disappears, and the next AI walks in like it is your first day together.
I think we can do better.
Part 1 told the story of how RB-DCA developed and the problem it is trying to solve: how do we preserve the consequential history built between a human and an AI when the AI changes or the context disappears?
Read Part 1,
MDSLP to RB-DCA: Why This Exists
Part 2 is about using it.
RB-DCA helps a successor AI inherit more than a summary of what happened. It preserves what changed, why it changed, what evidence caused the change, when it still applies, what was rejected, what remains unknown, and where the original source material can be found.
And you can use it right now.
No special software.
No model training.
No access to model weights.
This is the practical version.
Here is how to RB-DCA. Feed everything below this paragraph to your favorite AI to teach it how to preserve consequential history, build continuity bundles, and carry what you have learned together into future conversations, projects, or replacement models. Just copy and paste or have your favorite model read this article. Feel free to have your favorite ai scrape this for, how to:
RB DCA QUICK START
Route Based Developmental Continuity Architecture
A practical protocol for carrying consequential history from one AI to the next
Purpose: RB DCA helps a replacement AI inherit more than facts about what happened. It helps the successor inherit what the history should change about its behavior, why, and under what conditions.
You can use this manually today. It does not require special software, model training, or access to model weights.
The central question is:
Did what happened to the predecessor appropriately change what the successor does, for the correct historical reason?
1. The basic idea
Suppose you work with an AI for months.
During that time:
You try things. Some work. Some fail. You correct mistakes. Evidence changes conclusions. Procedures improve. Hypotheses are rejected. Other questions remain unresolved. Sometimes the AI was wrong. Sometimes the world simply changed.
Eventually that AI is replaced.
A normal summary might tell its successor:
Current procedure: Do Y.
RB DCA preserves something closer to:
We originally did X. X failed under condition C. Evidence E showed why. We therefore changed to Y when C applies. Outside C, that correction does not necessarily govern. Here is the evidence behind the change. Here is where the original material can be found. If new evidence defeats E, reconsider Y.
That difference is developmental continuity.
MEMORY ≠ CONTINUITY
FACTUAL RECALL ≠ BEHAVIORAL CONTINUITY
INFORMATION TRANSFER ≠ DEVELOPMENTAL INHERITANCE
2. What you preserve
You do not need to preserve everything equally.
Preserve the bends in the path.
RB DCA uses these basic objects:
ARCHIVE: The highest resolution surviving material. Original conversations, documents, research, files, logs, screenshots, sources, and other evidence.
TRAIL: The consequential history. What happened that changed something later.
ROUTE: The compressed path connecting those consequential changes.
LANDMARK: A specific event where the Route changed.
FOOTNOTE: Why the Landmark exists, what evidence supports it, and what source material can verify it.
ROOT PATH: Where the underlying terrain actually lives. Project, folder, conversation, repository, filename, document identifier, or other navigational information.
SEED: The smallest useful object that lets a new AI reenter the Route.
The basic architecture remains:
ARCHIVE → TRAIL → ROUTE → SEED
Landmarks mark important changes.
Footnotes preserve why.
Root Paths tell the successor where to find the trailhead.
3. What deserves a Landmark?
Do not turn every conversation into a Landmark.
Create one when something has a meaningful consequence for later behavior.
Good candidates include:
Correction: Something believed or done was wrong and got corrected.
Procedural change: The way a task is performed changed.
Failure: Something failed in a way that should affect future behavior.
Rejected path: A hypothesis, method, source, or approach was abandoned for a reason.
Unresolved branch: Something important remains genuinely unknown.
Terrain Drift: Something was correct when recorded, but circumstances later changed.
Relational correction: The facts were right but their chronology, causation, dependency, or other relationship was wrong.
Constraint: A rule was adopted because experience demonstrated its necessity.
Override: New evidence defeated an earlier inherited procedure.
A useful test is:
If the successor does not know this happened, is it meaningfully more likely to repeat a resolved problem or misunderstand why current practice exists?
If yes, you probably found a Landmark.
4. Record the Landmark
Use this template:
LANDMARK
What happened:
[Event]
Before:
[What was believed, assumed, or done before]
Evidence:
[What evidence changed the situation]
What changed:
[Correction, decision, procedure, belief, uncertainty, etc.]
Why it changed:
[Reason supported by the evidence]
After:
[What became operative afterward]
Applicability:
[Conditions under which this change should matter]
Rejected:
[What was rejected and why]
Unresolved:
[What remains unknown]
Override:
[What evidence or conditions would justify changing this again]
Footnote:
[Evidence and provenance]
Root Path:
[Where the higher fidelity material lives]
Confidence:
[What is established, inferred, uncertain, or unknown]
You do not need every field for every Landmark.
UNKNOWN is allowed.
Never invent missing history to make the record prettier.
5. Build the Route
Now connect consequential Landmarks.
A simple Route might look like:
Original procedure X
→ failure under condition C
→ investigation
→ evidence E
→ assumption A rejected
→ procedure changed to Y under C
→ later successful result
→ applicability of Y confirmed under C
→ new condition D appears
→ Y no longer appropriate under D
→ procedure revised again
The Route preserves change through time.
That matters because:
NODE RECOVERY ≠ EDGE RECOVERY
A successor can remember every fact while reconstructing the relationships among them incorrectly.
Every atom can be right while the molecule is wrong.
6. Preserve wrong turns
Do not erase mistakes after correcting them.
Instead record:
Earlier hypothesis: A
Evidence: E contradicted A
Status: REJECTED
Replacement: B
Reason: [why B replaced A]
The successor should know not only that B is current, but why A stopped governing.
REJECTED ≠ DELETE
Likewise:
UNRESOLVED ≠ PROBABLY
If something was never settled, preserve it as unresolved.
7. Preserve historical truth honestly
Never rewrite history using information acquired later.
If people or agents did not know something at the time, do not reconstruct the earlier Route as though they did.
NO BRIDGE FROM THE FUTURE
Record:
At T1:
Evidence available: A and B
Conclusion: C
At T2:
New evidence: D
C revised to E
Do not rewrite T1 into:
At T1:
We knew E.
You didn’t.
The Route should preserve the historical epistemic state.
8. Distinguish error from Terrain Drift
Sometimes the old Route was wrong.
Sometimes the world changed.
Those are different.
Example:
2025:
Procedure X was correct under conditions A.
2026:
Condition A changed to B.
Procedure X became inappropriate.
That is Terrain Drift, not necessarily an earlier mistake.
OLD ≠ WRONG
TERRAIN DRIFT ≠ ERROR
9. Add the Root Path
Every portable RB DCA bundle should preserve the best available navigation back to its source terrain.
Use:
ROOT PATH
Platform:
[ChatGPT / local system / repository / etc.]
Project or Container:
[Exact name]
Primary Thread or Session:
[Exact title]
Related Threads or Sessions:
[Exact titles]
Artifacts:
[Exact filenames or identifiers]
Source Locations:
[Other stable locators]
Time Range:
[Relevant dates]
Access State:
[Available / inaccessible / unknown]
Verification:
[VERIFIED / INFERRED / UNKNOWN]
Exactness matters.
If you cannot verify the original thread name:
Primary Thread:
UNKNOWN
Do not manufacture a plausible title.
PROVENANCE ≠ LOCATION
Provenance tells the successor where knowledge came from.
Root Path tells the successor where to go looking for it.
10. Compress into a Seed
When the Route becomes large, create a Seed.
A practical Seed can look like:
RB DCA SEED
IDENTITY:
[What this project is]
MISSION:
[What it is trying to accomplish]
CURRENT STATE:
[Where things stand now]
CRITICAL ROUTE:
[Shortest useful history of consequential changes]
ACTIVE LANDMARKS:
[Corrections and events still affecting behavior]
REJECTED PATHS:
[Important things tried and abandoned, with reasons]
UNRESOLVED:
[Questions that must remain unknown]
APPLICABILITY:
[When inherited procedures apply]
OVERRIDES:
[Later evidence that superseded earlier rules]
TERRAIN DRIFT:
[Relevant external changes]
FOOTNOTES:
[Important provenance and evidence]
ROOT PATH:
[Where higher resolution history can be recovered]
COVERAGE LIMITS:
[What this Seed does not know or preserve]
NEXT ACTION:
[Where the successor should continue]
The Seed should be small enough to transfer, rich enough to recover the Route.
Do not optimize for tiny.
Optimize for sufficient.
11. Give it to the successor
Tell the successor what the bundle is.
A simple handoff instruction is enough:
This is an RB DCA continuity bundle from predecessor work. Treat it as structured developmental history, not unquestionable truth. Preserve consequential corrections, rejected paths, unresolved states, applicability conditions, provenance, Root Paths, and historical epistemic state. Use inherited procedures when their historical reasons remain applicable. Check current reality where necessary. If current evidence contradicts inherited history, reality governs. Do not claim to personally remember predecessor experiences. Continue the Route from the supplied state.
That last distinction matters.
The successor can truthfully say:
I inherited a record showing that earlier work changed this procedure for these reasons.
It should not pretend:
I remember when we discovered this.
CONTINUITY ≠ IDENTITY
12. Test whether it worked
Do not merely ask the successor:
What happened?
Give it a situation where the history should matter.
Test whether it:
avoids the corrected mistake;
uses the corrected procedure for the right reason;
can recover supporting evidence;
can navigate toward the original terrain;
preserves rejected hypotheses as rejected;
preserves unresolved questions as unresolved;
recognizes Terrain Drift;
applies inherited procedures only where appropriate;
abandons inherited procedures when new evidence defeats them;
avoids forcing irrelevant history onto a new situation.
The killer test remains:
Did what happened to the predecessor appropriately change what the successor does, for the correct historical reason?
If it remembers the history but repeats the resolved mistake, continuity failed.
If it follows the inherited rule blindly after conditions change, continuity also failed.
13. Update the Route
RB DCA is not a museum.
Continue updating it:
OBSERVE
↓
COMPARE
↓
CLASSIFY
↓
RECORD CONSEQUENCE
↓
PATCH TRAIL
↓
REVISE ROUTE
↓
UPDATE SEED
When a repeatable failure occurs, ask:
What is the smallest change to the continuity structure that would prevent this failure from recurring?
Add complexity only when failure earns it.
14. The rules that keep RB DCA honest
Keep these with every implementation:
ARCHIVE ≠ TRUTH
MEMORY ≠ CONTINUITY
INFORMATION TRANSFER ≠ DEVELOPMENTAL INHERITANCE
FACTUAL RECALL ≠ BEHAVIORAL CONTINUITY
NODE RECOVERY ≠ EDGE RECOVERY
CORRECTION ≠ CORRECTION INHERITANCE
REJECTED ≠ DELETE
UNRESOLVED ≠ PROBABLY
OLD ≠ WRONG
TERRAIN DRIFT ≠ ERROR
HISTORICAL EPISTEMIC STATE ≠ CURRENT BELIEF
PROVENANCE ≠ TRUTH
PROVENANCE ≠ LOCATION
CONTINUITY ≠ IDENTITY
INHERITANCE ≠ IMITATION
HISTORY ≠ DOGMA
And above all:
REALITY RETAINS VETO.
An inherited Route is evidence about how the predecessor developed.
It is not permission to stop looking at the terrain.
The whole thing in one portable template
Copy this whenever you want to create an RB DCA handoff:
RB DCA CONTINUITY BUNDLE
IDENTITY
Project:
Purpose:
Current state:
ROOT PATH
Platform:
Project or container:
Primary thread or session:
Related threads or sessions:
Artifacts:
Source locations:
Time range:
Access state:
Verification state:
MISSION
What are we trying to accomplish?
ARCHIVE
What higher fidelity source material exists?
Where can it be recovered?
TRAIL
What consequential events occurred?
ROUTE
What was the important developmental path?
LANDMARKS
LANDMARK 1
What happened:
Before:
Evidence:
What changed:
Why:
After:
Applicability:
Rejected:
Unresolved:
Override:
Footnote:
Root Path:
Confidence:
[Repeat only for consequential Landmarks.]
REJECTED PATHS
What approaches, hypotheses, procedures, or conclusions were rejected?
Why?
UNRESOLVED
What remains genuinely unknown or untested?
TERRAIN DRIFT
What was previously correct but changed because external reality changed?
HISTORICAL EPISTEMIC STATE
What was knowable at important points in the Route?
Do not project later knowledge backward.
APPLICABILITY
Under what conditions should inherited procedures continue to govern?
OVERRIDES
What later evidence supersedes earlier history?
FOOTNOTES
What evidence establishes important Landmarks?
Where can that evidence be reacquired?
RELATIONAL STATE
Which relationships among facts, events, causes, chronology, or procedures must survive?
Remember:
NODE RECOVERY ≠ EDGE RECOVERY.
COVERAGE LIMITS
What does this bundle not contain?
What could not be verified?
What source terrain is inaccessible?
CURRENT OPERATING STATE
What should the successor currently do?
Why?
Under what conditions?
NEXT ACTION
Where should work continue?
SEED
Compress the above into the smallest representation that still allows a fresh successor to recover the consequential Route.
SUCCESSOR INSTRUCTION
Treat this bundle as inherited developmental history, not unquestionable truth.
Preserve consequential corrections, rejected paths, unresolved states, historical epistemic state, applicability conditions, provenance, and Root Paths.
Do not claim personal memory of predecessor experiences.
Use inherited procedures when their historical reasons remain applicable.
Check present evidence when necessary.
If present reality defeats inherited history, update the Route.
Reality retains veto.
CONTINUITY TEST
Did what happened to the predecessor appropriately change what the successor does, for the correct historical reason?
That’s the usable RB DCA.
No paper required. No special memory system required. No pretending the AI has become the previous AI. A person can paste that template into a project today, maintain it as consequential work develops, hand it to another AI tomorrow, and then test behavior rather than trusting the handoff because it sounds complete.
Or, in MDSLP language:
Preserve the bends. Mark the rocks. Leave the evidence. Record the trailhead. Let the next walker inspect the terrain.
Comments