Source-linked AI summary
Tuning the Stochastic Machine: A Systems Engineer's Operating Model for Human-AI Engineering
George Andrikopoulos
TL;DR
Expert corrections to LLM errors can be lost between sessions, while the discipline for governing persisted corrections remains missing. The paper maps the LLM stack to machine layers and reports practice cases that yield operational rules, including validating security parse results against intent.
Problem
Human-AI engineering corrections are stateful, yet prevailing practice lacks a governed store for them, leaving accumulated pair capability in an ephemeral chat session.
Source: §1 · p. 1Method
The paper maps session context, instructions, rules, and conversation onto boot firmware, loadable modules, persistent tunables, and volatile workload memory.
Source: §3 · p. 2Results
A practice case generalizes a security rule: validate a boundary’s parse result against intent, and treat an untested guarantee as a hypothesis.
Source: §7 · p. 6Takeaways & Limitations
The conclusion is that capability must be stored under governance and with provenance to compound, using practices such as persisting configuration and watching for drift.
Source: §10 · p. 7The evidence comes from one practitioner’s environments without quantitative comparisons; production baselines, cross-team transfer, and independent expert grading remain future work.
Source: §9 · p. 7
Abstract
from arXiv · showhide
When an expert corrects an LLM assistant's error, the correction usually dies with the session, and the error class returns. I argue this is an operations problem, not a tooling problem: mechanisms for persisting corrections exist and are shipping, but the discipline for governing them -- versioning with provenance, recurrence monitoring, counter-metrics, retirement of stale rules -- does not. Writing as a systems engineer of thirty years, I map the LLM stack onto the machines my profession already operates (frozen silicon, firmware, loadable modules, persistent configuration, volatile memory), identify where the mapping fails (stochastic generation, configuration that binds only probabilistically, no general-purpose retirement (verification) stage by default), and derive from the failures a seven-principle operating discipline with an error loop at its core. Three cases from my own practice illustrate the mechanism, among them a control that silently became the exact harm it was built to prevent. I close with the measurement framework this view implies and the lab study required to test it.
1 The reboot problem: capability is state without a store
A costly expert correction is lost with its chat session, so the same class of AI error can recur. The paper argues that human-AI capability needs a governed store, while prevailing practice leaves it in ephemeral sessions.
1 The reboot problem: capability is state without a store
- The model retains no state between sessions: its weights are frozen and its conversation context is cleared at session end; the MCP protocol is also stateless, removing its initialization handshake and session identifier [14].The passage presents statelessness as deliberate and appropriate for the plumbing, while distinguishing it from capability that ought to accumulate.Source: §1 · p. 1
- Human-AI capability—what a pair has learned and corrected—needs to accumulate, but prevailing practice leaves it in the chat session, where it is guaranteed to be destroyed.A senior engineer’s costly correction is followed a month later by the same class of mistake from the same tool, including in a colleague’s chat.Source: §1 · p. 1
- Usage dashboards measure activity, not improved capability, and can make a team improving AI-assisted output indistinguishable from one producing more drafts for review.The paper invokes Goodhart’s law: when usage numbers become targets, they reward activity over capability.Source: §1 · p. 1
- This is an experience report and operating model, not empirical validation; it argues that the missing layer is operational discipline and specifies a study for validation in §8.The paper frames that discipline as one systems engineers already possess.Source: §1 · p. 1
2 Related work, and the claim stated precisely
Persistence mechanisms already exist and are in use, but teams lack the operating discipline to govern them over time. The paper argues that persistence without governance does not compound and that the missing governance layer can be borrowed from operations management.
2 Related work, and the claim stated precisely
- Persistence mechanisms already span memory-augmented architectures, agent self-revision, executable skill libraries, simulated-agent memory, training feedback, and persistent coding-assistant instructions [5][6][7][8][9][10][11].Jiang and Nam’s study of 401 repositories classified persisted Cursor rules [17]; Lulla et al. measured 28.6% lower median runtime and 16.6% lower output-token consumption with AGENTS.md present [18].Source: §2 · p. 2
- The missing team-level discipline includes provenance and retirement for rules, recurrence monitoring, generalization from incidents to error classes, counter-metrics, and a standing cut list.The claim is that persistence without this governance does not compound, and the governance layer is borrowable from an older discipline [4].Source: §2 · p. 2
- Evaluation should track behavioral trajectories rather than release-time snapshots when systems continue learning after deployment through in-context learning and memory features.Jiang and Nam’s taxonomy [17] describes what practitioners persist, but not how rules are governed over time.Source: §2 · p. 2
- Unlike Karpathy’s “LLM OS” sketch [2] and LLMOps literature, which approach the system from the architect’s seat, this paper takes the operator’s seat to govern and measure systems in use.The distinction is between owning tools and running a production system.Source: §2 · p. 2
3 The machine, in the operator’s terms
The LLM stack can be understood through machine-room concepts, but natural-language instructions are probabilistic and the system lacks a general-purpose retirement stage. A correction that remains only in conversation disappears at session end, so durable corrections must be written to persistent configuration.
3 The machine, in the operator’s terms
- The stack maps fixed model weights to frozen silicon and each session to a cold boot, with prompts, modules, persistent rules, and conversation occupying distinct layers.The context window assembles like a boot sequence, while conversation RAM clears completely at session end.Source: §3 · p. 2
- Natural-language instructions shift probability toward compliance rather than enforcing it; conflicting files silently widen the output distribution, while grammar-expressible constraints can be enforced at sampling [12].The engine is stochastic, and guarantees held only in prose are unenforced.Source: §3 · pp. 2–3
- Because LLMs lack a general-purpose retirement stage, pipelines must deliberately supply verification through deterministic checkers or human experts.A hallucination has no in-band detector by default; verifier and critic models, guardrail classifiers, and self-consistency sampling are partial analogues [6][13].Source: §3 · p. 3
- A correction made only in conversation is like a runtime setting lost at reboot; unless written to persistent configuration, it never happened.The paper argues that organisations currently run their most expensive expertise in this volatile mode.Source: §3 · p. 3
4 The stochastic engine, and the tail
LLM responses are sampled from distributions whose tails remain reachable, so output quality varies across runs rather than resolving to a single value. Evaluating only average performance can hide rare but damaging failures in that tail.
The stochastic engine
- Each step deterministically computes a next-token distribution, then samples from it; sampling settings shape tail reachability, and batching or routing can leave residual variance even at temperature zero.Output quality is therefore a distribution, not a single value.Source: §4 · p. 3
The stochastic engine, and the tail
- LLMs are aiming engines: each response targets an outcome with scatter, and hallucinations are wild shots in the tail.The passage contrasts this with treating models as randomness engines.Source: §4 · p. 3
The tail
- Evaluating average responses hides damaging tail spikes: a model brilliant at p50 but dangerous at p99 can miss its SLA once a day.The passage frames model evaluation like latency work, where p50, p99, p99.9, and maximum matter.Source: §4 · p. 3
5 The discipline
The seven-principle discipline treats human–AI engineering as an operations problem: corrections must persist, rules must be placed and governed, and stochastic behavior must be controlled and evaluated against real targets. Its error loop depends on expert review writing fixes back into persistent configuration, while measurement must account for prevention that leaves no direct trace.
P1 — Persist or perish
- P1 requires every meaningful correction to become a durable, versioned instruction-layer artifact; a fix made only in the running workload disappears at reboot.The operational distinction is like sysctl -w versus a persistent configuration change: only the persistent layers survive reboot.Source: §5 · pp. 3–4
P2 — Aim by layers; one home per rule
- P2 assigns each rule one global, domain, or project home; when an error recurs, strengthen the original rather than duplicate it or create conflicting homes.Duplicates fork and decay, while conflicting homes widen the output distribution.Source: §5 · p. 3
P3 — Engineer the distribution; judge the tail
- P3 treats stochastic output as a distribution to engineer and judge by its tail, while placing guarantees in the strongest available deterministic control.The hierarchy descends from types to property-based and unit tests, constrained decoding, and finally natural-language instructions; type-driven design makes illegal states unrepresentable.Source: §5 · pp. 3–4, Figure 2 · p. 5
P4 — The human is the retirement stage of last resort
- P4 makes the expert the retirement stage of last resort: catch an undetectable mispredict, squash it, and write the fix back so the pipeline does not replay it.Expertise makes the machine safe, and write-back makes the human-machine pair compound rather than merely coexist.Source: §5 · p. 4
P5 — Every metric carries a counter-metric
- P5 pairs every metric with a counter-metric because optimizing a lone measure can diverge from the goal.Examples pair speed with rework and conformance with alert noise; usage is replaced by outcomes (§8).Source: §5 · p. 4
P6 — Govern or decay
- P6 requires review, provenance, recurrence monitoring, and a cut list because a long, ungoverned instruction library degrades its own signal [16].Since prevention can leave no trace, triangulate it with deflection citations, trigger-surface measurement, recurrence, and challenge trials; move rules from incident to prose, mechanised check, then provenance-preserving archive, never deleting solely for zero fires. This governance resembles standard work and continuous improvement in the Toyota tradition [4].Source: §5 · pp. 4–5
P7 — Aim only at real targets
- P7 says to verify that a real target exists: some decision must change on the measured outcome, or distribution engineering produces disciplined but worthless work.Pure scatter, noise mistaken for signal, and metrics without an attached decision are targetless processes.Source: §5 · p. 5
6 The loop
The section specifies an error write-back loop: fix each meaningful miss, turn recurring error classes into reasoned rules with checks, place them by layer, and maintain them through drift response and versioning.
6 The loop
- On every meaningful miss, fix the instance before process, then name an error class broad enough to prevent two future errors; one-offs need no rule.Abstract until the rule prevents at least two different errors, stopping before platitude. The write-back path for P1 and P4 follows a lean tradition [4].Source: §6 · p. 5
- Draft the destination rule as an imperative with its rationale, a check for unverified assumptions, and a one-line incident example.The check asks: under what configuration could this cause the exact harm it was chosen to prevent?Source: §6 · pp. 5–6
- Choose a layer-appropriate home after checking for related rules; if the error recurs despite one, treat it as drift and strengthen rather than duplicate.Version and record the date, class, incident, and one changelog line.Source: §6 · p. 6
7 Evidence from practice
Three practice cases illustrate how the correction loop operates in use; they do not establish effect sizes, which are left to §8.
Case 1 — a mechanism chosen by reputation
- io_uring fell back to io-wq threads that could run on protected cores, prompting a dated rule to trace touched resources and ask the failure-mode question; the class has not recurred.Source: §7 · p. 6
Case 2 — the control that became its own negation
- Review caught malformed JSON that would leave the allowlist inert and a CIDR typo parsed as /0; the rule validates security-boundary results against intent, not syntax.Both defects were caught by applying the same failure-mode question prescribed for design; the case illustrates a control silently becoming the harm it was meant to prevent.Source: §7 · p. 6
Case 3 — the loop running in both directions
- The assistant caught a missing deployment-and-adoption stage in the expert’s framework, while the expert corrected an estimated biographical fact; both fixes persisted, supporting the governed pair as the unit of improvement.Source: §7 · p. 6
8 Measurement, and the study this implies
The section proposes four paired, outcome-based measures for a maturing instruction library and a lab programme to validate them. Its central test is a blind challenge trial comparing fresh agents with and without a rule, while the programme’s pilot observations are not presented as results.
8 Measurement, and the study this implies
- The proposed measures are error-class recurrence, first-time-right rate, rework rate, and time-to-competence, each paired with a counter-metric to guard against gaming.Counters are rule usage and a cut list; severity-weighted review catches on a published, versioned scale; lead time; and escalation quality, respectively.Source: §8 · pp. 6–7
- The measures roll up into time saved and risk avoided, assessing whether the grouping is tightening rather than merely counting activity such as opening more chat windows.The author says the instruments are proposed, and their validation—including publication of the severity scale—belongs to the study, not this paper.Source: §8 · pp. 6–7
- The proposed lab study uses a versioned reference implementation with public provenance and blind challenge trials that compare fresh agents performing tasks with and without a rule loaded.Trials independently construct tasks to elicit a rule’s error class and use deterministic binary scoring, avoiding model-in-the-loop grading, deterrence paradox, and self-grading circularity.Source: §8 · p. 7
- The programme also tracks library corrections, generalisations, and recurrences, alongside rework and first-time-right rates against a published, versioned severity scale.Its questions concern which corrections become class-retiring artifacts, what governance sustains an effective library and valid measures, and whether the discipline transfers across domains.Source: §8 · p. 7
- The companion paper reports a first result: one mined rule closed a consistently failing task class, while a rule-authored suite found nothing; these and §7 cases are pilot observations, not programme results.The contrast locates the discipline’s value in measurement on real misses rather than in its own rulebook.Source: §8 · p. 7
9 Limits
The paper cautions that its machine-stack analogy is imperfect and that its evidence is practitioner-specific; validation and whether organizations need this framework remain empirical questions.
9 Limits
- The machine-stack mapping is a working analogy, not an isomorphism: context windows are not literally RAM, and retrieval degradation is only cache-like, though documented [16].Source: §9 · p. 7
- Instruction-trigger reliability, on which P1 partly depends, remains underexplored.Source: §9 · p. 7
- The evidence comes from one practitioner’s own environments, so the paper reports no quantitative comparisons of its own.Source: §9 · p. 7
- The §8 validation is lab-based: a single-author reference implementation offers clean provenance and deterministic scoring at the cost of ecological validity.Source: §9 · p. 7
- Production baselines, cross-team transfer, and independent expert grading remain future work for a host site, whose ownership terms the author does not claim before securing one.Source: §9 · p. 7
- Whether an organization’s AI use has a στόχος worth this framework’s machinery is an empirical question, which the author declines to assume.Source: §9 · p. 7
10 Conclusion
The paper argues that capability must persist as governed state with provenance so corrections can compound. The machine is new, but the discipline of adjusting after misses and governing drift is familiar to systems engineers.
10 Conclusion
- After every miss, adjust the configuration rather than relying on memory, as marksmen and systems engineers do.The conclusion compares adjusting sights after misses with persisting production-machine configuration and preferring deterministic controls.Source: §10 · p. 7
- Capability requires state to live somewhere under governance and with provenance, or it does not compound.The conclusion argues that evicting state from plumbing does not eliminate the need to retain and govern capability-bearing state.Source: §10 · p. 7
- The discipline is familiar: systems engineers already persist configuration, prefer deterministic control, watch the tail, and govern drift.The conclusion locates this operating discipline in engineers’ existing practice of bounding jitter distributions and keeping production machines in specification.Source: §10 · p. 7