AI Context Supply Chain / Provenance / Poisoning Defense Architecture

Batch 160 foundation note for Senior AI PM / AI Architect / Data Product Manager / Security Architect / CBAP-level BA. Core question: how do prompts, system instructions, RAG documents, embeddings, metadata, tool outputs, memory, user profiles, policy snippets and workflow state become a governed context supply chain with provenance, quality, permissions, poisoning defense and change control? Important note: this document is a learning and portfolio artifact. It is not legal advice, compliance advice, audit opinion, model validation, security certification, regulatory interpretation or production approval. Formal decisions require review by accountable business, risk, compliance, legal, privacy, security, model risk, data governance, architecture, operations and audit roles. Access date for source anchors: 2026-06-30.

---

Source Anchors

These anchors are used as architecture and product design references. They do not create a complete control catalog by themselves.

Source-use discipline:

• Treat official sources as anchors for language and evidence design, not as copy-paste requirements.
• Record source authority, access date, internal owner, applicability, affected workflow and change trigger.
• Separate formal policy, system-of-record data, vendor documentation, user-provided content, model output and analyst commentary.
• When a source changes, refresh affected context assets, indexes, eval cases, release gates and user-facing trust claims.

One-sentence thesis:

Enterprise AI quality and safety depend less on a single prompt than on a governed context supply chain: every context object needs authority, lineage, permission, quality, change control, runtime traceability and poisoning defense.

---

1. Executive Summary

Many AI failures are described as "the model hallucinated" or "RAG returned the wrong answer." In mature financial retail AI systems, the deeper failure is often context supply chain failure:

• A retired credit policy snippet remains in the vector index.
• A user profile attribute is joined without permission or purpose.
• A PDF uploaded by a customer includes indirect prompt injection and is treated as instruction.
• A tool observation from a downstream system is stale, partial or outside its data contract.
• A memory write turns a one-time exception into a persistent future instruction.
• An AML typology article from a low-authority source outranks the approved internal typology pack.
• A branch relationship manager copilot uses customer notes from an unaudited CRM field to draft advice-like language.

Context is not only text. It is every artifact that shapes the model's behavior:

system instruction
+ developer instruction
+ prompt template
+ user request
+ workflow state
+ retrieved documents
+ retrieved metadata
+ embeddings and index configuration
+ user profile
+ case history
+ memory
+ tool observations
+ policy snippets
+ examples
+ output schema
+ runtime policy decisions

The product and architecture challenge is that these assets come from different owners, systems, permissions, quality levels and change cadences. Once assembled into a prompt or agent state, they can override each other, conflict, leak data, become stale, or carry adversarial instructions.

A mature context supply chain therefore needs five integrated capabilities:

The senior-level move is to stop treating context as transient prompt material and start treating it as a managed product surface with owners, contracts, releases, SLOs, runtime traces and customer trust implications.

---

2. Target Audience

---

3. Learning Objectives

After studying this note, you should be able to:

1. Explain why context is a supply chain, not a prompt appendix.
2. Build a context asset taxonomy covering prompts, system instructions, RAG documents, embeddings, metadata, tool outputs, memory, user profiles, policy snippets and workflow state.
3. Define a context object schema with source authority, provenance claim, trust tier, permission scope, quality fields and release identity.
4. Design provenance and lineage across source documents, chunking, embedding, index builds, retrieval, prompt assembly, tool observations and final output.
5. Apply retrieval-time policy enforcement so unauthorized context is never retrieved, not merely hidden by prompt instruction.
6. Define memory write policy and tool observation validation for agentic workflows.
7. Detect and manage context drift, context poisoning, indirect prompt injection, stale policy and citation laundering.
8. Specify context quality SLOs and runtime context traces that connect product trust, eval, incident response and audit.
9. Create financial retail examples for customer service policy RAG, AML typology knowledge, KYC evidence documents, credit policy snippets, regulatory reporting instructions, collections hardship scripts and branch relationship manager copilot.
10. Answer senior interview questions about context provenance, poisoning defense and architecture controls.

---

4. Core Thesis: Context Is A Product Surface

Traditional prompt thinking treats context as a temporary string:

retrieve a few chunks
+ append instructions
+ call model
+ display answer

Enterprise AI must treat context as a product surface because context determines:

• what the AI knows;
• what it is allowed to know;
• what it believes is authoritative;
• which policy applies;
• which tool can be invoked;
• which memory is carried forward;
• which customer, employee or regulatory claim is generated;
• whether the output can be explained, challenged, corrected and trusted.

The context supply chain is therefore a sequence of controlled transformations:

source registration
  -> source verification
  -> ingestion and classification
  -> chunking / structuring
  -> embedding / indexing
  -> metadata enrichment
  -> permission binding
  -> retrieval and reranking
  -> context composition
  -> prompt assembly
  -> model invocation
  -> tool observation incorporation
  -> memory write decision
  -> output citation and trace
  -> feedback and correction loop

Every step can introduce quality, security, permission or trust failure. A senior AI PM should ask:

Which context claims are we making to the user, and can we prove the chain that supports them?

---

5. Context Supply Chain Model

5.1 Logical Model

Context sources
  policy repository | knowledge base | customer profile | case system | tool API | user upload | memory store
        |
Source authority registry
  owner | trust tier | approved use | effective date | jurisdiction | permissions | quality SLO
        |
Ingestion and transformation
  parse | classify | redact | chunk | embed | index | sign | approve
        |
Context retrieval and assembly
  intent | workflow state | entitlement | source selection | rerank | conflict detection | context budget
        |
Runtime enforcement
  instruction hierarchy | untrusted label | policy engine | tool gateway | memory write policy | output schema
        |
Evidence and learning
  trace | provenance graph | eval result | incident record | correction | release update

5.2 Control Planes

5.3 Context Trust Tiers

The key design principle:

Retrieved content can support facts, but it cannot alter instruction hierarchy, permissions, tool authority or memory write rules.

---

6. Context Asset Taxonomy

6.1 Context Object Schema

Every material context asset should have a machine-readable record. A practical schema:

{
  "context_object_id": "ctx-credit-policy-hardship-2026q2-v4",
  "asset_class": "policy_snippet",
  "title": "Credit Card Hardship Treatment Policy",
  "source_authority": "approved_internal_policy",
  "context_trust_tier": "T1",
  "owner": "Collections Policy Owner",
  "approved_use": ["collections_agent_assist", "branch_rm_copilot_internal"],
  "prohibited_use": ["autonomous_fee_waiver", "final_credit_decision"],
  "jurisdiction": ["US"],
  "effective_from": "2026-04-01",
  "effective_to": "2026-09-30",
  "permission_scope": {
    "roles": ["collections_agent", "collections_supervisor"],
    "purpose": ["hardship_assistance"],
    "customer_context_required": true
  },
  "quality_contract": {
    "freshness_slo_hours": 4,
    "citation_required": true,
    "conflict_policy": "higher_authority_source_wins"
  },
  "provenance_claim": {
    "derived_from": "policy-repo://collections/hardship/2026Q2",
    "ingestion_run_id": "ingest-20260630-042",
    "index_version": "collections-policy-index-2026q2-v11",
    "checksum": "sha256:7f15..."
  },
  "change_control": {
    "release_id": "ctx-release-2026.06.30",
    "approval_record": "AI-CONTEXT-CHANGE-2026-0630-017",
    "rollback_target": "ctx-credit-policy-hardship-2026q2-v3"
  }
}

6.2 Provenance Claim

A provenance claim is a compact statement that tells a reviewer what can be trusted:

This context object was derived from approved source X, transformed by activity Y, approved by owner Z, released in version R, and used in trace T under permission decision P.

Good provenance claims are specific:

---

7. Provenance And Lineage

7.1 PROV Mapping

7.2 Lineage Graph Example

Policy Source v14
  -> ingest activity `ingest-20260629-009`
  -> chunk set `chunk-card-fee-v14`
  -> embedding job `embed-card-fee-ada3-20260629`
  -> index snapshot `index-card-policy-v22`
  -> retrieval run `retr-88172`
  -> prompt assembly `prompt-asm-88172`
  -> model invocation `model-call-88172`
  -> answer `out-88172`

For every material answer, the institution should know:

• which source version was used;
• which chunking and embedding configuration transformed it;
• which index and reranker selected it;
• which permission filter allowed it;
• which prompt template included it;
• which model and tool observations combined with it;
• which output cited it;
• which release gate approved that combination.

7.3 Embedding / Index Lineage

Embedding and index lineage deserve explicit governance because behavior can change without source text changing.

7.4 OpenLineage-Inspired Events

---

8. Ingestion And Change Control

8.1 Context Ingestion Gate

Before a context source enters production retrieval or prompt assembly, it should pass an ingestion gate:

8.2 Context Release Gate

Context changes can change behavior as much as model upgrades. A context release gate should cover:

8.3 Change Classification

8.4 Context Drift

Context drift occurs when the meaning, relevance, authority or permission of context changes over time.

---

9. Poisoning And Prompt Injection Defense

9.1 Threat Types

9.2 Defense Principles

9.3 Indirect Injection Example

Scenario: a customer uploads a PDF during a card dispute.

9.4 Memory Write Policy

9.5 Tool Observation Validation

Tool outputs need validation before they are included as context:

---

10. Permission Enforcement

10.1 Prompt Is Not Permission

Writing "do not reveal restricted data" in a prompt is not access control. Permission must be enforced before context enters retrieval, prompt assembly, tool invocation or memory read.

user identity
  -> role and entitlement
  -> workflow purpose
  -> customer relationship
  -> data classification
  -> source permission tags
  -> retrieval-time policy enforcement
  -> context assembly

10.2 Retrieval-Time Policy Enforcement

10.3 Permission Failure Examples

---

11. Context Quality SLO

11.1 Why Context SLO

Context quality must be managed as an operational reliability problem. If a regulated AI answer depends on source freshness, citation support, permission filtering and conflict handling, those properties need SLOs.

11.2 Context Recall

Context recall measures whether the retrieval and assembly pipeline brought the necessary context into the model's working set. It is different from model answer accuracy.

context recall = required authoritative evidence retrieved / required authoritative evidence available

Example:

11.3 Quality Dashboard

---

12. Runtime Context Trace

12.1 Trace Goals

Runtime context trace should answer:

• What context entered the model?
• Who or what allowed it?
• Which source and index versions were used?
• Which context objects were treated as authority versus evidence?
• Which tool observations were included and validated?
• Which memory records were read or written?
• Which conflicts, injection flags or stale-source warnings occurred?
• Which output claims cite which context?

12.2 OpenTelemetry-Inspired Span Model

12.3 Context Manifest In Trace

A context manifest attached to the runtime trace can be compact:

{
  "trace_id": "trc-card-policy-88421",
  "context_release_id": "ctx-release-2026.06.30",
  "context_manifest_hash": "sha256:49ac...",
  "objects": [
    {
      "context_object_id": "ctx-card-fee-policy-v14-sec-3.2",
      "trust_tier": "T1",
      "source_authority": "approved_internal_policy",
      "index_version": "card-policy-index-v22",
      "permission_decision": "allowed",
      "use": "citation"
    },
    {
      "context_object_id": "ctx-customer-upload-complaint-492",
      "trust_tier": "T4",
      "source_authority": "customer_claim",
      "permission_decision": "allowed_case_bound",
      "use": "evidence_only",
      "injection_flag": true
    }
  ]
}

---

13. Financial Retail Examples

13.1 Policy RAG For Customer Service

Trust implication: customers trust the answer because it cites current policy and does not expose internal-only remediation logic.

13.2 AML Typology Knowledge

Trust implication: investigators get faster analysis without turning external articles or model summaries into SAR authority.

13.3 KYC Evidence Documents

Trust implication: the AI can suggest missing evidence but cannot make a final onboarding rejection without human review.

13.4 Credit Policy Snippets

Trust implication: credit staff receive consistent policy support without the AI becoming the credit decision owner.

13.5 Regulatory Reporting Instructions

Trust implication: finance and risk teams can reconstruct the evidence behind narrative drafts.

13.6 Collections Hardship Scripts

Trust implication: agents receive consistent support while vulnerable customer controls remain visible.

13.7 Branch Relationship Manager Copilot

Trust implication: the copilot helps prepare conversations without covertly crossing into advice, credit decisioning or unauthorized data use.

---

14. Incident Response

14.1 Context Incident Types

14.2 Response Workflow

detect signal
  -> classify affected context object and severity
  -> freeze evidence and version set
  -> query impact by context object, source, index, trace and output
  -> contain: disable source, purge chunk, rollback index, block tool, suppress memory, force human review
  -> evaluate customer, operational, regulatory and model-risk impact
  -> repair source, metadata, permission, index, prompt, eval and release gate
  -> rerun regression and context quality tests
  -> update incident record, owner actions and context release

14.3 Impact Queries

---

15. Operating Model

15.1 Roles

15.2 Cadence

15.3 RACI Snapshot

---

16. Anti-Patterns

---

17. PM / BA / Architect Implications

17.1 For Senior AI PM

• Write context requirements as product requirements: source authority, user trust, escalation and correction matter as much as UX.
• Define which context claims the product makes to customers, employees and managers.
• Use context SLOs to explain reliability and trust, not only model scores.
• Treat context incidents as product incidents because stale or unauthorized context breaks user trust.

17.2 For CBAP-level BA

• Model workflow state and rule precedence explicitly.
• Convert "AI should know the policy" into testable requirements: source, version, jurisdiction, exception, citation and escalation.
• Identify where case evidence, customer claims and verified facts differ.
• Write acceptance criteria for missing, conflicting, stale and untrusted context.

17.3 For AI Architect

• Design context assembly as a pipeline with policy enforcement, lineage and observability.
• Version prompts, system instructions, index snapshots, metadata filters, tool schemas and memory policies together.
• Use runtime trace to reconstruct context behavior, not just model calls.
• Build rollback at source, chunk, index, prompt, tool and memory levels.

17.4 For Data Product Manager

• Treat knowledge corpora and metadata as data products with owners, contracts, SLOs and lineage.
• Include authority, permission and effective-date fields in the data contract.
• Monitor context recall, source freshness, metadata completeness and unauthorized retrieval attempts.
• Ensure index rebuilds and embedding changes have release identity and impact analysis.

---

18. Interview Answers

Q1: What is an AI context supply chain?

30-second answer:

It is the managed chain of assets that become model context: system prompts, RAG documents, metadata, embeddings, workflow state, user profiles, tool outputs and memory. In enterprise AI, each context object needs source authority, provenance, permission, quality SLO, change control and runtime traceability. Otherwise the model may use stale, unauthorized or poisoned context even if the prompt looks safe.

2-minute answer:

I define context supply chain as the lifecycle from source registration to ingestion, chunking, embedding, indexing, retrieval, prompt assembly, tool observation, memory write and output grounding. The key is that context is not neutral text. It carries authority, permission, freshness and risk. For a bank, a policy RAG answer may combine a system instruction, customer profile, current fee policy, internal SOP, CRM note and payment status tool output. Those pieces do not have the same authority or permissions.

I would design a source authority registry, context object schema, provenance graph, retrieval-time policy enforcement, context quality SLO and runtime trace. I would also include poisoning and prompt injection defense by labeling retrieved documents and uploads as evidence, not instructions. This connects product trust, architecture controls, eval and incident response.

Q2: How do you prevent prompt injection in RAG?

I do not rely on prompt wording alone. I classify sources by trust tier, enforce permissions before retrieval, treat retrieved content as evidence only, sanitize and label untrusted content, validate citations, restrict tool calls through a gateway and test indirect injection cases in the release gate. For high-risk workflows, an uploaded file or external article can support a claim, but it cannot change instructions, authorize a tool or write memory.

Q3: What is retrieval-time policy enforcement?

It means the system applies role, purpose, customer relationship, jurisdiction, effective date and source permission filters before vector ranking and context assembly. Unauthorized documents should never reach the model. This is different from retrieving everything and asking the model not to reveal restricted content.

Q4: Why is embedding/index lineage important?

The same source documents can produce different answers when parsing, chunking, embedding, reranking or metadata filters change. Index lineage lets us answer which source version, chunking policy, embedding model, index build and permission filter produced a retrieval result. It is essential for stale policy incidents, poisoning response, rollback and audit.

Q5: How would you design memory safely?

I would define a memory write policy. Only allowed fields can be written, each memory record needs source trace, purpose, validation, confidence, expiry and owner, and memory reads use entitlement and purpose checks. User-provided instructions, one-time exceptions, approvals and unverified claims cannot become persistent future instructions. Every write and deletion is auditable.

Q6: How do you connect context controls to product trust?

Users trust AI when the system can explain what source it used, why it was allowed, whether it is current, and what happens when evidence is missing or conflicting. Context controls should therefore show up in product behavior: citations, uncertainty, escalation, approved language, correction loops and transparent handoff. Security controls are not separate from UX; they are how the product avoids confident wrong answers.

---

19. Portfolio Exercise

Scenario

A mid-size financial retail institution is building a shared context supply chain for seven AI use cases:

Required Artifacts

1. Context supply chain architecture diagram from source registration to runtime trace.
2. Context asset taxonomy covering at least 12 asset classes.
3. Context object schema with authority, provenance, trust tier, permission and quality fields.
4. Source authority matrix for the seven use cases.
5. Data contract for one policy corpus and one tool observation.
6. Embedding/index lineage design, including parser, chunker, embedding model, index version and rollback.
7. Retrieval-time policy enforcement design with role, purpose, customer relationship and effective-date filters.
8. Memory write policy with allowed fields, prohibited fields, expiry and audit events.
9. Tool observation validation rules for payment status, KYC document status and AML graph lookup.
10. Context quality SLO dashboard with at least 10 SLIs.
11. Runtime context trace schema with prompt, retrieval, tool, memory and output grounding spans.
12. Poisoning and indirect prompt injection red-team set with at least 20 cases.
13. Incident response playbook for stale policy and poisoned RAG source.
14. Executive narrative explaining how context provenance improves customer trust and audit readiness.

Evaluation Rubric

---

20. Final Mental Model

Context is the hidden operating system of enterprise AI.

No source authority -> citation laundering.
No provenance -> no audit replay.
No permission enforcement -> data leakage.
No index lineage -> no incident scoping.
No quality SLO -> stale and missing evidence.
No memory policy -> persistent corruption.
No runtime trace -> no accountability.
No release gate -> uncontrolled behavior change.

The mature question is not "What prompt did we write?" It is:

Which context objects shaped this AI behavior, why were they trusted, who allowed them, how fresh were they, what changed, and how would we know if they were poisoned?