Summary / 19. Transfer / Document
2026-10-03
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# Transfer as an Explicit Cognitive Subsystem in Piper **Component 19 — Transfer** **Working definition:** Using skills learned in one area somewhere else. **Status:** Not yet scored. **Current reviewer finding:** No explicit transfer machinery demonstrated in live use. ## Abstract Transfer should be treated as a causal, measurable property of Piper rather than as an impression that she can reuse ideas. The strongest operational definition is: **the change in target-task performance caused by prior experience with a source task, holding the base model, harness, budget, and target task fixed**. If Piper solves task B equally well without experience A, the result is capability or prior knowledge, not evidence that A transferred. The literature synthesized for this component points to a consistent pattern. Near transfer is common; far transfer is much harder. The main bottleneck is often not applying a known analogy once it is visible, but **retrieving or noticing the relevant prior experience when the new problem looks different on the surface**. Explicit abstraction helps, especially when induced from multiple verified episodes. Nearest-neighbour semantic retrieval is insufficient for far transfer because surface similarity can dominate structural similarity. Negative transfer is also common enough that any explicit transfer subsystem requires an applicability gate and an outcome ledger. For Piper, the recommended design is therefore not a single `transfer` function. It is a two-loop subsystem. The **online loop** runs on each non-trivial problem: encode structure, retrieve across domains, structurally re-rank, gate, adapt, execute, verify, and log the outcome. The **offline loop** periodically clusters verified episodes, induces reusable abstractions from multiple examples, revalidates existing lessons, recalibrates their usefulness, and retires harmful or obsolete ones. The appropriate evaluation is a **transfer gradient** across controlled source-target distances, not a binary pass/fail. A five-band benchmark with paired exposed/unexposed conditions, structural foils, synthetic or obfuscated targets, and a seven-arm ablation can determine whether Piper's explicit machinery extends the distance over which prior experience remains useful beyond what the base LLM already supplies. --- ## 1. The question being tested The central scientific question for this component is: > Can Piper acquire an experience in domain A, transform that experience into a reusable representation, recognize its relevance in a substantially different future domain B, adapt it appropriately, and measurably outperform the same Piper that never received experience A? That formulation matters because transfer is easy to overclaim. A large pretrained model may already know both A and B. It may also solve B from general reasoning even if A is irrelevant. Therefore, success on B after seeing A is not sufficient evidence of transfer. The correct claim is counterfactual: \[ TG(A \rightarrow B) = S(B\mid A) - S(B\mid \neg A) \] where `S` is an objective target-task score and every other relevant condition is held constant. This definition separates transfer from adjacent concepts: | Concept | Relationship to transfer | |---|---| | Generalization | Performance across changed inputs or distributions; does not require an explicit source-experience manipulation. | | Analogy | One mechanism for transfer: align relational structure from a source problem to a target problem. | | Abstraction | A representation that can enable transfer by stripping away source-specific details. | | Retrieval | Makes prior knowledge available; retrieval alone is not transfer unless that knowledge improves a different target task. | | Reuse | A near-transfer special case, often requiring little adaptation. | | Memorization | A confound, not transfer. | | OOD performance | Related, but does not establish that a specific previous experience caused the improvement. | For Piper, this implies a hard rule for future scoring: **if there is no no-exposure comparison, the result should not be entered as measured transfer.** --- ## 2. Why Piper's current description is not yet enough Piper currently describes transfer as a habit: map the dependency envelope, consider whether a language boundary is justified, and reuse measurement techniques across instruments. The reviewer correctly identified the evidentiary problem: the named tools — `transplant`, `polyglot-advisor`, `semantic-diff`, and `reuse-search` — had not been used recently, and there was no observed machinery enforcing the described behaviour. That does not imply that no transfer occurs. The underlying LLM almost certainly performs some implicit transfer. The issue is attribution. Without an explicit retrieval, abstraction, adaptation, and outcome trail, there is no way to distinguish: 1. knowledge already present in the base model; 2. an analogy produced spontaneously in the current context; 3. a retrieved prior Piper episode; 4. a stored abstraction or skill; 5. architecture-level assistance; 6. prompt-format effects; and 7. genuine cross-domain reuse caused by previous experience. The target of this component is therefore not “make Piper capable of analogy.” It is **make transfer observable, causally attributable, improvable, and testable**. --- ## 3. What the literature says ### 3.1 Retrieval is often the bottleneck Classic cognitive work on analogical transfer repeatedly shows a striking pattern: subjects may possess a relevant prior example and still fail to use it until they are told that it is relevant. This suggests that the problem is often **not mapping once the source is present, but spontaneous retrieval across surface differences**. That is directly relevant to Piper. An LLM can often explain the correspondence between two problems when both are shown together. The harder problem is causing Piper, in the wild, to ask: *Where else have I seen this structure?* The implication is important for the architecture: a “transfer opportunity detector” that decides whether to search risks reproducing the exact failure mode transfer research warns about. For non-trivial tasks, retrieval should normally happen automatically. The gate should decide **whether to use** a retrieved candidate, not whether to look. ### 3.2 Structure matters more than surface for far transfer Structure-mapping research distinguishes object or surface similarity from relational structure. Two problems can share vocabulary and still require different reasoning, or look unrelated while sharing the same causal or dependency pattern. This creates two failure modes for ordinary embedding search: - **surface false positive:** semantically similar episode, wrong underlying structure; - **structural false negative:** semantically distant episode, highly reusable underlying structure. Piper's current `reuse-search` style of retrieval should therefore not be the final decision mechanism. The stronger pattern is a two-stage search resembling the MAC/FAC family of analogy models: 1. **cheap broad retrieval** to collect candidates; 2. **expensive structural re-ranking** to find relational matches. For Piper, stage one can be ordinary semantic or vector retrieval. Stage two should compare a controlled structural signature: roles, relations, causal direction, constraints, failure pattern, transformation type, and solution operator. ### 3.3 Abstraction should be induced from multiple verified episodes One episode is usually a poor basis for a transferable lesson. It contains accidental details. Multiple episodes make it possible to contrast what changed with what remained invariant. A useful distinction is: **Episode:** > In service X, `None` reached line 172 and caused a numeric comparison to fail. **Potential transferable abstraction:** > When a value originates from an optional external source, establish presence and type before an operation that assumes either. The second representation can transfer to JavaScript `undefined`, an unset environment variable, missing sensor input, incomplete survey data, or a missing API field. But even that abstraction should not be trusted merely because Piper wrote it. It should be created from at least two compatible episodes and supported by external verification where possible. The strongest source report therefore recommends an offline induction rule: > **No promoted transfer lesson from a single unverified episode.** This is consistent with the broader pattern in agent-memory systems: useful reusable memories are typically distilled from repeated success/failure trajectories, causal observations, or validated skills rather than raw self-reflection alone. ### 3.4 Negative transfer is not an edge case Prior experience can hurt. A superficially similar case can prime the wrong strategy. An over-general lesson can be applied outside its valid preconditions. Irrelevant retrieved context can consume attention and distort reasoning. Therefore a transfer system needs to learn both: - **when a lesson helps**, and - **when a lesson should be rejected**. A useful transfer record should carry explicit preconditions and failure conditions, plus a history of successful and harmful applications. Over time Piper should be able to estimate quantities such as: > Lesson X helped 8/10 structurally matched targets, but only 1/7 surface-only matches and harmed 3 of those 7. That transforms transfer from a static library into a calibrated policy. ### 3.5 Near transfer is established; far transfer is still the interesting open problem The supplied research reports identify substantial evidence for experience reuse in agents — including skill libraries, workflow memories, causal abstractions, episodic memories, and retrieved procedures. The strongest demonstrations are generally within the same environment, task family, website family, game, or domain. The evidence becomes thinner as source-target distance grows. This is exactly why Piper's benchmark can be useful: the valuable question is not merely whether explicit memory helps, but **how far across domain boundaries that benefit persists**. A particularly useful hypothesis is that different memory forms dominate at different distances: - raw episodes may be strongest for very near targets; - executable skills may dominate near code/tool reuse; - abstractions may become more useful as surface similarity falls; - structure-keyed analogy search may matter most at medium/far distances; - at extreme distances the transfer effect may cross zero and become harmful. That shape is measurable. --- ## 4. Proposed Piper transfer architecture The recommended design splits transfer into an online loop and an offline consolidation loop. ### 4.1 Online loop — every non-trivial problem ```text new problem ↓ problem representation ↓ cheap cross-domain retrieval ↓ structural re-rank ↓ applicability / negative-transfer gate ↓ explicit source→target role mapping ↓ adapt lesson / skill ↓ execute ↓ external verification where available ↓ write episode + transfer ledger rows ``` #### Step 1 — Represent the problem twice Store both: - **surface representation:** normal natural-language/task embedding; - **structural signature:** a compact schema of what kind of problem this is. Example structural signature: ```json { "roles": [ "source:optional-external-value", "operation:type-assuming", "failure:runtime-crash" ], "relations": [ "source -> operation", "absent(source) => failure" ], "solution_operator": "guard-before-use" } ``` The vocabulary does not need to be perfect initially. It needs to be stable enough that the ledger can later tell Piper which signature dimensions actually predict transfer. #### Step 2 — Retrieve broadly Use a cheap first-stage search across **all domains**, not only the current repo or language. A reasonable starting policy: - semantic/vector top-k ≈ 20; - include episodes, abstractions, and executable skills; - do not suppress candidates solely because their domain label differs from the target. #### Step 3 — Structural re-ranking Re-rank candidates using the structural signature. Candidate scores can include: - role overlap; - relational overlap; - causal direction; - shared constraint pattern; - shared failure topology; - same solution operator; - historical help rate for this match type. The goal is not to find the most semantically similar memory. It is to find memories whose **reason for succeeding** is likely to survive adaptation. #### Step 4 — Applicability gate For every candidate, test: - are its preconditions present? - are any known failure conditions present? - can every important source role be mapped to a target role? - what is its historical posterior probability of helping under this kind of match? - is the expected value worth the token/tool cost? Candidates that fail the gate are still logged. Rejected candidates are useful training data for the gate. #### Step 5 — Explicit role mapping Force Piper to state the adaptation before execution. Example: ```text source role: optional API value maps to target role: environment variable that may be unset source operation: numeric comparison maps to target operation: path construction requiring a string shared lesson: establish presence/type before use ``` This makes hidden analogical leaps inspectable and allows bad mappings to be scored. #### Step 6 — Execute and verify Use objective verification whenever possible: - unit/integration tests; - deterministic evaluator; - simulator/environment state; - known answer; - external instrument reading; - frozen evaluator model where deterministic scoring is not possible. High-value tasks can additionally run a no-lesson variant to estimate local counterfactual benefit. #### Step 7 — Write the ledger Every retrieved candidate should generate a row even if rejected. Minimum fields: ```text problem_id candidate_lesson_id surface_similarity structural_similarity match_type applied / rejected reason verifier outcome estimated_help observed_counterfactual_gain (if available) cost ``` Without this ledger, Piper can accumulate memories but cannot learn whether her transfer policy is becoming better. --- ## 5. Offline loop — induction, consolidation, and maintenance The offline loop is where Piper turns experience into reusable transfer knowledge. ```text verified episodes ↓ cluster by structure ↓ contrast successes and failures ↓ induce candidate abstraction ↓ replay / verify candidate lesson ↓ promote, merge, demote, or retire ↓ recalibrate retrieval + gate statistics ``` ### 5.1 Promotion rule A candidate abstraction should normally require: - at least two supporting episodes; - a shared structural pattern; - at least one externally verified outcome; - explicit preconditions; - explicit known failure conditions or a statement that none are yet known; - replay against stored episodes before promotion. ### 5.2 Contrast success with failure Piper should not only ask “what was common across successes?” She should also ask “what distinguished success from superficially similar failure?” That contrast is how the system learns applicability boundaries. ### 5.3 Consolidation Periodic maintenance can: - merge duplicate lessons; - split overly broad lessons; - attach narrower preconditions; - promote frequently successful abstractions; - demote lessons with falling calibration; - retire dead or harmful skills; - protect well-supported lessons from accidental overwrite. A skill library without maintenance risks becoming another collection of unused tools — the exact condition the reviewer found in the current transfer subsystem. --- ## 6. Proposed transfer-memory record ```json { "id": "lesson-0412", "version": 3, "abstraction": "When a value comes from an optional external source, establish presence before any operation that assumes a type.", "form": "causal", "signature": { "roles": [ "source:untrusted-optional", "op:type-assuming", "failure:silent-or-crash" ], "relations": [ "source -> op", "absent(source) => failure" ], "solution_operator": "guard-before-use" }, "preconditions": [ "a value can be absent at runtime", "a downstream step assumes presence or type" ], "failure_conditions": [ "absence is already a valid handled state", "presence is guaranteed before runtime" ], "role_mapping_hints": { "source:untrusted-optional": [ "API field", "environment variable", "sensor dropout", "survey non-response" ] }, "source_episodes": [ "ep-python-null", "ep-javascript-undefined" ], "source_domains": ["python", "javascript"], "evidence": [ { "episode": "ep-javascript-undefined", "verifier": "unit-tests", "result": "pass" } ], "ledger": { "structural_match": { "applied": 10, "helped": 8, "hurt": 0 }, "surface_match_only": { "applied": 7, "helped": 1, "hurt": 3 }, "rejected_by_gate": 14 }, "posterior_help": { "structural_match": 0.75, "surface_match_only": 0.22 }, "max_distance_band_succeeded": 3, "composition_parents": [], "protected": true, "created": "timestamp", "last_calibrated": "timestamp" } ``` The critical difference from a normal memory record is that this object stores not only **what the lesson says**, but **where it has actually transferred successfully and where it has failed**. --- ## 7. Transfer distance A binary near/far label is too crude. Piper should use a multi-axis distance representation and then aggregate it into benchmark bands. Potential dimensions include: - same vs different repository; - same vs different programming language; - same vs different tool/environment; - same vs different task objective; - same vs different representation/modality; - same vs different causal structure; - same vs different solution operator; - amount of role remapping required; - amount of domain knowledge replacement required. The important distinction is between **surface distance** and **structural distance**. A Python and JavaScript bug may be far in syntax but near in structure. Two Python failures can be near in vocabulary but structurally unrelated. ### Proposed five-band benchmark | Band | Description | Example | |---|---|---| | D0 — very near | Same domain and representation; different instance | Python optional-value bug → another Python optional-value bug | | D1 — near | Same problem class, changed repo/tool/language | Python optional-value bug → JavaScript `undefined` bug | | D2 — medium | Different implementation domain, same reasoning procedure | Python debugging isolation → Bash debugging isolation | | D3 — far | Different domain, preserved relational structure | software dependency analysis → organizational dependency analysis | | D4 — very far | Different domain and representation, only deep procedure preserved | debugging hypothesis-test cycle → scientific experimental diagnosis | The benchmark should eventually fit an empirical curve rather than assume that the hand-labelled bands are perfect. --- ## 8. Metrics ### 8.1 Primary metric — Transfer Gain For distance band `d`: \[ TG(d)=E[S_B\mid A,d]-E[S_B\mid \neg A,d] \] Report confidence intervals and multiple seeds. ### 8.2 Transfer gradient Plot `TG(d)` against distance. The key object is the curve, not a single average. Useful summaries: **Transfer AUC** Area under the transfer-gain-by-distance curve. **Transfer horizon** The greatest distance at which transfer remains reliably positive. **Gradient slope** How rapidly benefit decays with distance. ### 8.3 Negative-transfer rate \[ NTR = P(TG < 0 \mid lesson\ applied) \] This should be reported separately from average gain. A system that helps greatly 60% of the time but damages 40% of tasks is different from one with the same mean and very low harm. ### 8.4 Retrieval and gate diagnostics Measure the subsystem itself: - **candidate recall:** was the useful prior lesson retrieved? - **structural rank:** where did the correct analogue rank after re-ranking? - **gate precision:** among lessons the gate allowed, how many helped? - **gate false-negative rate:** how often did the gate reject a lesson that would have helped? - **adaptation accuracy:** were source and target roles mapped correctly? - **cost delta:** extra tokens/tools/time per unit of transfer gain. These diagnostics identify *where* transfer failed rather than recording only a final score. --- ## 9. Benchmark design A useful initial suite is **40 target problems: eight per distance band**, plus structural foils. Each item should define: 1. source task A; 2. transferable lesson; 3. target task B; 4. shared deep structure; 5. deliberately changed surface features; 6. control condition; 7. transfer condition; 8. objective scorer; 9. contamination risk; 10. expected negative-transfer failure mode. ### Starter task families | Source | Target | Band | Transferable structure | |---|---|---:|---| | Python optional-value bug | Python service bug | D0 | guard uncertain input before type-assuming use | | Python optional-value bug | JavaScript `undefined` bug | D1 | same data-flow failure across language boundary | | Python debugger isolation | Bash failure diagnosis | D2 | reproduce → isolate → hypothesize → test | | unit-test minimization | SQL query fault isolation | D2 | shrink search space while preserving failure | | code dependency graph | deployment dependency graph | D3 | reachability and blast-radius reasoning | | software dependency graph | organizational workflow | D3 | critical-path / blocking-edge reasoning | | calibration of sensor bias | forecast calibration | D3 | detect systematic bias → estimate correction → re-evaluate | | TDD | non-code hypothesis testing | D4 | define falsifiable check before committing to solution | | provenance tracking | research-source verification | D3/D4 | claim → evidence lineage → stale dependency invalidation | | adversarial evaluator design | security test design | D3 | search specifically for cases that violate assumed invariants | | cache invalidation diagnosis | stale organizational policy | D4 | derived state must be invalidated when dependency changes | | flaky test diagnosis | noisy instrument diagnosis | D4 | distinguish stochastic observation noise from persistent fault | ### Structural foils For every several positive pairs, include at least one foil of each type: **Surface-similar / structure-different** Looks like the source but the old lesson should *not* be used. **Surface-different / structure-same** Looks unrelated but the old lesson is exactly the right abstraction. These foils are essential because otherwise embedding retrieval can appear successful without demonstrating structural transfer. --- ## 10. Preventing contamination and prior-knowledge confounds The base model is a major confound. Piper may already know the purported lesson before the experiment begins. Use several defences: ### Synthetic targets Generate novel rules, symbols, APIs, micro-languages, dependency graphs, or environments that did not exist in model pretraining. ### Obfuscation Rename predicates, entities, operations, and surface conventions while preserving relational structure. ### Counterbalancing Test both A→B and B→A when possible to separate transfer from unequal task difficulty. ### Hidden targets The source exposure should not announce which future problem it will be useful for. ### Format-matched controls Because demonstrations can help merely by revealing answer format or task conventions, give the control arm an equally sized but structurally irrelevant exposure. ### Cross-session channel For agent-memory transfer, source experience should normally occur in a separate context/session from the target. Otherwise the experiment partly measures in-context learning instead of agent memory. --- ## 11. Seven-arm ablation All arms use the same base model, target tasks, token/tool budget, and scoring. | Arm | Enabled | Main question | |---|---|---| | A — Base | no persistent transfer memory | What can the LLM do without agent-level experience? | | B — Episodic | raw episode retrieval | Does remembering prior cases help? | | C — Abstract | distilled semantic/causal lessons | Does abstraction extend transfer beyond raw episodes? | | D — Analogy | structural signatures + structural re-rank | Does explicit structure search improve medium/far transfer? | | E — Skill | executable/procedural skills where applicable | Does direct verified reuse outperform text lessons for near transfer? | | F — Gate | applicability / negative-transfer gate | Can Piper prevent harm from misleading memories? | | G — Full | retrieval + abstraction + analogy + skill + gate + calibration | Do the components compound into a stronger transfer system? | Three useful preregistered hypotheses are: **H1.** Raw episodic retrieval improves D0–D1 more than D3–D4. **H2.** Structural retrieval increases transfer gain primarily in D2–D4. **H3.** The applicability gate reduces foil errors and negative-transfer rate more than it reduces positive transfer gain. A stronger long-term hypothesis is: **H4.** Piper's transfer horizon moves outward over time as the ledger improves retrieval, abstraction quality, and gating. If H4 is observed on held-out task families, that would be evidence of **learning to transfer**, not merely possessing a static transfer mechanism. --- ## 12. What counts as a successful result The bar should be deliberately higher than “Piper used an old idea.” A convincing demonstration would show: 1. source A is learned or experienced; 2. the useful information is stored in agent memory; 3. target B occurs later without A remaining in the context window; 4. B differs substantially in surface representation; 5. Piper retrieves the relevant source or abstraction without being told which one to use; 6. Piper explicitly maps source roles to target roles; 7. objective target performance exceeds a matched no-A control; 8. the gain survives multiple randomized seeds/items; 9. structurally misleading foils do not produce a comparable false-positive effect; 10. an ablation shows which transfer machinery caused the improvement. This is the standard that would move the component from a descriptive claim to a measured cognitive subsystem. --- ## 13. Practical implementation order ### Phase 0 — Instrument first Before building new transfer logic: - add episode IDs; - log retrieval candidates; - log applied/rejected state; - log verifier outcome; - add source→target lineage; - make every transfer-related tool invocation observable. This alone fixes the current “no machinery in use” problem at the measurement layer. ### Phase 1 — Structural signatures + always-on retrieval Implement: - a small controlled signature vocabulary; - semantic top-k search across domains; - structural re-ranking; - explicit role mapping. Do not yet allow self-modifying transfer lessons. ### Phase 2 — Applicability gate + ledger Add: - preconditions; - failure conditions; - per-match-type success/harm counts; - calibrated probability of help; - rejection logging. ### Phase 3 — Offline abstraction induction Cluster verified episodes and create candidate lessons only from repeated structure. Replay them before promotion. ### Phase 4 — Benchmark and ablation Run the five-band suite across arms A–G. Establish the baseline transfer gradient. ### Phase 5 — Learning the transfer policy Once enough ledger data exists, tune: - retrieval weights; - structural feature importance; - gate thresholds; - which memory type to prefer by distance band; - retirement/promotion policies. At this point Piper is no longer merely using a transfer engine. She is learning **how she herself transfers successfully**. --- ## 14. The deeper design implication The original four modules — `transplant`, `polyglot-advisor`, `semantic-diff`, and `reuse-search` — are useful local tools, but they do not by themselves constitute transfer cognition. The missing layer is **meta-level coordination**: > What old experience might matter here? > What is structurally shared? > What parts are accidental? > Under what conditions did the old lesson work? > What maps to what in the new problem? > Did using it actually help? > Should the lesson become more trusted, narrower, broader, or retired? That is the machinery the reviewer could not find. If implemented, transfer becomes less like a bag of utilities and more like an empirical memory policy. The most important artifact is not the skill library itself; it is the **closed loop between retrieval, adaptation, verified outcome, and recalibration**. --- ## 15. Open research questions for Piper 1. Can a compact structural vocabulary span software, operations, science, and planning without becoming vague? 2. Does structure-keyed retrieval actually cause spontaneous cross-domain noticing, or does relevance judgement remain the bottleneck? 3. How many independent episodes are required before an abstraction becomes reliable enough to promote? 4. Can Piper learn when raw episodes are preferable to abstractions and when executable skills are preferable to either? 5. How should credit be assigned when several retrieved lessons contribute to one success? 6. Can the applicability gate remain calibrated when the underlying base LLM changes? 7. Does the transfer horizon expand with use, or is it largely fixed by the base model? 8. How much of apparent far transfer disappears under synthetic/obfuscated targets? 9. Can negative-transfer history predict harmful reuse before execution? 10. Can transfer-policy improvements survive a clean held-out benchmark without tuning to the benchmark itself? --- ## 16. Research map The following references were identified across the supplied research reports as particularly relevant to the design above. This is a **working bibliography**, not a fully source-verified literature review; several 2025–2026 claims in the source reports should be re-opened and checked before publication. ### Foundational transfer and analogy - Thorndike, E. L., & Woodworth, R. S. (1901). Early experimental work on transfer / identical elements. - Chi, M. T. H., Feltovich, P. J., & Glaser, R. (1981). Expert vs novice problem categorization by deep vs surface structure. - Gick, M. L., & Holyoak, K. J. (1980). Analogical problem solving and spontaneous transfer. - Gick, M. L., & Holyoak, K. J. (1983). Schema induction and analogical transfer. - Gentner, D. (1983). *Structure-Mapping: A Theoretical Framework for Analogy*. Cognitive Science. - Aamodt, A., & Plaza, E. (1994). Case-Based Reasoning: Foundational issues, methodological variations, and system approaches. - Forbus, K. D., Gentner, D., & Law, K. (1995). MAC/FAC two-stage analogical retrieval. - Barnett, S. M., & Ceci, S. J. (2002). When and where do we apply what we learn? A taxonomy for far transfer. - Gentner, D., Loewenstein, J., & Thompson, L. (2003). Comparison-based abstraction and transfer. ### Transfer learning, continual learning, and measurement - Taylor, M. E., & Stone, P. (2009). *Transfer Learning for Reinforcement Learning Domains: A Survey*. JMLR. - Pan, S. J., & Yang, Q. (2010). *A Survey on Transfer Learning*. IEEE TKDE. - Yosinski, J. et al. (2014). *How transferable are features in deep neural networks?* arXiv:1411.1792. - Lopez-Paz, D., & Ranzato, M. (2017). *Gradient Episodic Memory for Continual Learning*. arXiv:1706.08840. - Zamir, A. R. et al. (2018). *Taskonomy: Disentangling Task Transfer Learning*. CVPR. - Achille, A. et al. (2019). *Task2Vec: Task Embedding for Meta-Learning*. arXiv:1902.03545. - Vu, T. et al. (2020). *Exploring and Predicting Transferability across NLP Tasks*. EMNLP. - Pruksachatkun, Y. et al. (2020). *Intermediate-Task Transfer Learning with Pretrained Models: When and Why Does It Work?* ACL. - Hernandez, D. et al. (2021). *Scaling Laws for Transfer*. arXiv:2102.01293. ### LLM analogy, robustness, and contamination controls - Levy, I., Bogin, B., & Berant, J. (2023). *Diverse Demonstrations Improve In-context Compositional Generalization*. ACL. - Valmeekam, K. et al. (2023). *PlanBench*. arXiv:2206.10498 — particularly Mystery Blocksworld as an obfuscation pattern. - Webb, T., Holyoak, K., & Lu, H. (2023). *Emergent analogical reasoning in large language models*. - Wu, Z. et al. (2024). *Reasoning or Reciting? Exploring the Capabilities and Limitations of Language Models Through Counterfactual Tasks*. - Lewis, M., & Mitchell, M. (2024). Counterfactual evaluation of LLM analogical reasoning. - Yasunaga, M. et al. (2024). *Large Language Models as Analogical Reasoners*. - Huang, J. et al. (2024). *Large Language Models Cannot Self-Correct Reasoning Yet*. ### Agent memory, skills, and explicit experience reuse - Wang, G. et al. (2023). *Voyager: An Open-Ended Embodied Agent with Large Language Models*. arXiv:2305.16291. - Zhao, A. et al. (2024). *ExpeL: LLM Agents Are Experiential Learners*. arXiv:2308.10144. - Majumder, B. P. et al. (2023). *CLIN: A Continually Learning Language Agent for Rapid Task Adaptation and Generalization*. arXiv:2310.10134. - Wang, Z., Mao, J., Fried, D., & Neubig, G. (2024). *Agent Workflow Memory*. arXiv:2409.07429. - Sarch, G. et al. (2024). ICAL / experience distillation into embodied programs of thought. arXiv:2406.14596. ### 2025–2026 items from the supplied reports requiring source verification before publication The supplied reports also cite or discuss: EvaLearn, IsoSci, MetaFlowLLM, ExpWeaver, H2R, TDAG, SkillOps, AFTER, and *Break It Down, Pass It On: Cross-Task Skill Transfer in LLM Agents*. These are potentially valuable because they directly address modern agent transfer, hierarchical experience reuse, skill refinement, transferability, or negative transfer. Their exact publication status, titles, venues, identifiers, and quantitative claims should be independently verified before they are used as publication-grade evidence. --- ## 17. Component conclusion The reviewer finding should stand for the current implementation: **Piper has evidence of implicit transfer capability, but not yet of an explicit transfer subsystem operating in live use.** The path to changing that is concrete: > **Always retrieve. Represent structure. Re-rank across domains. Gate applicability. Map roles explicitly. Verify outcomes. Log counterfactual benefit. Induce abstractions offline from multiple verified episodes. Recalibrate continually.** The primary evaluation should be a five-band transfer gradient with paired exposed/unexposed arms, structural foils, synthetic or obfuscated targets, and component ablations. If Piper eventually shows that the full system pushes the positive-transfer horizon farther outward than the base model, episodic retrieval, or semantic abstraction alone — while reducing negative transfer on structural foils — then Component 19 will have a defensible measured result rather than a narrative description.