Expert fixes to LLM errors vanish after sessions because teams lack an operations discipline to persist and govern corrections; instituting a versioned write-back loop, tail-focused metrics, and explicit retirement processes would make human-AI collaborations accumulate real capability rather than replay the same mistakes.

Main Finding

Persisting expert corrections to LLM assistants without disciplined governance yields no cumulative improvement: the corrections live only in volatile sessions and are lost at "reboot." The missing layer is operations discipline — not persistence mechanisms — and an operator-focused seven-principle operating model (with an explicit error loop and measurement frame) is necessary to make human-AI pairing compound expertise over time.

Key Points

• Problem framing
  • Modern LLM stacks are intentionally stateless at session/protocol layers; valuable, stateful human corrections are therefore often stored only in ephemeral chat context and vanish at session end.
  • This is an operations problem: persistence mechanisms (memories, instruction files, rule files, retrieval, RLHF) exist, but teams lack governance (versioning with provenance, recurrence monitoring, retirement, counter-metrics).
• Systems mapping (axioms)
  • A1: Model weights are "frozen" (ROM/firmware analogue).
  • A2: Each session is a cold boot; context window ≈ volatile RAM; persistent artifacts must be written to the equivalent of /etc to survive.
  • A3: Natural-language configuration is probabilistic "hints," not deterministic guarantees.
  • A4: The engine is stochastic; output is a distribution with a tail of rare, harmful outputs.
  • A5: No default, general-purpose retirement/verifier stage ships — human review is often required.
• Seven operating principles (P1–P7)
  • P1 Persist or perish: every meaningful correction must become a durable, versioned artifact or it is lost.
  • P2 Aim by layers; one home per rule: use global/domain/project layers and avoid duplicates/conflicts.
  • P3 Engineer the distribution; judge the tail: evaluate on tail behavior, prefer deterministic controls where possible.
  • P4 Human is the retirement stage of last resort: humans supply the checker that catches unverifiable hallucinations and must write fixes back.
  • P5 Every metric carries a counter-metric: avoid Goodhart effects and gaming.
  • P6 Govern or decay: rule libraries degrade signal unless governed (versioning, provenance, recurrence monitoring, cut lists, challenge trials).
  • P7 Aim only at real targets: validate there is an operational decision to be improved before engineering.
• The error/write-back loop
  • Steps for every meaningful miss: (1) fix the instance immediately; (2) name the error class (generalize); (3) draft an imperative rule with rationale and a check; (4) choose one home (global/domain/project); (5) version and record (date, incident, changelog). The loop closes only when persisted and loaded at next boot.
• Measurement & tail focus
  • Evaluate trajectories not snapshots; focus on p99/p99.9 tails and recurrence detection; use deflection citations, trigger-surface measurements, challenge trials, and counter-metrics to triangulate prevention.
• Evidence & scope
  • The paper is an experience report from a 30-year systems engineer and provides three illustrative case studies (one where a chosen mechanism caused the very harm it was meant to prevent). It is conceptual and prescriptive; it does not present experimental effect sizes. The author specifies a lab study needed to validate impact.

Data & Methods

• Methodology
  • Qualitative, systems-engineering analysis: mapping LLM layers to classic machine layers, deriving axioms and operational consequences.
  • Literature synthesis of related work (memory-augmented architectures, agent curricula like Voyager, RLHF/Constitutional AI, context-engineering empirical work such as Jiang & Nam and Lulla et al., evaluation arguments about trajectories).
  • Experience-based case studies (three cases from the author’s practice) to show feasibility and failure modes of the proposed loop.
• Limitations
  • No quantitative validation or randomized experiments presented.
  • The paper explicitly calls for a formal lab study (§8) to measure effect sizes, operational costs, and benefits (proposed but not executed within the paper).
• Proposed measurement framework (high level)
  • Outcome-focused metrics rather than usage; tail-focused evaluation (p99/p99.9); recurrence monitoring; versioned provenance logs; challenge trials to surface latent error classes; paired metrics with counter-metrics to reveal gaming.

Implications for AI Economics

• Productivity and returns to expertise
  • Persisting and governing corrections converts one-off expert interventions into cumulative capability, increasing the marginal productivity of scarce experts. This raises the returns to investments in human domain expertise and reduces recurrent labor costs for recurring error classes.
• Organizational capital and scale economies
  • A governed instruction/rule layer is organizational capital that scales: teams that systematize corrections will compound improvements across users and time, creating durable competitive advantage and higher effective throughput per engineer.
• Cost structure and deployment economics
  • Implementing the proposed discipline requires operational investments (versioning systems, recurrence monitoring, challenge-trial tooling, governance cadence). These are likely cheaper than continuous expert rework but produce switching/maintenance costs; vendors or platforms that provide managed, provable persistence & governance could capture value.
• Incentives, measurement, and Goodhart risks
  • Shifting measurement from usage to outcomes and tail behavior changes incentives: vendors and teams must be paid/credited for risk reduction (tail mitigation) and durable outcomes, not activity. This reduces perverse incentives (overgeneration, superficial usage metrics) but requires richer SLAs and monitoring (raising monitoring/verification costs).
• Risk management, insurance, and externalities
  • The emphasis on tail and recurrence monitoring reframes economic exposure: rare but high-cost errors (p99/p99.9) drive reputational, legal and financial liabilities. Better operational discipline can lower these externalities and influence liability, compliance costs, and insurance pricing for AI deployments.
• Market implications
  • New markets/services: governance tooling, versioned rule libraries with provenance, challenge-trial platforms, and consulting around the P1–P7 discipline.
  • Platform vs. project layering: proper layering (global/domain/project) affects productization and potential vendor lock-in: rules tied into repositories (project layer) reduce drift but raise integration/coordination costs when migrating.
• Labor dynamics
  • If expertise is made persistent and compounding, specialized experts (who craft durable rules and checks) become more valuable relative to general reviewers. That shifts labor demand toward higher-skilled human-in-the-loop roles focused on governance and verification rather than repetitive correction.
• Evaluation & policy
  • Regulators and procurement should evaluate LLM-assisted systems on trajectories and governance (persistence, provenance, recurrence monitoring) rather than static bench performance. Procurement and compliance regimes that reward governed persistence will affect vendor incentives and adoption patterns.

Short takeaway: Persisted corrections without governance don't compound; treating human-AI pairs as stateful production systems (with versioned rules, recurrence monitoring, tail-focused measurement, and a human retirement stage) changes the economics of AI augmentation by converting ephemeral expert fixes into durable, scalable organizational capital while shifting costs toward disciplined operational infrastructure and different incentive structures.