Products remember state better than organizations remember reasoning.
The database can tell us the current configuration. Git can tell us which code changed. A project tool can tell us which tickets closed. A design file can show the current interface.
None of those necessarily tell us why a consequential decision was made.
What evidence existed? Which alternatives were rejected? Which constraint mattered at the time? What assumption was still uncertain? What would need to change before the team should revisit the decision?
When that context disappears, the organization loses more than documentation.
It loses decision quality.
Decisions Decay Faster Than Artifacts
A product team can accumulate years of decisions:
- why a workflow requires approval;
- why one vendor was chosen;
- why a data model preserves history;
- why a feature was intentionally excluded;
- why a service boundary exists;
- why a market segment was deferred;
- why an experiment failed.
The visible artifact often survives while the rationale disappears.
This creates a dangerous situation because later teams encounter a decision without knowing whether it is still valid.
They have two bad options.
They can preserve it blindly.
Or they can reverse it blindly.
Michael Nygard described this problem in the context of software architecture when introducing Architecture Decision Records. ADRs preserve context, decision, status and consequences so future teams can understand why a structural choice exists.
The same principle applies beyond architecture.
Product decisions need memory too.
Documentation Is Not the Same as Decision Memory
Organizations often have enormous quantities of documentation and weak memory.
A wiki may contain old research, meeting notes, strategy decks and requirements. The difficulty is not storage. It is knowing which information is current, authoritative and connected to a decision.
Decision memory needs structure.
A useful record distinguishes:
Facts
Assumptions
Evidence
Open questions
Decision
Rationale
Consequences
Revisit conditions
Superseded decisions
Those categories prevent one of the most common documentation failures: treating everything written down as equally true.
A customer quote is evidence.
An interpretation of the quote is not a fact.
A planning assumption may be useful without being verified.
A decision may be current even when the evidence behind it later changes.
The system needs to preserve those distinctions.
Canonical Context Reduces Repeated Discovery
Teams repeatedly pay for the same questions when context is fragmented.
A new engineer asks why an integration works a certain way. A product manager reopens an old market question. An AI assistant receives a partial prompt and proposes an option the team rejected six months earlier for a known reason.
The cost appears as repeated discovery.
Canonical context does not mean one giant document.
It means there is a maintained representation of the context the organization currently treats as authoritative, with links to evidence and history.
That context may include:
- product boundaries;
- actors;
- domain definitions;
- current assumptions;
- decisions;
- open questions;
- constraints;
- architecture implications;
- source provenance.
The objective is not to eliminate conversation.
It is to make conversation start from the latest known state instead of reconstructing history.
Superseded Decisions Should Not Disappear
When a decision changes, teams often overwrite the document.
That destroys useful information.
The previous decision may explain why the current system still contains a certain structure. It may reveal what changed in the environment. It may prevent the team from returning to an old option under the mistaken impression that nobody considered it.
Nygard's ADR format handles this by preserving old records and marking them as superseded.
Product decision memory should do the same.
A decision record can move through states such as:
Proposed
↓
Accepted
↓
Active
↓
Superseded
The old decision remains part of history without remaining authoritative.
That distinction is especially important for AI systems retrieving organizational knowledge. A retrieval system that finds an obsolete decision without status metadata can make historical context look current.
Revisit Conditions Are Often More Valuable Than Dates
A team may decide not to build a capability because only a small number of customers need it.
The decision is valid under a condition.
If the customer mix changes, the decision should be reconsidered.
A good decision record therefore includes revisit conditions:
- when transaction volume exceeds a threshold;
- when the vendor changes pricing;
- when a new jurisdiction becomes active;
- when an integration becomes a strategic dependency;
- when the product enters a regulated segment;
- when repeated support issues cross an agreed level.
This makes the decision responsive to reality.
It also prevents periodic strategy meetings from reopening every old question simply because time passed.
Product Memory Improves AI Context
AI systems make the memory problem more visible because their output quality depends heavily on supplied context.
A model asked to propose architecture without knowing prior constraints can produce a technically coherent answer that is organizationally wrong.
A model asked to summarize product strategy from mixed historical documents may merge superseded and current positions.
The problem is not solely the model.
The knowledge system lacks authority metadata.
This connects to AI Output Is Not Canonical Truth. AI can help retrieve, summarize and reason over product knowledge, but it should operate over context that distinguishes evidence, decisions, uncertainty and history.
Better prompts cannot fully compensate for poor organizational memory.
Decision Logs Should Be Small Enough to Maintain
Large governance systems often fail because maintaining them costs more than the perceived value.
Decision memory needs a low-friction unit.
A useful product decision record can be short:
Decision:
Allow a student account to survive school changes.
Context:
Students may change schools while personal achievement history should remain continuous.
Evidence:
Domain research shows school membership is time-bounded while student identity is persistent.
Decision:
Student identity belongs to the platform-level account model. School membership is a separate temporal relationship.
Consequences:
School-private data access ends when membership ends. Personal history remains visible under applicable permissions.
Open question:
What retention rules apply to school-generated artifacts after departure?
Revisit if:
Legal or contractual requirements require institution-owned identity boundaries.
The value comes from preserving reasoning, not formatting.
Memory Needs Ownership
Documentation that belongs to everyone often belongs to nobody.
Decision memory requires maintenance responsibility.
Ownership does not mean one person approves every change. It means someone or some role is responsible for keeping canonical context coherent.
Useful practices include:
- assign owners to major decision areas;
- review stale assumptions;
- link decisions to evidence;
- mark superseded state explicitly;
- capture new questions when evidence conflicts;
- include decision updates in meaningful product changes.
The maintenance model should be proportionate to consequence.
A small product does not need an enterprise knowledge-governance department. It does need a way to avoid silently losing important reasoning.
Memory Should Support Change, Not Freeze It
A decision log can become bureaucratic if teams start treating recorded decisions as law.
That is the opposite of its purpose.
Decision memory should make change safer by making prior context visible.
A good record says:
This is what we decided under these conditions.
It does not say:
This decision can never change.
Architecture Decision Records are valuable partly because they normalize supersession. Product decisions should have the same humility.
Understanding evolves.
Evidence changes.
Constraints disappear.
New constraints emerge.
The memory system should help the organization change consciously.
Noesis and the Product Intelligence Problem
NILLKAI's Noesis, the Product Intelligence System, sits in this conceptual territory.
The problem it addresses is broader than document storage. Product teams need a way to preserve context, evidence, assumptions, open questions, decisions and provenance so that future reasoning starts from an intelligible state.
The concept is still a structured response to a class of product-intelligence problems, not a claim that one framework eliminates organizational forgetting.
Its usefulness depends on the same principle described here:
Product knowledge should preserve not only what the organization currently believes, but how that belief became authoritative and what would justify changing it.
That is decision memory.
Preserve the Reasoning That Makes Change Intelligent
Software changes because context changes.
Organizations should expect decisions to evolve.
But evolution without memory is expensive. Teams rediscover old questions, repeat old mistakes, preserve obsolete constraints and feed incomplete context into both people and AI systems.
A useful memory system does not try to record everything.
It preserves the reasoning behind decisions that shape future options.
The test is simple:
When someone encounters an important product or architecture decision six months from now, can they understand:
- the context;
- the evidence;
- the alternatives;
- the rationale;
- the consequence;
- the current status;
- the conditions under which it should be revisited?
If the answer is yes, the organization has more than documentation.
It has memory that can improve the next decision.
References
- Michael Nygard. Documenting Architecture Decisions. 2011. https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
- ADR GitHub Organization. ADR Templates. https://adr.github.io/adr-templates/
- Google. Documentation Best Practices. Google Style Guides. https://google.github.io/styleguide/docguide/best_practices.html