Formation and Governance of Architecture Knowledge

In my experience, architecture decisions are often formed at a distance from the requirements they must satisfy. Product, Security, Reliability, Operations, and organizational technology functions express concerns through separate processes; the architect translates only part of that context into structural decisions; engineers then implement an interpretation that can differ again from the architect's intent. AI-assisted delivery magnifies this separation. An AI coding agent can produce a coherent implementation quickly from incomplete requirements, partial architecture knowledge, and plausible inferred rationale, allowing differences between requirements, architecture decisions, and implementation to propagate before a responsible person sees them.

Recent empirical evidence shows why that observation has become consequential. Zhou et al. assembled 100 architecture problems and decisions from Stack Overflow posts, GitHub issues, and GitHub discussions, then asked five large language models to generate or recover their design rationale through three prompting strategies. The models recovered many of the considerations recorded by human experts and added perspectives that evaluators found helpful. They also produced uncertain or misleading arguments and often lacked the practical experience and context-specific detail present in expert rationale. In follow-up interviews, practitioners consistently identified project context as necessary for trust, and several required substantial human review before relying on generated rationale.¹

These findings expose three connected delivery questions: where reliable product context comes from, how an AI participant identifies which architecture knowledge carries authority, and what turns a plausible architectural statement into an organizational decision. Better generation alone cannot answer them.

Specification-First Delivery treats architecture knowledge as a governed part of the Knowledge System. Product requirements, organizational technology direction, security and privacy requirements, reliability objectives, operational conditions, cost constraints, existing implementation evidence, and prior decisions enter an architectural discussion as named inputs. The accountable architecture decision owner reviews the resulting decisions and rationale. Publication then makes the approved knowledge available to later Structured Discussion and Technical Specification work.

This paper proposes an integrated lifecycle for that work:

1. establish the applicable inputs and the architectural question;

2. form decisions and rationale through structured architectural discussion;

3. distinguish current architecture, approved direction, realistic aspiration, and contingent change;

4. separate authorship from decision authority;

5. publish approved knowledge and Architecture Decision Records (ADRs) through a governed source;

6. give every maintained architecture record an owner and next review date; and

7. require later delivery work to consume the applicable architecture knowledge and surface conflicts to the proper decision owner.

Earlier research established architecture decisions, rationale, stakeholder involvement, chronology, capture, maintenance, sharing, and reuse as important concerns. Recent work also explores automated ADR generation, context selection, recovery of decisions from meetings, and AI-supported architectural knowledge systems. Specification-First Delivery connects those concerns with governed inputs, AI-assisted discussion, human decision authority, publication, applicability semantics, downstream specification, and continuing review as one delivery lifecycle.

Back to top

1. Architecture Knowledge and Its Delivery Role

Architecture knowledge is the maintained knowledge needed to understand why a product has its current structure, which architectural decisions apply, which approved changes should shape new work, which dependencies matter, and who may authorize a change. It includes more than diagrams or a component inventory. Decisions, assumptions, rationale, context, and relationships explain why the visible design exists and how it may evolve.² The decision-centered view of software architecture arose partly in response to "knowledge vaporization": design knowledge disappears when decisions remain implicit in the resulting structure. Making decisions explicit supports later development and evolution because a participant can examine the reasons that produced the current architecture instead of inferring them from code alone.³

In Specification-First Delivery, architecture knowledge serves as durable delivery context between product-wide concerns and increment-level execution. It has two linked responsibilities:

• describe the architecture that later work must understand or preserve; and

• carry approved architectural judgment into the specifications that shape implementation.

The formation and reuse workflow fulfills both responsibilities. Establishing inputs and forming decisions create the maintained description and judgment; review and publication give them authority; later application carries them into specifications and returns implementation evidence for continuing review.

A requirement or organizational direction states a condition that architecture must satisfy. Architecture converts the applicable conditions into structural decisions. For example, a Product Owner may set an operating-cost limit, Reliability may define recovery objectives, Security may define an approved trust model, and the organization may select Kafka as its supported event platform. The architecture decision owner then decides which responsibilities, deployment model, data flow, or integration pattern satisfies those inputs for the product.

The originating role retains authority over its requirement. The architecture decision owner retains authority over the structural response. An architect may identify that a recovery objective cannot be met, but Reliability decides whether the objective changes. A reliability specialist may reveal an architecture risk, but the discovery does not transfer authority to redesign the product.

Back to top

2. Prior Research and the Contribution Boundary

Architecture knowledge management has a substantial research history. A systematic review of 115 studies identified 56 approaches concerned with capturing, using, maintaining, sharing, and reusing architecture knowledge. The review found stronger support for using already-captured knowledge than for efficient capture, sharing, reuse, and especially long-term maintenance.⁴ Decision documentation research has also defined views for decision detail, relationships, chronology, and stakeholder involvement.⁵ These bodies of work establish that architecture knowledge includes decisions and rationale, that stakeholders need different views of it, and that maintenance is a persistent problem.

AI-focused research adds new mechanisms rather than replacing that foundation. Dhar, Vaidhyanathan, and Varma showed that large language models can generate relevant architectural decisions from decision context, while still falling short of human-level performance.⁶ Gupta et al. later evaluated sequential ADRs from 750 open-source repositories and found that context-aware prompting substantially improved ADR generation. A small window of recent ADRs usually gave the best quality-efficiency balance, which makes context selection a material design concern rather than a matter of sending every available record.⁷

Other work begins closer to the discussion itself. GADR uses a multi-agent workflow to extract decisions from noisy meeting transcripts and produce ADR drafts. Its feasibility study also reports a provenance risk: retrieval enrichment can improve an ADR while introducing content that is not faithful to the discussion.⁸ On-demand architectural knowledge systems have been proposed as conversational companions that organize relevant knowledge and support architects during decision-making.⁹ A 2026 vision for automated architecture knowledge management goes further toward continuous extraction, traceability, inconsistency detection, a structured knowledge base, and explicit human confirmation before consequential updates.¹⁰

Specification-First Delivery therefore does not claim that AI-assisted architectural reasoning, ADR generation, knowledge capture, human review, traceability, or conversational retrieval is new. The model in this paper combines those concerns around a delivery-specific governance question: how architecture knowledge is formed from authoritative product inputs, receives human authority, states when it applies, and becomes required reasoning context for later specifications.

Two parts of that combination are especially important. First, authorship and authority are separate properties. An AI participant may draft a discussion record, an ADR, or an architecture update. The record acquires authority only when the role with the relevant decision rights reviews and publishes it through the governed source. Second, the applicability of architecture knowledge is separate from the lifecycle status of its ADR. An accepted ADR may describe an approved direction that has not yet become current architecture.

Back to top

3. Formation Through Architectural Discussion

Architecture knowledge is formed through discussion because structural decisions must reconcile inputs from several professional responsibilities. The discussion may occur in a meeting, a written exchange, or a human-AI working session. Its format is an implementation choice. The required outcome is a reviewable record that connects the question, applicable inputs, decision, rationale, owner, and follow-up conditions, together with options when participants considered meaningful alternatives.

Back to top

3.1. Establish the Decision Context

The participant preparing the discussion gathers the knowledge that can materially affect the decision:

• the product behavior or change that raised the question;

• applicable organizational direction and product-wide requirements;

• current architecture and implementation evidence;

• related ADRs and unresolved architecture discussions;

• relevant security, privacy, reliability, operational, data, and cost concerns;

• dependencies and external decisions that constrain the available options; and

• the role that holds decision authority.

The context set should be selective and traceable. Each included source needs a reason for inclusion, and the discussion should preserve a route back to authoritative requirements or evidence. Retrieval can help discover candidate context, while the discussion record identifies which sources the participants actually relied upon.

Back to top

3.2. Separate Inputs, Options, and Decisions

The following categories form a recommended discussion-record template. AI may maintain the record as Structured Discussion proceeds, while the human participants confirm its substance. Use the categories that apply to the decision:

• Input: a requirement, constraint, organizational direction, current fact, or dependency condition that the decision must consider.

• Option: a realistic structural response that participants can compare, when meaningful alternatives were considered.

• Decision: the selected response within the architecture decision owner's authority.

• Rationale: the reasons, trade-offs, evidence, and assumptions that explain the decision.

• Open matter: an unresolved question whose owner and required resolution path are named.

This separation prevents an attractive option from being presented as an existing constraint. "Use Azure Functions" is an architecture option or decision. "Keep average compute cost within the approved operating budget" is a cost input. The rationale must show how the selected compute model responds to the cost input and what consequences accompany the choice. The record does not need to repeat every obvious, organization-wide decision. For example, a product in an organization that operates entirely on AWS can link to that authoritative direction when it is already discoverable, then record only the product-specific consequence or decision.

Back to top

3.3. Review and Publish the Result

AI may prepare the first complete record and update it as the discussion proceeds. The decision owner then conducts line-by-line confirmation with the relevant participants, resolving inaccurate statements, unsupported rationale, conflicts with source requirements, and questions outside the current authority. This line-by-line review is essential: broad approval can leave a plausible AI-authored sentence with an authority or implication that no participant intended. The decision becomes organizational architecture knowledge when the owner deliberately publishes the reviewed result. In a repository-centered Knowledge System, this transition may occur when the architect or other authorized owner commits, pushes, and merges the record into the governed branch. In a document or architecture platform, it may occur through the equivalent save, approval, and publish controls. A draft visible in a discussion tool remains a draft until that authority transition occurs.

Back to top

4. Architecture Knowledge Applicability

Architecture knowledge needs explicit applicability because present state, approved change, aspiration, and dependency-triggered intent guide delivery differently. Specification-First Delivery uses four applicability states.

An aspiration must remain plausible within the product and organizational context. A current on-premises monolith may carry an aspiration to move selected capabilities to a cloud-native architecture when the aspiration addresses recognized deployment or scaling pain. An unsupported expectation about an unrelated future technology has no present decision relevance and does not belong in maintained architecture knowledge.

A contingent direction names an observable trigger. "Eventually use Kafka" leaves an AI participant to guess whether the change is authorized now. A usable record states that the current integration polls System B, that the product will adopt System B's event stream when a production-supported contract becomes available on the organizational Kafka platform, and how the team will verify that the trigger has occurred.

These states describe how architectural knowledge applies. ADR status describes the lifecycle of a decision record, such as proposed, accepted, superseded, or rejected. The dimensions can coexist. An accepted decision may create an Approved Direction. After implementation and review, the relevant architecture knowledge becomes Current while the accepted ADR remains part of the decision history.

Back to top

4.1. Worked Example: AI Travel-Planning Product

Consider a travel-planning product that currently serves users through a web application. Its architecture Knowledge Set could contain four related statements:

• Current: The itinerary capability owns itinerary state and all accepted itinerary mutations. The web application presents proposed changes, while provider adapters retrieve external availability and prices.

• Approved Direction: Planning behavior will be exposed through a stable application capability so that the web interface and future conversational interfaces use the same business rules. New rules within the approved migration scope belong behind that capability instead of in interface-specific components.

• Aspirational: Selected workloads may move from the current on-premises monolith to cloud-native services. The aspiration addresses documented release-independence and scaling pain, but no migration authority or target service decomposition has been approved. A review is scheduled after production demand and operating-cost evidence are available.

• Contingent: The product currently polls an enterprise customer platform for profile changes. It will adopt the platform's Kafka event stream after the platform owner publishes a production-supported contract and confirms the required event coverage. Until then, polling remains the Current integration.

A Technical Specification for a new itinerary rule applies the Current ownership and the Approved Direction. It can place the rule behind the shared planning capability when the increment has migration authority. The cloud-native aspiration can shape the discussion only to the extent stated in its record. The Kafka direction has no implementation effect until the named trigger is verified.

Back to top

5. Architecture Decision Records and Discussion Records

An Architecture Decision Record (ADR) is a durable output of architectural discussion. Creating it from the reviewed discussion preserves the reasoning as the decision forms, and the record can stay concise when its links retain the necessary context.

A recommended ADR template contains:

Title
Description
Rationale
Made by
Made date
Related discussion
Supersedes / superseded by

The related discussion can preserve considered options, source inputs, unresolved questions, and review participants. The Architecture Decision Record states the authoritative outcome and its provenance. Decision-documentation research supports treating decision detail, relationships, chronology, and stakeholder involvement as connected views rather than reducing a decision to a single conclusion.⁵

Architecture discussion records provide a controlled path for proposals and open questions. An engineer or AI coding agent may discover that the current integration pattern blocks a required change. The participant records the observation, source delivery work, rationale, affected knowledge, and requested decision. The finding does not silently amend the architecture or enlarge the current execution authority.

For a small product, one architecture-discussions.md file may be sufficient. A larger product may keep separate records under docs/architecture/architecture-discussions/. Discussion records may also be maintained in a knowledge base outside the code repository. The storage choice is a reference implementation; the required capability is a discoverable route from an observation to the architecture decision owner and then to an authoritative decision or closure.

Back to top

6. Organizing and Publishing the Architecture Knowledge Set

The architecture Knowledge Set is the connected collection of current descriptions, directions, dependencies, ADRs, discussion records, external sources, owners, and review information that delivery participants use. A listing document gives humans and AI a stable entry point. The set may reside in the code repository or in an external knowledge base, provided the Knowledge System gives the AI coding agent and other delivery participants a supported way to read it. In a repository-centered implementation, README.md can list each source, its scope, applicability, authority, and review state.

A compact product might use:

A larger product might use:

The folder names do not define the framework requirement. An architecture repository, service catalog, document platform, or knowledge graph can satisfy the same responsibility when participants can find the authoritative material, determine when it applies, identify the owner, and inspect its review state.

Each maintained architecture document should state:

• its scope and subjects;

• its authority and decision owner;

• the applicability state of its material;

• the implementation evidence or decisions that support current claims;

• its relationship to other architecture sources;

• the last review date and next review date; and

• the path for raising a conflict, correction, or proposal.

The architecture Knowledge Set contains distilled information about external dependencies that is relevant to product decisions. A useful entry identifies why the product depends on the external system, which side is authoritative for the relevant data or capability, the interface through which the dependency operates, the current failure or change implications that affect architecture, and any Approved Direction or Contingent change. Current external systems should normally provide maintained hosted documentation or knowledge through an accessible interface such as Model Context Protocol (MCP). Older dependencies may expose only static manuals, archives, or vendor files and may change less frequently. In that case, link to the available source and retain only the stable, product-relevant facts, provenance, and review responsibility within the architecture Knowledge Set.

Back to top

7. Consumption by Later Specifications

Published architecture knowledge becomes useful when later work actively consumes it. Retrieval alone is insufficient because a participant may retrieve several plausible records without knowing their authority or applicability.

During Structured Discussion, the responsible participants and supporting AI should:

• locate the architecture entry point and sources relevant to the proposed change;

• identify the Current baseline and any applicable Approved Direction;

• evaluate Aspirational material only for its stated decision relevance;

• verify whether a Contingent trigger has occurred;

• connect architectural statements to their owner, rationale, and source evidence;

• surface conflicts, missing knowledge, and proposed departures; and

• route each material architecture decision to the proper owner.

During Technical Specification, the author should translate applicable architecture into implementation constraints, dependencies, protected behavior, and required decisions for the increment. The specification may implement an Approved Direction when the change has the required scope and authority. It may not promote an aspiration, declare a trigger satisfied, or resolve a conflict merely because one option appears technically attractive.

Architecture knowledge therefore becomes executable reasoning context without becoming autonomous execution authority. It helps a human or AI participant reason about the right implementation surface and trade-offs while keeping material decisions under named human accountability.

Back to top

8. Maintenance, Review, and Knowledge Convergence

Architecture knowledge changes through implementation, organizational decisions, operational evidence, and dependency evolution. Every maintained source has a next review date because even an accurate record can become misleading as the product changes.

A review examines whether:

• Current knowledge still matches implementation evidence;

• Approved Direction remains authorized and its adoption state is accurate;

• Aspirational knowledge still addresses a real pain point and affects present decisions;

• Contingent triggers remain unsatisfied, have occurred, or are no longer realistic;

• referenced requirements, dependencies, and external sources remain authoritative;

• ADR relationships and supersession links remain complete; and

• later specifications have exposed new conflicts or learning that belongs in durable knowledge.

Events may require review before the scheduled date. Examples include a material implementation deviation, a changed organizational platform decision, a security or reliability requirement update, a dependency contract change, an incident that invalidates an assumption, or a delivery discussion that cannot reconcile two authoritative sources.

Conflicting architecture sources create a Knowledge Convergence responsibility. The participant records the conflict and its delivery consequence, identifies the sources and owners, and pauses dependent decisions that require a single answer. The accountable owner resolves the meaning, authority, or applicability of the sources and publishes the result. AI retrieval ranking, document recency, or implementation convenience does not decide which architectural claim governs the product.

Back to top

9. Readiness and Validation

The architecture Knowledge Set is ready when a qualified participant unfamiliar with the product can use it to perform a defined delivery responsibility and route unresolved decisions correctly. The validation should use the same access path available to the participant being tested, including the actual retrieval path available to an AI coding agent.

Give the participant a representative proposed change and ask them to establish:

• the Current architecture relevant to the change;

• the system or capability that owns the affected behavior or state;

• the applicable organizational, product, security, reliability, operational, and cost inputs;

• the dependencies and interfaces that constrain the change;

• any Approved Direction that should shape the implementation;

• any Aspirational knowledge that may inform discussion without authorizing implementation;

• any Contingent direction and the evidence needed to confirm its trigger;

• the Architecture Decision Records and rationale that explain material decisions;

• the person or role with authority to approve a departure; and

• the route for recording a conflict or architecture proposal.

The test passes when the participant can locate supported answers, distinguish authority and applicability, and escalate material gaps without inventing architecture. A failed answer becomes a readiness gap with an owner and resolution path, and dependent delivery proceeds only when the missing knowledge is unnecessary for the current responsibility or the proper owner has resolved it. Architecture knowledge can then participate directly in delivery because governed concerns have been converted into reviewed decisions, published with explicit applicability, maintained through evidence and scheduled review, and made reusable whenever later specifications translate intent into software change.