Slop In, Signal Out: The Augmentation Stack and Why Knowledge Management Is the Fitness Function for AI

A working architecture for turning the noisy substrate of human output — including your organization’s — into a compounding intelligence asset.


A few weeks ago I argued that human slop, not AI slop, is the real problem. Forty thousand years of cave paintings, bad medieval treatises, Cold War strategy memos, two hundred years of replication-crisis-grade research, and a present-day internet drowning in opinion-as-fact. The Sturgeon’s Law ratio — ninety percent of everything is crap — was coined to describe what humans, with their hands and their wetware, were producing in 1957. The mediocrity isn’t new. Only the volume is.

The pushback to that piece was predictable: but AI is just remixing the slop. Garbage in, garbage out. Models trained on the human corpus inherit the contradictions, the errors, the dead-end paradigms. Recursive training collapses. Synthetic data degrades the next generation. The internet eats itself.

That critique is right about one specific implementation pattern and wrong about almost everything else. The naive version of recursive AI training does collapse. The non-naive version doesn’t — it compounds. The difference between collapse and compounding is precisely what this article is about, and it has a name: the Augmentation Stack. It’s a four-layer architecture that turns AI from a slop-remixer into an evolutionary selection mechanism on the human knowledge corpus. And here’s the part that should matter to anyone running a data, search, or knowledge function inside an organization: the same architecture, scaled down, is the missing piece in nearly every enterprise AI initiative that has quietly underperformed in the last three years.

The substrate isn’t the problem. The fitness function is.


The Evolutionary Frame

Step back from the model-collapse discourse for a moment and look at how biological information actually evolves. You start with a noisy substrate — DNA replication is famously imperfect, mutations are common, most are neutral or harmful, a few are useful. Replication alone doesn’t produce intelligence. Replication plus selection pressure does. The selection layer is what turns noise into signal over generations.

The same logic applies to the corpus of human knowledge. Humans produce an enormous noisy substrate — most of it forgettable, some of it wrong, some of it brilliant. Pre-AI, the selection mechanisms were slow and lossy: peer review, citation networks, market validation, replication studies, professional reputation, the eventual filtering of textbooks and canonical references. These mechanisms work, but on timescales measured in decades, and they’re notoriously biased toward institutional gatekeeping rather than truth.

AI changes the cycle time and the carrying capacity of the selection layer. A correctly-built AI system applied to the human corpus can:

  1. Read more of it than any individual human can read in a lifetime.
  2. Detect contradictions, replication failures, and citation chains across domains.
  3. Synthesize cross-domain patterns invisible to specialists.
  4. Generate candidate hypotheses that get tested against external reality.
  5. Feed validated outputs back into the corpus as a higher-quality next-generation substrate.

That last step is the evolutionary one. It’s also the step that goes wrong. If “validated” means the model agreed with itself, you get collapse. If “validated” means the model’s output survived contact with grounded structure, causal reasoning, persistent verifiable memory, and external agentic checks, you get compounding.

The collapse literature — Shumailov and colleagues’ work on model collapse, the broader synthetic-data degradation findings — is empirically correct about ungrounded recursive training. It’s also describing a strawman implementation that no serious production system should use. The systems that have actually demonstrated multi-generational compounding (AlphaFold, AlphaZero, FunSearch, AlphaProof) all have one thing in common: they pair the generative layer with a verification mechanism that lives outside the model. Protein folding gets validated against physical reality. Self-play games are validated by the rules of Go. Mathematical conjectures get validated by formal proof. The model proposes; something else disposes.

This is the entire premise of the Augmentation Stack, and it’s the entire premise of what serious knowledge management has always done.


The Four Layers

A production AI system that compounds rather than collapses needs four layers running in concert. Almost no enterprise deployment I’ve reviewed in the last two years has all four. Most have one. Some have two. The ones that ship with all four are the ones still working a year later.

Layer 1 — Structured Retrieval Grounding

This is the knowledge engineering layer, and it’s the one most teams skip because it looks like overhead. Taxonomy, ontology, entity resolution, schema design, controlled vocabularies, knowledge graphs — the unglamorous structural work that determines whether a retrieval system can actually find the right thing.

The default RAG pattern — chunk your documents, embed them, drop them in a vector store, retrieve top-k by cosine similarity — is the architectural equivalent of throwing your entire filing cabinet on the floor and asking someone to find the right page by squinting. It works for trivial use cases. It fails the moment your corpus has any of the following: ambiguous entity references, polysemous terms, temporal updates, hierarchical relationships, or domain-specific jargon. Which is to say, it fails for every real organization.

The grounded version uses a hybrid retrieval architecture: dense vectors for semantic recall, sparse retrieval (BM25) for keyword precision, an entity resolution pass that disambiguates references against a knowledge graph, and a re-ranker that uses graph relationships to score candidate chunks. Tools that show up in production stacks doing this well: Neo4j or Apache AGE for the graph, Elasticsearch or Weaviate for hybrid retrieval, spaCy or GLiNER for entity recognition, rapidfuzz and dedupe for entity resolution, sentence-transformers for embeddings, and Cohere Rerank or a fine-tuned cross-encoder for the re-ranking pass.

Here’s what that looks like at a sketch level:

from sentence_transformers import SentenceTransformer, CrossEncoder
from neo4j import GraphDatabase
import spacy

class GroundedRetriever:
    def __init__(self, graph_uri, index_name):
        self.encoder = SentenceTransformer('BAAI/bge-large-en-v1.5')
        self.reranker = CrossEncoder('BAAI/bge-reranker-large')
        self.ner = spacy.load('en_core_web_trf')
        self.graph = GraphDatabase.driver(graph_uri)
        self.index = index_name  # vector index handle

    def retrieve(self, query: str, k: int = 20) -> list[dict]:
        # 1. Entity recognition + resolution against the KG
        entities = self._resolve_entities(query)

        # 2. Hybrid retrieval: dense + sparse, filtered by entities
        candidates = self._hybrid_search(query, entities, k=k * 4)

        # 3. Graph expansion: pull neighbors of resolved entities
        candidates = self._expand_with_graph(candidates, entities)

        # 4. Cross-encoder re-rank
        scored = self.reranker.predict(
            [(query, c['text']) for c in candidates]
        )
        for c, s in zip(candidates, scored):
            c['score'] = float(s)

        return sorted(candidates, key=lambda x: -x['score'])[:k]

This is roughly fifty lines of glue around well-understood components. The hard part isn’t the code; it’s the knowledge graph behind it. Building and maintaining that graph — the entity types, the relationships, the canonical references, the disambiguation rules — is knowledge engineering. It’s the work most organizations underinvest in by an order of magnitude.

Layer 2 — Causal Reasoning Over Correlation

The second layer addresses a problem that most LLM applications quietly ignore: language models are correlation engines. They tell you what tokens tend to appear together, not which factors caused which outcomes. Ask an LLM why your conversion rate dropped last quarter and it will produce a confident-sounding answer that is essentially a vector-space rearrangement of common explanations from its training data. It has no idea what actually caused your conversion rate to drop, because causality is not in the embeddings.

For any AI system that makes recommendations about decisions — and most enterprise AI systems do — this is a critical gap. The fix is to bolt a causal reasoning layer onto the generative layer. Tools in the Python ecosystem worth knowing: DoWhy (Microsoft) for explicit causal modeling and refutation testing, EconML for heterogeneous treatment effects, CausalML (Uber) for uplift modeling, CausalNex for Bayesian network discovery, and Tigramite for time-series causal discovery. For my own work I’ve been building Papilon and PyCausalSim, which extend agent-based causal simulation into territory where observational data alone won’t get you a causal answer.

The pattern at the system level looks like this: when an AI agent is asked to recommend a decision, it doesn’t just retrieve and summarize. It identifies the candidate causal levers, runs a counterfactual simulation against historical data, generates effect-size estimates with confidence intervals, and presents the recommendation with explicit causal claims and refutation tests. The output isn’t “based on similar customers, you should try X” — it’s “under our causal model, X has an estimated effect of Y ± Z, and here are the three assumptions that, if violated, would invalidate this recommendation.”

That’s a fundamentally different epistemic posture, and it’s what separates AI that compounds organizational intelligence from AI that confidently amplifies organizational mistakes.

Layer 3 — Persistent Verifiable Memory

The third layer is memory, and not in the trivial conversation-buffer sense. Most agentic systems treat memory as a sliding context window — the agent forgets what it learned last week because the tokens fell off the back of the buffer. This is fine for chatbots. It’s catastrophic for any system that’s supposed to accumulate institutional knowledge over time.

Persistent memory in a serious sense means an external store that captures: every decision the system or its users made, the context that led to that decision, the outcome, and the provenance trail back to the source documents. It’s the equivalent of an episodic memory layer for the organization. Most of what makes a senior employee valuable is not what they know in the abstract — it’s what they remember about what was tried, what worked, what failed, and why. Organizations that don’t capture this institutional memory lose it every time someone leaves, and they re-learn the same mistakes for years.

Architecturally, this layer uses a temporal knowledge graph or an event-sourced data store with strong provenance. EventStoreDB or a Postgres-backed event log for the substrate, a graph database for the relationships, and a memory-management policy that decides what to elevate from short-term to long-term storage based on outcome verification. I’ve published on a specific architecture for this — Memory-Node Encapsulation, or MNE — that handles autobiographical causality in artificial agents. The general pattern matters more than the specific implementation: if your AI system doesn’t remember what it tried and what happened, it can’t compound. It’s just a clever lookup over a static corpus.

For knowledge management specifically, this layer is what turns a search tool into a learning system. Every query that gets answered, every document that gets used to answer it, every user judgment about whether the answer was right — all of that is signal that should feed back into the next generation of the corpus. The companies running this loop well are the ones whose internal AI gets visibly better quarter over quarter. The companies skipping this layer are the ones whose internal chatbot is the same in 2026 as it was when they shipped it in 2024.

Layer 4 — Agentic Verification Loops

The fourth layer is where the evolutionary pressure actually lives. The first three layers ground the system in structure, causality, and memory. The fourth layer is the loop that takes a generated output, validates it against external reality, and feeds the validated output back as next-generation substrate.

This is the layer that AlphaFold, FunSearch, AlphaProof, and AlphaZero all share, and it’s the layer that most enterprise AI projects entirely lack. Take FunSearch as the cleanest illustration. The system uses an LLM to propose candidate mathematical functions for combinatorial problems. Each candidate is then executed — run through an actual evaluator that scores whether the function solves the problem better than the existing best. Bad candidates get discarded. Good candidates get fed back as in-context examples for the next generation. Over thousands of iterations, the population of candidates evolves toward genuinely novel mathematical results — including, in published work, new constructions for the cap set problem and improved bounds on bin packing.

The pattern here is simple: propose, execute, verify, retain. The model generates candidates; an external mechanism — code execution, formal proof, simulation, A/B test, human review with structured rubric — validates them; only validated outputs survive into the next generation. This is the fitness function. Without it, you have generation without selection, which is drift, not evolution.

In production systems, this looks like:

class VerificationLoop:
    def __init__(self, generator, verifier, memory):
        self.generator = generator
        self.verifier = verifier  # external check: code, formal, sim, human
        self.memory = memory      # persistent corpus from Layer 3

    def evolve(self, problem, generations: int = 100, pop_size: int = 16):
        population = self.memory.seed(problem, n=pop_size)

        for gen in range(generations):
            # Generation: model proposes candidates
            candidates = self.generator.propose(
                problem,
                exemplars=population,  # in-context evolutionary pressure
                n=pop_size,
            )

            # Selection: external verification
            scored = [(c, self.verifier.score(c, problem)) for c in candidates]
            survivors = sorted(scored, key=lambda x: -x[1])[:pop_size // 2]

            # Retention: memory writes only validated outputs
            for cand, score in survivors:
                self.memory.write(
                    problem=problem,
                    candidate=cand,
                    score=score,
                    generation=gen,
                    provenance=self.generator.last_trace(),
                )

            population = [c for c, _ in survivors]

        return self.memory.best(problem)

The verifier in that loop is the entire ballgame. For coding tasks, it’s a test suite. For mathematical work, it’s formal proof. For business decisions, it’s A/B test outcomes. For knowledge management, it’s user feedback combined with downstream task performance. What you cannot do — and what every “we built a chatbot on our docs” project does — is use the model itself as its own verifier. That’s not selection. That’s a hall of mirrors.


Receipts: Where Evolution Worked, Where It Didn’t

The case for the Augmentation Stack is not theoretical. It’s empirical, and the evidence is now substantial enough to argue from.

AlphaFold was trained on the Protein Data Bank — roughly 200,000 experimentally-determined protein structures representing decades of accumulated human work. The model then generated predictions for over 200 million protein structures, which now constitute a corpus an order of magnitude larger than the human-determined substrate. Crucially, those predictions are validated against physical reality through downstream experimental work, and the validated subset becomes training signal for the next generation. This is not corpus collapse. This is evolution under selection pressure, and it has measurably accelerated structural biology across the field.

FunSearch (Romera-Paredes et al., DeepMind, published in Nature, 2023) used the propose-execute-verify pattern to discover new mathematical constructions in the cap set problem and bin packing — improvements over results that human mathematicians had been refining for decades. The verification layer was code execution against problem instances. Without the verifier, the same LLM produces nothing of value. With the verifier, it produces published mathematical results.

AlphaProof and AlphaGeometry extended this to formal mathematical reasoning. AlphaProof reached silver-medal performance at the 2024 International Mathematical Olympiad. The training loop relies on Lean as the verification mechanism — proofs that don’t typecheck are discarded; proofs that do become next-generation training data.

AlphaZero is the cleanest evolutionary case study. Self-play under fixed game rules generates an arbitrarily large training corpus from zero human data, with the rules themselves serving as the fitness function. The result is superhuman performance in Go, chess, and shogi from scratch.

The negative cases — the model collapse literature — are equally instructive. Shumailov, Shumaylov, Zhao, and colleagues showed in their 2024 Nature paper that recursive training on model-generated text without filtering leads to progressive degradation of the output distribution, with the tails of the distribution disappearing first. This is real and important. It’s also a description of what happens when you remove the verification layer — exactly the implementation pattern the Augmentation Stack rules out. The collapse paper is not evidence against evolutionary AI; it’s evidence for why the fourth layer is non-negotiable.

The pattern across all of these results is consistent. AI without external verification collapses. AI with external verification compounds. The substrate is irrelevant in either case. What determines the trajectory is the architecture.


Bringing It Home: The Organizational Knowledge Corpus

Now scale all of this down to the enterprise.

Every organization is sitting on its own version of the human corpus. Confluence pages going back a decade. Slack archives. Jira tickets and post-mortems and design docs. PRDs and sprint retros. Customer support transcripts. Sales call recordings. Engineering RFCs and architecture decision records. The 47 different versions of “the onboarding doc” that nobody can find. The institutional knowledge in the heads of senior employees who are about to retire.

This corpus is the organizational substrate. It is full of contradictions, outdated information, undocumented decisions, tribal knowledge, abandoned experiments — and kernels of genuine institutional wisdom that would compound enormously if the organization could actually access them. It is exactly analogous to the broader human corpus, just narrower and more proprietary.

What most companies have done with this substrate in the last two years is the architectural equivalent of throwing it on the floor and squinting. Bolt an LLM onto the docs via vanilla RAG. Ship it. Watch it confidently reproduce the contradictions, hallucinate around the gaps, and surface the outdated SOP from 2021 instead of the corrected one from last quarter. After six months, the chatbot project is quietly downgraded to “good enough for FAQs.” After twelve months, it’s mostly forgotten. The organizational corpus has not improved. The institutional intelligence has not compounded. The slop has been retrieved with greater fluency, which is not the same as being elevated.

The Augmentation Stack, applied at the organizational level, is the architecture that turns the corpus into a compounding asset. And every layer maps directly onto a knowledge management discipline that has existed for thirty years, just with newer tools.

Layer 1 (Structured Retrieval Grounding) is taxonomy and ontology work. It’s defining the entity types that matter to the business, building the controlled vocabulary, designing the schema, doing the entity resolution against canonical sources, maintaining the knowledge graph. This is the work knowledge engineers and information architects have always done. The tools have changed — Neo4j and dbt and Great Expectations instead of TopBraid and Protégé — but the discipline is continuous. The companies that did this well before AI are the companies whose AI works now. The companies that skipped it are the ones with the chatbot that confidently retrieves the wrong document.

Layer 2 (Causal Reasoning) is decision science and analytics maturity. It’s the discipline of separating what correlates from what causes. Marketing mix modeling, incrementality testing, A/B test design, propensity scoring, instrumental variables. This is the work senior analysts and decision scientists have always done. Bolting it onto the AI layer means an enterprise system that can answer not just “what tends to be associated with retention” but “what would happen if we changed this specific lever, with this confidence interval.” That’s the difference between a dashboard and a decision support system.

Layer 3 (Persistent Memory) is records management and lessons-learned culture, instrumented for machines. It’s capturing every meaningful decision with its context, outcome, and provenance, in a form that can be queried by both humans and agents. This is the discipline that good consultancies have always practiced — the after-action review, the project retrospective, the win/loss analysis — formalized into a memory system that lives outside any individual employee’s head. Tools: an event-sourced store, a temporal knowledge graph, and a memory policy that promotes validated decisions into long-term retention.

Layer 4 (Agentic Verification) is the discipline of grounding AI outputs against measurable outcomes. Every recommendation the system makes, every answer it produces, every action it takes gets paired with a downstream outcome signal. The signal feeds back into the corpus. Outputs that lead to good outcomes get reinforced. Outputs that lead to bad outcomes get filtered. This is, in its essence, the scientific method applied to organizational learning, with AI as the proposal mechanism and reality as the verifier.

When an organization runs all four layers in concert, the corpus genuinely compounds. The knowledge graph improves as new entities and relationships are validated. The causal models tighten as more decisions accumulate evidence. The memory grows richer as more outcomes are recorded with provenance. The verification loop sharpens as more signals connect outputs to consequences. Each generation of the corpus is measurably more useful than the last. The organization’s collective intelligence — distributed across documents, data, and decisions — actually evolves.

This is what knowledge management was always trying to do. The pre-AI tooling made it heavy and slow. The AI augmentation makes it tractable for the first time. But the discipline — the structural, semantic, causal, and verificational work — is the entire game. Without it, AI is a fluent slop-retriever. With it, AI is the selection mechanism that turns the substrate into something compounding.


What This Means for Knowledge Management Roles

The implication for anyone building or hiring for knowledge management functions in 2026 is direct.

The traditional knowledge management role — librarian-adjacent, document-centric, focused on findability and curation — is being absorbed into a broader role that combines knowledge engineering, applied AI, and decision science. The job is no longer “make the documents searchable.” The job is “architect the four-layer system that turns the organization’s substrate into a compounding intelligence asset.” That is a substantively different role, with substantively different skills, and most organizations don’t yet have job titles that match it.

The skill stack that matters: ontology and taxonomy design; entity resolution and graph databases; hybrid retrieval architecture; embedding models and vector stores; causal inference and experimental design; agent frameworks and tool orchestration; memory architectures and provenance tracking; evaluation methodology; production engineering for AI systems. No one person will be world-class in all of these, but the Knowledge Engineer or Knowledge Architect role of the next five years is the person who can credibly speak to all of them and execute on most of them.

The organizations doing this well — and there aren’t many yet — are pulling their knowledge engineers up the org chart, often into a Director of Knowledge Engineering or Head of AI-Knowledge Systems role that reports into either the CTO or the Chief Data Officer. The reporting line matters. Knowledge engineering placed under marketing or content operations stays small and tactical. Placed under engineering or data leadership, with a mandate to architect the corpus as a strategic asset, it becomes the durable competitive advantage.

If you’re an executive deciding whether to invest in this function, the question to ask is not “do we need a chatbot.” The question is “is our organizational corpus compounding, or is it accumulating?” If your institutional knowledge is just piling up — in Confluence, in Slack, in Salesforce, in the heads of senior employees — without any architecture for selection, validation, and feedback, you’re losing the compounding curve. AI without the stack will not save you. AI with the stack will widen the gap between you and your competitors over generations of the corpus.

If you’re a practitioner deciding where to invest your career, the answer is the inverse. The market is going to need a lot of people who can build the four layers. There aren’t many of us yet. The window for becoming one is open.


Generation Zero

We are at generation zero of a multi-generational compounding process. The organizations that get the architecture right now will own the resulting intelligence gradient for decades. The organizations that ship vanilla RAG over a messy corpus and call it done will, in five years, look back at this moment the way companies in 2010 looked back at the moment they decided not to take their data warehouse seriously.

The slop is not the problem. The slop has always been there. What’s new is that, for the first time, we have the architectural means to build a serious selection layer over it — to turn the noisy substrate of human output into a corpus that genuinely compounds. The organizations doing this well are using AI not as a remix engine but as the evolutionary pressure that elevates their accumulated knowledge into something more accurate, more useful, and more capable each generation.

The substrate evolves under selection. The selection layer is the architecture. The architecture is the work.

That’s the job.


Brian Curry is an applied AI researcher and the founder of Vector1 Research, an independent lab focused on knowledge engineering, causal inference, agent evaluation, and the architecture of compounding organizational intelligence. He is the author of open-source frameworks including MeaningFlow (semantic content modeling), Papilon (causal inference and complex systems simulation), and Memory-Node Encapsulation (autobiographical memory architecture for agentic systems). He writes regularly on applied AI, knowledge architecture, and decision science.

Connect on Medium · GitHub · LinkedIn

Related research