Knowledge Architecture Beyond the Single Consumer
When knowledge becomes an interface
A platform now explains itself to developers, agents, auditors, and software that acts before a human can repair an ambiguity. Each consumer needs a different interface. All of them need compatible beliefs about what the system does, where the claim applies, who stands behind it, which version it describes, and how to check it.
Knowledge architecture is the closed-loop design of that relationship. Responsible sources represent relevant system state as scoped assertions and project them for declared consumers. Recorded outcomes then supply evidence that can support, qualify, contest, or supersede those assertions.
Working thesis
Reliable knowledge systems preserve material meaning across different projections and reconcile those projections against observed outcomes.
This page presents a design synthesis and an illustrative capability. Its claim envelope, projection invariants, and measures are implementation proposals awaiting comparative validation.
01 · The problem
One system fact, three chances to drift
Consider one illustrative rule: the v2 upload endpoint rejects decoded payloads above 10 MB, defined here as 10,000,000 bytes after transport decoding. A developer needs a plain-language limit and recovery path. An agent needs a typed boundary before tool selection. An assurance reviewer needs the requirement, owner, release, and test result. The material fact is shared; its useful form changes with the decision.
When teams maintain those forms as independent artifacts, each can begin accurately and still diverge after a release. A guide says 10 MB, a manifest still declares 5 MB, and a control checklist omits the version. Duplicate prose creates a maintenance problem. Divergent truth conditions create an epistemic one.
Developer guide
10 MB
current
Agent manifest
5 MB
stale
Assurance check
10 MB
version missing
“Single-consumer coupling produces rebuild cycles” is shorthand here for a conditional mechanism. Translating a new interface from artifacts written for a previous decision context can produce a rebuild cycle. Under that condition, each new consumer may trigger another rebuild. A shared assertion layer changes the work: teams model the material claim once, preserve its coordinates, and govern each projection against that record.
Existing information architecture already supports modularity, reuse, metadata, and multiple renderings. DITA explicitly supports different deliverables from shared content (OASIS DITA Technical Committee 2026). OpenAPI describes interfaces for people and computers (OpenAPI Initiative 2024). The new threshold appears when a knowledge artifact participates in operational selection, execution, assurance, or recovery. Such an artifact needs interface-grade semantics, versioning, provenance, failure states, and observation.
When a knowledge surface can cause action, it becomes part of the system's control surface.
Authorization remains with policy and execution systems. The knowledge surface shapes what a consumer believes those systems permit, require, and produce.
02 · The model
The unit of architecture is a claim envelope
Pages are delivery surfaces. The durable unit beneath them is a scoped assertion: a proposition with enough coordinates for another reasoner to interpret, evaluate, and trace it. A claim envelope gives that assertion an address and carries its conditions wherever it travels.
Epistemic interoperability lets different consumers form scoped, current, and traceable beliefs from shared assertions. Their projections are compatible when they do not contradict one another about the material invariants, even if consumers draw different task-specific conclusions.
Illustrative claim envelope
JSON{
"id": "files.upload.max-size",
"type": "specification",
"assertion": "POST /files rejects decoded payloads above 10,000,000 bytes with HTTP 413.",
"scope": {
"interface": "Public Upload API",
"operation": "POST /files"
},
"authority": "API platform team",
"validity": {
"systemVersion": "api-v2",
"effectiveFrom": "2026-08-20"
},
"constraints": [
"10 MB means 10,000,000 bytes, measured after transport decoding"
],
"verification": {
"method": "conformance test",
"record": "upload-limit-v2"
},
"status": "confirmed"
}Identity
Which assertion is this?
A stable address lets every projection, test, and revision refer to the same object.
Assertion and type
What is being asserted?
Observation, specification, policy, and promise carry different evidentiary obligations.
Scope
Where does it apply?
Interfaces, actors, configurations, jurisdictions, and boundary conditions prevent accidental generalization.
Authority
Who stands behind it?
The responsible source and approval state remain visible when the assertion travels.
Validity
For which state and time?
System version, effective interval, and supersession links bind meaning to the state being described.
Constraints
Which conditions change the meaning?
Limits, preconditions, exclusions, failure semantics, and uncertainty stay beside the assertion they govern.
Verification
How can it be checked?
A test, record, observation, or cited source gives the consumer a route from assertion to support.
Status and conflict
What is its epistemic state?
Confirmed, disputed, unknown, withheld, superseded, and withdrawn are explicit states rather than silent gaps.
The envelope is an intermediate model, not a replacement for DITA, OpenAPI, MCP, JSON Schema, W3C PROV, or domain-specific assurance formats. Teams can serialize these fields into existing standards and retain local extensions where the decision requires them.
03 · Consumer projections
Different interfaces can preserve the same material assertion
Every projection removes detail. A useful human explanation, compact tool schema, and assurance record emphasize different relations. Knowledge architecture decides which losses are safe for a declared decision and which qualifiers must survive.
A summary carries obligations. It may reduce resolution while preserving scope, constraints, uncertainty, and a route to deeper support. Projection fidelity names the correspondence between a source assertion and the material meaning represented in a view.
Human guide
Upload size
Help a developer prepare a valid request and recover from failure.
Assertion files.upload.max-size The api-v2 Public Upload API accepts decoded payloads up to 10 MB (10,000,000 bytes). POST /files returns HTTP 413 above that decoded limit. Authority: API platform team · Effective: 2026-08-20 · Status: confirmed Verification: conformance record upload-limit-v2
Decision supported
Resize, split, or reject the file before submission.
Invariant across all views
Meaning
The material proposition and its qualifiers survive.
Coordinates
Scope, authority, system state, and time remain explicit.
Trace
The projection points back to its assertion and support.
Absence
Unknown, disputed, and withheld fields remain visible states.
Software engineering already treats consistency among multiple views as a problem that requires explicit relations and periodic restoration. Distributed work makes temporary inconsistency likely, which makes unrecognized inconsistency the dangerous state (Stevens 2020). Knowledge projections need the same discipline, with semantic invariants defined around the decisions each view supports.
04 · Closed-loop architecture
A knowledge system should reconcile with reality
Publishing completes a delivery step. Operational knowledge remains open until accountable teams can compare assertions and projections with recorded outcomes, investigate discrepancies, and update or dispute the responsible record. The loop makes that maintenance observable without treating any observation as self-interpreting.
01
System state
Accountable sources select relevant configuration, code, policy, and observations.
02
Claim envelope
A scoped assertion with authority, validity, constraints, and support.
03
Projection
A view shaped for a declared consumer and decision context.
04
Belief and action
Selection, interpretation, execution, review, or escalation.
05
Evidence and reconciliation
Recorded outcomes support, qualify, contest, or supersede the assertion.
Design consequence
Every omission delegates a decision to the consumer's default.
An explicit unknown invites a question, safe rejection, or escalation. A silent gap invites each consumer to supply its own assumption. Structured absence belongs in the model because it changes behavior.
05 · Agent application
DNCE turns the envelope into an execution lifecycle
Declaration, Negotiation, Contract, and Evidence describe the questions an agent must resolve from discovery through reconciliation. DNCE applies the shared claim layer across an agent execution lifecycle without creating a parallel knowledge system.
Negotiation has a literal role here. The consumer supplies task constraints. A provider or broker returns compatible options or structured mismatch reasons. A local orchestrator can apply the same comparison semantics without a network exchange.
Declaration
What is exposed?
- Reads
- Identity, assertion, scope, authority, validity
- Produces
- A discoverable capability with explicit boundaries
Negotiation
Does it fit this task?
- Reads
- Consumer constraints, cost, latency, permissions, alternatives
- Produces
- A fit decision or a structured mismatch reason
Contract
What governs execution?
- Reads
- Inputs, outputs, state changes, errors, retry and idempotency terms
- Produces
- An execution agreement the consumer can interpret
Evidence
What happened?
- Reads
- Result state, event record, validation output, causal identifiers
- Produces
- A checkable outcome and a route back into reconciliation
MCP already provides names, human-readable descriptions, input and output schemas, structured results, and behavioral annotations. Its specification also says that tool annotations are hints and should not drive decisions when the server is untrusted (Model Context Protocol 2025). DNCE begins at that boundary: declarations support discovery, while negotiation, contract, policy, and evidence determine whether and how an agent should act.
06 · Knowledge as a control surface
Knowledge surfaces govern through defaults and expectations
Language and metadata shape recognition, selection, recovery, and migration. Contracts establish expectations. Code and policy enforce authority. Keeping those levels distinct makes the governance claim useful without turning a description into an access-control mechanism.
| Surface | Decision shaped | Design obligation |
|---|---|---|
| Description | Whether a consumer recognizes and selects a capability | Separate purpose, authority, and risk in direct language. |
| Missing field | Which default fills the gap | Encode unknown, inapplicable, withheld, and unsupported states. |
| Error model | Whether a consumer retries, revises, aborts, or escalates | Publish typed failure states and bounded recovery paths. |
| Version signal | Whether prior assumptions remain valid | Bind every material projection to system state and supersession. |
Governance is distributed across several actors. Domain owners establish assertions, while knowledge stewards preserve coordinates and projection rules. Client applications and operators own trust policy, approval flows, and local logs. Servers enforce access controls. Outcome records should preserve identifiers that let investigators locate where a mismatch first appeared and test which layer introduced it.
07 · Put it to work
Start with one brittle decision
A team can test this architecture without rebuilding its publishing stack. A one-week pilot should follow a small set of consequential assertions from source through two projections and one observed outcome.
- 01
Choose five consequential assertions
Start where a wrong belief changes selection, cost, safety, compliance, or recovery. A page inventory can follow later.
Done when: Each assertion has a named consumer decision and failure cost.
- 02
Build the envelopes
Extract identity, type, scope, authority, validity, constraints, verification, status, and known conflicts from existing sources.
Done when: A reviewer can see both what is known and what remains unresolved.
- 03
Produce two projections
Render one human view and one machine view from the same envelopes. Preserve consumer-specific language and structure.
Done when: Both views retain the material invariants required for their decisions.
- 04
Add conformance checks
Test envelope completeness, projection invariants, version binding, links, and any executable behavior that supports the assertion.
Done when: A release fails when a material projection drifts from its envelope.
- 05
Reconcile observed outcomes
Capture mismatches among the record, the projection, consumer interpretation, policy, and runtime behavior. Route each mismatch to its owner.
Done when: The next revision changes the responsible layer and records why.
Pilot question
Can a developer, an agent, and a reviewer correctly select, use, recover, and verify one capability from the same governed assertions without private context?
08 · Measurement
Measure correspondence instead of content volume
Page counts and word counts describe output. The loop needs measures that reveal whether material assertions carry their coordinates, survive projection, match deployed state, and recover from mismatch.
Envelope coverage
material assertions with complete envelopes / material assertions sampled
Shows how much decision-critical knowledge has explicit coordinates and support.
Projection fidelity
material invariants preserved / material invariants tested
Detects summaries, schemas, and views that change the meaning while changing the form.
Temporal alignment
operational projections correctly bound to the system state they describe / operational projections tested
Distinguishes a correct historical record from a stale operational interface.
Verification reach
assertions with a usable verification path / material assertions sampled
Measures whether consumers can move from published language to inspectable support.
Reconciliation latency
median time from detected mismatch to corrected or explicitly disputed envelope and projections
Measures how quickly the system corrects drift or records a legitimate disagreement.
These measures are proposed audit instruments. Their usefulness depends on whether they predict lower selection error, safer recovery, faster integration, or more accurate assurance. Field evaluation must isolate the source of failure among the knowledge record, projection, consumer, policy, and runtime.
09 · Boundaries
What the model preserves, and what it cannot settle
Structure can expose the conditions of a claim and improve the quality of downstream reasoning. It cannot manufacture truth, eliminate judgment, or predict every emergent outcome. The architecture earns trust by making those boundaries operable.
Formalization leaves a remainder
Judgment, experience, and emergent behavior can outrun a schema. The envelope should mark the need for interpretation, an owner, and an escalation path instead of manufacturing precision.
Provenance does not establish truth
Authority and lineage show where an assertion came from. Verification, corroboration, and observed correspondence determine what weight it earns.
Consistency does not require consensus
A shared substrate can carry competing assertions, different authorities, and unresolved conflicts. Epistemic interoperability depends on exposing those relations faithfully.
Shared semantics do not require central ownership
Federated teams can own separate records when they share identifiers, status semantics, provenance links, and rules for reconciliation.
10 · Convergence
One semantic substrate, plural interfaces
Technical writing, API description, agent metadata, disclosure, and assurance remain distinct practices. They converge on a shared engineering problem: preserving material assertions while their form, resolution, and decision context change.
Existing standards supply important parts. DITA separates reusable content from delivery. OpenAPI describes an API surface for people and computers. MCP supplies tool schemas and structured results while drawing a boundary around untrusted hints. W3C PROV provides a common model for provenance and responsibility (W3C Provenance Working Group 2013). Each solves a real layer of the problem.
Reusable topics and multiple deliverables from shared content
Delivery reuse alone does not test whether operational qualifiers survive every view.
A formal API description consumable by people and computers
Source-state binding, evidence, and decision-specific projections still depend on implementation.
Tool schemas, structured results, and behavioral annotations
Annotations are hints; policy, trust, verification, and task fit remain distributed responsibilities.
A common model for entities, activities, agents, and provenance
Provenance supports assessment without proving truth or specifying action semantics.
The new object
The object of knowledge architecture is the correspondence among source state, claim envelopes, consumer projections, and observed outcomes.
The page, manifest, and assurance record remain plural. Shared semantics and a reconciliation loop let them differ without quietly becoming different accounts of reality.
The practical next move is small: choose one brittle decision, model the assertions it depends on, produce two faithful projections, and observe what happens. Repeating that loop reveals which invariants reduce drift, improve recovery, and deserve to become operating requirements.
Sources and status
References
- Model Context Protocol. 2025. “Tools.” Specification revision November 25, 2025. modelcontextprotocol.io. Accessed August 28, 2026.
- OASIS DITA Technical Committee. 2026. “Darwin Information Typing Architecture (DITA) Version 2.0.” dita-lang.org. Accessed August 28, 2026.
- OpenAPI Initiative. 2024. “OpenAPI Specification, Version 3.1.1.” October 24, 2024. spec.openapis.org. Accessed August 28, 2026.
- Stevens, Perdita. 2020. “Maintaining Consistency in Networks of Models: Bidirectional Transformations in the Large.” Software and Systems Modeling 19: 39–65. https://doi.org/10.1007/s10270-019-00736-x.
- W3C Provenance Working Group. 2013. “PROV-O: The PROV Ontology.” W3C Recommendation, April 30, 2013. w3.org/TR/prov-o. Accessed August 28, 2026.
Available for reading as a working draft.
Version 1.0 · revised