AI 底层逻辑 / 经典论文
AI Organizational Memory：组织记忆与知识资产治理架构
After studying this note, you should be able to:
834 行ai-foundations/papers/162-ai-organizational-memory-knowledge-asset-governance-architecture.md
AI Organizational Memory / Knowledge Asset Governance / Decision Memory Architecture
Batch 162 foundation note for Senior AI PM, AI Architect, Knowledge Architect, Enterprise Architect, and CBAP-level BA. Core question: how should an organization decide what AI systems may remember, forget, version, retire, challenge, cite, and reuse across teams, products, channels, and regulated workflows? Important note: this document is a learning, architecture, and portfolio artifact. It is not legal advice, compliance advice, model validation, audit opinion, records-retention approval, privacy impact assessment, or production authorization. Formal decisions require review by Legal, Compliance, Privacy, Security, Data Governance, Model Risk, Enterprise Architecture, Records Management, Business Owners, Operations, and accountable executives. Source access date: 2026-06-30.
Target Audience
| Role | What this role must learn to do | Evidence this role should produce |
|---|---|---|
| Senior AI PM | Convert AI memory from a product feature into a governed capability that improves reuse, personalization, quality, speed, and institutional learning without increasing stale knowledge risk | memory product thesis, reuse roadmap, value metrics, adoption telemetry, retirement decisions |
| AI Architect | Design memory stores, knowledge graphs, RAG indexes, provenance, versioning, citation, freshness checks, and deletion paths across AI applications | memory architecture views, source-to-context lineage, ADR memory, retrieval freshness controls |
| Knowledge Architect | Define knowledge asset taxonomy, authority hierarchy, ontology, claim model, stewardship, challenge workflow, and reuse rules | knowledge source registry, asset taxonomy, authority matrix, KG/RAG integration design |
| Enterprise Architect | Align organizational memory with business capabilities, application portfolio, data governance, records management, risk appetite, and platform standards | enterprise memory reference architecture, capability map, operating model, lifecycle policy |
| CBAP-level BA | Turn decisions, policies, exceptions, complaints, case learnings, and stakeholder rationale into reusable, cited, versioned business knowledge | decision log, exception pattern catalog, requirements-to-memory traceability, process knowledge model |
| Risk / Compliance / Privacy | Decide which memory is permitted, restricted, prohibited, retained, deleted, challenged, or placed under legal hold | memory control matrix, retention and forgetting rules, prohibited memory policy, challenge evidence |
| Operations Leader | Ensure knowledge updates, policy changes, complaint RCA, training, handoff, and call-center scripts feed reliable AI memory | operations knowledge loop, steward review cadence, correction action register |
| Internal Audit | Reconstruct what the AI system knew, cited, used, ignored, changed, and retired at a decision point | provenance evidence, version trace, decision memory replay package, audit sampling results |
Learning Objectives
After studying this note, you should be able to:
- Distinguish session memory, working memory, semantic memory, decision memory, policy memory, case memory, customer preference memory, prohibited memory, audit memory, and institutional learning memory.
- Design an organizational memory model that connects AI product behavior, knowledge asset governance, architecture decision repositories, and enterprise records obligations.
- Build a knowledge asset taxonomy with owner, version authority, source authority, freshness expectation, retention class, reuse scope, citation rules, and retirement state.
- Explain why AI memory governance is different from generic knowledge management: it directly affects prompt context, retrieval, model output, agent actions, user rights, and evidence quality.
- Define decision memory for ADRs, PRDs, risk acceptances, policy interpretations, KYC exceptions, AML typology changes, complaint RCA, and architecture tradeoffs.
- Design a memory lifecycle from capture, classification, validation, citation, indexing, use, feedback, challenge, correction, versioning, retirement, deletion, and archival.
- Govern retention and forgetting across RAG indexes, embeddings, knowledge graphs, caches, prompt logs, eval sets, feedback stores, and audit evidence.
- Identify stale knowledge risk, memory poisoning, citation failure, institutional amnesia, knowledge debt, context reuse leakage, and false personalization.
- Integrate knowledge graph, RAG, memory service, lineage, OpenLineage-style events, W3C PROV-style provenance, and source authority controls.
- Create interview answers and portfolio artifacts that show senior AI PM, BA, and architecture judgment.
Executive Summary
AI memory is not a chat feature. In an enterprise, memory is a decision and evidence architecture.
Financial retail organizations already have memory everywhere:
- Contact center policy manuals remember approved service rules.
- AML typology libraries remember patterns of suspicious behavior.
- KYC onboarding exception logs remember why unusual cases were approved or rejected.
- Complaint RCA repositories remember root causes, remediation, and control weaknesses.
- Credit policy committees remember underwriting decisions and rationale.
- Regulatory reporting teams remember interpretations, data definitions, and attestation assumptions.
- Architecture decision repositories remember why systems, vendors, controls, and integration patterns were chosen.
The new challenge is that AI systems actively consume, summarize, retrieve, cite, reuse, and act on this memory. That changes the risk profile. A stale policy page is no longer only a document problem; it can become an incorrect customer answer. A weak ADR is no longer only architecture history; it can become a copied pattern across many AI products. A complaint RCA that never enters the AI knowledge loop becomes an institutional learning failure. A memory store that captures customer preferences without purpose, consent, and deletion controls becomes a trust and privacy risk.
Mature AI memory architecture links seven disciplines:
knowledge asset governance
+ decision memory
+ provenance and citation
+ RAG / knowledge graph / memory service integration
+ retention and forgetting
+ operating ownership
+ institutional learning feedback loops
The design question is not "How do we store more knowledge?" The stronger question is:
What should this organization remember, forget, version, challenge, cite, retire and reuse so AI systems improve over time without turning old, weak or unauthorized knowledge into automated behavior?
This note centers AI memory as a product architecture and governance capability. It is not generic knowledge management. It focuses on how memory enters model context, how decisions become reusable knowledge, how evidence stays fresh, how citation and provenance create trust, and how organizations avoid knowledge debt as AI products scale.
Source Anchors
These anchors provide governance, architecture, provenance, lineage, and trustworthy AI language. They are used as design anchors, not as complete legal or compliance requirement catalogs.
| Anchor | Official / primary link | How this note uses it |
|---|---|---|
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | Uses Govern, Map, Measure, Manage as the risk loop for memory capture, use, monitoring, correction, and retirement |
| ISO/IEC 42001 AI management system | https://www.iso.org/standard/81230.html | Uses management-system language for policy, roles, operation, performance evaluation, management review, and continual improvement |
| ISO/IEC/IEEE 42010 Architecture Description | https://www.iso.org/standard/74393.html | Uses stakeholder concerns, viewpoints, architecture views, rationale, and correspondence to structure decision memory |
| W3C PROV Overview | https://www.w3.org/TR/prov-overview/ | Uses entity, activity, agent, derivation, attribution, and association concepts for memory provenance |
| OpenLineage Documentation | https://openlineage.io/docs/ | Uses lineage events, jobs, datasets, runs, facets, and integration thinking to make knowledge transformations observable |
| OECD AI Principles | https://oecd.ai/en/ai-principles | Anchors human-centered values, transparency, robustness, security, safety, and accountability expectations |
Source-use discipline:
- Treat source anchors as governance vocabulary, not as copy-paste checklists.
- Record access date, authority level, owner interpretation, affected artifact, and decision impact.
- Separate official standards and principles from vendor claims, analyst opinions, and internal habits.
- When a source changes, update affected memory assets and decision records instead of silently letting old interpretations remain active.
1. Core Thesis: Organizational Memory Is an AI Control Plane
Organizational memory becomes an AI control plane when it determines:
- Which knowledge can be retrieved into context.
- Which decision rationale can be reused by another team.
- Which customer facts or preferences can influence output.
- Which policies override local practices.
- Which incidents become regression tests.
- Which sources require citation.
- Which assets must be retired, deleted, archived, or challenged.
Low maturity organizations treat memory as a storage problem:
Upload documents.
Index content.
Let teams search.
Let the model summarize.
Keep chat history.
High maturity organizations treat memory as an accountable system:
Classify memory type.
Assign owner and version authority.
Record provenance and source authority.
Define allowed use and citation rules.
Monitor freshness and retrieval quality.
Route challenges and corrections.
Retire stale or superseded memory.
Feed lessons into institutional learning.
The most important shift:
AI memory is not what the model remembers.
AI memory is what the organization permits, curates, cites, reuses, challenges and forgets through AI systems.
This matters because AI products scale context. A small error in a knowledge base can affect thousands of answers. A poor decision rationale can be copied into future architectures. A poisoned memory entry can persist across sessions, users, workflows, evals, and product lines. A missing retirement path can keep superseded policy alive after a regulatory or product change.
2. Organizational Memory Model
An enterprise AI memory model should separate four layers.
| Layer | Purpose | Example assets | Key governance question |
|---|---|---|---|
| Interaction memory | Preserve task continuity and user experience within a bounded session or relationship | session history, working notes, customer preference, case context | What can be remembered about this user, task, case, channel, and purpose? |
| Knowledge memory | Provide authoritative reusable knowledge for AI retrieval and reasoning | policies, SOPs, product terms, ontology, FAQ, AML typologies, regulatory interpretations | Which source is authoritative, current, permissioned, cited, and fit for AI use? |
| Decision memory | Preserve why important business, product, architecture, risk, and policy decisions were made | ADRs, PRD tradeoffs, risk acceptances, credit policy committee decisions, KYC exception rationale | What rationale, evidence, assumptions, triggers, and consequences must future teams know? |
| Institutional learning memory | Convert incidents, complaints, eval failures, user feedback, and operations lessons into improved products and controls | complaint RCA, incident postmortems, regression cases, control findings, training updates | How does the organization learn without overgeneralizing from weak or sensitive evidence? |
2.1 Memory Architecture Stack
Authoritative sources
-> source registry and authority matrix
-> ingestion and provenance capture
-> classification and allowed-use policy
-> knowledge graph / document store / decision repository
-> search index / vector index / memory service
-> context composer and policy filter
-> model / agent / workflow use
-> citation, audit trace, feedback and challenge
-> correction, versioning, retirement and forgetting
The stack should make every AI answer or agent action traceable to:
- What source or memory asset was used.
- Which version and effective date applied.
- Who owned the source.
- Why it was allowed for this user, purpose, channel, jurisdiction, and model.
- Whether the output cited the source accurately.
- Whether feedback later challenged the asset or the output.
2.2 Memory Boundaries
| Boundary | Good design | Failure mode |
|---|---|---|
| Memory vs source of truth | Memory points to and summarizes authoritative systems, but does not replace them | AI answer treats a cached summary as account status |
| Memory vs audit | Audit traces support reconstruction; they do not automatically become personalization memory | Complaint details appear in future marketing prompts |
| Memory vs inference | Stored memory records verified facts or authorized preferences, not speculative personality labels | Model infers a vulnerable customer profile and reuses it |
| Memory vs training | Retrieval memory can be deleted or versioned; training data may be hard to remove after model adaptation | Teams send complaint logs into fine-tuning without deletion impact analysis |
| Memory vs knowledge | A remembered interaction is not policy knowledge until reviewed and promoted | Call center workaround becomes "policy" after repeated retrieval |
3. Memory Type Taxonomy
AI memory governance needs a taxonomy because each type has different owner, risk, retention, evidence, and reuse rules.
| Memory type | Definition | Financial retail example | Default use stance |
|---|---|---|---|
| Session memory | Short-lived current conversation or task context | Customer is asking about a fee dispute in the current call | Use within session, clear on task or identity boundary |
| Working memory | Temporary task state, drafts, hypotheses, intermediate tool results | AML copilot stores candidate transaction clusters during investigation | Use for task completion, mark unverified, expire quickly |
| Semantic memory | Stable domain knowledge, concepts, rules, and procedures | Contact center refund policy, KYC document requirements | Use with source authority, version, citation, freshness |
| Policy memory | Approved rules, controls, standards, and interpretation boundaries | Credit policy exception criteria, call recording disclosure rule | Use only from approved sources and effective versions |
| Decision memory | Rationale for significant choices and accepted tradeoffs | ADR for using GraphRAG in AML investigation workbench | Reuse as rationale context, not as automatic approval |
| Case memory | Prior case facts, investigation notes, complaint outcomes, exception decisions | KYC onboarding exception for complex ownership structure | Reuse for precedent learning with privacy and applicability controls |
| Customer preference memory | Explicit or authorized customer/staff preferences | Customer requests paperless statements and Spanish service language | Use transparently, let user inspect, edit, pause, delete where allowed |
| Feedback memory | Human review, QA, eval, user correction, incident-derived lessons | Agent marked citation unsupported for fee-waiver answer | Use for improvement, routing, regression, and steward review |
| Audit memory | Immutable or controlled evidence of what happened | Prompt manifest, retrieval result IDs, reviewer decision, tool call trace | Use for investigation and audit, not default prompt context |
| Prohibited memory | Information the AI system must not store or reuse for a purpose | Sensitive inferred vulnerability label for sales targeting | Block capture, purge if found, record incident where required |
| Retired memory | Formerly valid memory no longer active for retrieval or reuse | Superseded KYC SOP, retired model selection ADR | Keep archival trace if required, block active retrieval |
| Challenge memory | Record that a source, answer, rationale, or decision is disputed | Compliance challenges interpretation of regulatory reporting rule | Use to suppress or warn until resolved |
3.1 Advanced Distinctions
| Confusion | Better framing |
|---|---|
| "The model remembered it" | The application, memory service, index, prompt log, cache, or training artifact persisted it |
| "RAG is our memory" | RAG is a retrieval pattern; memory governance requires source authority, lifecycle, provenance, and allowed-use controls |
| "A decision log is documentation" | Decision memory is a reusable architecture and product asset with status, assumptions, triggers, citations, and consequences |
| "Old case examples are precedent" | Case memory needs applicability constraints; one exception does not become universal policy |
| "Deletion means remove from the database" | Forgetting must cover document stores, vector indexes, caches, prompt logs, eval sets, feedback stores, derived summaries, and vendor copies |
4. Knowledge Asset Taxonomy
Knowledge assets should be treated as governed product assets. Each asset needs metadata that supports AI use, not only human browsing.
| Asset family | Examples | Required metadata | AI-specific risk |
|---|---|---|---|
| Authoritative policy | KYC policy, AML standards, credit risk policy, complaint handling policy | owner, authority level, version, effective date, jurisdiction, approval status, citation granularity | wrong version or jurisdiction used in answer |
| Procedure and SOP | Contact center SOP, branch onboarding guide, regulatory reporting checklist | process owner, step version, control point, exception path, channel applicability | AI gives operational steps that conflict with policy |
| Product and customer knowledge | fee schedule, account terms, offer rules, FAQ | product owner, customer segment, channel, language, source terms | simplified FAQ overrides legal terms |
| Decision records | ADR, risk acceptance, model selection memo, architecture review record | decision owner, status, options, rationale, evidence, assumption, trigger, replacement | old rationale copied after assumptions changed |
| Case knowledge | complaint RCA, AML SAR typology, KYC exception, fraud pattern | case owner, sensitivity, anonymization, applicability, pattern confidence | sensitive facts reused outside original purpose |
| Data and metric definitions | regulatory reporting interpretation, KPI definition, data lineage note | data owner, calculation rule, source system, validity period, attestation owner | AI explains wrong metric or stale report logic |
| Ontology and taxonomy | customer type hierarchy, complaint reason taxonomy, AML typology ontology | concept owner, label, definition, relationship, version, mapping | retrieval slices and evals use inconsistent terms |
| Eval and failure knowledge | golden sets, red-team cases, incident regression cases, QA rubrics | dataset owner, source, sensitivity, retention, coverage, failure class | sensitive production examples leak into broad test access |
| Reusable patterns | RAG pattern, human-review pattern, tool gateway pattern, evidence extraction pattern | pattern owner, applicability, constraints, controls, variants, deprecation | teams reuse implementation without inherited assumptions |
4.1 Knowledge Asset Card
Every AI-consumable knowledge asset should have a card:
| Field | Description |
|---|---|
| asset_id | Stable identifier used across source registry, index, KG, eval, trace, and audit |
| asset_type | policy, SOP, ADR, case, metric definition, ontology, eval, pattern |
| business_domain | AML, KYC, complaints, credit, deposits, cards, regulatory reporting, architecture |
| authority_level | external binding, internal approved policy, approved procedure, system of record, training material, operational note |
| owner | accountable person or role |
| steward | role responsible for curation, metadata, review, and correction |
| version_authority | role or system allowed to create an active version |
| effective_period | start and end dates or event conditions |
| jurisdiction_scope | geography, legal entity, product line, customer segment |
| allowed_ai_use | retrieve, cite, summarize, draft, classify, recommend, train, eval, audit only |
| prohibited_ai_use | uses explicitly blocked |
| citation_requirement | none, source-level, clause-level, evidence-span-level |
| freshness_slo | expected review interval or change trigger |
| retention_class | operational, regulatory, audit, legal hold, ephemeral, deletable |
| retirement_rule | when and how it leaves active retrieval |
| challenge_route | who resolves disputes and what happens while disputed |
4.2 Version Authority
Version authority is the right to declare a memory asset active for AI use. It is more specific than content ownership.
| Asset | Content owner | Version authority | Why the distinction matters |
|---|---|---|---|
| KYC policy | Compliance | Compliance policy office | Branch teams may comment, but cannot activate policy memory |
| Contact center SOP | Operations | Process owner with compliance review | A local workaround cannot become active SOP memory |
| AML typology library | Financial Crime | Typology governance forum | Analyst notes require promotion before broad reuse |
| Credit policy decision | Credit Risk | Credit policy committee | Product teams cannot reinterpret credit criteria through AI prompts |
| Architecture ADR | Architecture owner | Architecture decision forum | Implementation teams can propose supersession, not silently replace rationale |
| Regulatory reporting interpretation | Finance / Regulatory Reporting | Attestation owner with Compliance | AI cannot reuse analyst interpretation after reporting rule changes without review |
5. Decision Memory Architecture
Decision memory is the structured record of why a significant choice was made, what evidence supported it, what assumptions were accepted, and when it must be reopened.
5.1 What Counts as Decision Memory
| Decision type | Example | Required memory elements |
|---|---|---|
| Product scope decision | Agent assist drafts complaint response but does not send it | user impact, risk tier, excluded actions, evidence, review trigger |
| Architecture decision | Use hybrid RAG plus policy graph for KYC assistant | alternatives, quality attributes, data constraints, citation tests, consequences |
| Model decision | Route low-risk FAQ to small model and high-risk complaint cases to stronger model | eval comparison, cost, latency, risk, fallback, monitoring |
| Data/knowledge source decision | Exclude operational notes from active contact center policy memory | authority rationale, inclusion rule, exception route |
| Risk acceptance | Limited launch despite citation precision below target for low-risk article summaries | residual risk, owner, compensating controls, expiry, monitoring |
| Policy interpretation | Regulatory reporting team defines how to interpret a new field mapping | source anchor, jurisdiction, approver, effective period, impacted reports |
| KYC exception precedent | Complex ownership structure accepted after enhanced due diligence | facts, rule applied, exception reason, non-precedent warning, privacy control |
| Complaint RCA decision | Fee disclosure script revised after repeated customer harm pattern | root cause, corrective action, affected knowledge assets, regression tests |
5.2 Decision Memory Object
| Field | Purpose |
|---|---|
| decision_id | Stable ID used in PRD, ADR, release notes, eval, and audit |
| title | Clear decision statement |
| status | draft, proposed, accepted, conditionally accepted, challenged, superseded, retired |
| decision_owner | accountable role |
| affected_capability | business or architecture capability |
| affected_memory_assets | sources, indexes, prompts, policies, ontology, evals, case libraries |
| options_considered | realistic alternatives, including no-AI or no-change |
| rationale | concise reason for the decision |
| evidence | linked eval, source, metric, risk assessment, user research, incident, legal interpretation |
| assumptions | statements that must remain true |
| triggers | events that reopen the decision |
| consequences | benefits, tradeoffs, constraints, costs, risks |
| citation_rule | how future teams may cite or reuse the decision |
| review_date | freshness point |
| successor | replacement decision if superseded |
5.3 ADR Memory
Architecture Decision Records are a core form of decision memory. For AI systems, ADR memory must include:
- Model, prompt, knowledge, tool, eval, and policy versions affected by the decision.
- Quality attribute tradeoffs such as accuracy, latency, explainability, cost, resilience, security, maintainability, and auditability.
- Evidence freshness and trigger conditions.
- Reuse boundary: which teams may reuse the rationale and which must revalidate it.
- Supersession path: how old decisions remain visible without staying active.
Example:
| ADR memory question | Strong answer |
|---|---|
| Why GraphRAG for AML typology investigation? | Multi-hop entity relationships, evidence paths, and typology-to-case explanation are decision-critical, while simple FAQ retrieval failed on relationship questions |
| What would reopen it? | Material graph quality defects, typology changes, latency above SLO, analyst override trend, model provider change, regulatory challenge |
| Can another team reuse it? | Fraud investigation may reuse graph evidence pattern after local ontology review; contact center FAQ may not inherit this decision |
6. Memory Lifecycle
AI memory lifecycle should be explicit because memory can become more valuable or more dangerous over time.
discover
-> classify
-> validate
-> approve
-> index / publish
-> retrieve / cite / use
-> observe
-> challenge / correct
-> version / supersede
-> retire / archive / delete
-> learn
| Stage | Key question | Evidence |
|---|---|---|
| Discover | Is this candidate memory worth governing? | source inventory, case pattern, incident, decision trigger |
| Classify | What type, sensitivity, authority, retention, and allowed use apply? | asset card, data classification, purpose map |
| Validate | Is it accurate, current, permissioned, and fit for AI use? | steward review, ingestion QA, citation test, conflict test |
| Approve | Who can activate it for retrieval or reuse? | owner approval, version authority, release record |
| Publish | How does it enter document store, KG, RAG index, decision repository, eval set, or memory service? | index manifest, graph version, registry update |
| Use | How is it retrieved, cited, summarized, or acted on? | prompt manifest, retrieval trace, citation support, tool trace |
| Observe | Is it helping, harming, or drifting? | quality metrics, user feedback, QA sampling, incident signals |
| Challenge | How can users, staff, risk partners, or systems dispute it? | challenge record, suppression state, reviewer decision |
| Correct | How are errors fixed and downstream artifacts updated? | change record, rebuild event, regression case |
| Version | What changed and what remains valid? | diff, effective date, successor link |
| Retire | When does it stop active retrieval or reuse? | retirement log, active index purge, warning state |
| Forget | What must be deleted or no longer used? | deletion orchestration, purge certificate, vendor attestation |
| Learn | What lesson becomes reusable institutional memory? | RCA, updated policy, new eval, revised pattern |
6.1 Promotion Path
Not every memory candidate should become authoritative. Promotion should be staged.
| Level | Name | Example | Allowed use |
|---|---|---|---|
| L0 raw signal | A call-center agent reports repeated confusion about fee reversals | triage only | |
| L1 candidate memory | A pattern is recorded with examples and steward | internal review | |
| L2 reviewed memory | Operations confirms pattern and links affected SOP | low-risk internal retrieval with warning | |
| L3 approved memory | Process owner updates SOP and version authority publishes | active retrieval and citation | |
| L4 institutional memory | Complaint RCA adds regression tests and training update | reuse across products under scope |
6.2 Demotion and Retirement Path
Memory must also move down the maturity ladder.
| Trigger | Action |
|---|---|
| Source superseded | Mark old version superseded, block active retrieval, preserve archive if required |
| Owner unavailable | Move asset to restricted state until ownership is re-established |
| Citation failure trend | Suppress asset from high-risk answers and open steward review |
| Conflicting authority | Route to source authority owner and show conflict warning |
| Complaint or incident | Freeze memory asset where appropriate, create regression case, reopen decision |
| Retention expiry | Remove from active stores, purge indexes, keep lawful audit metadata where permitted |
7. Governance and Ownership
AI memory needs explicit ownership because unowned knowledge becomes stale knowledge.
7.1 Core Roles
| Role | Responsibility |
|---|---|
| Knowledge Asset Owner | Accountable for accuracy, authority, approval, review, retirement, and allowed use |
| Knowledge Steward | Maintains metadata, source registry, curation, issue triage, and quality checks |
| Version Authority | Approves active versions and effective periods |
| Memory Platform Owner | Owns memory service, indexing, lineage, deletion orchestration, access controls, and observability |
| AI Product Owner | Defines product-specific memory use, value metrics, UX, escalation, and feedback loop |
| AI Architect | Designs memory integration, retrieval, KG, context composer, traceability, and fallback |
| Data / Privacy Owner | Defines sensitivity, purpose, retention, deletion, and sharing limits |
| Risk / Compliance Partner | Reviews high-risk memory use, policy interpretation, challenge workflow, and residual risk |
| Records Manager | Aligns memory lifecycle with records retention, legal hold, archival, and disposition |
| Human Reviewer / SME | Validates correctness, resolves disputes, and promotes or demotes candidate memory |
| Internal Audit | Tests whether memory governance is operating as designed |
7.2 RACI Snapshot
| Activity | PM | Architect | Knowledge Owner | Steward | Risk/Compliance | Privacy/Data | Records | Platform |
|---|---|---|---|---|---|---|---|---|
| Define memory use case | A | C | C | C | C | C | C | C |
| Classify asset | C | C | A | R | C | C | C | C |
| Approve active version | C | C | A/R | C | C | C | C | I |
| Publish to RAG/KG | C | A | C | R | C | C | I | R |
| Set retention and forgetting | C | C | C | C | C | A/R | A/R | R |
| Resolve challenge | C | C | A | R | C | C | C | I |
| Retire memory | C | C | A | R | C | C | C | R |
| Report quality metrics | A | R | C | R | C | C | I | R |
8. Retention and Forgetting
AI memory governance must support remembering and forgetting. Forgetting is not only deletion; it can include suppressing active retrieval, removing from personalization, retiring a version, narrowing allowed use, or archiving for audit.
8.1 Retention Classes
| Class | Description | Example | Default handling |
|---|---|---|---|
| Ephemeral | Needed only for current task or session | temporary AML investigation scratchpad | expire quickly, not reused |
| Operational active | Needed for ongoing operations | current contact center SOP | active retrieval with freshness SLO |
| Decision evidence | Needed to explain a significant choice | ADR, risk acceptance, policy interpretation | retain with status and review trigger |
| Regulatory / records | Required by formal records schedule | complaint handling record, reporting attestation | retain under records policy |
| Audit trace | Needed for reconstruction and accountability | prompt manifest, retrieval trace, reviewer decision | restricted access, minimization |
| Learning asset | Anonymized or approved lesson for future improvement | complaint RCA pattern, incident regression case | use with sensitivity and applicability controls |
| Prohibited | Not allowed for storage or reuse in this context | inferred sensitive customer vulnerability for cross-sell | block, purge, investigate if captured |
8.2 Forgetting Patterns
| Pattern | Use when | What happens |
|---|---|---|
| Context reset | User changes task, customer, role, product, or authenticated identity | clear session and working memory |
| Active retrieval suppression | Asset is challenged, stale, conflicted, or out of scope | source remains archived but is not retrieved |
| Version supersession | New policy or decision replaces old one | old version marked superseded and linked to successor |
| Purpose withdrawal | Customer or owner withdraws allowed use where permitted | remove from future personalization or training eligibility |
| Targeted purge | Source deleted or retention expires | purge chunks, embeddings, summaries, caches, and index references |
| Legal hold override | Deletion is blocked by formal hold | suspend deletion, restrict use, record hold authority |
| Model adaptation exclusion | Data cannot be removed from trained weights reliably | prevent entry into training path or isolate adapter for retirement |
8.3 Prohibited Memory
Prohibited memory should be explicit. Examples in financial retail:
- Inferred health status, vulnerability, hardship, or protected-class proxy used for sales targeting.
- Raw authentication secrets, one-time passcodes, passwords, security answers, full card numbers, or unnecessary identity documents in prompt memory.
- Unreviewed employee workarounds promoted as policy.
- Customer complaint details reused for unrelated personalization.
- Analyst suspicion notes reused as factual customer profile outside financial crime workflow.
- Legal advice, regulatory interpretation, or audit conclusion generated by AI and stored as authoritative without approved owner.
9. Trust, Citation, and Provenance
Trustworthy AI memory requires the system to show where knowledge came from, why it applies, and whether it remains current.
9.1 Citation Levels
| Level | Description | Suitable for |
|---|---|---|
| C0 no citation | Output does not need a source reference | low-risk brainstorming or formatting |
| C1 source citation | Cite document or source asset | internal training overview |
| C2 section citation | Cite section, clause, page, or policy paragraph | contact center policy answer |
| C3 claim citation | Each critical claim is tied to evidence span | KYC requirement, credit policy, complaint response |
| C4 decision citation | Output cites decision record, rationale, assumptions, and status | architecture recommendation, risk acceptance reuse |
| C5 replayable evidence | Answer can be reconstructed from prompt manifest, retrieval trace, model version, source versions, and reviewer action | regulated workflow, audit investigation |
9.2 Provenance Model
W3C PROV-style thinking maps cleanly to AI memory:
| PROV concept | AI memory mapping |
|---|---|
| Entity | policy document, clause, ADR, case note, prompt manifest, retrieval result, output, eval item, feedback record |
| Activity | ingest, classify, chunk, embed, retrieve, compose context, invoke model, review, correct, retire, purge |
| Agent | knowledge owner, steward, user, service account, model endpoint, reviewer, vendor, records manager |
| wasDerivedFrom | chunk derived from policy document; eval item derived from complaint incident |
| wasGeneratedBy | output generated by model invocation using prompt manifest |
| wasAssociatedWith | retrieval activity associated with application service account |
| wasAttributedTo | memory asset attributed to knowledge owner |
OpenLineage-style events can make this operational:
source document updated
-> ingestion job run
-> chunk dataset changed
-> embedding index version changed
-> KG graph version changed
-> retrieval eval run
-> release decision recorded
-> affected products notified
9.3 Trust Rules
| Rule | Why it matters |
|---|---|
| No source, no high-risk answer | Prevents fluent unsupported assertions |
| No owner, no active memory | Prevents unmaintained knowledge from entering production context |
| No effective date, no policy use | Prevents old or future policy from being used at the wrong time |
| No permission, no retrieval | Prevents cross-role and cross-purpose leakage |
| No challenge path, no trust | Users and staff need a route to correct memory |
| No lineage, no replay | Audit and incident teams must reconstruct what happened |
10. Knowledge Graph, RAG, and Memory Integration
AI memory architecture should not force every knowledge problem into one pattern. RAG, knowledge graphs, decision repositories, and memory services each solve different problems.
| Component | Best for | Not enough for |
|---|---|---|
| Document store | Authoritative source retention, versioned documents, access control | semantic relationships, claim-level evidence, retrieval ranking |
| Vector index | semantic recall over text chunks | authority, provenance, lifecycle, exact rules, structured relationships |
| Knowledge graph | entities, relationships, claims, evidence paths, ontology, conflict handling | long-form source storage by itself |
| Decision repository | ADRs, risk acceptances, policy interpretations, status and rationale | real-time retrieval unless indexed and governed |
| Memory service | user/session/task/case memory with scope, TTL, permissions | enterprise knowledge authority by itself |
| Context composer | selects current evidence for model call | source governance without upstream registry |
| Lineage/event layer | traces transformations and affected assets | human meaning without stewardship |
10.1 Integration Pattern
Source Registry
-> Document Store
-> Knowledge Graph for entities, claims, decisions and source authority
-> Vector Index for semantic recall with metadata filters
-> Decision Repository for ADR and policy interpretation memory
-> Memory Service for session, working, case and preference memory
-> Context Composer with policy, freshness and citation controls
-> AI Runtime with trace, feedback, challenge and correction loop
10.2 Retrieval Freshness
Retrieval freshness measures whether the answer is grounded in current and applicable memory.
| Freshness control | Example |
|---|---|
| Source freshness | Contact center fee policy reviewed within required cycle |
| Index freshness | Vector index built from latest approved source snapshot |
| Graph freshness | KYC entity and rule graph version matches policy version |
| Decision freshness | ADR assumptions reviewed after model provider changed terms |
| Case freshness | AML typology pattern reviewed after new suspicious behavior trend |
| Citation freshness | Answer cites active clause, not retired clause |
11. Change, Retirement, and Knowledge Debt
Knowledge debt accumulates when AI systems keep using old assumptions, unowned documents, uncited claims, duplicated definitions, obsolete eval cases, or retired decisions.
11.1 Knowledge Debt Types
| Debt type | Symptom | Risk |
|---|---|---|
| Stale source debt | Old policy versions still retrievable | customer harm, regulatory breach, operational error |
| Ownership debt | Knowledge assets have no accountable owner | no one updates or retires memory |
| Citation debt | Answers cite documents weakly or not at all | low trust and weak auditability |
| Decision debt | Teams cannot explain why model, RAG, vendor, or policy choices were made | repeated debate, bad reuse, architecture drift |
| Ontology debt | Same concept has multiple labels and meanings | poor retrieval, inconsistent analytics, eval slice failure |
| Feedback debt | Corrections and incidents do not update memory | repeated failures |
| Retirement debt | Superseded knowledge remains active | old rules continue influencing AI behavior |
| Context debt | Prompt context grows without pruning or purpose | leakage, cost, confusion, lower quality |
11.2 Retirement Events
| Event | Retirement action |
|---|---|
| New policy version | mark old version superseded, rebuild index, rerun eval, notify products |
| Product discontinued | retire product knowledge, archive obligations, purge active prompts |
| ADR superseded | keep old rationale, block it as active recommendation, link successor |
| Regulatory interpretation changed | reopen affected decision memory, update reporting knowledge, create audit note |
| Complaint RCA completed | promote approved lesson, retire incorrect script, add regression case |
| Vendor exits | retire vendor-specific pattern, migrate memory integration, preserve audit trace |
12. Quality Metrics
AI memory quality should be measured at asset, retrieval, output, governance, and learning levels.
| Metric family | Example metrics |
|---|---|
| Asset quality | percentage with owner, effective date, authority level, retention class, citation granularity |
| Freshness | assets past review date, index lag, graph lag, decision review overdue |
| Retrieval | grounded recall, authority-filter pass rate, stale retrieval rate, permission-filter violation rate |
| Citation | citation precision, unsupported critical claims, citation-to-active-version rate |
| Use quality | answer correctness by memory type, human override rate, edit distance, escalation rate |
| Challenge | challenge volume, time to triage, time to correction, repeat challenge rate |
| Retirement | superseded assets still retrieved, purge completion time, orphaned embeddings |
| Learning | incident-to-regression conversion, RCA-to-policy update time, recurring failure rate |
| Reuse | approved pattern reuse count, decision memory reuse with validation, avoided duplicate work |
| Knowledge debt | unowned asset count, duplicate concept count, stale decision count, context bloat |
Quality target examples:
- 100 percent of high-risk policy memory has owner, effective period, authority level, citation granularity, and review trigger.
- Zero active retrieval of retired policy clauses in production.
- Critical financial retail answers require claim-level citation support above the release gate threshold.
- Complaint RCA lessons enter regression memory within the agreed review cycle.
- All L3/L4 architecture decisions have reopen triggers and review dates.
13. Operating Model
13.1 Governance Forums
| Forum | Cadence | Decisions |
|---|---|---|
| Memory intake triage | weekly | classify candidate memory, route ownership, reject prohibited memory |
| Knowledge steward review | weekly or biweekly | approve metadata, resolve conflicts, correct stale assets |
| Decision memory review | monthly | reopen stale ADRs, risk acceptances, policy interpretations |
| Memory quality review | monthly | review freshness, citation, challenge, retirement, and knowledge debt metrics |
| Product memory review | release-based | approve memory changes that affect AI behavior |
| Management-system review | quarterly | assess operating effectiveness, risk trends, investment, and institutional learning |
13.2 Control Planes
| Control plane | Questions |
|---|---|
| Authority | Which source wins in conflict? |
| Access | Who can retrieve, cite, view, edit, approve, or delete memory? |
| Purpose | Which AI use is allowed for this asset? |
| Freshness | How does the system know memory is current? |
| Provenance | Can we reconstruct source-to-output lineage? |
| Citation | Are claims supported at the right granularity? |
| Challenge | Can users and staff dispute memory and see resolution? |
| Retention | What must be retained, deleted, suppressed, or archived? |
| Reuse | When can one product inherit memory, evidence, or decisions from another? |
| Learning | How do incidents and feedback change the memory system? |
14. Financial Retail Examples
14.1 Contact Center Policy Memory
| Design element | Example |
|---|---|
| Memory assets | fee policy, waiver SOP, escalation matrix, approved scripts, complaint trigger list |
| Key risk | old fee waiver rule retrieved after policy change |
| Controls | effective-date filtering, clause-level citation, source owner, index rebuild event, QA sampling |
| Learning loop | repeated agent edits trigger SOP review and new eval cases |
14.2 AML Typology Memory
| Design element | Example |
|---|---|
| Memory assets | typology library, case pattern catalog, SAR narrative examples, entity relationship ontology |
| Key risk | one investigation note becomes broad suspicious label |
| Controls | case anonymization, typology promotion gate, analyst review, graph provenance, applicability warning |
| Learning loop | confirmed new typology updates detection playbook and investigator copilot eval |
14.3 KYC Onboarding Exceptions
| Design element | Example |
|---|---|
| Memory assets | exception rationale, approved evidence, beneficial ownership interpretation, jurisdiction notes |
| Key risk | exception precedent reused for a materially different customer |
| Controls | non-precedent flag, customer-segment scope, privacy restrictions, compliance challenge route |
| Learning loop | repeated exception pattern triggers policy clarification or process redesign |
14.4 Complaint RCA Knowledge Base
| Design element | Example |
|---|---|
| Memory assets | complaint taxonomy, RCA, remediation action, affected policy, customer communication template |
| Key risk | remediation not connected to AI assistant answer policy |
| Controls | RCA-to-knowledge mapping, regression cases, owner sign-off, closure evidence |
| Learning loop | complaint spike updates scripts, eval cases, and product roadmap |
14.5 Credit Policy Decisions
| Design element | Example |
|---|---|
| Memory assets | credit policy committee decisions, underwriting rationale, affordability interpretation |
| Key risk | AI assistant gives implied approval criteria from old decision |
| Controls | policy authority hierarchy, decision status, effective period, risk-owner review |
| Learning loop | override trends reopen policy interpretation memory |
14.6 Regulatory Reporting Interpretation Memory
| Design element | Example |
|---|---|
| Memory assets | data definition, interpretation memo, attestation logic, lineage map |
| Key risk | AI draft report uses stale interpretation after regulatory update |
| Controls | source anchors, attestation owner, report-period scope, decision review trigger |
| Learning loop | regulator question updates interpretation memory and reporting eval set |
14.7 Architecture Decision Repository
| Design element | Example |
|---|---|
| Memory assets | ADRs for model routing, RAG architecture, tool permission, retention, vendor exit |
| Key risk | teams copy an old ADR without checking assumptions |
| Controls | ADR status, successor link, reuse qualification, trigger events, evidence freshness |
| Learning loop | incident postmortem reopens ADR and updates reference implementation |
15. Anti-Patterns
| Anti-pattern | Why it fails | Better approach |
|---|---|---|
| Upload-and-pray memory | Treats all documents as equally valid | Source authority matrix and active version control |
| Infinite memory | Saves everything because it may be useful later | Purpose-specific retention and minimization |
| Vector database as governance | Confuses retrieval infrastructure with memory policy | Registry, provenance, stewardship, and lifecycle controls |
| Decision amnesia | Teams remember what was chosen but not why | Decision memory with rationale, assumptions, triggers, and consequences |
| Copy-paste precedent | Reuses case exceptions outside context | Applicability constraints and non-precedent flags |
| Silent retirement | Old policy replaced in source system but index remains active | lineage event, index rebuild, retrieval suppression, regression test |
| Weak citation theater | Answer includes links that do not support critical claims | claim-level citation tests |
| Feedback black hole | User corrections become tickets but not knowledge updates | feedback-to-memory and incident-to-regression workflow |
| Ownerless knowledge | Assets have no accountable role | no active retrieval without owner |
| Memory poisoning by convenience | Unreviewed summaries, workarounds, or malicious content enter shared memory | promotion gate, provenance, challenge, anomaly monitoring |
16. Interview Answers
Question 1: What is AI organizational memory?
Short answer:
AI organizational memory is the governed set of knowledge, decisions, cases, preferences, evidence and lessons that AI systems are allowed to retrieve, cite, reuse, challenge, retire or forget across products and teams.
Senior answer:
AI organizational memory is not generic knowledge management and not only long-term chat history. It is the control layer that determines which organizational knowledge can enter AI context, which decision rationale can be reused, which case lessons can become institutional learning, and which information must be suppressed, retired, deleted or kept only for audit. In financial retail, this covers contact center policy memory, AML typology memory, KYC exception memory, credit policy decisions, complaint RCA memory, regulatory reporting interpretation memory, and architecture decision memory. The governance design must include owner, authority, version, provenance, citation, retention, freshness, challenge, and retirement.
Question 2: How do you prevent stale knowledge in RAG systems?
Strong answer:
I would not rely on vector refresh alone. I would start with a knowledge source registry that records owner, authority level, effective date, review trigger and active status. Ingestion should generate lineage events and index manifests. Retrieval must filter by effective period, jurisdiction, product, permission and active state. High-risk answers require citation to active clauses. Monitoring should track stale retrieval rate, index lag, graph lag and citation-to-active-version rate. When a source is superseded, the system should suppress old chunks, rebuild indexes, rerun regression evals and notify affected products.
Question 3: How should an organization decide what AI should forget?
Strong answer:
Forgetting should be designed by memory type and purpose. Session and working memory should expire quickly. Preference memory should be user-visible and adjustable. Policy memory should be superseded rather than erased if records retention requires archive. Prohibited memory should be blocked and purged. Audit memory may need restricted retention for reconstruction, but should not be reused for personalization. Deletion orchestration must cover document stores, embeddings, indexes, caches, prompt logs, eval sets, feedback stores and vendor environments. Legal hold and records schedules must be explicit exceptions, not hidden behavior.
Question 4: What is decision memory and why does it matter?
Strong answer:
Decision memory is the structured record of why significant product, architecture, risk or policy choices were made. It includes options, rationale, evidence, assumptions, triggers, consequences, status and successor decisions. It matters because AI systems scale decisions. If teams reuse an old ADR, model selection memo or policy interpretation without context, they inherit stale assumptions. Decision memory lets future teams challenge, supersede or reuse the rationale responsibly.
Question 5: How do you handle memory poisoning?
Strong answer:
I would treat memory poisoning as a lifecycle and provenance problem. Candidate memory should not become active without classification, source authority, steward review and allowed-use controls. Runtime feedback and operational notes need promotion gates before they become policy memory. Retrieval should enforce authority filters and citation checks. Monitoring should detect unusual source changes, citation failures, challenge spikes and retrieval of low-authority assets. Correction requires suppression, root-cause analysis, downstream index purge, regression tests and owner review.
17. Portfolio Exercise
Create a portfolio artifact titled:
AI Organizational Memory and Knowledge Asset Governance Architecture for a Financial Retail Enterprise
Scenario
A bank has launched AI assistants for contact center agents, KYC onboarding analysts, AML investigators, complaint handlers, regulatory reporting analysts and architecture teams. Each assistant uses separate document stores and prompt histories. Teams complain that answers are inconsistent, old policy appears in RAG results, case exceptions are reused incorrectly, ADRs are hard to find, and complaint lessons do not update AI behavior.
Deliverables
| Deliverable | What to include |
|---|---|
| Memory taxonomy | session, working, semantic, policy, decision, case, preference, feedback, audit, prohibited, retired |
| Knowledge asset registry | fields for owner, version authority, source authority, allowed use, retention, citation, freshness |
| Decision memory model | ADR, policy interpretation, risk acceptance, KYC exception, complaint RCA, credit policy decision |
| Architecture view | source registry, document store, KG, vector index, memory service, context composer, lineage, challenge loop |
| Lifecycle workflow | capture, classify, validate, approve, publish, use, observe, challenge, correct, version, retire, forget |
| RACI | owner, steward, PM, architect, risk, privacy, records, platform, audit |
| Metrics | stale retrieval, citation precision, challenge closure, index lag, orphaned memory, knowledge debt |
| Financial retail example | contact center policy memory or KYC onboarding exception memory |
| Executive narrative | why this reduces risk, improves reuse, and creates institutional learning |
Evaluation Rubric
| Dimension | Strong evidence |
|---|---|
| AI-centered | Shows how memory affects prompt context, retrieval, citation, agent action and product behavior |
| Governance depth | Includes owner, authority, retention, forgetting, challenge, and retirement |
| Architecture clarity | Separates source of truth, index, graph, memory service, audit trace and context composer |
| Financial retail specificity | Uses real examples from AML, KYC, complaints, credit, reporting or contact center |
| Senior judgment | Explains tradeoffs, stale knowledge risk, memory poisoning, provenance, and institutional learning |
18. Final Mental Model
The mature organization does not ask whether AI can remember more. It asks whether the organization can manage memory as a trusted, versioned, cited, challengeable and forgettable product asset.
Remember what is authoritative.
Reuse what is proven and still applicable.
Challenge what is disputed.
Retire what is superseded.
Forget what is no longer allowed.
Cite what supports a claim.
Learn from what failed.
That is the difference between an AI system that accumulates context and an enterprise that builds institutional intelligence.