A Working Doctrine: Stochastic Tools in DevOps/SRE Practice
An engineering-use doctrine — not a substitute for enterprise security, privacy, legal, procurement, or regulated-use controls.
Premise. Generative and agentic tools produce outputs whose correctness cannot be assumed from fluency, confidence, or repeatability — and they operate on whatever they are shown. Two consequences drive everything below: reliability must be supplied by the surrounding workflow, and inputs must be controlled before any workflow exists.
Principles
1. Govern the reliance, not the label. This doctrine applies to any machine-generated artifact a person or system will act on — where "act on" includes selecting, ranking, filtering, or summarizing what a person sees. If nothing relies on the output, minimal output-assurance ceremony applies; input and access controls always apply.
2. Select tasks by verification asymmetry. Favor tasks where verifying is meaningfully cheaper than generating: ground truth exists, outputs can be executed, sampled, or reconciled against an authoritative source. Where verification is as costly as the work — or delayed, circular, or impossible — the tool may still aid exploration and option generation, but nothing it produces is a reliable final artifact. It stays in the exploratory tier until Principle 6 promotes it.
3. Control inputs before the loop starts. Output errors can be caught; disclosures cannot be un-sent. Check data classification before material enters a context window, working directory, or vendor tool. This is the one control that cannot be applied after the fact — which is why it applies even to exploration.
4. Reliability lives in the harness, not the generator. Determinism, where required, is restored at the artifact boundary: types, schemas, tests, linters, pinned dependencies, reproducible runs, reconciliation against systems of record. The harness bounds the output space and makes failure visible; it does not certify correctness. Review still has a job.
5. Load-bearing configurations are engineering artifacts. Reusable prompts, skills, and agent configurations that materially shape surviving artifacts get version control, review, and change history. For agent runs, the load-bearing artifact is the invocation environment — model version, permissions, retrieved context — not the prompt alone. One-off queries need none of this ceremony.
6. Assurance scales with artifact promotion. Institutional status sets the assurance requirement; content and access set handling — a draft containing credentials or destructive commands is controlled regardless of status. Promotion includes copying, summarizing, or incorporating an output into any artifact of higher authority. Exploratory sketch → working record → recommendation → executed change or audit evidence: each crossing raises the evidence bar and re-triggers validation.
7. Provenance scales with promotion. Exploratory work: the sources used and an "unverified" marker. Promoted artifacts: source material, assumptions, validation performed, reviewer, and authorized status — a change record, not a warning label. The goal is traceability (enough to reconstruct and challenge the artifact), not exhaustive execution logging.
8. Sign only what you can inspect, refuse, and interrupt. Ownership requires the information, access, competence, time, and authority to detect a problem — and to intervene before the consequence becomes practically irreversible. Where no single person holds all of these, make the control explicitly collective (peer review, separation of duties) rather than nominally individual.
9. Measure the whole workflow. Cost includes generation, review, correction, escalation, and downstream rework — not generator time alone. Cycle-time and quality claims require baselines, however crude: task timestamps, defect escape rate, rework frequency. No baseline: it's an anecdote, not a claim.
10. Preserve independent understanding. Verification depends on a model of the system built independently of the generator. Maintain it deliberately: work cold periodically, explain generated changes in your own words, and check whether the team can still perform the core task unassisted. That capacity is the asset every principle above depends on.
Closing rule. New tools may be explored from day one — under bounded input and execution controls. They enter a relied-upon workflow only after their verification method and promotion path are named. Until then, everything they produce stays in the exploratory tier: use it there, and nowhere else.