RecoveryTeller: Recovery Systems Pattern

• RecoveryTeller is a recovery system pattern that explicitly models state, decision logic, and adaptive interventions to address disruptions.
• Its implementations span diverse domains including chatbots for eating disorder support, account recovery in security, robotics, and blockchain incident response.
• RecoveryTeller systems commonly separate nominal and recovery logic using historical context, risk scoring, and tailored intervention strategies to enhance robustness.

RecoveryTeller denotes, in the supplied research usages, a class of recovery-centered systems that detect disruption, incompleteness, or risk and then adapt a recovery path accordingly. In the narrowest and most explicit sense, it is the name of an LLM-based recovered-peer chatbot for eating-disorder support; in broader uses, it functions as a design label for systems that perform risk-based account recovery, humanoid disturbance recovery, chatbot error recovery, wallet recovery, transaction tracing, portfolio recovery optimization, and robot task recovery (Choi et al., 18 Sep 2025, Büttner et al., 2024, Liu, 24 Apr 2026, Zhao et al., 7 Jul 2026). Taken together, these usages suggest a recurring architecture: recovery is treated not as an afterthought to nominal operation, but as a first-class process with its own state representation, decision logic, and execution policy.

1. Scope and semantic range

Across the supplied literature, RecoveryTeller is not a single standardized framework. It is instead attached to several technically distinct systems that share a common concern with recovery under uncertainty, partial observability, or adversarial conditions.

Domain	Concrete referent	Characteristic mechanism
Eating-disorder support	Recovered-peer persona chatbot	First-person recovery narratives plus non-clinical guidance
Account security	Risk-based account recovery	Contextual features, risk scoring, adaptive challenge paths
Humanoid robotics	End-to-end recovery policy	Transformer history encoder, latent modes, contact affordances
LLM operation	Recovery code / runtime repair	Persona-conditioned repair or graph-guided diagnosis and intervention
Wallet recovery	Password-, image-, or registry-based recovery	Threshold crypto, visual-password matching, keyed discovery
Finance and blockchain	Loan recovery, tracing, recoverable tokens	Delinquency thresholds, graph search, settlement markets
Robot task execution	Recovery-Driven Development	Hierarchical scripts, separate monitor, situated recovery refinement

The specific instantiations differ sharply. In the security literature, RecoveryTeller-like systems are described as “secure, intelligent, context-aware” recovery mechanisms centered on RBAR and privacy-preserving discovery (Büttner et al., 2024, Wang, 3 Mar 2026). In robotics, the term is used for a policy that “reads the recent history,” selects a recovery “story,” and executes multi-modal stabilization, as well as for a development methodology that separates nominal recipes from recovery engineering (Liu, 24 Apr 2026, Banerjee et al., 2020). In LLM-centered work, the label attaches either to persona-shaped conversational repair or to an external runtime layer that localizes failure-critical transitions and keeps corrective guidance active during re-execution (Hill et al., 6 May 2026, Zhao et al., 7 Jul 2026).

A plausible implication is that RecoveryTeller is best understood as a recovery-oriented systems pattern rather than a single artifact. Its stable features are stateful diagnosis, context-sensitive intervention, and explicit treatment of recovery as an operational phase with its own logic.

2. Recovered-peer conversational support

The most direct use of the name is the chatbot introduced in "Collective Voice: Recovered-Peer Support Mediated by An LLM-Based Chatbot for Eating Disorder Recovery" (Choi et al., 18 Sep 2025). That system is a Telegram-based chatbot backed by GPT-4 (gpt-4-1106-preview) and designed to speak as a peer mentor who has fully recovered from an eating disorder. When the conversation is ED-related, it adopts a first-person recovered-peer persona, shares short recovery vignettes, and then provides coping suggestions and emotional support linked to those vignettes. When the conversation is not ED-related, it shifts to a friendly but bounded mentor tone.

The system was evaluated in a 20-day cross-over deployment study with 26 participants, each using RecoveryTeller and a comparison chatbot, WellnessBot, for 10 days each. RecoveryTeller elicited stronger emotional resonance than the lay-mentor chatbot, while participants often treated the two personas as complementary rather than substitutable (Choi et al., 18 Sep 2025). Comparative ratings favored RecoveryTeller on Emotional Support, Bond, and, to a lesser extent, Willingness to Communicate, whereas Informational Support did not favor it uniformly. This distinction matters: the study reports tensions between emotional and epistemic trust, meaning that a bot may feel more understanding without being treated as more authoritative.

Its implementation is organized as a prompt pipeline. An Indicator Detector checks whether the user message matches personal ED indicators in a Wellness Plan; a Context Checker determines whether prior conversation should be retrieved; and a Chat Generator combines persona prompt, guardrails, coping strategies, contextual history, and user profile. Shared guardrails prohibit clinical diagnosis, meal plans, weight-loss advice, triggering specifics, and body comparisons (Choi et al., 18 Sep 2025).

The persona mechanism is not merely stylistic. The recovered-peer framing changed how messages were interpreted. Participants described the bot as embodying the “knowledge of people who have already recovered,” as offering a “collective voice,” and as making setbacks legible as part of a recovery trajectory rather than as isolated failures (Choi et al., 18 Sep 2025). At the same time, the study reports that upward comparison could backfire: for some participants, the bot’s already-recovered stance created distance rather than hope. This makes persona design a substantive recovery variable, not just a presentation layer.

3. Security and identity recovery

In account security, RecoveryTeller aligns with RBAR, defined as “a dynamic account recovery process on online services” (Büttner et al., 2024). The supplied synthesis describes RBAR as a pipeline in which a user initiates recovery, provides an identifier and implicit context, and the service compares that context to the user’s historical context to compute a risk score and adapt the recovery flow accordingly. One formalization given is

$$\text{RBAR pipeline}:\; x \xrightarrow{\,r(\cdot)\,} \text{risk level} \xrightarrow{\,f(\cdot)\,} \text{challenge set / recovery path}.$$

Empirically, RBAR was observed at Google, LinkedIn, and Amazon, but not at Dropbox or GOG in the reported black-box experiments. The same study proposes a maturity model with Level 0 (None), Level 1 (CAPTCHA), Level 2 (Background knowledge), and Level 3 (Pre-configured MFA), with Google exhibiting the highest maturity in the tested services (Büttner et al., 2024).

Wallet and credential recovery work extends this recovery logic into cryptographic infrastructure. "VA-DAR" introduces a serverless, enumeration-resistant discovery-and-recovery layer in which recovery requires only a user identifier and a recovery passphrase, but public lookup is protected by a keyed discovery identifier (Wang, 3 Mar 2026). The central construction is

$$DiscoveryID \leftarrow \mathsf{HMAC}(K_{\mathrm{idx}},\, \mathsf{ctx}_{\mathrm{did}} \,\Vert\, Norm(I)),$$

where $K_{\mathrm{idx}}$ is derived from passphrase-rooted material. The registry maps this privacy-preserving identifier to an immutable content identifier for a sealed backup artifact, while monotonic versioning and artifact commitments support rollback and tamper detection (Wang, 3 Mar 2026). This design explicitly targets cross-device recovery, computational resistance to public-directory enumeration, mapping integrity, and rollback safety.

A more unconventional recovery mechanism appears in "One Picture is Worth a Thousand Words" (Chabannne et al., 2022). There, a secret photograph functions as a visual password; VGG-16 produces a $4096$-dimensional feature vector, which is projected and binarized into a $512$-bit template. That template is stored using obfuscated fuzzy Hamming matching so that a new photo of the same object can unlock the wallet seed if it falls within a Hamming radius $r$. The reported implementation uses $n=512$, $r=140$, and $\lambda=87$, with EER $= 2\%$ at $$DiscoveryID \leftarrow \mathsf{HMAC}(K_{\mathrm{idx}},\, \mathsf{ctx}_{\mathrm{did}} \,\Vert\, Norm(I)),$$0 rotation and EER $$DiscoveryID \leftarrow \mathsf{HMAC}(K_{\mathrm{idx}},\, \mathsf{ctx}_{\mathrm{did}} \,\Vert\, Norm(I)),$$1 at $$DiscoveryID \leftarrow \mathsf{HMAC}(K_{\mathrm{idx}},\, \mathsf{ctx}_{\mathrm{did}} \,\Vert\, Norm(I)),$$2; at the chosen operating point, FAR is approximately $$DiscoveryID \leftarrow \mathsf{HMAC}(K_{\mathrm{idx}},\, \mathsf{ctx}_{\mathrm{did}} \,\Vert\, Norm(I)),$$3, while FRR is $$DiscoveryID \leftarrow \mathsf{HMAC}(K_{\mathrm{idx}},\, \mathsf{ctx}_{\mathrm{did}} \,\Vert\, Norm(I)),$$4 at $$DiscoveryID \leftarrow \mathsf{HMAC}(K_{\mathrm{idx}},\, \mathsf{ctx}_{\mathrm{did}} \,\Vert\, Norm(I)),$$5 and $$DiscoveryID \leftarrow \mathsf{HMAC}(K_{\mathrm{idx}},\, \mathsf{ctx}_{\mathrm{did}} \,\Vert\, Norm(I)),$$6 at $$DiscoveryID \leftarrow \mathsf{HMAC}(K_{\mathrm{idx}},\, \mathsf{ctx}_{\mathrm{did}} \,\Vert\, Norm(I)),$$7 (Chabannne et al., 2022).

A third line, much older but structurally similar, is client-server password recovery based on partial knowledge of the password or personal-entropy answers (0906.4668). There the similarity relation is

$$DiscoveryID \leftarrow \mathsf{HMAC}(K_{\mathrm{idx}},\, \mathsf{ctx}_{\mathrm{did}} \,\Vert\, Norm(I)),$$8

and recovery data are stored at the server, not locally, to reduce offline brute-force exposure. The protocols rely on a variation of threshold encryption and are designed so that a client recovers the password if and only if the perturbed password or personal answers match the stored secret in at least $$DiscoveryID \leftarrow \mathsf{HMAC}(K_{\mathrm{idx}},\, \mathsf{ctx}_{\mathrm{did}} \,\Vert\, Norm(I)),$$9 positions (0906.4668).

These security-focused instantiations share a strong asymmetry: nominal authentication or wallet use may remain simple, but recovery is treated as a privileged, high-impact path that requires context isolation, domain separation, or threshold-based proof of legitimacy. This suggests a general RecoveryTeller principle in security: recovery paths are often more dangerous than login paths and therefore demand stronger contextualization than ordinary access.

4. Recovery orchestration for language-model systems

One LLM-oriented use of RecoveryTeller concerns social repair in dialogue. "Every(bot) Makes Mistakes" presents a recovery code framework that maps four chatbot contexts to Big Five traits, tone categories, and three-stage recovery instructions (Hill et al., 6 May 2026). The contexts are C1: Correcting grammar, C2: Emotional support, C3: Brainstorming, and C4: Learning a concept. These are paired respectively with Conscientiousness, Agreeableness, Openness, and Extraversion, and with tones Polite, Warm, Conversational, and Engaging. The encoded form is

$K_{\mathrm{idx}}$0

where $K_{\mathrm{idx}}$1 specifies a three-step recovery sequence: identify error, reassure user, continue. In the reported exploratory evaluation, coded recovery responses improved from $K_{\mathrm{idx}}$2 to $K_{\mathrm{idx}}$3, an absolute increase of $K_{\mathrm{idx}}$4 percentage points, with the strongest gains in the Appropriateness dimension (Hill et al., 6 May 2026).

A more operationally ambitious recovery layer appears in "AgentTether" (Zhao et al., 7 Jul 2026). There, each run is abstracted into Transition Units

$K_{\mathrm{idx}}$5

and these are linked in a Critical Transition Graph $K_{\mathrm{idx}}$6 with temporal and dependency edges. AgentTether combines an offline normal-behavior model and a run-local detector to localize failure-critical subtrajectories, then generates behavior-scoped guidance backed by Repair Memory, and can optionally intervene during re-execution (Zhao et al., 7 Jul 2026). On 261 $K_{\mathrm{idx}}$7-bench tasks, the full system improved repair effectiveness over blind retry while reducing agent turns and end-to-end approach tokens; on the hardest Banking domain, it repaired $K_{\mathrm{idx}}$8 $K_{\mathrm{idx}}$9 of initially failed Qwen3.7-max tasks and $4096$0 $4096$1 of initially failed GPT-5.4 tasks (Zhao et al., 7 Jul 2026).

The two systems represent distinct recovery philosophies. The recovery-code framework assumes that error recovery is, in part, a social act whose success depends on persona, tone, and stage structure (Hill et al., 6 May 2026). AgentTether assumes that recovery is a trajectory-level control problem requiring localization of failure-critical transitions, graph-based attribution, and guarded runtime intervention (Zhao et al., 7 Jul 2026). A plausible implication is that RecoveryTeller in LLM systems can denote either narrated repair or runtime repair, and that robust deployments may need both: human-facing explanation and machine-facing constraint maintenance.

5. Embodied recovery and robot task execution

In humanoid control, the closest analogue is "RecoverFormer," described as a fully end-to-end humanoid recovery policy that learns when and how to switch among compensatory stepping, hand-environment contact, and center-of-mass reshaping (Liu, 24 Apr 2026). It uses a causal transformer over a 50-step observation history together with a latent recovery mode head and a contact affordance head. The observation history is

$4096$2

and the control stack maps history to actions via an encoder state, latent mode, and affordance vector. Evaluated in MuJoCo on the Unitree G1 humanoid, trained only on open floor, RecoverFormer transfers zero shot to walled environments, achieving $4096$3 recovery success across $4096$4-$4096$5 pushes and wall distances from $4096$6-$4096$7. Under zero-shot dynamics mismatch, it reaches $4096$8 at $4096$9 mass, $512$0 under $512$1 latency, $512$2 at low friction, and $512$3 under compound perturbation (Liu, 24 Apr 2026).

A more developmental, rather than policy-level, notion appears in "Taking Recoveries to Task" (Banerjee et al., 2020). That paper defines Recovery-Driven Development as a “2-pronged iterative approach” consisting of specification—incrementally scripting a hierarchical task sequence from a recipe, using strong assumptions—and refinement—developing recovery behaviors by executing a situated task, noting a fault, specifying new recoveries, and repeating (Banerjee et al., 2020). The framework uses a YAML-based DSL for hierarchical tasks, a Task Executor for nominal scripts, and a Task Monitor for recovery. The monitor selects recoveries using task or action location, number of aborts, beliefs, error signal, and immediate action result, and resumes with one of five strategies: RESUME_NONE, RESUME_CONTINUE, RESUME_RETRY, RESUME_NEXT, or RESUME_PREVIOUS (Banerjee et al., 2020).

The two robotic uses illuminate different recovery strata. RecoverFormer treats recovery as online embodied control over latent strategies and environmental affordances (Liu, 24 Apr 2026). RDD treats it as a software-engineering discipline in which recoveries are explicitly discovered, scripted, and attached to a hierarchical task tree (Banerjee et al., 2020). Taken together, they suggest that RecoveryTeller in robotics can mean either a controller that enacts recovery or a framework that organizes the development and narration of recoveries around a nominal task recipe.

6. Financial, blockchain, and asset-recovery systems

In credit risk, a RecoveryTeller-like system is the LROD procedure in "Simulation-based optimisation of the timing of loan recovery across different portfolios" (Botha et al., 2020). There the recovery problem is formalized as choosing a delinquency threshold $512$4 on a delinquency measure $512$5 so as to minimize total discounted loss: $512$6 The total loss function combines discounted expected future balance and discounted arrears, and the paper shows that threshold optima can exist across all reasonable values of both payment probability and loss rate (Botha et al., 2020). The supplied synthesis presents RecoveryTeller here as an expert system that searches over delinquency-based recovery rules and returns the threshold minimizing economic loss.

In blockchain incident response, "TRacer" models an account-based blockchain as a directed, weighted, temporal, multi-relational transaction graph and frames tracing as graph search (Wu et al., 2022). It introduces a transaction tracing rank based on a personalized PageRank variant that incorporates directionality, amount weighting, temporal reasoning, and token redirection for DeFi actions. On 20 real-world cases spanning Ethereum, BSC, and Polygon, the reported average metrics are Recall $512$7, Nodes $512$8K, and Depth $512$9, compared with much larger graphs for BFS and Poison approaches (Wu et al., 2022). In the supplied interpretation, RecoveryTeller becomes an incident-response system that turns illicit fund flows into ranked, human-auditable recovery narratives.

A complementary blockchain recovery mechanism appears in "R-Pool and Settlement Markets for Recoverable ERC-20R Tokens" (Wang et al., 2023). ERC-20R wraps a base ERC-20 token into settled and unsettled balances, where unsettled balances remain clawbackable during a recovery window and settled balances can be unwrapped immediately. Because many DeFi systems are expected to refuse unsettled recoverable assets, the paper designs R-Pools that exchange unsettled ERC-20R for base ERC-20. In the automated market formulation, the exchange rate is

$r$0

where $r$1 is the settled balance in the pool, $r$2 is total ERC-20R in the pool, $r$3 is the oracle-supplied risk-adjusted base rate, and $r$4 is a threshold parameter (Wang et al., 2023). This makes recovery risk explicitly market-priced rather than merely tolerated.

These financial and blockchain examples show RecoveryTeller operating on different objects—loan portfolios, tainted transaction flows, recoverable token wrappers—but with a common emphasis on structured state, explicit recovery windows or thresholds, and quantitative control of risk transfer.

7. Cross-cutting architecture, misconceptions, and limits

Across the supplied literature, several architectural motifs recur. RecoveryTeller-like systems rely on remembered history rather than single-step state: RecoverFormer uses a 50-step observation history, RBAR compares present recovery context to historical login context, AgentTether reasons over entire trajectories through Transition Units and CTGs, and LROD evaluates cumulative arrears and future balances rather than instantaneous delinquency (Liu, 24 Apr 2026, Büttner et al., 2024, Zhao et al., 7 Jul 2026, Botha et al., 2020). They also tend to separate nominal and recovery logic: RDD makes that separation explicit in Task Executor versus Task Monitor, AgentTether separates the underlying agent from the runtime repair layer, and VA-DAR separates lookup, sealing, and registry authorization through domain-separated keys (Banerjee et al., 2020, Zhao et al., 7 Jul 2026, Wang, 3 Mar 2026).

A common misconception would be to treat RecoveryTeller as inherently narrative or inherently conversational. The supplied corpus does not support that. In some uses, recovery is literally narrated, as in the recovered-peer chatbot and the personality-conditioned recovery code framework (Choi et al., 18 Sep 2025, Hill et al., 6 May 2026). In others, recovery is a policy, a graph search, a cryptographic protocol, or a portfolio optimization routine (Liu, 24 Apr 2026, Wu et al., 2022, 0906.4668, Botha et al., 2020). A more accurate statement is that RecoveryTeller names systems that make recovery explicit and structured, whether or not they verbalize it.

Another recurring issue is the tension between affective success and epistemic or operational robustness. The ED chatbot produced stronger emotional resonance, but participants often distinguished that from informational trust (Choi et al., 18 Sep 2025). The recovery-code study reports improvement, but it is explicitly exploratory, uses no human participants, and relies on LLM evaluator agents (Hill et al., 6 May 2026). AgentTether improves repair success and efficiency, but its analyst and verifier remain LLM-based, and runtime intervention can hurt when repeated warnings push the agent into replanning rather than execution (Zhao et al., 7 Jul 2026). In security, RBAR black-box studies reveal effective adaptation, but internal scoring models remain opaque, and overly strict policies can lock out legitimate users (Büttner et al., 2024). In robotics, RecoverFormer is simulation-only and RDD is not well suited to hazardous or remote environments that cannot support frequent situated testing (Liu, 24 Apr 2026, Banerjee et al., 2020).

Taken together, these results suggest that RecoveryTeller is most productively treated as a systems-design orientation. Recovery is modeled as stateful, high-impact, and frequently multi-stage; diagnosis is tied to structure rather than ad hoc exceptions; and intervention is graded, context-aware, and often separated from nominal execution. Where the literature diverges is in the object being recovered—trust, access, physical balance, wallet secrets, stolen assets, cash-flow value, or task execution—and in whether recovery is primarily an internal control loop, a user-facing narrative, or a market or cryptographic mechanism.