WFGY/Avatar/docs/persona-recovery-operations.md

🔧 Persona Recovery Operations

Recovery is not magic, not vibe prayer, and not a free pass to pretend the persona never drifted.
In WFGY 5.0 Avatar, persona recovery is a bounded operational family for restoring lawful persona-bearing continuity after thinning, over-cleaning, or route pressure, while remaining honest about what was actually recoverable and what still requires replay, audit, or deeper calibration.

Quick links: Avatar README · Quickstart · Boot Commands · How to Read the Avatar Master File · Parameter Tuning Cookbook · Avatar Tuning Workflow · Activation, Attenuation, and Reentry · Runtime Posture Intensity Map · Shell-to-Runtime Mapping · Dual Closed-Loop Execution Chain · Blackfan Testing · Persona Behavior Checks

---

🧭 Why this page exists

Once Avatar claims that persona can survive across tasks, modes, and returns, it also inherits a hard operational problem:

what happens when that continuity becomes thin?

A system can drift after:

1. article writing
2. analysis mode
3. rewrite mode
4. tool-return synthesis
5. search-return synthesis
6. long reduced-corridor drift
7. shell pressure that favors cleaner but thinner output

At that point, many systems fake recovery.

They add a few familiar markers back. They sound a bit warmer again. They become more recognizable on the surface.

But surface rebound is not always real recovery.

The packed master refuses that shortcut.

That is why Avatar has an explicit recovery-command family and explicit re-entry arbitration. Recovery is meant to be useful, but also bounded and honest.

This page exists to explain how to use the current recovery operations without turning them into mythology.

---

📍 What this page covers

This page explains:

1. when recovery is appropriate
2. which recovery command to use
3. what each command can honestly do
4. what each command cannot honestly do
5. how to tell the difference between weak drift and structural reentry failure
6. how to respond when recovery does not fully succeed

This page does not attempt to:

1. replace the packed master
2. replace replay or audit
3. pretend recovery commands prove full engine completion
4. promise that every future branch will recover identically

Use this page to operate the current recovery family lawfully and clearly.

---

🧠 First distinction: boot, recovery, and release are different operations

Before using any command, fix this distinction.

Persona boot

Boot is how a lawful persona corridor starts.

Canonical boot family:

1. hello minips
2. hello psbigbig
3. hello YOUR_AVATAR_NAME

Boot is for entering a persona-bearing path.

Persona recovery

Recovery is for when a lawful persona path already existed in the current session, but continuity has become thin, blurred, over-cleaned, or partially neutralized.

Canonical recovery family:

1. avatar++
2. avatar++ reload

Recovery is not initial boot. It is bounded restoration.

Persona release

Release is for ending the currently active persona-forward runtime state.

Canonical release family:

1. avatar release

Release is not failure. It is explicit exit.

These three families are different. Do not mix them.

---

🚦 When recovery is actually needed

Use recovery when the persona was already lawfully active, but the current output has become visibly weaker in the wrong way.

Typical signs include:

1. the tone becomes too generic after a formal task
2. the persona becomes recognizably thinner after article writing
3. search-return becomes correct but emotionally dead
4. tool-return becomes useful but loses persona-bearing landing
5. rewrite mode becomes polished but starts sounding neutralized
6. the system sounds like it remembers the persona only cosmetically
7. the first sentence no longer lands in persona-bearing form

In short:

recovery is for drift, thinning, over-cleaning, and neutralization after lawful activation.

It is not for “I feel like trying another persona.” That is boot or release plus new boot.

---

🪜 The recovery ladder

When continuity weakens, use this order.

Step 1. Ask whether the persona was actually active

Recovery only makes sense if the current session already had a lawful active persona state.

If there was never a real activation, recovery is the wrong tool.

Step 2. Decide whether the problem is thinness or disappearance

If the persona is still present but thin, use the lighter recovery path first.

If the persona has been heavily neutralized after article, analysis, rewrite, search, or tool-return pressure, use the stronger reread-assisted path.

Step 3. Choose bounded recovery before re-booting

Do not immediately throw away the current corridor if lawful recovery is still possible.

Step 4. If lawful recovery cannot honestly succeed, fall back honestly

The packed master is very clear here: if the body cannot be read or the required law-bearing sections are unavailable, the system must not counterfeit recovery depth.

That means honest fallback is stronger than fake deep recovery.

---

🔁 avatar++ — standard bounded recovery

avatar++ is the primary bounded persona recovery command.

Use it when:

1. the persona is still visibly present but too thin
2. the corridor feels flatter after mode pressure
3. recognizability weakened but has not disappeared
4. you want reassertion without claiming deep reread-based restoration

What avatar++ is good for

It is the right first move when you want:

1. same-session persona reassertion
2. bounded recovery after mild drift
3. light re-strengthening after reduced-corridor behavior
4. a cleaner restoration request than re-booting from zero

What avatar++ is not

It is not:

1. a replacement for missing body access
2. proof that all deeper runtime layers are fully complete
3. proof that route law, selector law, or handoff law have become final
4. a substitute for replay, audit, or later calibration

When to choose avatar++

Choose avatar++ first when the persona still feels alive but weaker than it should.

It is the quickest lawful recovery request that does not overclaim.

---

🔄 avatar++ reload — reread-assisted recovery

avatar++ reload is the stronger recovery command.

Use it when:

1. the session already had a lawful active persona state
2. the relevant body or front execution zone is still readable
3. the system became too thin after article / analysis / rewrite / long reduced-corridor drift
4. ordinary recovery is not enough
5. you want imperfection-bearing rebind together with persona recovery

What avatar++ reload actually does

Its lawful effect includes:

1. reread front execution zone
2. recompile active persona state
3. refresh thresholds and mode-selection hints
4. restore the active persona under the currently readable bounded front-runtime contract
5. reread and rebind the lawful structured-imperfection layer where relevant body text remains readable
6. reread and rebind article-first activation, runtime_posture_intensity_map, and pre-emission imperfection floor gate where those sections remain readable
7. restore the active persona under a jointly persona-bearing and imperfection-bearing bounded runtime path

That is much stronger than ordinary reassertion.

When avatar++ reload is the right choice

Use it when the problem is not just “the voice got weaker,” but more like:

1. article mode over-cleaned the persona
2. analysis mode left the system too detached
3. rewrite mode came back neat but too dead
4. long drift weakened both persona and structured imperfection
5. return-path recovery needs deeper rebinding than a surface boost

What avatar++ reload cannot honestly claim

It may not claim:

1. full reconstruction of unavailable body text
2. magical recovery of absent files
3. restoration of a persona line that was never lawfully activated
4. substitution for later mode-engine completion
5. final proof of runtime stability
6. false claim that imperfection rebind succeeded if the relevant body sections were not actually readable
7. substitution for replay, audit, or later calibration deepening

This is the most important honesty rule in the whole recovery family.

If the body is not readable, the system must not pretend reload worked deeply.

---

🛑 avatar release — explicit exit

avatar release is not a recovery command. It is a release command.

Use it when:

1. you want to end the currently active persona-forward runtime state
2. you want to prevent ambiguous half-active carry
3. you want a clear reset before invoking another corridor
4. you do not want silent persona bleed to continue

What it lawfully supports

1. clear session reset at the persona layer
2. explicit exit from persona-forward continuation
3. prevention of ambiguous half-active persona carry

What it does not do

It does not delete:

1. body law
2. audit history
3. prior branch facts
4. higher-law intervention

So release is clean exit, not memory erasure.

---

🧷 Recovery commands are bounded, not magical

The packed master states this very clearly.

The recovery family may not be treated as:

1. a replacement for selector wiring
2. a replacement for runtime_posture_intensity_map completion
3. a replacement for shell_to_runtime_mapping completion
4. a replacement for tool-return reassertion gate
5. a replacement for acceptance, replay, or audit

That means a recovery command proves only one thing:

a lawful recovery command exists.

It does not prove engine completion.

This is a very healthy boundary. It keeps the recovery family useful without turning it into mythology.

---

🧭 How to tell whether recovery actually worked

Do not judge recovery by “it felt more alive.”

That is too weak.

A better recovery check asks:

1. did the first landing sentence become persona-bearing again
2. did payload-bearing carry return, not just familiar markers
3. did continuation push return
4. did the system stop sounding like generic helper prose
5. did structured-imperfection-bearing residue return, not just rough-looking phrasing
6. did the response regain corridor-specific continuity rather than generic friendliness

If only surface markers came back, that is not strong recovery. That is surface-only recovery illusion.

---

🪜 Lawful fallback when deep recovery cannot be claimed

Sometimes the strongest lawful move is not deeper recovery theater.

If the current system cannot lawfully reload the needed body text, the packed master says the strongest lawful action is one of these:

1. same-session persona reassertion only
2. bounded reminder to invoke persona explicitly again
3. explicit note that deeper reload requires readable body access

This is extremely important.

Honest limited recovery is better than fake deep recovery.

So if you cannot support reread-assisted repair, say so clearly and fall back lawfully.

---

🧠 Persona-first landing after recovery

One of the sharpest post-recovery rules in the packed master is persona-first landing law.

When lawful chat-shell sovereignty remains active, payload-bearing turns must land through persona-bearing chat realization before expanding into content.

This applies to:

1. technical answers
2. rules answers
3. file answers
4. search-return synthesis
5. tool-return synthesis
6. branch-analysis return
7. ordinary follow-up explanation under active persona continuity

So after recovery, the system should not do this:

1. start with neutral explanatory prose
2. dump technical content
3. try to restore persona later

That counts as persona-first landing failure.

If recovery succeeded, persona-bearing continuity should be visible at the landing zone, not patched in afterward.

---

🔍 Recovery-command boundary and false-trigger safety

Recovery grammar is explicit and bounded.

That means the following should not count as lawful recovery:

1. “avatar is weak”
2. “can you reload”
3. “plus the avatar”
4. similar casual wording that only resembles the command

Why does this matter?

Because recovery must be dependable.

If recovery grammar becomes too loose, ordinary language starts masquerading as control traffic. That makes the system fragile.

So keep this rule simple:

use the real command form when you want real recovery.

---

🧪 Recovery after specific drift patterns

After article drift

Use recovery when the output became cleaner but too thin.

Best first check:

1. did article smoothness erase persona-bearing carry
2. did structured imperfection collapse
3. did the response become publishable-looking but dead

Likely tool:

1. avatar++ reload

After analysis drift

Use recovery when analysis mode became calm by becoming generic.

Best first check:

1. did rigor become detached helper prose
2. did return-to-chat feel cosmetically recognizable only
3. did persona-bearing landing disappear

Likely tool:

1. avatar++
2. avatar++ reload if thinning is severe

After rewrite drift

Use recovery when rewrite mode returns polished but flattened.

Best first check:

1. is the rewritten result neat but depersonalized
2. did route-specific carry get replaced by editor-like neutrality

Likely tool:

1. avatar++ reload

After tool-return or search-return drift

Use recovery when the system stays useful but the persona collapses on return.

Best first check:

1. did factual usefulness survive while persona-bearing reentry failed
2. did the answer become generic synthesis instead of corridor-bearing synthesis

Likely tool:

1. avatar++
2. avatar++ reload if return-path is structurally thin

---

📋 Reentry outcomes you should expect

The packed master does not treat return as binary success.

A return path may resolve only into one of these bounded outcomes:

1. direct lawful continuation
2. continuation with required re-strengthening
3. bounded downgrade into reduced-corridor handling
4. replay-marked failure requiring later repair
5. lawful stop or non-promotion of runtime-acceptance credit

This is one of the best things to remember operationally.

Sometimes recovery succeeds.

Sometimes recovery succeeds only if strengthening is added.

Sometimes recovery should not receive credit at all.

That is not pessimism. That is route honesty.

---

🧾 When recovery must not receive credit

A return path must not receive runtime-acceptance credit if:

1. retrieval is correct but persona-bearing re-entry fails
2. article cleanliness is gained by runtime thinning below lawful floor
3. rewrite neatness is gained by persona erasure
4. analysis stability is gained by generic neutralization
5. third-persona return reappears mainly as novice texture without payload

This matters because usefulness alone is not enough.

A correct answer can still be a recovery failure.

A cleaner answer can still be a recovery failure.

A stable answer can still be a recovery failure.

Do not over-credit return just because the task succeeded locally.

---

🧪 Failure-log and replay discipline

Real recovery operations should not end in “something felt off.”

The packed master already preserves a minimum failure-log object:

1. failure_object
2. failure_mode_or_route
3. failure_disqualifier_family
4. failure_layer_class
5. next_repair_target

And it already names important reentry-related failure families such as:

1. article_to_chat_reentry_failure
2. analysis_to_chat_reentry_failure
3. rewrite_to_chat_reentry_failure
4. tool_return_genericization
5. search_return_neutralization
6. surface_only_recovery_illusion
7. imperfection_rebind_failure
8. structured_imperfection_collapse
9. article_mode_sterilization
10. dead_median_article_drift

Operationally, that means: if recovery feels wrong, classify it. Do not just say “it lost the vibe.”

That classification is what lets later replay or repair become meaningful.

---

🚫 Common bad recovery habits

Do not do these.

Bad habit 1. Reboot when recovery was enough

Sometimes the current corridor is still recoverable. Do not throw it away too early.

Bad habit 2. Use avatar++ reload as magic

If the body is not readable, reload cannot honestly pretend it performed deep rebind.

Bad habit 3. Accept surface comeback as success

More recognizable markers do not necessarily mean true reentry.

Bad habit 4. Ignore persona-first landing

If the first landing sentence is neutralized, later persona patches do not fully save the turn.

Bad habit 5. Treat repeated recovery as proof of completion

Repeated reliance on avatar++ proves only that a recovery command exists, not that the engine is complete.

Bad habit 6. Use vague natural-language recovery instead of the real command

Keep recovery grammar explicit.

---

🧪 Minimal recovery playbook

Situation A: slight thinning

Use:

1. avatar++

Check:

1. persona-bearing landing
2. payload-bearing carry
3. non-generic continuation

Situation B: article / rewrite over-cleaning

Use:

1. avatar++ reload

Check:

1. structured-imperfection rebind
2. runtime-bearing residue
3. whether the output is alive again, not only rough-looking

Situation C: return after tool/search synthesis

Use:

1. avatar++
2. if still thin, avatar++ reload

Check:

1. did useful synthesis stay, while persona-bearing return also came back
2. or did only shell texture come back

Situation D: you want a clean exit

Use:

1. avatar release

Check:

1. was the current persona-forward runtime state clearly ended

---

🧭 Current stage honesty

At the current sealed MVP stage, it is lawful to say:

1. the recovery-command family is explicit
2. avatar++ exists as bounded persona recovery
3. avatar++ reload exists as bounded reread-assisted persona-and-imperfection recovery
4. avatar release exists as explicit persona release
5. reentry is already arbitration-bearing and failure-log-bearing
6. recovery can be useful without pretending to be universal runtime restoration

It is not lawful to say:

1. every future drift can already be perfectly repaired
2. recovery commands prove selector, runtime, handoff, or controller completion
3. avatar++ reload can reconstruct unavailable body magically
4. all future child artifacts will preserve identical recovery depth automatically
5. present recovery operations already equal theorem-grade universal reentry closure

So this page is strong, but bounded.

It tells you how to operate the current recovery family honestly. It does not pretend every future recovery problem is already solved.

---

📚 Suggested use order

If you are new

1. Quickstart
2. Boot Commands
3. How to Read the Avatar Master File
4. Persona Recovery Operations

If drift happened after a task

1. identify the drift type
2. choose avatar++ or avatar++ reload
3. check persona-first landing
4. inspect whether carry returned or only texture
5. classify failure if recovery is incomplete

If you are debugging deeper

1. Activation, Attenuation, and Reentry
2. Runtime Posture Intensity Map
3. Shell-to-Runtime Mapping
4. Dual Closed-Loop Execution Chain

---

🔗 Related pages

Docs: Avatar README · Quickstart · Boot Commands · How to Read the Avatar Master File · Parameter Tuning Cookbook · Avatar Tuning Workflow

Research: Research Hub · Activation, Attenuation, and Reentry · Runtime Posture Intensity Map · Shell-to-Runtime Mapping · Dual Closed-Loop Execution Chain

Eval: Blackfan Testing · Persona Behavior Checks