We Have DevOps, DataOps, MLOps. We Need EpOps.

A practitioner's notes on the *Ops discipline that has to exist.

The Setup

In early 2026, a few months after relocating my family across jurisdictions, I got fed up. Months of discordant advice across service providers, law-firm blog posts, community handbooks in multiple languages, and word-of-mouth practitioner experience — all of it from reputable people presumably working in good faith, and all of it contradicting other reputable people working in good faith on specifics that mattered — had left me with the unwelcome realization that the discordance itself was the problem. Even a careful person querying competent sources couldn’t know in advance which to believe. I’d been working with AI in various forms for over a decade. The last year and a half approximated something like full-time applied work with the new GenAI/LLM generation — figuring out how to actually get useful work out of these tools by building over a dozen (private) little projects — and I’d developed a toolkit of methods for sifting BS at scale. So I decided to give up on finding individual practitioners and service providers as the final arbiters of fact (as high as their utility sometimes is), and build my own epistemic infrastructure to triangulate across relevant sources instead.

What emerged, over several weeks of iteration and intermittent upkeep since, is a knowledge base of just over five hundred atomic claims.

Each claim carries:

• Source attribution across multiple sources, weighted by authority class: statutes rank above administrative rulings rank above practitioner opinions rank above community/forum sources rank above self-reported marketing claims

• A three-dimensional verifiability taxonomy: what kind of source could (in principle) verify this, how it has been verified (actually), and how stable is the underlying fact (laws vs. regulations vs. prices, etc.)

• A confidence score computed from a sigmoid-bounded formula that aggregates evidence with authority weights, verdict valences, source reliability, and time decay

• Dependency edges connecting claims, serving two purposes. Cascade invalidation: when one claim is verified incorrect, every claim downstream is flagged for re-verification. And critical-path surfacing: the navigational trails through the claim landscape that matter most for downstream decisions. The claims aren’t just isolated facts; together they form a map of a domain, and the entire point of the system is enabling effective traversal of that map. Critical paths show which claims deserve deeper verification or special attention the most — the ones that the most consequential routes and decisions cross.

• Source reliability scores that update as verifications complete: one of mine sits at 0.56 because four out of nine verifications refuted claims it originally made, and that score now weights-down other contributions from that source

Here’s the thing: Since building this, the database has won every cross-check I’ve run against practitioner advice. As in: every time I’ve since come across a conflicting claim from a practitioner, upon careful re-examination of the facts of the matter, the database was correct. Every. single. time. Now: Before reading too much into that, here’s a careful read of what’s actually happening. The contradictions the database has caught share a profile: questions about codified rules where the practitioner is working from heuristic memory or institutional lore rather than the source text, questions where regulations have changed since the practitioner last verified, questions where someone has answered confidently because their work model rewards workable answers given fast rather than perfectly-verified answers given slowly. None of this necessarily indicts individual practitioners.¹ The ones I continue to work with bring lived knowledge, judgment, political feel, and execution capability my database can’t match — and which I’d be foolish to do without. What the pattern points at is structural: knowledge work performed with inferior epistemic infrastructure isn’t reliable even when the people performing it are skilled and well-intentioned. The discordance and overconfidence I encountered weren’t evidence of bad practitioners: they are evidence of what an entire field looks like when no one has built the infrastructure for keeping its knowledge calibrated.

I’ve come to believe that what I delineate here are the concrete outlines of a field that is forming in at least six independent intellectual communities — none of whom, as far as my cursory research indicated, seem to cite each other in any major way: epistemic engineering.

The Field That Keeps Trying to Be Born

The phrase “epistemic engineering” currently shows up across several intellectual strands that don’t seem to be in significant conversation with each other (but what do I know - I’m more interested in applying it to the real world than in theorizing about it in the most beautiful and academic fashion).

Cognitive scientists use it as a descriptive principle of how distributed systems — brains, bodies, tools, institutions — generate new knowledge. A tradition in philosophy of information, STS, and social epistemology doesn’t use the exact phrase but has been writing for decades about knowledge infrastructure as designed and therefore redesignable. At least several sub-clusters in the AI and LLM research community have been publishing related work during 2024-2026 on sycophancy, epistemic alignment, AI epistemic limits, and the architectural basis of epistemic outcomes. And there are at least two informal practitioner uses of the proper-noun phrase from 2025: an August Substack post — whose definition overlaps closely with the synthesis I’m describing here, and who reached for a civil-engineering analogy first — and “Applied Epistemic Engineering” (a September website where the term names a different project). Neither seem to have accumulated much traction since — but their near-simultaneous emergence is itself the signal: multiple unrelated people reached for this exact term in 2025 because the conceptual territory is ripe.

Two practitioner-led currents in AI have converged on adjacent problems without using the phrase:

Context engineering — coined by Walden Yan, popularized by Karpathy, Lütke, and Harrison Chase, canonicalized by Anthropic’s engineering blog. The discipline of curating the entire information environment an agent operates in. The field has named its own failure modes — context rot (Chroma’s research, 2025, validating the pattern empirically across 18 frontier models), context poisoning, lost-in-the-middle. By early 2026 it had become an organizing concept at IBM, Moody’s, AWS, Sequoia, and dozens of enterprise AI vendors.

Compound engineering (Kieran Klaassen at Every, Inc.) — the practice of accumulating learnings across AI sessions so that each use makes future uses more effective. Compound engineering asks how to make sessions accumulate. Epistemic engineering asks whether what’s accumulating is actually true. Compound without epistemic discipline just compounds contamination.

The convergence is real. The need is real. But nothing yet ties the pieces together into a unified discipline with a named practice layer. That’s the gap.

The Missing Quality Layer

The cleanest way to say it: context engineering is plumbing. Epistemic engineering is water treatment.

Context engineering asks: what does the model need to know, and how do I architect the system that delivers exactly that information at the right moment within the context window constraints? That’s a critical question, and the field around it is doing real work. But it’s a per-model-invocation consideration, and it’s silent on a prior question: is what’s flowing through the plumbing actually worth drinking?

“Make the implicit explicit” is the meta-principle. Every epistemic engineering intervention traces back to it: Implicit confidence becomes explicit confidence scores. Implicit quality standards become explicit methodological requirements. Implicit assumptions become explicit dependency tracking. Implicit iteration becomes explicit version control. Implicit provenance (”we know this,” or “ABC is a fact”) becomes explicit sourcing (something closer to “it appears that ABC, because of evidence X, assessed by Y, on date Z, with confidence W” — it’s more complex, but you get the idea).

The reason the principle is so load-bearing is that implicit epistemic structures are invisible to quality assurance. You cannot audit what you cannot see. You cannot track the decay of confidence that was never quantified. You cannot detect the failure of a verification process that was never formalized. The move — making the implicit explicit — is the precondition for every other intervention.

The move itself has ancestry. Bowker and Star called it “infrastructural inversion” in Sorting Things Out (1999): treating invisible infrastructure as foreground rather than background. Much of what I’m describing operationalizes that tradition. What’s new isn’t the move. It’s that the same move is the atomic operation underneath any cognitive system that has to stay calibrated: individuals, teams, organizations, academic fields, business intelligence departments, knowledge-producing communities of every kind. The failure modes don’t belong to one discipline. They’re general. AI doesn’t create them. AI makes them more legible — and more urgent — by amplifying the miscalibrated cognitive horsepower at play.

In the pre-AI paradigm, doing all of this systematically used to be so expensive as to be a pipe dream outside of, but probably even within, very well-resourced projects or institutions (intelligence agencies, very well-funded labs, etc). When mental work is hard and access to mental horsepower the limiting constraint, it can’t be done. But with mental horsepower becoming cheap, deep rigor becomes not just tractable - it becomes existentially necessary. It becomes an imperative.

The Failure Modes

If epistemic engineering is the discipline, one of its first products is a failure mode taxonomy — a structured antipattern registry for what goes wrong when knowledge systems aren’t actively maintained.

Some of these have older names in adjacent fields. Others seem indeed new, emerging from AI-augmented work specifically. Five on top of mind (a fuller version with more modes and deeper analysis is in the works — subscribe to catch it):

Confidence laundering.² AI-generated content acquires the appearance of established fact through passage across epistemic boundaries without corresponding verification. A hypothesis gets drafted by an LLM, pasted into a document, summarized by another one, cited by a third one, and within a few cycles nobody (none of them and no onlooker) can recall it was ever speculative. Confidence inflates while the underlying foundation never actually strengthened.

Provenance collapse. The accumulated loss of where beliefs came from. “We know X” gets divorced from the source chain that justifies it. A year later no one can reconstruct whether X was a documented finding, a plausible inference, or a confident hallucination that survived review. The more conventional analogs are the logical fallacies of appeal to consensus and appeal to authority: “everybody knows,” “it is known that”, “experts agree”, etc. But where there’s no provenance, surprises await. Provenance is cheap to lose and expensive to rebuild.

Epistemic monoculture. If every agent in an organization uses the same AI model — or models with overlapping training data and failure modes — their outputs will share all manner of systematic biases. (Bias in cognitive systems is deeply misunderstood anyways - another story for another post.) When multiple agents independently produce the same answer, it can look like a relevant convergence of evidence could be present - while just being non-independent replication of the same error. The appearance of consensus masks the absence of triangulation. This extends to languages, to schools of thought, and to much else: an organization that does all its research in English (or that relies exclusively on a narrow set of disciplines) is systematically blind to knowledge living primarily in other linguistic communities (or disciplines). This is the same reason interdisciplinary teams have appeal, why outsiders tend to produce disproportionate intellectual breakthroughs, and part of why external consultants keep getting hired by corporations. Independence of perspective is epistemically valuable precisely because it can break the replication of shared error.

Compounding drift. The self-reinforcing divergence of organizational beliefs from reality through the accumulation of small, uncorrected errors. A small error becomes a premise. That premise shapes a conclusion. The conclusion becomes institutional knowledge. Future work builds on it. The error is now load-bearing and increasingly hard to detect because everything built on top of it appears coherent relative to the contaminated foundation. In the worst case the organization generates analyses that appear to confirm the original error — the organizational equivalent of overfitting.

Information degradation through transformation. Every time a knowledge artifact is transformed rather than surgically modified — regeneration, summarization, paraphrase, cross-agent handover, context compaction — some information is lost. Each transformation may be individually acceptable, below the threshold of obvious degradation. The cumulative effect over many cycles, however, is catastrophic. It’s a giant, open-ended game of telephone: it’s the epistemic equivalent of generational loss in analog copying, or the accumulating compression artifacts in an image that’s been resaved too many times. Organisations or individuals that routinely ask AI to “update this document” rather than specifying precise changes are unknowingly running their knowledge base through a lossy compression-decompression cycle on every edit. Some AI authoring tools (such as Claude Chat) have gotten better at avoiding this in recent releases — but that’s evidence the issue is severe enough to warrant engineering attention, not evidence it’s “a solved problem”.

These five aren’t nearly an exhaustive list. They’re the ones most immediately practical to name. The point is the pattern - these aren’t one-off mistakes: they’re structurally predictable degradation patterns that become the default behavior of an AI-augmented knowledge system without active countermeasures.

Without epistemic engineering, AI-augmented workflows face what’s most accurately called epistemic collapse — the analog of model collapse in machine learning (Shumailov et al. documented this empirically in Nature in 2024), where language models trained on their own outputs progressively lose diversity and fidelity until they produce only degenerate text. This is where generative AI turns into degenerative AI.³ Model collapse is the training-time side of the medal; epistemic collapse is the inference-time side — its incarnation in AI-native knowledge work, whether at the scale of one or the scale of an organization, and even irrespective of whether the setup is only humans, only AIs, or hybrid. (Yes, human-only endeavors can encounter epistemic collapse as well - AI today just speedruns the process). An organization or individual whose knowledge base becomes increasingly populated by unverified AI outputs that future AI interactions then treat as ground truth follows the same trajectory: beliefs progressively disconnect from reality while feeling or appearing increasingly confident, because the evidence for those beliefs consists of other beliefs within the same contaminated system.

The antidote to model collapse is training data curation. The antidote to epistemic collapse is epistemic engineering.

EpOps: The Practice Discipline

Following the established *Ops naming convention — DevOps, DataOps, MLOps, SecOps, etc — one might call the operational instantiation or integration of epistemic engineering EpOps. Where the original *Ops discipline, DevOps, tightly integrates (if not fuses) development and operations of - in that case - software artifacts, EpOps does the same for epistemic artifacts: holistically managing them through their entire life cycle.

A note on the naming, because this matters. DevOps is not “development operations.” MLOps is not “machine learning operations.” DataOps is not “data operations” (though some “Ops” fields, such as “AIOps” (coined and pushed by consultancies more than adoptees), misunderstand and misapply the terminological family). These aren’t names for the operations teams that run those systems. They’re names for the practice discipline — the know-how, the integration patterns, the workflows, the hard-won lessons — that keep the underlying thing alive and healthy as it contacts and moves through the real world. DevOps is how the dev function integrates with the operations reality downstream of it. DataOps is how data engineering integrates with the consumers of data and the real-world processes that depend on data being fresh and accurate. The *Ops pattern is about grounding a specialty in practitioner reality so the specialty doesn’t live in an ivory tower out of touch with how anything actually works. (That’s why AIOps is an outlier that breaks this convention — it names an operational use of AI, not the discipline of keeping AI systems alive. The dominant pattern is the discipline-of-practice naming.)

EpOps grounds epistemic engineering in practitioner reality. It’s the practice discipline of doing this — with agents, documents, workflows, teams (or solo), organizations of all types and sizes — not the theory of it. EpOps is to epistemic health what DevOps is to deployment health: the daily practices, tools, and workflows that turn principles into discipline.

I believe EpOps is going to become a thing, whether under this banner or a different one. Not because I say so, but because it describes real practices that address real pain points — pain points that have arisen now (never before has there been such a flood of slop and not-slop mixed together, muddying the water and befuddling humans and AI systems alike), and practices that are becoming tractable now (only now is it possible to orchestrate processes like this at scale, affordably, across heterogeneous human-AI workforces). My background is in DevOps and DataOps consulting, with a particularly early stake in DataOps. I’ve watched other *Ops disciplines emerge before. This one has that same signature: the right kind of pain, the right kind of tractability, and practitioners starting to reach for a name.

Some EpOps practices follow directly from the failure mode taxonomy:

Against confidence laundering: epistemic status metadata on every document (AI-generated / human-reviewed / human-cleared); confidence ceilings that cap what AI-generated content can claim without human review; deterministic confidence protocols (confidence derived from evidence, not asserted impressionistically); the “epistemic opener” (via system prompt) — a standard preamble for AI research interactions that shifts the session from confident-answer mode to careful-analysis and epistemic-humility mode.

Against provenance collapse and temporal decay: source documentation standards (every load-bearing claim carries a URI and potentially associated metadata, date accessed, assessor identity and potentially associated metadata, and a quality flag); staleness alerts on evidence age; verifiability tagging that classifies claims by authority, verification method, and stability.

Against epistemic monoculture: monoculture audits (periodic checks for over-reliance on single models or single-source evidence); multilingual research directives (multi-language search strategies when topics warrant); the “multi-angle demand” — forcing analysis from multiple orthogonal perspectives rather than shallow “three points” responses; the council pattern — convening multiple models or perspectives on the same question when the stakes justify the increase in token cost.

Against compounding drift: dependency mapping and cascade review (when foundational claims are invalidated, explicit tracing of dependents); epistemic circuit-breakers (automatic review triggers when dependency chains exceed specified lengths).

Against information degradation through transformation: the anti-regeneration rule — surgical edits only; never full rewrites unless explicitly intended; flanked by planning gates — “show me what you intend to do before doing it; I will review the plan, then authorize execution.” - and versioning (for simple rollback capability when the agent/AI veered off track).

EpOps is not one policy or one tool. It’s the full discipline: named, visible, measurable, and eventually capable of being hired for the way DevOps engineers have been for a long time.

A Practitioner Case: What This Looks Like in a Real System

The knowledge base I described at the top implements several of these practices in concrete form. A brief tour:

Authority-weighted evidence. Every piece of evidence carries an authority class — statutes and constitutional provisions at the top, then official administrative rulings, then licensed practitioners, then community sources, then self-reported marketing claims. The weights feed the confidence calculation: a statute beats a forum post roughly four-to-one. Does four forum posts equal a statute? I don’t know. The specific weights and aggregation formulas are a work in progress. What matters more than the exact numbers is that we’re naming the dimensions, attaching ratios to them, and making them available for critique — rather than letting them live implicit in someone’s judgment.

Evidence verdicts with valence. Evidence can confirm, support, be neutral, contradict, or refute a claim, with asymmetric valences that make refutations count for more than original assertions. This is the mechanical anchor for calibrated disagreement. Same caveat applies: the specific values are hypotheses, not discoveries. The point is having a common language for accounting disagreement.

Source reliability as a learning (and learned) parameter. Every source accumulates a reliability score from its verification track record. The 0.56 I mentioned earlier is one of mine, computed from the fact that four out of nine of that source’s claims, when verified, turned out to be incorrect. The score multiplies the source’s future evidence contributions. The system learns which sources to trust less over time. This is one of the most valuable behaviors in the whole setup; it converts verification effort into durable reliability signal.

Time decay by stability class. Every claim is tagged with its stability: FIXED (statutes — effectively no decay within relevant time frames), PERIODIC (regulations — moderate half-life), VOLATILE (fees, processing times — short half-life). Old evidence on volatile claims naturally fades in the confidence calculation. Temporal decay, mechanized.

Cascade invalidation with named dependents. When a claim gets verified incorrect, the system looks up every claim that declared a dependency on it and flags them for re-verification. Dependents aren’t guessed at runtime — they’re tracked explicitly in a dependency matrix. This is the “automatic review trigger when dependencies are invalidated” EpOps practice in concrete form.

Variant IDs for live disagreements. When two credible sources contradict each other, the system doesn’t collapse one; it creates variant claims and a structured discrepancy record that tracks the disagreement until further evidence resolves it. This is how you hold a live disagreement with integrity instead of pretending it isn’t there. It’s also the operational form of F. Scott Fitzgerald’s remark that “the test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function.” We’re trying to build actually intelligent systems — not systems that fluently con us into believing they’ve resolved conflicts they never even attempted to do any (let alone proper) accounting of.

Methodological versioning. The schema itself has changed through multiple significant versions as I learned what was needed. The changelog carries a “methodological discontinuities” section noting when counting methodology, authority taxonomy, or evidence encoding format changed — with explicit compatibility declarations. The methodology is evolving faster than the documents it governs, and that fact itself is tracked.

None of this is speculative. It runs. It has produced decisions I’ve already acted on, saving me high costs (and even higher opportunity costs) as a result. The mechanisms are straightforward — the system is a Markdown table with some rules, a set of skill files that encode the protocols, and the discipline of actually applying them. It hasn’t gone through many of these Bayesian-ish updates. The math may not completely work out — I specified what the mechanisms should do, but LLMs are notoriously weak at math and I haven’t spent the time or tokens to really stress-test the formulas against edge cases where my intuitions about correct answers disagree with what the calculations produce. But theoretical perfection or mathematical elegance wasn’t the point - pragmatic value was. The initial impulse to map out the relevant aspects of the new country in ever-more perfect detail subsided somewhat once the initial maps were made and our most critical paths were charted or taken. I haven’t actively extended it in a few months; I have bills to pay and neither my personal attention nor my token budget are unlimited. But I’ve been planning to hand it over to my long-running autonomous-agent instance for ongoing maintenance. Stay tuned.

Where This Sits

I’m not claiming all or even any particular ones of these ideas are new. Each part has ancestors: Bowker & Star (1999) on infrastructural inversion; Frankfurt (1986) on the analysis of bullshit (very relevant to AI confabulation and the “sloppocalypse”); the forecasting tradition on calibration and temporal decay; intelligence analysis on provenance hygiene; and the librarians, of course, on all of this for -conceivably- millennia.

What seems new — what this piece is trying to stake out — is the assembly. As far as I’ve seen, the specific combination of a named failure mode taxonomy, a practice discipline (EpOps) explicitly pulled into the *Ops family, a scale-agnostic maturity model that applies from individual knowledge worker to enterprise, and “make the implicit explicit” as the unifying architectural move — that synthesis doesn’t exist anywhere else yet. Adjacent pieces exist. The synthesis doesn’t. (If I’m wrong, please do let me know in the comments!)

On coinage: I’m not claiming to have coined “epistemic engineering” itself — the phrase predates my use of it, in different senses.⁴ EpOps as a *named Ops practice discipline, on the other hand, doesn’t seem to be out there yet — epops.com has been an empty placeholder since the 1990s, and I haven’t found anyone using “EpOps” or “Epistemic Operations” as a discipline name in the *Ops (or any other) sense. That naming — and the framing as a sibling to DevOps / DataOps / MLOps, with everything that implies for how the practice should be structured, taught, and matured — is something I’m contributing here. The *Ops field for epistemic quality doesn’t yet exist. It urgently needs to.

Thinkers worth reading if any of this resonates:

• Bowker & Star, Sorting Things Out (1999). Infrastructural inversion — the direct ancestor of “make the implicit explicit.”

• Frankfurt, On Bullshit (1986). Structural analysis of assertion-without-regard-for-truth. The Frankfurtian lens on LLM output is devastatingly apt.

• Tetlock, Superforecasting (2015). The empirical anchor for calibrated confidence as a trainable (and therefore engineerable) property.

• Knorr Cetina, Epistemic Cultures (1999). Validates the central premise that epistemic outcomes are artifacts of institutional design.

• Karpathy, Chase, Yan on context engineering. The adjacent discipline this piece proposes the quality layer for. Their work created the vocabulary and practitioner adoption that EE/EpOps can now build on top of.

On Adjacent Memory Systems

Separate note: the AI ecosystem has produced a growing set of memory systems — OpenClaw’s Memory Wiki, MemMachine, Mem0, Letta, Cognee, memory-x, and others. Some of these (Memory Wiki in particular) have started supporting structured claims with evidence. These solve pieces of the problem I’m pointing at: structured storage, retrieval, cross-session continuity, and in some cases provenance.

But these are memory systems — the plumbing through which knowledge flows between sessions and agents. What epistemic engineering adds is a layer above: the discipline of deciding whether what’s being stored is worth storing, how disagreement between sources should be accounted, what counts as verification, how confidence should regress when an upstream claim is invalidated, and how to detect and arrest failure modes that aren’t storage failures but discipline failures. Memory systems give you storage and retrieval. Epistemic engineering gives you governance of the stored knowledge itself.

The relationship is quite complementary. Memory systems are likely to be substrates on which EpOps practice runs. But they aren’t the discipline.

Why It Compounds

The thesis underneath all of this: in an environment where computational intelligence is abundant and cheap, the scarce resource is not processing but epistemic hygiene.

The standard AI competitive narrative is “who has the best model wins.” My version is: “who has the best epistemic discipline wins — because access to the frontier models is rapidly becoming table stakes, and the real competitive edge is in how you actually employ them.” That insight was already being stabbed at by the context engineering discourse over the past year or so. But context engineering is conceptually anchored on the single-model interaction — what goes into a single context window, for a single turn, for a single agent. Epistemic engineering addresses the complex system effects that emerge when this is scaled up: across many agents, many models, many sessions, many humans, over time. That’s cognitive systems territory, and it’s where the compounding and the emergence effects happen.

This thesis arrived at me from practice, but it has acquired independent formal-economic support since. Acemoglu, Kong & Ozdaglar’s NBER paper “AI, Human Cognition and Knowledge Collapse” (February 2026) presents a model in which sufficiently accurate agentic AI tips an economy into a knowledge-collapse steady state— and the welfare-improving intervention they identify (aggregation capacity for pooling and curating human-generated knowledge so it remains available, updatable, and reliable) is, almost word-for-word, what EpOps as a practice arm operationalizes. The competitive thesis I’m describing is now convergent with NBER-tier formal economics, not merely a practitioner intuition.

The one — or the organization — that maintains calibrated beliefs at scale across a heterogeneous workforce of humans and AI agents outperforms the one that “YOLOs” its AI usage — treating every output as good enough, never giving critical feedback, always allowing to --dangerously-skip-permissions. (The horror stories I hear from friends and acquaintances about what some organizations are actually doing right now raise the hair on the back of my neck...)

Worth noting before going further: epistemic engineering doesn’t replace practitioners or expert advice. It changes what practitioners and advisors are optimally for — freeing them from being the final arbiters of factual recall and letting them focus on judgment, execution, and the edge cases where lived knowledge and embodiment matter. The practitioner working with EE infrastructure beats both the practitioner working alone and the infrastructure running alone. The same compounding holds for entrepreneurs, solopreneurs, businesses, and organizations more broadly: the combination is where the competitive advantage lives.

That compounding cuts both ways. Epistemic discipline compounds positively: each warranted belief becomes a reliable foundation for further work, enabling increasingly sophisticated and trustworthy output over time. Epistemic negligence compounds negatively: each unwarranted belief becomes a vector for compounding drift, progressively corrupting the knowledge base until a catastrophic, non-linear epistemic collapse — a “slop tsunami” — becomes inevitable.

The one — or the organization — practicing epistemic engineering is not merely better informed. They are structurally more reliable over time, in a way that widens the gap with every passing cycle. Their generative AI is truly generative. Their competition’s “generative AI” is, increasingly, degenerative.

An Invitation

This note is a flag-plant — and the first post in what I expect to become a fuller arc of writing on epistemic engineering and EpOps. More is in the works and at various stages of drafting: additional failure modes, deeper practitioner examples, the case study above written up properly, the layered architecture (from theoretical foundations through epistemic quality assurance, knowledge engineering, context engineering, and EpOps), the maturity model from Consumer through Epistemic Engineer, and the objections a proposed field needs to answer.

(Honestly, I should have published this earlier. Friends have been pushing me for months. I’ve finally figured out the format.)

In the meantime, I’d welcome:

• Pushback from anyone who thinks the framing is wrong, overclaims, or recreates a wheel that’s already well-established somewhere I haven’t looked

• Convergence from anyone working on adjacent pieces who wants to co-develop the vocabulary

• Adoption attempts from practitioners willing to try these practices on real systems and report back what breaks

This is an early-stage field, and the EpOps territory is still mostly empty. This practice/discipline fascinates me — and it appears to me poised to be the differentiator between AI-augmented knowledge work that “works”, and AI-augmented work that simply steers one into a long, first-slow-then-sudden rot and decline.

If any of this resonates, say hi.

Valentin Kotov. Founder of Salix Austral — an independent intelligence operation on agentic AI risk. Writing on epistemic engineering and EpOps at epistemicengineering.substack.com.

1. Not all practitioners, anyway. A subset fits Frankfurt’s bullshit diagnosis precisely — the ones who don’t really care whether what they’re saying is true, only whether it’s billable. Frankfurt’s original analysis arguably found its human archetype there, before LLMs came along and embodied the pattern more purely than any human ever could. The structural diagnosis still holds for the rest: most working practitioners aren’t bad-faith, just constrained by the absence of epistemic infrastructure. The bad-faith subset is where infrastructure absence meets motivational rot — and where the cost of taking advice on faith is highest.

2. The term “confidence laundering” turns out to have been arrived at independently by at least two other groups, which I discovered after naming it from my own practice. Matthew Kelly’s The Epistemic Suite (arXiv:2510.24721, September 2025) uses it as one of twenty output-diagnostic lenses for evaluating individual LLM utterances. Romanchuk & Bondar (arXiv:2601.08333, January 2026) formalize a closely related architectural pattern they call “semantic laundering” — propositions acquiring high epistemic status by traversing tool or model boundaries without inference relevant to warrant. I’m using the term at a third resolution: the organizational and systemic level, where outputs become inputs to other outputs across humans, agents, and time. The convergence across three independent projects at three resolutions is a sign the pattern is real, not that any of us coined it.

3. “Degenerative AI” has been used since approximately 2022 in the model-collapse / training-time-rot literature, where it describes what happens when a language model is recursively trained on its own outputs. The usage in this piece extends the term to the inference-time and organizational equivalent: human or agentic knowledge work that progressively rots as unverified AI outputs become inputs to future AI work. Same diagnostic pattern, different layer of the stack.

4. Cowley & Gahrn-Andersen (2023, Frontiers in AI) used the phrase in academic work in a different cognitive-systems sense; Vonn’s August 2025 substack use is acknowledged in the strand survey above.