The Knowledge Factory

Overview

A customer problem becomes a ticket: evidence compressed, tradeoffs chosen, answer framed. That is the knowledge factory. AI accelerates whatever system exists—hidden queues or shared learning. Engineers can execute its instructions or become factory engineers who improve the line.

What the Previous Articles Establish

This fourth essay builds on three claims:

• Vision and Values: value begins with human stakes and accountable choice, not output.
• Understanding and Bottlenecks: clear context lets more people solve the right problems.
• Truth and Inference: prediction needs stable constraints and feedback; coherence proves neither truth nor meaning.

This essay asks what an organization must build once it accepts those claims.

Core Thesis

A knowledge factory turns learning—not models or agents alone—into reusable problem-solving capacity.

Factory engineers improve the context graph , ontology, workflows, evaluation, observability, and feedback through which future decisions pass. Their unit is the capability producing the next hundred outputs.

Key Terms

1. You Already Have a Factory

Customer experience → evidence → interpretation → priority → design → implementation → verification → release → observed consequence. That path is already a factory.

This system has queues, handoffs, stations, checks, rework, bottlenecks, and feedback. Its design decides what survives, who may question the plan, and where learning goes. AI amplifies clear context or vague tickets, shared learning or fragmented memory, serious evaluation or cosmetic approval. The factory was always there; AI makes its shape consequential faster.

2. The Implicit Factory Turns People into Workers

A small group defines solutions; tickets move downstream; customer context fades; engineers optimize locally. Success becomes output and schedule; learning stays in calls, pull requests, and memory.

An implicit factory keeps queues hidden and decisions gated; an explicit factory makes context, evaluation, and feedback visible. Talented people become bounded workers because they cannot improve the frame or system.

3. A Factory Engineer Improves the Line

A factory engineer improves a class of outputs, not one unit:

• aligning a domain concept across prompts, schemas, APIs, analytics, and UI;
• turning repeated review judgment into an evaluation suite;
• connecting decisions to evidence and outcomes;
• replacing coordination queues with safe self-service;
• making agent failures visible and learnable;
• encoding side effects and escalation boundaries; and
• letting domain experts change systems without routing everything through specialists.

This combines domain knowledge, systems thinking, software craft, teaching, and institutional design. It is a way of working—not a title—across product, research, operations, design, engineering, and leadership.

4. Make Good Judgment Portable

With the same models, a gated company sends framed solutions downstream; AI burdens the gate. A distributed company gives teams evidence, context, boundaries, tools, and evaluations to test locally and escalate only broader-authority choices.

The latter explores more without lowering standards. This distributed solutioning depends on context, decision rights, safety constraints, and evaluation—not unlimited autonomy.

5. Fix the Factory Before Asking AI to Scale It

AI cannot preserve unnamed boundaries, reconcile conflicting contracts, or verify remembered correctness; it consumes structural debt. Make contracts machine-readable and carry domain distinctions across database, API, runtime validation, application types, analytics, and UI.

• schemas can generate types, validators, clients, fixtures, and documentation;
• API specifications can generate request and response types, stubs, and clients;
• database schemas can generate query types, migrations, and policy checks; and
• design systems can generate tokens, components, documentation, and visual references.

The source need not be a particular technology. It must be authoritative enough to own, version, validate, and regenerate. Generated artifacts are materialized views, not competing truths.

Authoritative source → generated contracts → runtime validation → end-to-end verification.

Types expose relationships; runtime checks guard untyped boundaries; tests prove composition. Together they make changes legible enough for AI to propose, check, and correct.

6. Systematize the Whole Chain

Software is one station. Repeated decisions across the chain can become reusable systems:

• design: shared tokens, components, interaction rules, accessibility checks, and visual regression evidence;
• reports: governed definitions, datasets, queries, templates, provenance, and scheduled review;
• engagement: research repositories, support signals, experiments, consent, segmentation, and feedback loops;
• development: schemas, types, tests, build pipelines, release controls, observability, and incident learning; and
• operations: explicit workflows, ownership, service levels, escalation paths, and outcome measures.

Systematize everything that repeats. This does not mean automate every decision.

A system may end in human judgment while preserving inputs, constraints, choice, and consequences for the next cycle.

7. The Knowledge-Factory Stack

The eight-layer stack is an inventory, not a vendor architecture.

In AI-assisted mathematics, a problem and its literature supply context; an orchestrator and specialist agents generate conjectures, lemmas, counterexamples, scripts, and proofs; tests or proof assistants reject candidates; provenance records tools and assumptions. Mathematicians still judge fidelity, significance, and direction. High-volume search helps only with trustworthy verification and human governance of meaning, standards, attribution, and direction.

8. Triggers Open Investigations

A product metric crosses a threshold after a release. PostHog reports a journey drop, Sentry reports errors, and runtime telemetry supplies operating conditions. These observations justify investigation; they do not establish a cause or authorize a code change. This is an illustrative workflow assembled from documented sensing capabilities, not a demonstrated autonomous product.

A trigger should open a hypothesis, not declare a diagnosis.

Translate the signal into an event contract containing:

• source, observation window, baseline, provenance, and uncertainty;
• affected journey, system, release, and owner;
• corroborating and contradicting evidence; and
• permitted next steps, expiry, and links to the underlying observations.

Keep several explanations live: a regression, an intended change with an unexpected tradeoff, or a coincident change elsewhere. Name the observation that could distinguish them. A work record links these hypotheses, their evidence, and the person responsible for the next decision.

Configure thresholds, event identity, deduplication, and cooldowns so repeated alerts do not launch repeated interventions. A trigger may schedule an investigation; the evidence and authority required for a release remain separate. Rules handle exact conditions. Model judgment can help classify bounded ambiguity, while contested goals and exceptions go to the responsible people.

9. Agent DAGs Make Delegation Inspectable

Authorized work becomes a directed acyclic graph (DAG) of scoped tasks. For one investigation, context retrieval and failure reproduction can proceed independently, converge on a hypothesis review, and then feed a proposed change, verification, and an integration decision.

Each node names:

• inputs, selectively retrieved context, and expected outputs;
• tools, permissions, and permitted side effects;
• dependencies, acceptance checks, and evidence to retain;
• an owner and the authority required for the next handoff; and
• retry limits, stop conditions, and recovery or rollback requirements.

The DAG describes dependencies within one work attempt. The feedback loop surrounds that attempt: new evidence can schedule a revised graph or a bounded retry. A loop across attempts does not make the task graph cyclic. Record state durably so interruption or duplicate delivery does not silently repeat a side effect.

Give teams authority to revise local work within their boundary. An integration owner resolves shared dependencies without becoming the mandatory reviewer of every local decision. Escalate changes that alter another team's commitments or exceed the task's mandate.

The graph—not the model—is the durable unit of automation.

Here that means the inspectable work record preserves decisions, dependencies, and outcomes beyond an individual model call. It is an architectural proposal, not a claim about a particular orchestration product.

Executable context turns relevant knowledge into enforceable checks: a definition becomes a schema, an ownership rule an escalation path, and an observed failure a regression case. Historical records remain evidence to consult; they become operating constraints only through an explicit, owned decision.

10. Engineer the Return Path

Loop engineering connects a completed action to the consequence it was meant to produce. Before executing, name the expected effect, observation window, acceptable tradeoffs, outcome owner, and conditions for stopping or reversing the change.

1. Record a signal and the competing explanations it opens.
2. Authorize a bounded investigation and instantiate its task graph.
3. Produce a reviewable artifact with evidence and integration ownership.
4. Apply checks and the appropriate release authority.
5. Observe customer and operational consequences during the stated window.
6. Retain the result, revise the hypothesis, and update the relevant evaluation or procedure.

Verification checks the artifact against known requirements. Outcome evaluation asks whether the action produced the intended effect. A passing test can coexist with a worse customer journey; a recovered funnel can conceal higher support cost.

Bound retries and escalation, define what happens when evidence never arrives, and make delayed outcomes visible. Close the work as inconclusive when warranted. Repeated generation without a stopping rule is an unfinished process, not a learning loop.

Work produces outcomes → outcomes produce evidence → evidence updates context and evaluation → better context can improve the next work.

11. Human Direction Sets the Boundary

A factory retrieves evidence, generates options, exposes inconsistencies, and simulates reactions. It cannot choose the future or whose outcome counts. Evidence narrows the choice; a person makes the accountable wager.

Do not hide judgment behind automation; make it inspectable. For each consequential choice, retain:

• the desired change and whose experience defines its stakes;
• supporting and contradictory evidence;
• assumptions, uncertainty, and rejected alternatives;
• owners, decision rights, and escalation boundaries;
• predictions and disconfirming signals; and
• the revision made after consequences arrive.

Systematize the feedback. Do not automate away the judgment.

12. Retain Learning, Not Just Outputs

The factory compounds only when completed work changes the context available to the next decision:

Evidence → interpretation → choice → action → outcome → revised context.

Organizational memory is more than notes: it links claims to evidence, decisions to owners, experiments to predictions, and outcomes to revisions. Search finds documents; graph context recovers reasoning, dependencies, and needed revisions.

It answers: Why did this matter? What supports or contradicts it? What depends on it? What did we predict? What makes us stop or revise? What did we learn?

Explore the relationship graph → or open the relationship graph editor.

13. Start with One Broken Handoff

Do not begin with a company-wide AI program. Start where context disappears or judgment is trapped in a review queue:

1. Trace customer experience to observed consequence.
2. Expose hidden evidence and decisions.
3. Name stable distinctions and invariants.
4. Turn repeated judgment into tools, workflows, tests, and escalation rules.
5. Let teams frame and test solutions within those boundaries.
6. Instrument outcomes and connect them to the original decision.
7. Promote validated learning into shared context.

The goal is more sound judgment, responsible experiments, and consequences returned to memory—not maximum automation.

14. What Actually Compounds

Durable advantage is the residue of learning. Proprietary data, domain knowledge, ontology, tools, relationships, infrastructure, and network effects become defensible as one customer-value system that improves through use. Owning the parts is not the moat. Compounding them is.

15. Ontology Makes It Coherent; Cognition Makes It Learn

Two disciplines complete the model. The Ontology Factory makes ownership, vocabulary, relationships, constraints, and evidence rules checkable. The Cognitive Factory develops the sensemaking capabilities that guide this machinery: meaningful signals, cognitive reach, and discoverable memory of plans, priorities, decisions, and outcomes. Ontology makes those records interpretable; cognition relates them to the present problem; people choose what is worth pursuing.

Sources

• Sentry, Seer documentation; PostHog, Insights documentation; AWS, CloudWatch alarm actions. Individual sensing and investigation capabilities; the workflow composition is proposed here.
• DORA, Google, 2025 State of AI-assisted Software Development Report. AI as a systems problem amplifying strengths and weaknesses.
• Ikujiro Nonaka, “A Dynamic Theory of Organizational Knowledge Creation” (1994). Continuous knowledge creation as shared capability.
• James G. March, “Exploration and Exploitation in Organizational Learning” (1991). Exploration versus capability refinement.
• Karl E. Weick, Kathleen M. Sutcliffe, and David Obstfeld, “Organizing and the Process of Sensemaking” (2005). Equivocal evidence and provisional models.
• James P. Walsh and Gerardo Rivera Ungson, “Organizational Memory” (1991). Memory acquisition, retention, retrieval, use, and misuse.
• Michael E. Porter, “What Is Strategy?” (1996). Coherent choices and activities, not improvement lists.
• ISO, ISO 9241-210:2019. Ongoing attention to users, needs, and consequences.
• NIST, AI Risk Management Framework 1.0 (2023). Context mapping, measurement, evaluation, governance, and accountability.