Product Knowledge as Architecture
From Project Memory to Declarative Product Composition
Given an existing library of trusted UI components, can documentation become an authoring surface for composing bounded experiences from them? This paper explores the product-knowledge architecture that would require.
- #context-engineering
- #ui-architecture
- #software-architecture
- #applied-ai
Last revised October 1, 2026
Reading depth
Can documentation author an experience?
Given an existing library of trusted components and actions that engineering built, could documentation become the place where experiences are authored from those parts, with authors describing the task and engineering keeping behavior, state, permission, and policy?
Making that work suggests something larger: the product knowledge in such documents—why a flow exists, what matters, and what to explain—may deserve its own explicit place in the architecture.
An explanation is not a permission
Account review · identity verification has not succeeded
Product knowledge · may guide
Explain the next step
Show why verification matters and when a removal action is relevant.
A task, not a new power
Imagine an account-review screen. A product author can describe its purpose, relevant details, prerequisites, and helpful explanations. A system might one day select existing customer, verification, and restriction tools around that task.
But a description cannot retrieve transactions, verify a person, authorize removal, or invent a verification capability that has not been built.
The question still open
This is an architectural proposal, not a working generator or a case for generating every screen. Product knowledge would need clear ownership, conditions for when it applies, and tests against code and policy.
If those boundaries hold, how much of a repeated workflow could be composed without giving up deliberate design or deterministic control?
Start from a common situation: a product already has a library of trusted UI components, along with the services and actions behind them. Engineering built them, tested them, and owns how they behave. That raises a practical question: could documentation become the place where experiences are authored from those existing parts, so that a product or domain author describes a task and the system assembles it from what engineering has already built?
The ownership line has to be clear from the start. Authors would describe the task: what it is for, what information matters, which actions belong, what must be true first, and what to explain. They would not implement behavior, invent components, retrieve current state, grant authorization, or perform side effects. Behavior, current state, validation, authorization, effects, and governing policy stay with engineering and the application architecture.
A Bounded Composition
Consider an account-review task. Engineering has already built customer identity, account status, transaction history, identity verification, restriction management, and risk escalation. A documentation author could describe the task without implementing any of those mechanics:
Account Review
Investigate a restricted customer account. Show why the account is restricted, what has happened recently, and what the operator may do next under current policy.
Relevant information
- Customer identity
- Restriction reason
- Recent activity
- Verification state
Available actions
- Request identity verification
- Remove the restriction after verification succeeds
- Escalate to risk review
Guidance. Explain unavailable actions through their unmet prerequisites. Never imply an action completed that the application did not confirm.
The document does not retrieve transactions, verify identity, grant permission, or remove a restriction. It contributes intent, relevance, an explanation of what must happen first, and guidance on how the task should be presented. The removal step mentions verification only as a reference: the rule that verification must succeed belongs to policy and is enforced by the application, not by this document.
The example also shows why a component library alone is not enough. Some of what the task needs are views, such as a customer profile. Others are actions with real effects, such as requesting verification or removing a restriction, and they do not map one-to-one onto visual components. For composition to stay bounded, the existing implementation units need to be exposed as trusted capabilities with explicit contracts. A capability may be a view, an action, a bounded interaction, or a bounded service. Its contract states its inputs, the state it requires, who may use it, how it validates, and what effects it can have.
Figure 02
A surface assembled within boundaries
- Current state
- Restricted · identity unverified · no active risk review
- Trusted capabilities
- Profile / status · transactions · verification · restriction action · risk escalation
- Product knowledge
- Purpose · relevance · prerequisites · explanation / composition guidance
- Deterministic policy
- Removal requires verification · escalation permitted while restricted
Select relevant capabilities, order the task, apply guidance, respect state and policy.
Account Review
- Customer profile
- Jordan Rivera
- Recent transactions
- 3 entries, 1 blocked transfer
- Restriction reason
- Identity verification required
- Request verification
- Prerequisite for removal
- Remove restriction
- Blocked: identity not verified
- Escalate to risk
- Permitted while restricted
This is not a staffing proposal or an argument that prose should execute a product. It is an abstraction test. If a domain author can describe much of the desired experience without recreating its mechanics, there may be a useful boundary between the capabilities engineering builds and the task compositions documentation describes. No composition layer or generator has been built or evaluated in this work; Figure 02 illustrates the boundary, not a working system.
A requirement no existing capability satisfies still requires implementation. Composition could only assemble what is already trusted; it cannot make missing behavior real.
The Missing Architectural Home
That account-review description is a kind of artifact most software has no deliberate place for. Ask where a mature system’s implemented behavior lives and the answer is code. Ask where its current facts live and the answer is application state or data. Ask where its valid shape and contracts live and the answer is schemas.
Ask why a flow exists, who it serves, when a capability is relevant, or what should be explained when an action is unavailable, and the answer is less precise. That knowledge may be split across product documents, tickets, UI copy, support material, conditionals, release notes, and the memory of the people who made the decisions.
Figure 01
Give meaning an architectural home
- Implemented behavior
- Code
- Current facts
- Application state / data
- Structure & contracts
- Schemas
- Meaning / intent / explanation
- Product knowledge
- Composition
- Product knowledge + policy + trusted capabilities
- Durable
- Selectable
- Applicable
- Composable
This paper calls that material product knowledge, and it proposes that product knowledge may deserve a first-class architectural home. Context is the wider thread running through this research; product knowledge is the specific architectural object proposed here.
Product knowledge may deserve a first-class architectural home, and if it has one, it may allow parts of an interface to be composed from trusted capabilities rather than imperatively authored.
The home is deliberately narrow. Product knowledge includes task intent, relevance, explanation, policy rationale, references to authoritative prerequisites and rules, and composition guidance. It does not own current facts, governing rules, capability contracts, or implemented behavior. It may explain why verification comes before removal and point to the rule; the rule itself belongs to policy and the capability that enforces it. A first-class home for product knowledge is not a place where all product truth goes.
The problem is not that software has never represented rules or meaning. Rule engines, expert systems, configuration-driven products, model-driven systems, and knowledge graphs all have relevant lineage. The practical change is that software can increasingly interpret structured and semi-structured knowledge written in the language product teams already use.
The proposition is not a new database named context. It is more explicit architectural ownership for knowledge that otherwise survives as an accidental byproduct of implementation.
Durable, Selectable, Applicable, Composable
For a document like the account review to take part in composition, the knowledge it carries has to meet four conditions. Three of them were explored in earlier work. The fourth is what this paper proposes.
Durable. Important knowledge survives the conversation or task that produced it. Decisions, constraints, and product intent persist as versioned artifacts. Explored in From Prompts to Project Memory.
Selectable. Durability without selection produces a larger pile, not better context. A system needs the subset relevant to the task. Explored in Context Engineering for Software Development.
Applicable. Knowledge has conditions. Guidance that is correct for one role, version, product state, or audience may be wrong for another. Explored in Documentation-Driven Adaptive UX, which moved the question into a running interface.
Composable. Proposed here. Knowledge that is durable, selectable, and applicable may also help choose and arrange trusted capabilities into a useful surface.
The step from applicable to composable is the largest one, and the authoring problem shows what it requires. Applicable knowledge says when guidance is true. Composable knowledge must also refer to the capabilities it would arrange, through stable references to their contracts. Those references are necessary but not sufficient. Naming a capability in a document does not make composition work; contracts, capability metadata, a way to look capabilities up, allowed layouts and interactions, and policy constraints all remain unbuilt and untested.
Development-time agents and runtime interfaces are still different consumers. They draw from different projections of product knowledge, with different lifecycles, authority boundaries, and failure modes. The shared idea is not one operational context layer. It is knowledge represented explicitly enough that each consumer can select what belongs to its job.
Authority Belongs to the Concern
A knowledge architecture does not need one universal source of truth. It needs explicit authority for each kind of claim.
Figure 03
Neither code nor docs always wins
This is more accurate than saying either code or documentation always wins. If a governing policy requires identity verification before removing a restriction and the implementation fails to enforce it, executable code does not make the behavior correct. If product guidance says verification succeeded while application state says it did not, the guidance cannot change the fact.
Authority belongs to the artifact responsible for the concern.
AI fits on the interpretation side of this boundary. A model may connect the question “Why can’t I remove this restriction?” to the relevant verification policy. It may retrieve knowledge, select candidate capabilities, adapt an explanation, or propose a composition. It does not decide whether verification occurred, whether the user is authorized, or whether an irreversible action completed.
When representations disagree, the system should expose the conflict and identify which artifact owns the disputed concern.
From Pages to Capability Systems
Component generation is the most visible AI and interface story, but generated code does not answer the product question. A system still has to determine what should exist, for whom, under which conditions, and within which constraints.
A capability-oriented architecture would change the unit of composition. Engineering builds reliable views, actions, and bounded services with real contracts. Product knowledge describes the task, relevant information, available actions, explanations of prerequisites, and presentation intent. State establishes current facts. Policy constrains what is permitted. A composition layer, if one were built, would select only from what already exists.
Its limit is equally important: composition cannot conjure a missing capability. If the product cannot verify identity, no description of an identity-verification step makes that behavior real. New requirements still require engineering.
The idea that interfaces can be derived has substantial lineage. Server-driven UI, declarative systems, model-driven systems, and configuration-driven products predate the current AI wave. The narrower proposition here is that structured product knowledge can participate more directly in the derivation.
Thinking model · bounded composition
UI = f(state, capabilities, policy, context)State, trusted capabilities, policy, and context are explicit inputs to composition; none of them grants the others authority.
This is a thinking model, not an executable formula and not an argument for generating every screen at runtime. Some interactions require careful authorship. Some layouts encode meaning. Predictability can itself be a requirement.
The opportunity is strongest where software repeatedly orchestrates the same trusted capabilities around different roles, states, workflows, products, and policy boundaries. In those systems, the page may become less of a primary authored artifact and more of a derived view.
Engineering does not disappear. Its effort moves toward capability contracts, policy enforcement, validation, observability, and the infrastructure that makes allowed compositions testable.
From Authoring Surface to Architectural Asset
A Markdown document an author can read is not yet something a system can rely on. To become an architectural asset, the knowledge in it would need to be normalized into typed elements—task, relevant information, action reference, explanation—carry provenance such as who wrote it, when, and under which product version, and link to the authoritative rules and capability contracts it describes rather than restating them.
That last point carries the most weight. An explanation that paraphrases a governing rule creates a second copy of that rule, and the two can drift apart. An explanation that references the rule can be checked against it. The machine-usable form keeps authority where it already belongs and makes the explanatory layer verifiable.
This differs from docs-as-code. Docs-as-code gives documentation engineering practices such as version control, review, automated checks, and publishing. Those practices help, but they treat documentation as a publication. The proposal here treats the meaning inside it as an input other systems can select, apply, and test. Markdown is one possible authoring form; the durable asset is the represented meaning and the contracts governing its use.
What the Thesis Still Has to Prove
The conceptual model is simple. Making it reliable is not.
- Authority. Which knowledge is explanatory, which is normative, and who can change it?
- Synchronization. When an explanation duplicates or paraphrases an authoritative rule, how does the system detect drift between them, and between code, specifications, policy, and product knowledge more broadly? This is an architectural problem, not an implementation detail.
- Capability contracts. What metadata must a capability expose—inputs, required state, authorization, validation, effects—for composition to stay bounded?
- Registry and lookup. How would product knowledge resolve a stable reference to a trusted capability?
- Allowed compositions. Which layouts and interactions are permitted, and how do policy constraints limit them?
- Dynamic range. Which parts of composition may vary, and which should remain deliberately fixed?
- Testability. How should a system verify knowledge applicability, capability selection, policy constraints, and allowed compositions?
- Representation. Is prose only the authoring surface while schemas, typed objects, or knowledge graphs become the machine-facing form?
- Inference boundaries. Where should semantic interpretation stop and deterministic authority begin?
These are not implementation details postponed until later. They determine whether product knowledge becomes architecture or merely another source of confident drift.
The endpoint worth investigating is not a model that can generate more components. It is a system in which state, trusted capabilities, policy, and product knowledge are explicit enough that parts of an interface can be derived without surrendering deterministic control.
If those layers are explicit, how much of the final interface still needs to be authored imperatively?
Research lineage
Where this argument came from and where it continues.
- Runs alongside
- Adaptive AI Runtime for Enterprise UIUnpublishedContext Engineering for Software DevelopmentUnpublishedDocumentation-Driven Adaptive UXFrom Prompts to Project Memory: Spec-Driven Development for Coding Agents