Four Types of Knowledge. That's It.

I Didn't Design This

I want to be clear about something: I did not sit down with a whiteboard, draw four quadrants, and declare a taxonomy. That would have been neater. It also would have been wrong.

What actually happened was messier. I had six apps, months of accumulated AI knowledge scattered across CLAUDE.md files, rules directories, and database tables, and I kept running into the same organizational problem. Where does this piece of knowledge go? Which harness owns it? When I write down how to run a CI/CD pipeline, is that the same kind of knowledge as a skydive progression rule? When I define a product roadmap, does it belong next to coding standards?

The answer kept being no. And the reason it was no kept falling into the same pattern.

Every piece of knowledge I created belonged to exactly one of four categories. Not five. Not three. Four.

Build, product, operations, domain — these four types are the taxonomy of AI Knowledge Engineering. They answer the question: what kinds of knowledge does an AI agent need to participate effectively in any process?

The Four Types

Build — the creation process

HOW to make things. This was the first type I recognized, and I got it wrong initially. I thought build knowledge was about software development. Coding standards. Architecture patterns. CI/CD pipelines. TDD workflows.

That was too narrow. Build knowledge is about all creation. How to write a blog post. How to produce a YouTube video. How to design an Instagram carousel. How to structure a marketing campaign. The editorial guidelines for this blog series you're reading right now — that's build knowledge. Content calendars, design systems, coding standards, deployment scripts. If it's about the craft of making digital things, it's build.

The unifying thread: build knowledge answers the question "how do I create this?" regardless of what "this" is.

Product — the management process

WHAT to build. Roadmaps. Specifications. Architecture decisions. Feature definitions. Prioritization frameworks. Each app gets its own product harness because the decisions are scoped to that product. The way2fly roadmap is not the way2save roadmap.

Product knowledge is about decisions and direction. It's the strategic layer. When I ask "should we add voice debriefs to way2fly?" that question lives in the product harness. The answer involves user needs, technical feasibility, competitive landscape, and timeline. None of that is build knowledge, even though it determines what gets built.

Operations — the operational process

HOW to run things. This is the type that tripped me up the longest, mostly because of what I originally called it: "process." The problem with calling one of your four knowledge types "process" is that all four types are processes. Build is a process. Product is a process. I was using the genus as a species — like having a taxonomy of Animals, Plants, Fungi, and Living Things. Confusing and imprecise.

Renaming it to "operations" fixed the ambiguity immediately. Operations knowledge is domain-specific procedural knowledge. Skydive progression rules. Hospitality onboarding procedures. Fitness programming science. Financial budgeting patterns. Manufacturing quality standards.

This is the type that changes completely by industry. A hotel's operations harness has nothing in common with a skydiving school's. A finance operations harness looks nothing like a fitness one. The structure is identical — knowledge, rules, workflows, learnings — but the content is entirely different. That's the point.

Domain — the data process

The raw records. Jump logs. Workout records. Financial transactions. Guest check-in histories. Manufacturing batch records. Per-user, per-entity data. The thing that makes an app personal and useful rather than generic and theoretical.

Domain data is what operations knowledge acts on. The operations harness knows how to progress a skydiver through license levels. The domain harness contains the specific jumps, the specific student, the specific progression. Operations is the playbook. Domain is the game tape.

Searching for the Fifth

I spent real time trying to break this. Four is a suspiciously clean number, and I didn't trust it. So I went looking for knowledge that didn't fit.

Partnership knowledge? How to work with vendors, integration agreements, relationship management. This is relational, and I'll be honest — it sits awkwardly. Currently it lives in either operations or domain depending on context. It's a known gap.

Governance and compliance? Legal requirements, audit trails, regulatory frameworks. This cuts across all four types. Your build process has compliance requirements. Your product decisions are constrained by regulation. Your operations must follow legal procedures. Your domain data has retention rules. Governance is cross-cutting, not a separate type.

Security knowledge? Same pattern. Cross-cutting. Security shapes how you build, what you can ship, how you operate, and how you store data. It's a lens applied to all four types, not a fifth bucket.

Stress-Testing Against the Literature

I'm a practitioner, not an academic. But I wanted to know if I was reinventing something poorly. So I stress-tested the four types against established knowledge management frameworks.

Porter's Value Chain maps well — primary activities land in operations, support activities distribute across build and product. TOGAF's architecture domains align roughly with the four types. Intellectual Capital theory (human, structural, relational capital) maps onto three of the four but highlights something I'm missing: relational capital — the knowledge embedded in relationships between organizations — doesn't have a clean home.

Zack's knowledge taxonomy distinguishes declarative, procedural, causal, and relational knowledge. My four types map to different mixes of these. But again, relational knowledge surfaces as a gap.

The honest assessment: two genuine gaps exist. Relational/Ecosystem knowledge (partnerships, integrations, inter-organizational dynamics) and Governance/Meta-organizational knowledge (compliance, audit, regulatory) don't have clean homes in the four-type system. They'll likely need formal handling as the system scales.

The question is whether they become fifth and sixth types, cross-cutting layers, or sub-types of existing types. The honest answer: it depends on what hurts first. Right now, with six apps and two cortex.ai tenants, the gaps are theoretical. When they start causing real organizational pain, that's when the architecture will need to evolve.

Composable Building Blocks

Here's where the type system becomes practical. Any product is a composition of these four types.

• Developer platform = Build + Product. Tools and decisions about what to build next.
• B2B SaaS = Operations + Domain. Industry procedures applied to customer data.
• Full operating system = all four. Build + Product + Operations + Domain.

cortex.ai is Operations + Domain per tenant. build.ai is Build + Product for orchestration. marco.ai is a hub connecting all four types across every domain. The types are Lego bricks. Products are assemblies.

This is what keeps the system consistent across scales. Whether you're running markdown files for a solo project or federated databases for an enterprise, the four types are the same. The implementation changes. The conceptual architecture doesn't.

What's Different Here

I looked. CrewAI doesn't have a knowledge type system. LangChain doesn't. AutoGen doesn't. The major AI development frameworks treat knowledge as undifferentiated context — you stuff things into a vector store or a prompt, and the categories are whatever folder names you invent.

The four-type decomposition — build, product, operations, domain — with identical internal structure in each (knowledge, rules, workflows, learnings) hasn't been proposed elsewhere in the AI platform literature that I've found. It emerged from practice, from the repeated experience of trying to organize knowledge and discovering that the same four buckets kept appearing.

That makes it the part of harness.os I think is most interesting, and also the part most in need of validation by someone other than me.

The Structure Within

Four types. Same internal structure in each: knowledge, rules, workflows, learnings. Different content. Composable into any product. And scale-invariant — the types work whether you're using markdown files or federated databases.

Now the question was: is this just my personal system, or is it a methodology?