# Knowledge Convergence Across the Increment Lifecycle

A [Shared Knowledge System](/en-us/hub/shared-knowledge-system) preserves the durable product knowledge that another qualified participant needs before making a material change. Product intent, architecture requirements, domain semantics, governing instructions, specifications, and existing code provide the context for delivery. Qualified engineers exercise professional judgment over the implementation questions that this established knowledge deliberately leaves open.

This means an increment, shaped through the requirement and structured-discussion model described in [Requirements, Structured Discussion, and Increments](/en-us/hub/requirements-increments-and-structured-discussion), can begin from a coherent Knowledge System and still produce several reasonable answers to a question that nobody needed to settle previously. One engineer may use an ORM to access a database, another may use a dataframe library, while a third notices repeated access patterns and introduces a shared API. A fourth may decide that the responsibility deserves a separate service. None of these approaches necessarily violates an existing specification. The delivery process may simply have exposed a technical decision that the organization had never needed to make before.

The same problem becomes more consequential when the output is reusable knowledge rather than local code. Two engineers working independently may create overlapping skills that give AI coding agents different procedures for substantially the same task. Two experienced engineers may both conclude that the repository's governing instructions are incomplete, propose incompatible corrections, and each believe that their change should guide future contributors.

The Knowledge System therefore has to do more than provide knowledge to an increment. It must also absorb the knowledge produced by the increment without allowing parallel professional judgments to become conflicting organizational precedent.

This paper defines that process as **knowledge convergence**.

> **Knowledge convergence is the process by which material knowledge created, challenged, or clarified during a delivery increment is given an explicit scope, relationship to existing knowledge, and appropriate authority before future work relies on it.**

Convergence determines which decisions may remain local, which findings affect shared work, which reusable knowledge needs reconciliation, and which matters require an accountable decision before they become authoritative. It preserves local engineering discretion for choices whose consequences remain local.

Knowledge convergence begins when new learning acquires shared consequences. At that point, the organization connects the question to the professional expertise and decision authority appropriate to its scope. Local choices remain under delegated engineering authority until their consequences extend to other work.

## 1. Knowledge States Within an Increment

The Knowledge System changes throughout delivery. A useful operating model assigns information an appropriate status and authority by separating the knowledge that already applies from the judgment and learning produced while the increment is being delivered.

| Knowledge category | Role during the increment | Typical examples |
| --- | --- | --- |
| Current-state knowledge | Describes the product as it currently exists and provides reusable context for the increment. | Product intent, architecture, interfaces, domain semantics, standing product requirements, governing instructions, current code |
| Increment specifications and decisions | Define the intended change, applicable constraints, execution scope, decision authority, and acceptance conditions for the current increment. | Functional specifications, architecture specifications, technical specifications, accepted design decisions |
| Local implementation judgment | Decisions made by an executor within the authority deliberately left to engineering discretion. | Choice of helper structure, local algorithm, internal naming, use of an existing library |
| Implementation learning | New knowledge discovered while implementing, integrating, verifying, or reviewing the increment. | Previously unknown dependency, incompatible assumptions, recurring implementation need, performance constraint, missing architectural decision |
| Resulting current-state knowledge | Knowledge that describes the accepted product after the increment and can be used directly by later work. | Updated architecture, interface documentation, shared engineering practice, code, revised product requirements |

These categories preserve specialized professional practice while making its material implications explicit to the rest of delivery. Product, architecture, engineering, security, quality, and other functions can continue to reason within their own disciplines while shared consequences acquire an explicit status and authority.

These categories are related, and durable shared knowledge remains proportionate to the consequences of the decision. Local choices can stay with the implementation that made them. Requiring advance specification for every implementation choice would make the Knowledge System unnecessarily detailed, creating the context bloat described in [Shared Knowledge System](/en-us/hub/shared-knowledge-system). Allowing every merged choice to establish precedent without review would instead accumulate accidental conventions and conflicting interpretations.

Consider these scenarios:

- A locally scoped decision remains local after the code is merged. A formatter used for decimal values in one implementation, for example, may carry no product-wide consequence.
- A pattern discovered by one engineer becomes a shared pattern only when its applicability and authority extend beyond the original implementation. A design pattern may suit one scenario without applying to others in the same product.
- An implementation finding can initiate a change to an architecture specification. The appropriate decision owner, such as an architect, engineering lead, or accountable group, decides whether the finding becomes an architecture decision.

The proportionality principle protects both engineering autonomy and organizational consistency. [Specification-First Delivery](/en-us/hub/specification-first-delivery) leaves implementation decisions local until their consequences cease to be local.

## 2. Local Engineering Judgment and Shared Consequences

A delivery increment often reveals that several decisions initially treated as independent are actually related.

Consider four implementation jobs, each assigned to a different engineer and each requiring access to the same database. The specifications define the required behavior, database contract, security requirements, and acceptance criteria, but do not prescribe a particular access library because that level of detail was unnecessary when the increment was defined.

The engineers make different choices:

| Engineer | Implementation choice | Possible wider implication |
| --- | --- | --- |
| A | Uses SQLAlchemy | Establishes an ORM pattern that other modules may copy |
| B | Uses pandas database access | Introduces a different abstraction appropriate to a data-oriented workflow |
| C | Creates a shared internal API | Proposes centralizing database access behind a reusable application abstraction |
| D | Introduces a separate service | Proposes a new architectural responsibility and deployment unit |

The four jobs may have genuinely different needs, so several implementations can remain valid. The material question is whether the choices remain independent. Isolated, understandable implementations that impose no shared obligation can remain local engineering decisions. A product-wide rule becomes useful when wider consistency serves a product need, not simply when the code looks different.

The situation changes when implementation exposes shared consequences. Examples include:

- several jobs independently solving substantially the same problem;
- one approach creating an interface or dependency that other jobs must use;
- multiple implementations competing to own the same responsibility;
- a local abstraction becoming a likely precedent for later work;
- a new library or service changing product-wide operational or architectural expectations;
- one job creating reusable instructions intended for other humans or AI systems;
- two implementation choices becoming mutually incompatible when integrated; or
- implementation learning showing that a previously local question should be answered consistently across the product.

Questions that begin as local implementation choices become harder to coordinate when several participants need a shared interpretation or must change how they work. Carlile's framework distinguishes transfer, translation, and transformation as coordination moves from shared syntax to different interpretations and then to interests that require participants to change what they know or do.[^citation-01] Knowledge convergence takes this knowledge-boundary problem into the increment lifecycle: when implementation learning becomes shared technical knowledge, the team must establish its scope, decision authority, relationship to existing knowledge, and propagation before later work treats it as precedent.

At that point, the team has discovered a *shared technical question* that was not apparent when the increment began. Delivery has produced new material knowledge, and the team must determine what authority that knowledge should have.

## 3. Knowledge Convergence During Delivery

Knowledge convergence begins when implementation learning or competing professional judgment becomes material to work beyond the decision in which it originated. The team should then make the relationship between the competing approaches explicit before an accidental winner becomes precedent.

**Converging new knowledge during delivery**



Material implementation learning is surfaced, assessed, resolved at the appropriate level, and propagated before future work relies on it.



1. **Make the new knowledge visible**

   Record the implementation finding, competing approaches, duplicated knowledge, or newly discovered shared technical question.

2. **Determine its scope**

   Decide whether the matter can remain local or affects other jobs, modules, specifications, reusable procedures, or future delivery.

3. **Identify the decision owner**

   Refer material questions to the role with the authority and professional responsibility to resolve them.

4. **Resolve the relationship**

   Keep approaches local, select a shared approach, specialize their applicability, supersede one, or leave the matter explicitly unresolved.

5. **Update affected work**

   Revise specifications, implementation jobs, reusable knowledge, or current-state documentation when the decision changes what other participants should do.

6. **Verify convergence**

   Confirm before acceptance that material conflicting interpretations have not become competing authoritative sources or accidental precedent.

### 3.1. Keeping Some Decisions Local

The database example might show that SQLAlchemy is appropriate for transactional application code while pandas access is appropriate inside a controlled analytical process. The correct outcome may be to retain both approaches without creating a universal database-access rule.

The important result is that the team understands why the approaches coexist and whether future work needs to know the distinction.

A local choice should normally remain local when:

- it affects only the implementation that made it;
- another reasonable choice would not change product behavior or system responsibilities;
- it creates no shared interface or obligation;
- future contributors do not need to reproduce the choice for compatibility; and
- recording it as durable shared knowledge would add more maintenance cost than delivery value.

This is the normal operation of delegated autonomy.

### 3.2. Establishing a Shared Decision

A shared decision becomes appropriate when several parts of the product need one answer or when one implementation choice constrains other participants.

In the database example, the team may conclude that application modules should use one shared access abstraction because transaction handling, connection management, observability, or testability would otherwise be implemented repeatedly.

That decision should then be expressed at the level where it applies. Depending on its consequence, this may require an architecture specification, an updated technical specification, product architecture documentation, a shared implementation component, or another authoritative source.

The objective of documenting a shared decision is to ensure that future participants can discover the resulting decision and its applicability without reconstructing it from several competing implementations.

### 3.3. Preserving an Unresolved Question

Some material questions can remain unresolved after the current increment when their status and consequences are explicit.

The team may establish that two approaches are currently valid, that evidence is insufficient to standardize one, or that a larger architectural question should be handled separately. An unresolved question should remain explicit when future work could otherwise mistake one existing implementation for an approved product-wide convention.

For example:

> Both database access patterns remain valid for their current implementations. This increment establishes no product-wide database access abstraction. The question should be revisited if a third shared consumer is introduced.

An explicit unresolved question is coherent knowledge. Several implementations silently implying different standards for the same use case are not.

## 4. Reusable Knowledge and Semantic Conflict

The convergence problem becomes more serious when an increment creates knowledge that is designed to be reused.

A local helper affects the code that calls it. A reusable skill may affect many future AI sessions and engineers who never participated in the decision that created it.

Suppose two engineers independently identify a recurring schema-change problem and create two skills:

```text
skills/
  database-migration/
  schema-change/
```

Both skills may be individually useful and contain technically correct instructions. The problem arises when their purposes overlap so extensively that future participants cannot determine which one applies. This is a **semantic inconsistency**, and the team needs to determine the relationship between the two pieces of reusable knowledge.

Possible outcomes include:

- **Merge them.** They address the same class of work and should become one maintained procedure.
- **Specialize them.** One governs schema migration while the other governs data migration, with distinct applicability.
- **Establish precedence.** A specialized skill overrides a more general procedure when defined conditions apply.
- **Retain both deliberately.** They solve different problems even though some steps overlap, and their purposes are clear enough for future selection.
- **Supersede one.** One approach should no longer guide future delivery.

The Specification-First Delivery framework requires enough clarity within the Shared Knowledge System for a qualified human or AI participant to determine what knowledge applies and why. In fact, in this scenario, repo skills and governing instructions shall be discussed with the entire team.

> **Mergeability is not knowledge consistency**
>
> Two changes can merge cleanly while leaving contradictory instructions, overlapping reusable procedures, or incompatible architectural precedents. Source control resolves textual integration. Knowledge convergence requires participants to resolve material semantic relationships.

As AI coding tools become more common, repositories increasingly contain machine-consumable knowledge. Humans may notice that two documents look redundant and ask for clarification. An AI coding agent may instead select one, apply it confidently, and create further work based on whichever interpretation it happened to retrieve. Reusable knowledge therefore deserves more convergence discipline than an equivalent local implementation detail.

## 5. Authority and the Reach of Knowledge

The amount of review required for new knowledge should reflect how widely that knowledge can influence future delivery. Different organizations will assign authority differently. The relevant question is how much future decision-making a change can affect.

| Example | Typical reach | Convergence concern |
| --- | --- | --- |
| Local implementation choice | One implementation surface | Whether the decision can remain local |
| Module documentation or shared component | Several related implementation jobs | Whether users of the module receive one coherent description |
| Reusable skill or procedure | Future jobs that select or retrieve it | Applicability, overlap, ownership, and maintenance |
| Product-wide architecture or standing requirement | Many future increments | Decision authority, affected specifications, and current-state synchronization |
| Governing instructions | Contributors and AI systems operating under those instructions | Who may change the rules that define execution behavior and authority |

The broader the effect of the knowledge, the less appropriate it is for an individual implementation job to establish or revise it incidentally.

> **Documentation structure should follow product needs**
>
> Specification-First Delivery does not prescribe one documentation folder structure. A product may begin with a few files under `docs/`, such as `product-intent.md` and `use-cases.md`. As a monorepo grows to cover many components and use cases, the team may organize use cases by scenario or create structures for product-specific material, such as calculation methods. Documentation structure should evolve with the product's knowledge and retrieval needs.

### 5.1. Competing Changes to Governing Instructions

Governing instructions make this principle especially visible.

Consider two engineers who encounter the same missing repository rule. One concludes that all application database access should use a shared repository abstraction. Another concludes that direct ORM access should remain permitted within modules that own their persistence responsibilities.

Both are exercising legitimate professional judgment and may have strong evidence. Both propose a change to `AGENTS.md`. The problem appears if each implementation job can independently turn its preferred answer into governing knowledge.

A source-control merge conflict may expose the disagreement if both engineers edit the same lines. That is useful but accidental. They could modify different sections and produce instructions that merge without error while expressing incompatible policies. The Knowledge System therefore cannot treat a successful merge as evidence that governing knowledge has converged.

A participant may discover that governing instructions are incomplete, impractical, or wrong. That participant should be able to propose a change. The authority to execute an increment, however, does not automatically include the authority to redefine the instructions that govern other increments.

Specification-First Delivery requires the proposed knowledge change to be considered at the level of authority appropriate to its effect. Governing instructions establish how contributors operate across a product, repository, or defined part of the codebase. They should not be changed casually or become authoritative until the accountable participants have reviewed and agreed on the change.

The detailed structure, placement, ownership, and lifecycle of governing instructions belong to a later paper on preparing and governing the codebase. For the increment lifecycle, the narrower rule is sufficient:

> **An implementation job may discover the need to change governing knowledge without automatically acquiring the authority to make that change authoritative.**

## 6. Propagation of Converged Knowledge

Resolving a material question is not sufficient if other parts of the increment continue from the old interpretation. In that case, the knowledge exists in the Knowledge System but has not taken effect. Knowledge convergence therefore includes propagation. If several technical implementation jobs depend on a shared decision, resolving that decision may require more than updating one engineer's code. The team may need to update:

- an architecture specification;
- one or more technical specifications;
- affected implementation jobs;
- a shared interface or component;
- acceptance criteria or test specifications;
- module or product documentation;
- a reusable skill;
- a recorded decision;
- current-state architecture or domain knowledge; or
- another authoritative source relevant to future work.

The exact propagation depends on what changed.

A newly discovered local optimization may require no documentation update. A decision that establishes how all modules access a shared database probably requires a durable technical or architectural record. A finding that two existing skills overlap requires the skills themselves to be reconciled. A change to a standing product requirement may affect several specifications and acceptance conditions.

The Knowledge System is therefore more than a collection of documents. Its value lies in the relationships between knowledge sources and in the ability to update the sources that downstream work actually uses. In parallel delivery, propagation gives every affected job the reviewed decision and its applicability. When the change is material to work already in progress, the relevant jobs should be realigned before their implementations establish additional incompatible precedent.

## 7. Knowledge Convergence at Increment Completion

Implementation completion, verification, acceptance, and release approval are different decisions. Knowledge convergence is primarily concerned with what must be coherent before the increment is accepted as the new state of the product.

By that point, material implementation learning should have reached an explicit outcome. It may have been:

- retained as local implementation judgment;
- incorporated into an existing specification or current-state knowledge source;
- established as new shared knowledge;
- reconciled with overlapping or conflicting knowledge;
- recorded as an explicit unresolved question;
- rejected as an approach that should not become precedent; or
- preserved in the delivery record because its historical rationale may matter later.

The objective is to prevent material disagreement from becoming ambiguous authority.

Before accepting an increment, the accountable participants should be able to determine:

1. whether material implementation learning has been surfaced and recorded where needed;
2. whether decisions that affect multiple jobs have been resolved or explicitly deferred;
3. whether reusable knowledge created during the increment overlaps or conflicts with existing knowledge;
4. whether changes to architecture, requirements, interfaces, or other current-state knowledge have been reflected in their authoritative sources;
5. whether affected implementation jobs were updated after shared decisions changed;
6. whether superseded knowledge can still mislead future participants; and
7. whether a qualified human or AI participant can now determine what is authoritative for the resulting product state.

[Trusted Increments and Acceptance Evidence](/en-us/hub/trusted-increments-and-acceptance-evidence) explains how verification evidence supports conformance review and accountable acceptance. Knowledge convergence addresses a related question: whether the organization has preserved a coherent understanding of the system it is accepting.

After acceptance, two forms of knowledge remain important.

**Current-state knowledge** should explain the resulting product as it now exists. It should contain the architecture, requirements, interfaces, domain semantics, instructions, and other durable knowledge that future work needs directly.

**Delivery records** should preserve how the increment reached that state, including material alternatives, decisions, deviations, evidence, and unresolved questions where historical context remains useful.

The distinction prevents future work from treating every past implementation discussion as current policy while still preserving the reasoning needed to understand how important decisions were made.

The [Shared Knowledge System](/en-us/hub/shared-knowledge-system) defines these knowledge classes in greater detail. The increment lifecycle adds the convergence requirement: delivery should not leave future participants to infer authoritative knowledge from whichever implementation, skill, document, or instruction they happen to encounter first.

## 8. Relationship to the Increment Lifecycle

Knowledge convergence operates throughout the increment and should not be left as a documentation task at the end.

```mermaid
flowchart TD
  accTitle: Knowledge convergence across a delivery increment
  accDescr: Current knowledge and increment specifications guide execution. Implementation creates local judgment and new learning. Material shared questions are resolved and propagated before acceptance establishes the next current state.

  K0[Current-state knowledge]
  I[Increment specifications and decisions]
  X[Implementation]
  L[Local judgment and implementation learning]
  M{Material shared consequence?}
  LOCAL[Retain as local judgment]
  R[Resolve scope, authority, and relationship]
  P[Propagate to affected work and knowledge]
  V[Verification]
  A[Acceptance]
  K1[Resulting current-state knowledge]

  K0 --> X
  I --> X
  X --> L
  L --> M
  M -->|No| LOCAL
  M -->|Yes| R
  R --> P
  P --> X
  LOCAL --> V
  X --> V
  V --> A
  P --> A
  A --> K1
```

The lifecycle therefore contains two related forms of control.

The first is **specification conformance**. Implementation should satisfy the reviewed intent, requirements, scope, constraints, and acceptance conditions that apply to the increment.

The second is **knowledge convergence**. Material knowledge created during implementation should not silently fork the organizational understanding that future increments will rely on.

These controls solve different problems. Conformance prevents an executor from silently departing from an agreed decision. Convergence handles questions for which the organization did not yet have an agreed decision and which become material only because delivery exposed them.

A well-designed Knowledge System strikes a balance. It preserves established knowledge and material decisions without attempting to replace professional judgment with exhaustive instructions. Making it complete is neither realistic nor necessary. The increment lifecycle is where professional judgment encounters reality, produces new knowledge, and determines which parts of that knowledge should become durable.

## 9. Operating Outcome

A healthy Knowledge System gives qualified participants enough shared context, specifications, authority, and history to make local decisions while recognizing when those decisions begin to affect others.

Knowledge convergence provides the corresponding lifecycle discipline.

Local judgment remains local when no wider consistency is required. Repeated or conflicting approaches are visible when they acquire shared consequences. Reusable knowledge is reconciled before it creates ambiguous instructions. Material decisions are made by roles with the appropriate authority. Changes are propagated to the specifications and knowledge sources that future work will use. Unresolved questions remain explicit rather than hiding behind accidental precedent.

The resulting increment should therefore improve the organization's understanding of how the product should be built and continued. A trusted increment should leave both the code and the Knowledge System in a current, usable state.

[^citation-01]: Carlile, P. R. “Transferring, Translating, and Transforming: An Integrative Framework for Managing Knowledge Across Boundaries.” *Organization Science* 15, no. 5 (2004): 555–568. [INFORMS](https://doi.org/10.1287/orsc.1040.0094).