Governed Experience Cards for Code Debugging

• Governed Experience Cards are standardized abstractions derived from GitHub issues, pull requests, and patches that decouple error symptoms from resolution strategies.
• They employ a dual-layer schema—Index for diagnostic signals and Resolution for repair strategies—to enable efficient retrieval and analogical bug-fixing by autonomous code agents.
• This approach yields measurable improvements in bug resolution rates and supports scalable, cross-repository debugging, as demonstrated in empirical SWE benchmarks.

A governed experience card is a standardized, agent-consumable abstraction derived from the closed-loop record of a GitHub issue, pull request, and corresponding patch. Each card captures the decoupling between the problem’s symptoms (“what went wrong”) and its resolution logic (“how it was fixed”), enabling autonomous code agents to retrieve relevant history by diagnostic signals and transfer distilled debugging strategies to novel bug-fixing scenarios. In the MemGovern framework, governed experience cards serve as the atomic unit in a memory infrastructure, providing structured, cross-repository human repair expertise and supporting an analogical reasoning workflow that outperforms traditional “fix-from-scratch” approaches (Wang et al., 11 Jan 2026).

1. Abstraction and Structure of Governed Experience Cards

Governed experience cards are designed for compatibility with LLM-based code agents, providing a dual-layer schema:

• Index Layer ($I_i$): Encodes a normalized problem summary and a set of 10–18 diagnostic signals, which typically comprise exception types, error signatures, and coarse component tags. This layer is mapped into a retrieval embedding space $\phi(I_i)$, enabling efficient nearest-neighbor search given a natural-language query.
• Resolution Layer ($R_i$): Contains an evidence-backed root-cause analysis, an abstract (design-level) fix strategy, a concise summary of the code patch (as changed files and semantic chunks), and the associated verification plan (e.g., unit test specification).

The formal representation is:

$$E_i = \langle \text{Index}=I_i, \; \text{Resolution}=R_i \rangle$$

A concrete example:

Problem Summary	Signals	Root Cause	Fix Strategy	Patch Digest	Verification
"ArrayIndexOutOfBounds in sorter when input length = 0."	[“ArrayIndexOutOfBounds”, “sorter module”, ...]	“lack of empty-list check”	“add guard for length ≤ 1”	“Modified SortUtil.java; added ‘if ...’”	“Added unit test for zero-length arrays”

This structural decoupling allows for analogue-driven repair: the agent retrieves cases using the Index Layer and applies generalized fix strategies from the Resolution Layer, adapting them to context-specific variables and APIs.

2. Governance Pipeline: From Raw Data to Actionable Experience

MemGovern operationalizes card generation through a multi-stage pipeline. The stages ensure that only high-quality, context-rich debugging experience propagates to agent memory:

A. Hierarchical Experience Selection

• Repository selection: Each repository $r$ is scored by popularity $(S_r)$, issue ($I_r$), and PR volume $(P_r)$:

$$\text{Score}(r) = \lambda_s \log(1+S_r) + \lambda_i \log(1+I_r) + \lambda_p \log(1+P_r)$$

Top $M$ repositories are retained, prioritizing active projects with sustained maintenance.

• Instance purification: Only “closed-loop” triplets (issue, PR, patch) are kept if the PR merges the patch, the diff is parsable, and diagnostic anchors exist. Threads with a technical-comment ratio below $\tau = 0.2$ are excluded.

B. Standardization and Purification

• Nontechnical content is pruned via LLMs (removing greetings, redundant logs, merge notifications).
• Each triplet is parsed into the unified protocol—Index and Resolution layers—enabling normalization across repositories.

C. Checklist-based Quality Control

• Cards are scored by an LLM evaluator on summary correctness, diagnostic signal coverage, and causal–fix–verification alignment. Cards failing to meet threshold fidelity $(\gamma)$ are revised in up to three refinement loops.

3. Agentic Experience Search and Transfer Workflow

Agents interact with governed experience cards through two primitives:

A. Searching

• Given a natural-language query $q$ (constructed from issue symptoms, stack traces, etc.), agents retrieve top-$K$ index-matched cards via cosine similarity:

$$\text{sim}(q, I_i) = \frac{\phi(q) \cdot \phi(I_i)}{\|\phi(q)\| \; \|\phi(I_i)\|}$$

B. Browsing

• Upon selection, the agent accesses the full Resolution Layer, obtaining root-cause patterns, modification logic, and validation plans.

The agent performs iterative query refinement, repeatedly searching and browsing until a relevant, transferrable repair strategy is identified. The workflow operationalizes:

1. Formulating queries from the present context.
2. Retrieving and filtering cards for relevance.
3. Adapting abstract strategies to current variable names and APIs.

4. Quantitative Evaluation and Empirical Impact

MemGovern was evaluated on the SWE-bench Verified benchmark, encompassing 500 real-world GitHub issues. Key results:

• Memory Size: 135,000 governed experience cards used.
• Resolution-rate improvement: Mean absolute gain of +4.65% over the SWE-Agent baseline.
• Cross-model effectiveness: Notable findings across seven LLMs.

Model	Baseline (%)	MemGovern (%)	Δ(%)
Claude-4-Sonnet	66.6	69.8	+3.2
GPT-5 Medium	65.0	67.4	+2.4
DeepSeek-V3.1T	62.8	65.8	+3.0
Qwen3-235B	47.2	55.4	+8.2
Kimi-K2-Instruct	43.8	51.8	+8.0
GPT-4o	23.2	32.6	+9.4
GPT-4o-Mini	14.0	17.2	+3.2

Ablation studies demonstrate that:

• Increasing the memory size from 10% to 100% yields monotonic gains in resolution rates.
• Retrieval top-$K$ sweeps ($K=1$ to $\sim20$) show diminishing returns beyond moderate $K$, indicating robust recall properties.
• Agentic search (dynamic, iterative retrieval and adaptation) yields higher gains than static or naive retrieval-augmented generation (RAG) strategies.

Efficiency is maintained: token usage per session increases by less than 10%, and cost by less than 5%, which is outweighed by performance improvements (Wang et al., 11 Jan 2026).

5. Limitations and Prospective Advancements

Limitations

• Dual-stage search and browsing workflows increase the context window token usage by 2–5% per agent session.
• The initial curation of governed cards incurs substantial computational cost, relying on advanced LLMs (e.g., GPT-5.1) and multiple quality refinement loops, which could be prohibitive at larger scales.

Potential Extensions

• Memory compression: Summarization/clustering to minimize redundancy and context requirements.
• Dynamic prioritization: Predictive ranking of cards by project metadata or issue type.
• Multi-modal schema: Integration of execution traces or test logs as additional fields.
• Continual update: Incremental incorporation of new experience using few-shot (rather than full-pipeline) governance.
• Schema evolution: Addition of fields for performance impact or security risk classification for domain-specialized debugging.

A plausible implication is that further integration of multi-modal and domain-specific metadata may not only improve precision in retrieval but also permit richer forms of analogical transfer.

6. Contextual Significance within Automated Software Engineering

Governed experience cards provide the foundational infrastructure enabling code agents to harness open-world human debugging experience at scale. By systematizing noisy and unstructured GitHub traces into searchable, logic-rich abstractions, MemGovern facilitates analogical solution transfer, improves generalization beyond project boundaries, and significantly boosts empirical bug-fixing performance across a range of LLM agents. This approach circumvents the historical closed-world limitation—namely, the inability of code agents to exploit nonlocal, precedent-based repair knowledge from the global developer community. The methodology and demonstrated efficacy position governed experience cards as a central paradigm in the evolution of autonomous software engineering (Wang et al., 11 Jan 2026).