The Domain Knowledge Network

A new layer of the organization that owns what it intends

Organizations have always treated domain knowledge as an input. Someone provides requirements, someone else builds them, and the assumption is that knowledge travels in a straight line from the business to the team. The review meeting is where that assumption goes to die: the compliance expert sees the finished work for the first time, finds the policy constraint the team never knew existed, and everyone in the room experiences the encounter as failure. The failure actually happened months earlier, at kickoff, when the knowledge was not in the room.

That was tolerable when teams built slowly and had time to discover what they did not know. When a team builds an increment per day, missing knowledge on three days out of five means 60% of the team's capacity is rework.

The Domain Knowledge Network is the structural answer, a new layer of the organization rather than a practice bolted onto an old one. It is a governing layer, not a help desk, and not a department. A department has a manager and a queue, and knowledge that waits its turn arrives too late. A layer runs through everything, named, funded, and wired to the work.

And what it owns runs deeper than a review function. The network holds what the organization intends. Not the meaning of its documents, the intention behind them, carried as living domain knowledge and translated into deliverables that add value for the people the organization touches. Correctness is the daily face of that ownership, and it has two faces of its own. Right against the rules, and right about what customers value. The Intent Architect engineers how intent moves. The network holds what intent is made of. The Decision Owner owns the outcome.

The claim has old backing. Aristotle, in the Physics and the Metaphysics, held that a made thing is intelligible through its telos, the end it exists for, and that the form of an artifact lives in its maker before it lives in the material. A knife means cutting because cutting is what it was made for. Grice, in a 1957 paper titled simply Meaning, made the modern version exact. Meaning is derived from intention, and what words mean is constituted by what their speaker intends them to do. An organization is a made thing, a network of commitments in language, so its meaning is downstream of its intention. The model has a word for a declared telos. An outcome, the condition that must become true. That is the dependency the whole model is built on. The network holds the intention, the Intent Architect engineers the meaning it becomes, and the fleet executes the expression. Intention upstream of meaning, meaning upstream of text.

Governance arrives as knowledge on the way in, rather than as a review queue on the way out. This single shift, from post-build review to pre-build injection, is what makes daily acceptance possible in a regulated environment.

Machine speed raises those stakes from efficiency to survival. A fleet propagates whatever enters it with perfect fidelity, including a wrong assumption, so the only place to catch an error cheaply is before the build, which is exactly where the network stands.

The three verbs of the Domain Knowledge Network: Inject, Encode, Return
The three verbs of the Domain Knowledge Network: Inject, Encode, Return

The reach the owner does not have

When execution stops being the constraint, domain context becomes the scarce resource. Every daily cycle depends on the spec being correct, the criteria being checkable, and the constraints being known before the build starts.

The Decision Owner handles most of this, because they are a domain expert embedded in the team. That is the design point of the role. But no single person carries all the knowledge a portfolio needs. A pricing expert's Effort runs into a disclosure rule. An operations outcome hits a policy constraint. A data migration touches privacy. The network exists for that reach: the knowledge the owner does not carry.

If a team is calling the network for questions its own Decision Owner could answer, the wrong person was named as owner. That is a naming failure fixed at formation, not a network failure.

The guild

The network draws from every function holding institutional knowledge the portfolio needs: policy, compliance, data, the business analysts who carry deep process knowledge, and the customer-facing people in research, service, support, and sales who carry the evidence of what customers value. Members stay in their home functions. Network membership is an additional, named, funded commitment of 20 to 30% of their week, released by their home officer and paid for by the portfolio. And the functions are knowledge streams, not job titles. People map onto them in combinations, a compliance lead who also holds policy, an analyst who carries domain and data, and a stream may have several holders. The floor is that every stream has at least one named holder and no stream depends on exactly one person for long. A small guild of three or four people can cover every stream between them. Not volunteered. See Knowledge Investment for why the funding is non-negotiable.

Every expert floats, and none are dedicated. Dedicating an expert to one team means the portfolio needs as many experts as it has teams. Floating them means it needs as many as peak demand requires, which is far smaller. The rota is set at weekly Flow Council calibration, so expert availability is planned alongside capacity rather than begged for in the moment. The one exception is the Decision Owner, pulled from this same guild and seated with one team for most of the week, because someone has to be present to accept every single day. The rest of the owner's week stays in the business on purpose. The knowledge that made them worth naming is perishable, and it is refreshed only by doing the business.

A day in the life

The guild is also where Decision Owners come from, and the staffing path is deliberate. When an Effort clears No Owner, No Now, the Flow Council looks at the guild rather than the org chart, because the qualification screens are mostly a description of a guild member in good standing. The owners are a standing job family, membership preceding any Effort, and intake assigns rather than recruits. The sponsoring officer funds the assignment, and the network's deepest holder of that domain becomes the crew's resident judgment. At least one owner per Effort, two or three where the size justifies it, and each owner on one Effort at a time.

The deployed owner runs one job with two seats. The embedded majority of the week faces delivery, the spec and the daily acceptance. The remainder stays in the business as the scouting seat, out where the business touches people, listening for what should be built next. The posture is the atrophy defense in daily form. Qualification decays on the domain's clock, and only time in the business winds it back.

The tour ends at the guild. When the Effort completes, the owner returns entirely, carrying the Effort's questions, patterns, and customer signal home as the richest Return the network receives. Embedding is a tour, not an emigration, and an owner who lingers in delivery between outcomes is quietly converting into a delivery person carrying last year's domain, which is the extraction failure arriving by a politer road.

The profile of the guild

Two things describe every seat on the guild, and neither is a job title.

The first is disposition. Guild people are knowledgeable business people with the scout's wiring, never off duty, always tracking what customers care about, which is the same thing as what is good for the business, which is what value is. The Decision Owner's release formalizes that posture as 40% of an owner's week, but for the guild at large it is not a schedule. It is how these people already watch the business, and it is why demand, briefs, and corrections all trace back to their watching.

The second is context engineering. The guild's knowledge reaches a fleet only through written, structured artifacts, so every seat needs the fluency to front-load authorship. The outcome brief that states the condition, the Effort specs that describe the need, the acceptance criteria a check can be written against. That is the business half of the authorship cascade, drafted with spec agents at the guild's side and finished before the Fleet Lead decomposes it into the technical specs that drive the fleet. A guild member who can only explain in meetings is running the old layer. One who can put the need into a spec is running this one.

Inject, Encode, Return

Inject. The network works on a push model. Each evening, daily planning names the expert tomorrow's spec needs. Each morning, the right expert reaches the right team before anyone has to ask. A typical contribution is a 15 to 30 minute working session, not a review cycle, not a half-day workshop. The specialist hands over the constraints and validation criteria the work must satisfy, and the team builds to the constraint from the beginning instead of discovering it at the end. The rework this prevents costs an order of magnitude more than the thirty minutes of expert time.

Encode. The step that makes a floating guild viable is not the injection. It is what happens immediately after. The expert's criteria are encoded into the harness, and their context joins the knowledge graph. From that moment their judgment runs on every push, for every team, without the expert in the room. Explaining the answer to the people in the room is necessary and not sufficient, because people rotate and memory fades. If nothing outlives the conversation, the network is consulting rather than governing, and the same question comes back next month. And encoding stores enforcement rather than replacing the expert. A check enforces what was foreseen. The guild notices what was not, and noticing is the part that stays human.

The encoding pattern is concrete. The expert states the constraint in checkable form. In a lending business, that means not "loans must comply with fair lending regulations" but "no rate differential greater than X basis points between demographic groups with equivalent risk profiles, computed using method Y." The test agent turns it into a harness check that runs on every push, whether or not the team knows the constraint exists. And the reasoning, the regulatory source, and the edge cases enter the knowledge graph so the next team gets the full picture. After that, the expert is needed only when something genuinely new arises.

Return. Questions, edge cases, and patterns the expert did not anticipate flow back from the teams and update the playbooks the next team receives. This is what makes the network compound rather than merely serve. Budget a monthly two-hour network session for absorbing what came back. Skip it and the network degrades into a rota of interruptions.

The three verbs prevent the same queue in different ways. Inject pushes current judgment to the work before the build. Encode makes the repeatable part available without another meeting. Return carries what was learned back in. Without Return, the network distributes knowledge. With it, the organization learns.

The health test of the whole thing fits in one sentence: expert hours per outcome trend down while coverage of their constraints trends up. If both are flat, encoding is not happening.

The customer stream

Most of the guild guards correctness against the rules, and rules move slowly. A policy constraint encoded last year is probably still a constraint. The customer seat is different in kind. What customers value decays in months rather than years, and it is the one stream where an organization is most tempted to substitute its own consensus for evidence. Every enterprise believes it knows its customer. What it usually knows is what its customer wanted the last time anyone honestly checked.

The network treats customer knowledge with the same three verbs, plus one added discipline. Evidence of what customers value enters the outcome brief when the brief is authored, cited and dated, the way a policy constraint enters a spec. It is encoded into the knowledge graph with its date attached, so the next brief can tell current knowledge from last year's customer. And what live work surfaces, support themes, usage patterns, acceptance evidence, returns to the network like any other edge case.

The rule is short. Evidence, not assumption. If nobody can point to where a customer said it, showed it, or did it, the brief records an assumption to be tested rather than a fact to build on. A wrong guess about the customer used to have months of meetings to get caught in. Now the fleet executes the guess with perfect fidelity, the same day. Internal consensus is to customer truth what consulting is to governing.

Customer means whoever the organization exists to serve, and the weighting is not equal. The customers who matter most are outside the walls, the people whose dollars keep cash flowing, or the public an agency was chartered for. An internal owner's chain of service traces out to them in the end, and a chain that cannot find its way to anyone outside is not serving a customer. It is overhead defending itself.

This stream has its own health test: the customer evidence behind each active brief stays dated and recent. When the dates age, the network has started guessing.

The failure modes

Help desk vs network: reactive consulting with rising expert hours vs encoded governance with declining expert hours
Help desk vs network: reactive consulting with rising expert hours vs encoded governance with declining expert hours

The help desk. The most common failure. Experts are pulled in reactively after teams stall, arriving in the afternoon to answer questions that should have been settled before the build started. Restore the push model: daily planning names the expert, the rota plans the availability, the expert arrives before the question is asked.

The expert who explains but does not encode. Their contribution is perishable, and the next team in the same domain needs the same expert for the same conversation. Make encoding non-negotiable: every contribution leaves at least one harness check and one knowledge graph entry behind. This is how a small guild governs a large portfolio.

The expert who leaves. The highest-risk event in the knowledge model. An expert who leaves after encoding leaves executable checks and documented context. An expert who leaves after only explaining leaves nothing. You never know when the departure risk will materialize, so encode everything, every time.

The brief written from the house. Every seat on the guild was consulted except a customer. The brief reads confidently, cites nothing anyone could be shown, and the fleet builds it beautifully. The tell is an outcome accepted for weeks whose usage numbers never move. The correction is the citation rule. Briefs cite dated customer evidence, and a brief that cannot is carrying assumptions, which are legitimate to build on only when they are named as assumptions.

The overloaded expert. Every team needs the same person simultaneously. The correction is not asking them to work harder. It is encoding faster, so their contributions persist and reduce future demand. It may also mean the portfolio genuinely needs a second expert in that specialty.

Its place in the Model

In The AI-Native Operating Model™, the Domain Knowledge Network sits across the bottom of the model in green, spanning the full width. It has three labeled verbs: Inject on the left (knowledge flows in at spec time), Encode in the center (knowledge becomes checks and context), and Return on the right (learning flows back from teams).

The network connects to:

Read the essay The Knowledge Layer for where the layer comes from and why it was never funded. Read the Domain Knowledge Network white paper (PDF). Return to the Model to see how the network connects to the rest of the system.