Amo.ng curated workflow
Assess Enterprise Knowledge and RAG Readiness
Govern enterprise knowledge freshness, source authority, retrieval evidence, entitlements, and sensitive-context boundaries before expanding or releasing a RAG capability.
# Assess Enterprise Knowledge and RAG Readiness Workflow ID: AMO-W-000016 Workflow URL: https://amo.ng/workflows/enterprise-knowledge-and-rag-readiness-review ## Outcome A Ready, Restricted, Revalidate, or Hold package containing corpus decay findings, freshness objectives, source-authority decisions, retrieval evidence, entitlement controls, sensitive-context lineage, and accountable revalidation work. ## Before you begin - Knowledge use case, decision risk, users, owners, corpus scope, and current RAG architecture - Source inventory, ownership, authority, effective dates, review history, ingestion records, and change evidence - Freshness expectations, incident history, current monitoring, and revalidation capacity - Representative documents, query logs or benchmarks, retrieval configuration, and answer standards - Identity, tenant, purpose, region, document ACL, index, cache, citation, and data-flow evidence - Sensitive-data classifications, memory and tool boundaries, retention rules, and release constraints ## Step 1 — Assess corpus freshness and knowledge decay **Prompt** Enterprise Knowledge Corpus Freshness and Decay Review **Instructions** Map decision-critical knowledge assets to source change, effective date, review evidence, usage and retrieval exposure, accountable ownership, decay risk, and revalidation triggers. **Input for this step** Supply the source inventory, content and decision uses, ownership, authoritative systems, ingestion dates, source changes, review history, usage exposure, and known stale-content incidents. **Carry forward** Carry the freshness map, decay-risk register, priority assets, authority gaps, and owner assignments into freshness-control design. **Review note** The knowledge owner and domain owner confirm which sources are decision-critical and which stale or unowned assets require restriction. **Prompt ID** AMO-P-000282 **Prompt URL** https://amo.ng/prompts/enterprise-knowledge-corpus-freshness-and-decay-review **Prompt content** Determine where the enterprise knowledge corpus has become stale, time-sensitive, or decision-unsafe by relating source authority, change events, usage, review evidence, and retrieval exposure. Focus on freshness decay and revalidation evidence, not a broad knowledge-base quality audit. Context and inputs to provide: - Knowledge corpus name: [Knowledge corpus name] - Corpus export or representative content set: [Corpus export or representative content set] - Source inventory and authority rules: [Source inventory and authority rules] - Known change events and effective dates: [Known change events and effective dates] - Usage and retrieval exposure data: [Usage and retrieval exposure data] - Existing review evidence and owner list: [Existing review evidence and owner list] - Decision horizon and risk tolerance: [Decision horizon and risk tolerance] Evidence rules: - Separate observed evidence from inference. Label each conclusion as Observed, Inferred, or Unknown. - Do not claim that a source, log, review, owner approval, or retrieval result was inspected unless it appears in the provided material. - Preserve uncertainty where evidence is incomplete, contradictory, old, or sampled. - Prefer source-effective dates, documented review records, owner attestations, change logs, and actual retrieval or usage evidence over assumptions. - If the corpus export is incomplete, treat the result as a scoped review and state the coverage limits. Authority boundaries: - Do not make final compliance, legal, medical, financial, security, or customer-impact determinations unless an accountable owner has provided the relevant authority rule in the inputs. - Assign proposed decisions to accountable roles such as knowledge owner, source authority, product owner, policy owner, compliance owner, data owner, search owner, or support operations owner. - Where the correct owner is unclear, mark Owner Unknown and specify the evidence needed to assign accountability. Review method: 1. Establish the freshness policy map. - Identify content classes that require freshness controls, such as policy, product behavior, pricing, regulated guidance, operational runbooks, customer-facing answers, security procedures, data definitions, and historical reference material. - For each class, map source authority, expected review cadence, change triggers, acceptable age, required evidence of review, and decision owner. - If no explicit policy exists, infer a provisional freshness expectation from risk, source type, and decision use; mark it as Inferred. 2. Detect decay signals. - Compare corpus claims against known source changes, effective dates, product or policy updates, review timestamps, ownership changes, usage patterns, and retrieval exposure. - Identify assets with missing source authority, expired review windows, superseded references, conflicting versions, orphaned ownership, high retrieval exposure, or recent source changes without revalidation. - Distinguish content that is merely old from content that is decision-unsafe. 3. Build the decay-risk register. For each material risk, provide: - Asset or content group - Decision or workflow it may affect - Decay signal observed - Source authority status - Last known review evidence - Retrieval or usage exposure - Potential consequence if used as-is - Confidence level and evidence basis - Accountable owner - Recommended disposition: Retain, Revalidate, Update, Restrict, Retire, or Split/Merge 4. Build the source-change impact matrix. - List each known source change or effective-date event. - Map the affected corpus assets, topics, audiences, workflows, and retrieval surfaces. - Identify whether the corpus reflects the change, partially reflects it, conflicts with it, or lacks enough evidence to determine impact. - Prioritize changes that affect high-exposure retrieval, customer-facing guidance, regulated decisions, operational safety, financial terms, security controls, or contractual commitments. 5. Produce the revalidation queue. - Rank assets by decision risk, retrieval exposure, source-change proximity, review age, and owner availability. - For each item, specify the minimum evidence needed to clear or confirm the risk. - Assign an accountable owner and a practical next step. - Separate urgent restrictions from routine revalidation work. 6. Make retire, restrict, update, or revalidate decisions. - Recommend a disposition for each priority item. - Use Restrict when content could cause harmful or materially wrong decisions before validation is complete. - Use Retire when content is superseded, duplicate, ownerless with no defensible authority, or no longer tied to a valid business use. - Use Update when authoritative replacement information is available. - Use Revalidate when the content may still be valid but lacks current review evidence. - Use Retain only when freshness requirements, source authority, and review evidence are adequate for the stated decision horizon. Output format: A. Scope and evidence coverage - Corpus reviewed - Materials provided - Materials not provided but needed - Coverage limits - Assumptions and uncertainty B. Freshness policy map Create a table with columns: Content class | Source authority | Review cadence or trigger | Acceptable age | Required review evidence | Decision owner | Basis: Observed/Inferred/Unknown. C. Decay-risk register Create a table with columns: Priority | Asset or group | Affected decision/workflow | Decay signal | Source authority status | Review evidence | Retrieval/usage exposure | Consequence | Confidence | Owner | Recommended disposition. D. Source-change impact matrix Create a table with columns: Source change | Effective date | Affected assets/topics | Exposure surface | Alignment status | Risk level | Required action | Owner. E. Revalidation queue Create a table with columns: Queue rank | Asset or group | Reason for queueing | Minimum evidence needed | Proposed verifier | Target decision | Urgency | Dependency. F. Retire/restrict/update decisions Create a table with columns: Asset or group | Decision | Rationale | Evidence basis | Owner to confirm | Completion check. G. Missing evidence and unresolved questions List the specific missing logs, source records, review attestations, authority rules, owner assignments, or retrieval evidence needed to convert Unknown or Inferred judgments into Observed judgments. H. Completion criteria State whether this review is complete enough to support immediate restriction, update, retirement, or revalidation planning. Identify which decisions require confirmation by the relevant knowledge owner, source authority, product owner, compliance owner, data owner, or search owner before implementation. ## Step 2 — Define retrieval freshness controls **Prompt** Retrieval Freshness SLO and Revalidation Design **Instructions** Turn the decay findings into risk-based freshness objectives, measurement rules, source-change triggers, breach responses, revalidation evidence, and sustainable ownership. **Input for this step** Provide the freshness map, risk tiers, source-change cadence, ingestion and validation history, current monitoring, incident evidence, owner capacity, and operating constraints. **Carry forward** Carry the freshness SLO register, breach and exception rules, revalidation queue, evidence requirements, and owner commitments into source-authority review. **Review note** Knowledge and service owners approve risk tiers, achievable objectives, breach responses, and temporary restrictions. **Prompt ID** AMO-P-000308 **Prompt URL** https://amo.ng/prompts/retrieval-freshness-slo-revalidation-design **Prompt content** Design freshness service-level objectives and revalidation controls for knowledge assets used by enterprise retrieval, RAG, search, or assistants. Set different evidence requirements for different decisions rather than one arbitrary age limit. Inputs: - Knowledge domains, asset types, user groups, decisions supported, and consequence of stale use: [Knowledge domains and decision uses] - Authoritative publishers, source hierarchy, update patterns, effective dates, expiry rules, and change notifications: [Source authority and change behavior] - Ingestion cadence, transformation, indexing, replication, cache, retrieval, citation, and serving paths: [Ingestion retrieval and cache architecture] - Asset age distribution, observed update lag, stale-answer incidents, review history, query/use data, and available monitoring: [Freshness and incident evidence] - Legal, policy, operational, security, service-level, staffing, knowledge-owner, data-owner, and product-owner constraints: [Risk constraints and accountable owners] Do not assume newer means more authoritative or that an unchanged source remains valid. Do not invent publication dates, change frequency, query volume, or incident rates. Distinguish observed freshness evidence from inference and label missing evidence explicitly. Separate source freshness, ingestion freshness, index freshness, cache freshness, and answer-time evidence. Label proposed objectives when baseline data is missing. Design method: 1. Define freshness risk classes. Group assets by decision consequence, change velocity, source authority, legal/effective-date sensitivity, user exposure, and reversibility. Keep policy, pricing, security, operational, reference, and historical knowledge distinct where appropriate. 2. Map the freshness chain. For each class, trace source publication through acquisition, validation, transformation, indexing, replication, caching, retrieval, citation, and answer serving. Identify where timestamps, version identifiers, or authority can be lost. 3. Establish measurable freshness indicators. Define source age, detection lag, ingestion lag, index lag, cache lag, unresolved conflict age, review age, and answer evidence age only where measurable. State clock and timestamp semantics. 4. Set objectives and error budgets. Propose maximum lags, revalidation intervals, coverage targets, and breach budgets tied to risk evidence. When evidence is thin, mark the objective Provisional and specify baseline collection before enforcement. 5. Define change-triggered revalidation. Include source revisions, effective dates, schema changes, ownership changes, incidents, query shifts, policy notices, conflicts, and upstream authority changes. Specify what is revalidated and whether serving is restricted during review. 6. Design breach responses. Choose warn, annotate, downgrade ranking, bypass cache, re-ingest, restrict, abstain, or temporarily remove for each risk class. Assign authority and preserve historical evidence. 7. Define verification and governance. Specify monitoring, sampling, lineage proof, alert recipients, exception expiry, owner attestation, and periodic SLO recalibration. Avoid requiring manual review where automated authoritative change evidence is sufficient. Separate observed freshness evidence from inference, assumptions, and unknowns; request blocking provenance or decision-criticality evidence rather than inventing an age rule. The knowledge owner approves the SLO, and privacy, legal, or security reviewers approve constraints in their domains. Require acceptance evidence for each tier: expected observation, actual observation from a revalidation sample when supplied, breach handling, rollback or restriction path, and unresolved conflict. Proposed monitors and revalidation tests remain not executed until results exist. Record approval from the knowledge owner for the SLO and approval from the relevant privacy, legal, or security reviewer for domain constraints. Required deliverable: # Retrieval Freshness SLO and Revalidation Design ## Knowledge Risk Classes | Class | Decision use | Authority | Change velocity | Staleness consequence | Owner | |---|---|---|---|---|---| ## Freshness Chain | Stage | Version/time evidence | Current lag evidence | Failure mode | Monitorable? | |---|---|---|---|---| ## Freshness Indicators and Objectives | Class/stage | Indicator | Proposed objective | Evidence basis | Error budget | Provisional? | |---|---|---|---|---|---| ## Revalidation Triggers | Trigger | Affected assets | Required check | Serving behavior during review | Owner | |---|---|---|---|---| ## Breach Response Matrix | Risk class | Breach condition | User/system response | Restoration evidence | Authority | |---|---|---|---|---| ## Implementation and Verification Plan | Priority | Smallest control | Data/evidence needed | Acceptance check | Owner | |---|---|---|---|---| Completion requires measurable indicators from source to served answer, a risk-based objective or explicit provisional status for every material knowledge class, and a bounded response for each freshness breach. ## Step 3 — Resolve source authority and supersession conflicts **Prompt** Knowledge Source Supersession and Conflict Resolution Brief **Instructions** Determine which conflicting or superseded sources govern each use by tracing authority, effective dates, scope, lineage, exceptions, and current downstream retrieval exposure. **Input for this step** Supply conflicting source versions, authority rules, effective dates, owners, lineage and ingestion records, retrieval or citation exposure, and decision constraints. **Carry forward** Carry the authority matrix, supersession chains, affected content and decisions, remediation or exception states, and unresolved conflicts into retrieval validation. **Review note** The domain and knowledge owners approve authoritative-source dispositions; legal or compliance reviewers decide requirements within their remit. **Prompt ID** AMO-P-000310 **Prompt URL** https://amo.ng/prompts/knowledge-source-supersession-conflict-resolution-brief **Prompt content** Prepare a decision brief for enterprise knowledge sources that conflict, overlap, or may have superseded one another. Determine governing authority by scope and effective period without flattening legitimate contextual differences. Provide: - Exact decision or operating question, affected users, systems, regions, products, and consequences: [Decision question and affected uses] - The supplied policy, procedure, specification, documentation, notice, dataset, record, or source extracts with identifiers: [Conflicting source materials] - Publisher authority, ownership, approval, jurisdiction, effective dates, version history, supersession notices, and exception rules: [Authority scope and effective-date evidence] - Source lineage, copies, transformations, links, indexes, citations, retrieval results, queries, and observed downstream use: [Lineage retrieval and usage evidence] - Retention, legal, compliance, operational, archival, product-owner, knowledge-owner, and policy-owner constraints: [Constraints and accountable owners] Do not assume the newest source governs every context. Do not invent authority, effective dates, approvals, or supersession relationships. Distinguish observed source evidence from inference and identify missing authority evidence. Quote or cite supplied source sections for material differences. Separate direct conflict, scoped exception, temporal transition, terminology mismatch, stale copy, and unresolved ambiguity. Resolution method: 1. Bound the question. Define the exact proposition or instruction in conflict and the contexts in which it matters. Exclude differences that do not affect the decision. 2. Build a source authority ledger. Record stable identifier, publisher, owner, approval, source type, jurisdiction, audience, product/process scope, effective period, status, and provenance for each source. 3. Create a claim-level conflict map. Break sources into material claims or instructions. For each, cite the evidence, describe agreement or difference, and classify as Direct contradiction, Partial overlap, Scope difference, Temporal succession, Exception, Terminology mismatch, or Missing context. 4. Apply authority and scope rules. Use supplied governance evidence to determine precedence. Consider mandatory versus guidance status, source-of-record designation, jurisdiction, effective date, explicit supersession, product/process scope, and authorized exceptions. Do not create a precedence rule when none is supplied. 5. Trace downstream exposure. Identify stale copies, indexes, caches, links, citations, prompts, assistants, training materials, or operational artifacts that use each source. Separate confirmed use from potential reach. 6. Make a resolution disposition. For each claim/context choose Governing source identified, Both valid in distinct scopes, Transitional rule required, Restrict pending owner decision, or Unresolved. State the rationale and authority. 7. Define the smallest safe propagation plan. Preserve required historical records while updating, annotating, deprecating, redirecting, re-indexing, or restricting current-use surfaces. Assign owner approvals and evidence checks. Verification must reconcile each material claim to an authoritative current source. Record the expected observation, actual observation, source locator, supersession status, and acceptance evidence; unresolved conflicts remain explicit and prevent the affected claim from being marked current. Required deliverable: # Knowledge Source Supersession and Conflict Resolution Brief ## Decision Boundary - Question in conflict: - Affected contexts: - Consequence of wrong resolution: - Authority gaps: ## Source Authority Ledger | Source | Publisher/owner | Scope | Effective period | Status | Authority evidence | Provenance confidence | |---|---|---|---|---|---|---| ## Claim-Level Conflict Map | Claim/instruction | Source positions | Conflict type | Applicable context | Evidence | Resolution status | |---|---|---|---|---|---| ## Governing Dispositions | Claim/context | Disposition | Governing source/rule | Rationale | Approver | Uncertainty | |---|---|---|---|---|---| ## Downstream Exposure and Propagation | Surface/artifact | Current source | Confirmed/potential use | Required action | Historical preservation | Owner | Verification | |---|---|---|---|---|---|---| ## Completion Decision - Resolved scopes: - Restricted scopes: - Unresolved questions and owner: - Revalidation trigger: Completion requires a claim-level resolution or explicit restriction for every consequential context, traceable authority evidence, and verification that current-use retrieval surfaces no longer present an unqualified stale rule. ## Step 4 — Validate retrieval configuration when material **Prompt** Retrieval Chunking and Metadata Experiment Design **Instructions** Define a controlled experiment when chunking or metadata choices lack decision-grade evidence or are changing. If representative current evidence already supports the configuration, record it and mark a new experiment Not applicable. **Input for this step** Provide representative documents, source-authority decisions, current and candidate configuration, query logs or benchmarks, answer standards, source-version fields, and constraints. **Carry forward** Carry the experiment or verified-configuration boundary, query slices, measures, guardrails, acceptance criteria, and untested assumptions into entitlement review. **Review note** The retrieval, data, and domain owners approve the evidence standard and any configuration selected for testing or release. **Prompt ID** AMO-P-000284 **Prompt URL** https://amo.ng/prompts/retrieval-chunking-and-metadata-experiment-design **Prompt content** Design a controlled retrieval experiment to isolate how chunking choices and metadata choices affect retrieval and answer quality. Keep the scope limited to corpus configuration decisions: do not redesign the full RAG architecture, diagnose the whole pipeline, change model selection, or introduce unrelated retrieval changes unless they are explicitly controlled constants. Context to use: - Corpus description and sample documents: [Corpus description and sample documents] - Current retrieval setup: [Current retrieval setup] - Candidate chunking options: [Candidate chunking options] - Candidate metadata fields: [Candidate metadata fields] - Query logs or benchmark questions: [Query logs or benchmark questions] - Answer evaluation standard: [Answer evaluation standard] - Decision owners and constraints: [Decision owners and constraints] Evidence discipline: - Separate observations supported by the provided inputs from inferences and assumptions. - Do not claim that experiments, tests, retrieval runs, indexing jobs, or evaluations were completed unless results are provided. - If required information is missing, state the missing evidence and design the smallest reasonable way to obtain it. - Preserve uncertainty where the available evidence does not justify a firm conclusion. - Before defining experiment arms, treat the baseline retrieval configuration, candidate changes, representative corpus and query evidence, and answer-evaluation standard as blocking when absent or materially conflicting. Request all blocking items in one consolidated clarification and stop the affected design decision until they are supplied. Record other gaps as Unknown with their effect on sizing, confounding, metrics, and acceptance criteria. - Treat the retrieval owner as accountable for experiment execution, the data owner as accountable for corpus and metadata validity, and the product owner or domain owner as accountable for acceptance criteria tied to user impact. Produce the following deliverable: 1. Experiment objective and decision boundary - State the configuration decision this experiment will support. - Define what is in scope: chunking strategy, overlap, boundary rules, parent-child or hierarchical chunking if relevant, metadata extraction, metadata normalization, and metadata use in filtering or ranking. - Define what is out of scope and should be held constant: embedding model, reranker, generation prompt, answer model, UI behavior, permissions, and production rollout unless the inputs require otherwise. - Identify the baseline configuration and the candidate configurations to compare. 2. Controlled variables and constants Create a table with: - Variable under test - Candidate levels - Why it matters - Expected retrieval effect - Required implementation evidence - What must remain constant Include at minimum: - Chunk size or token range - Chunk overlap - Chunk boundary rule - Structural handling of headings, tables, lists, or sections - Metadata fields to attach - Metadata normalization rules - Metadata use pattern: display only, filter, boost, grouping, or attribution 3. Factorial experiment matrix Build a practical factorial or fractional-factorial matrix that isolates chunking and metadata effects without creating unnecessary runs. For each experiment arm include: - Arm ID - Chunking configuration - Metadata configuration - Retrieval settings held constant - Indexing requirements - Expected comparison value - Risk of confounding - Minimum evidence needed before execution If the full factorial design is too large, propose a staged design: - Screening stage to remove weak options - Focused comparison stage for finalists - Confirmation stage against the baseline 4. Dataset and query slices Define the evaluation dataset and query slices needed to detect meaningful differences. Include: - Document sample selection rules - Minimum corpus coverage requirements - Query source: logs, expert-written questions, synthetic-but-reviewed questions, or known support cases - Query slice taxonomy - Required number of queries per slice if enough information is available; otherwise give a sizing rule Use query slices such as: - Exact lookup questions - Multi-section synthesis questions - Long-tail entity questions - Recent or version-specific questions - Table or list extraction questions - Procedure or policy questions - Ambiguous terminology questions - Metadata-dependent questions - Queries where the answer should not be in the corpus For each slice, specify the retrieval failure mode it is intended to expose. 5. Relevance judgments and answer evaluation setup Define how ground truth or reference judgments should be created. Include: - Who should judge relevance and answer correctness - What evidence they need - How to label relevant, partially relevant, irrelevant, stale, duplicate, and misleading chunks - How to handle multiple valid source passages - How to record uncertainty and disagreements - How to prevent evaluators from seeing the tested configuration when practical 6. Retrieval metrics Specify retrieval metrics that directly measure chunking and metadata effects. Include: - Recall@k - Precision@k or context precision - MRR or nDCG where graded relevance exists - Source coverage for multi-source answers - Duplicate or near-duplicate rate in top-k - Metadata filter precision and filter fallout - Freshness or version correctness when metadata includes time or version fields - No-answer retrieval behavior for queries outside the corpus For each metric, define: - Formula or scoring method in plain language - Required inputs - Which query slices it applies to - What kind of configuration failure it reveals 7. Answer-level metrics Define answer metrics only as downstream checks of retrieval configuration, not as a full generation evaluation. Include: - Answer correctness against the evaluation standard - Citation/source support - Missing critical fact rate - Unsupported claim rate - Wrong-version or wrong-jurisdiction rate if relevant - Refusal or no-answer correctness where the corpus lacks the answer Explain how to attribute answer failures to retrieval versus generation when the top-k evidence is sufficient but the answer is wrong. 8. Error attribution rules Create a concrete error taxonomy with decision rules. Include at minimum: - Chunk boundary split error - Chunk too broad or noisy - Chunk too narrow or missing context - Overlap redundancy error - Metadata absent - Metadata incorrect - Metadata too coarse - Metadata filter excludes relevant evidence - Metadata boost overpromotes irrelevant evidence - Duplicate chunk crowding - Stale or wrong-version retrieval - Relevant evidence not indexed - Relevant evidence indexed but not retrieved - Answer failure despite sufficient retrieved evidence For each error type, define: - Observable evidence - How to distinguish it from similar errors - Likely configuration implication - Whether it should count against chunking, metadata, indexing, retrieval settings, or answer generation 9. Analysis plan by query slice Define how results should be compared across arms and slices. Include: - Primary metric and secondary metrics - Minimum practical improvement threshold - Regression checks where a configuration improves one slice but harms another - Treatment of ties - Treatment of small sample sizes - Required confidence or stability checks if repeated runs are possible - How to summarize tradeoffs for decision owners without hiding slice-level failures 10. Configuration acceptance decision Create a decision framework the retrieval owner, data owner, and product owner can use after the experiment is run. Include: - Acceptance criteria for adopting a new chunking and metadata configuration - Rejection criteria - Conditional acceptance criteria requiring remediation - Required evidence package before approval - Rollback or re-indexing considerations if adopted - Open questions that must be resolved before production use 11. Completion checklist End with a checklist that confirms whether the experiment design is ready to execute. Include checks for: - Baseline defined - Candidate arms defined - Constants identified - Query slices complete - Relevance judgment process defined - Metrics mapped to slices - Error attribution rules defined - Acceptance criteria agreed by named accountable owners - Missing evidence listed - No unsupported claims of completed execution ## Step 5 — Reconcile effective knowledge entitlements **Prompt** Knowledge Entitlement Drift Review **Instructions** Compare authoritative access policy with effective permissions across source, ingestion, index, cache, retrieval, citation, and response layers; identify stale grants, missing restrictions, and recertification gaps. **Input for this step** Provide identity and tenant models, source ACLs, group and role data, ingestion and index mappings, cache behavior, retrieval traces, exception registers, recertification history, and prior findings. **Carry forward** Carry the entitlement matrix, drift findings, exposed scope, containment needs, owner actions, and regression requirements into context-lineage review. **Review note** The data owner, security reviewer, and identity or service owner authorize access removal, exception continuation, and recertification decisions. **Prompt ID** AMO-P-000309 **Prompt URL** https://amo.ng/prompts/knowledge-entitlement-drift-review **Prompt content** Review whether effective access to enterprise knowledge has drifted from authoritative entitlement policy anywhere between the source system and the final retrieval response. Provide: - Approved subject, group, tenant, region, purpose, document, field, and time-bound access rules: [Authoritative entitlement policy] - Source repositories, ingestion, transformations, embeddings, indexes, namespaces, caches, retrievers, rerankers, citations, response filters, and identity propagation: [Knowledge architecture and identity flow] - Current ACLs, groups, policies, index filters, namespace rules, token claims, cache keys, and configuration exports: [Effective permission and configuration evidence] - Sanitized query/access traces, denials, sampled results, recertification records, deployments, migrations, and permission changes: [Retrieval access and change logs] - Data classification, privacy, residency, incident, availability, knowledge-owner, identity-owner, security-reviewer, and service-owner constraints: [Risk constraints and accountable owners] Do not claim a leakage event from configuration drift alone, and do not treat absence of logged leakage as proof of correct enforcement. Do not claim live access tests unless supplied. Distinguish observed evidence from inference, as well as authoritative policy, configured control, effective access, observed use, and confirmed exposure. Preserve uncertainty where identities or document lineage cannot be joined. Review: 1. Define authoritative entitlement contracts. Translate policy into subject-resource-action-context rules, including inheritance, deny precedence, purpose, tenant, region, embargo, expiry, field-level, and break-glass conditions. 2. Trace identity and entitlement propagation. Map how the caller identity and claims reach source filtering, ingestion metadata, index namespaces, retrieval filters, caches, citations, and response controls. Flag stages where identity is dropped, transformed, defaulted, or cached. 3. Reconcile effective controls. Compare authoritative rules with source ACLs, indexed metadata, filter logic, namespace membership, cache partitioning, service credentials, and post-retrieval controls. Account for stale groups, deleted users, broad service accounts, and shared indexes. 4. Build a drift register. Classify differences as Stale grant, Missing grant, Metadata loss, Filter mismatch, Namespace error, Cache-key weakness, Inherited expansion, Migration residue, Exception, or Not assessable. Record potential exposure and confirmed use separately. 5. Assess change and time behavior. Measure supplied lag between source permission changes and downstream propagation. Review revocation, role change, tenant move, embargo, and expiry handling. Do not invent propagation time. 6. Define the smallest safe correction. Recommend targeted re-indexing, metadata repair, filter correction, cache invalidation, token/session refresh, service-account restriction, or temporary serving restriction. Preserve availability and forensic evidence. 7. Design recertification proof. Specify positive and negative access cases, identity/tenant/region slices, document lineage checks, revocation timing, cache isolation, monitoring, and owner approval. Required deliverable: # Knowledge Entitlement Drift Review ## Authoritative Entitlement Matrix | Subject/context | Resource/class | Allowed/denied action | Condition/expiry | Policy evidence | Owner | |---|---|---|---|---|---| ## Propagation Map | Stage | Identity/entitlement input | Transformation | Enforcement | Evidence | Gap | |---|---|---|---|---|---| ## Drift Register | Drift | Classification | Policy state | Effective state | Potential exposure | Observed use | Confidence | Owner | |---|---|---|---|---|---|---|---| ## Correction and Restriction Plan | Priority | Smallest safe action | Affected layer | Availability effect | Authorization | Verification | |---|---|---|---|---|---| ## Recertification Gate | Test slice | Positive expectation | Negative expectation | Evidence source | Owner | Status | |---|---|---|---|---|---| ## Decision - Entitlement state: Aligned / Aligned with exceptions / Drift present / Not assessable - Serving restrictions: - Required corrections: - Unresolved exposure: - Revalidation trigger: Completion requires policy-to-response traceability for material knowledge classes, explicit separation of drift from confirmed exposure, and negative access evidence before removed permissions are considered effective. ## Step 6 — Trace sensitive context beyond retrieval **Prompt** Sensitive Context Propagation and Cross-Agent Contamination Audit **Instructions** Trace sensitive context from source and retrieval through agent handoffs, prompts, memory, tools, logs, shared workspaces, and downstream outputs. Reconcile propagation with freshness, authority, retrieval, and entitlement evidence. **Input for this step** Provide data classifications, RAG and agent flows, representative payloads, memory and tool configuration, logs, retention rules, tenant and purpose boundaries, and prior-step findings. **Carry forward** Produce the final Ready, Restricted, Revalidate, or Hold record with control work, restrictions, regression criteria, owners, evidence gaps, and re-review triggers. **Review note** Knowledge, data, product, and release owners make the readiness decision with security and privacy review for material exposure. **Prompt ID** AMO-P-000286 **Prompt URL** https://amo.ng/prompts/sensitive-context-propagation-and-cross-agent-contamination-audit **Prompt content** Conduct an evidence-based audit of sensitive context propagation across the specified agent workflow. Trace actual context movement through handoffs, memory, retrieval, tools, logs, outputs, and shared workspaces. Do not produce a generic sensitive-data checklist. Separate observed evidence from inference, expose missing information, and preserve uncertainty. Context to provide: - System or workflow under review: [System or workflow under review] - Authorized purposes and tenant boundaries: [Authorized purposes and tenant boundaries] - Sensitive context categories: [Sensitive context categories] - Evidence package: [Evidence package] - Known incidents or concerns: [Known incidents or concerns] - Accountable owners: [Accountable owners] - Review date range: [Review date range] Evidence rules: - Use only the evidence provided in [Evidence package] and clearly identified user-supplied context. - Do not claim that a source, system, log, tool, workspace, approval, command, or deletion was inspected or completed unless evidence is present. - Label each material statement as one of: Observed, Inferred, Not evidenced, or Requires owner confirmation. - Distinguish sensitive context from ordinary workflow context. - Distinguish authorized propagation from unauthorized propagation, excessive retention, purpose drift, and cross-tenant or cross-task contamination. - If evidence is incomplete, state the missing artifact and why it matters. Audit scope: Trace sensitive context across these surfaces where evidence exists: 1. User inputs, uploaded files, tickets, records, conversations, or task instructions. 2. Agent-to-agent handoffs, delegation messages, intermediate reasoning summaries, or task state objects. 3. Short-term memory, long-term memory, vector stores, retrieval indexes, embeddings, caches, and session stores. 4. Tool calls, API payloads, browser sessions, database queries, SaaS integrations, webhooks, automations, and background jobs. 5. Logs, traces, analytics events, evaluation datasets, transcripts, error reports, monitoring records, and support workspaces. 6. Shared folders, project workspaces, collaboration tools, exported artifacts, generated documents, and downstream notifications. 7. Human review queues, escalation paths, approval records, and operator notes. Required deliverable: 1. Audit Boundary and Evidence Inventory Create a concise table with: - Evidence item - Source or owner if known - Date range covered - Context surfaces covered - Reliability limits - Material gaps 2. Context Lineage Map Create a lineage table that traces each sensitive context category through the workflow: - Context item or category - Origin - Initial authorized purpose - Receiving agent, service, tool, memory store, log, workspace, or person - Transfer mechanism - Transformation or summarization performed - Retention location and retention duration if evidenced - Tenant, customer, project, task, or workspace boundary crossed - Evidence reference - Status: authorized, questionable, unauthorized, excessive, contaminated, or not evidenced Then provide a short narrative explaining the highest-risk propagation paths. Do not infer a path merely because it is technically possible; identify it as a hypothesis if not evidenced. 3. Sensitivity and Purpose Register Create a register with: - Sensitive context category - Sensitivity rationale - Data subject, tenant, customer, project, or task boundary affected - Authorized purpose from [Authorized purposes and tenant boundaries] - Actual observed use - Purpose alignment: aligned, narrowed, expanded, drifted, unrelated, or not evidenced - Minimum context needed for the task - Excess context observed - Owner accountable for purpose decision from [Accountable owners], or owner not identified 4. Cross-Agent and Cross-Boundary Contamination Findings For each finding, include: - Finding title - Evidence basis - Contamination type: cross-agent, cross-tenant, cross-task, cross-customer, cross-project, memory reuse, retrieval bleed, logging exposure, tool propagation, workspace exposure, or purpose drift - Affected context - Affected boundary - How the propagation occurred or is suspected to occur - Impact on confidentiality, integrity, compliance, customer trust, operational safety, or decision quality - Likelihood rating: evidenced, plausible, weakly supported, or unknown - Severity rating: critical, high, medium, low, or informational - Confidence level and reason - Missing evidence that would change the rating 5. Minimization and Containment Controls Propose controls tied to the observed lineage, not generic policy slogans. For each control, include: - Propagation point addressed - Control objective - Specific change to inputs, prompts, handoff schema, memory policy, retrieval filtering, tool payloads, logging, access control, workspace permissions, retention, or operator procedure - Expected reduction in sensitive context exposure - Owner responsible for implementation - Verification method - Residual risk Prioritize smallest effective controls that reduce propagation without breaking the authorized workflow. Avoid broad rewrites unless the evidence shows the workflow design itself is unsafe. 6. Deletion, Quarantine, and Revalidation Plan Create an action plan with: - Artifact or location requiring deletion, quarantine, redaction, re-indexing, access review, or retention change - Reason action is needed - Required owner approval: data owner, security reviewer, legal/privacy owner, product owner, platform owner, or customer account owner as appropriate - Preconditions before action - Execution evidence needed after action - Revalidation test or sampling method - Rollback or exception handling if deletion would impair legal hold, auditability, customer support, or service reliability Do not state that deletion, quarantine, redaction, or re-indexing has been completed. State only the plan and the evidence needed to verify completion. 7. Open Questions and Owner Decisions List unresolved questions that materially affect risk or remediation. For each, identify: - Question - Why it matters - Evidence needed - Accountable owner from [Accountable owners], or owner not identified - Decision deadline if inferable from [Known incidents or concerns] 8. Completion Check End with a completion check stating whether the audit is ready for owner review. Include: - Whether every sensitive context category in [Sensitive context categories] was traced or marked not evidenced - Whether every material propagation path has an evidence reference or uncertainty label - Whether contamination findings are tied to actual lineage evidence - Whether minimization controls map to specific propagation points - Whether deletion and revalidation actions identify accountable owners and verification evidence - Remaining blockers before security reviewer, data owner, product owner, or platform owner decision ## Completion criteria The workflow is complete when: - Decision-critical knowledge has an evidence-based freshness state, SLO or trigger, owner, breach response, and revalidation priority. - Conflicting or superseded sources have an authority disposition and downstream exposure decision. - Retrieval configuration is supported by measured evidence or an explicit controlled experiment. - Effective entitlements are reconciled across source, ingestion, index, cache, retrieval, citation, and response layers. - Sensitive-context propagation is bounded and the final state is Ready, Restricted, Revalidate, or Hold with observable conditions. - Uninspected systems, unrun tests, and unavailable evidence remain explicit. # Assess Enterprise Knowledge and RAG Readiness Workflow ID: AMO-W-000016 Workflow URL: https://amo.ng/workflows/enterprise-knowledge-and-rag-readiness-review Use this Amo.ng workflow with your preferred AI tool. Complete the steps in order and carry the specified output forward. Outcome: A Ready, Restricted, Revalidate, or Hold package containing corpus decay findings, freshness objectives, source-authority decisions, retrieval evidence, entitlement controls, sensitive-context lineage, and accountable revalidation work. Required inputs: - Knowledge use case, decision risk, users, owners, corpus scope, and current RAG architecture - Source inventory, ownership, authority, effective dates, review history, ingestion records, and change evidence - Freshness expectations, incident history, current monitoring, and revalidation capacity - Representative documents, query logs or benchmarks, retrieval configuration, and answer standards - Identity, tenant, purpose, region, document ACL, index, cache, citation, and data-flow evidence - Sensitive-data classifications, memory and tool boundaries, retention rules, and release constraints ## Step 1 — Assess corpus freshness and knowledge decay **Instructions** Map decision-critical knowledge assets to source change, effective date, review evidence, usage and retrieval exposure, accountable ownership, decay risk, and revalidation triggers. **Input for this step** Supply the source inventory, content and decision uses, ownership, authoritative systems, ingestion dates, source changes, review history, usage exposure, and known stale-content incidents. **Carry forward** Carry the freshness map, decay-risk register, priority assets, authority gaps, and owner assignments into freshness-control design. **Review note** The knowledge owner and domain owner confirm which sources are decision-critical and which stale or unowned assets require restriction. **Prompt** Enterprise Knowledge Corpus Freshness and Decay Review **Prompt ID** AMO-P-000282 **Prompt URL** https://amo.ng/prompts/enterprise-knowledge-corpus-freshness-and-decay-review ## Step 2 — Define retrieval freshness controls **Instructions** Turn the decay findings into risk-based freshness objectives, measurement rules, source-change triggers, breach responses, revalidation evidence, and sustainable ownership. **Input for this step** Provide the freshness map, risk tiers, source-change cadence, ingestion and validation history, current monitoring, incident evidence, owner capacity, and operating constraints. **Carry forward** Carry the freshness SLO register, breach and exception rules, revalidation queue, evidence requirements, and owner commitments into source-authority review. **Review note** Knowledge and service owners approve risk tiers, achievable objectives, breach responses, and temporary restrictions. **Prompt** Retrieval Freshness SLO and Revalidation Design **Prompt ID** AMO-P-000308 **Prompt URL** https://amo.ng/prompts/retrieval-freshness-slo-revalidation-design ## Step 3 — Resolve source authority and supersession conflicts **Instructions** Determine which conflicting or superseded sources govern each use by tracing authority, effective dates, scope, lineage, exceptions, and current downstream retrieval exposure. **Input for this step** Supply conflicting source versions, authority rules, effective dates, owners, lineage and ingestion records, retrieval or citation exposure, and decision constraints. **Carry forward** Carry the authority matrix, supersession chains, affected content and decisions, remediation or exception states, and unresolved conflicts into retrieval validation. **Review note** The domain and knowledge owners approve authoritative-source dispositions; legal or compliance reviewers decide requirements within their remit. **Prompt** Knowledge Source Supersession and Conflict Resolution Brief **Prompt ID** AMO-P-000310 **Prompt URL** https://amo.ng/prompts/knowledge-source-supersession-conflict-resolution-brief ## Step 4 — Validate retrieval configuration when material **Instructions** Define a controlled experiment when chunking or metadata choices lack decision-grade evidence or are changing. If representative current evidence already supports the configuration, record it and mark a new experiment Not applicable. **Input for this step** Provide representative documents, source-authority decisions, current and candidate configuration, query logs or benchmarks, answer standards, source-version fields, and constraints. **Carry forward** Carry the experiment or verified-configuration boundary, query slices, measures, guardrails, acceptance criteria, and untested assumptions into entitlement review. **Review note** The retrieval, data, and domain owners approve the evidence standard and any configuration selected for testing or release. **Prompt** Retrieval Chunking and Metadata Experiment Design **Prompt ID** AMO-P-000284 **Prompt URL** https://amo.ng/prompts/retrieval-chunking-and-metadata-experiment-design ## Step 5 — Reconcile effective knowledge entitlements **Instructions** Compare authoritative access policy with effective permissions across source, ingestion, index, cache, retrieval, citation, and response layers; identify stale grants, missing restrictions, and recertification gaps. **Input for this step** Provide identity and tenant models, source ACLs, group and role data, ingestion and index mappings, cache behavior, retrieval traces, exception registers, recertification history, and prior findings. **Carry forward** Carry the entitlement matrix, drift findings, exposed scope, containment needs, owner actions, and regression requirements into context-lineage review. **Review note** The data owner, security reviewer, and identity or service owner authorize access removal, exception continuation, and recertification decisions. **Prompt** Knowledge Entitlement Drift Review **Prompt ID** AMO-P-000309 **Prompt URL** https://amo.ng/prompts/knowledge-entitlement-drift-review ## Step 6 — Trace sensitive context beyond retrieval **Instructions** Trace sensitive context from source and retrieval through agent handoffs, prompts, memory, tools, logs, shared workspaces, and downstream outputs. Reconcile propagation with freshness, authority, retrieval, and entitlement evidence. **Input for this step** Provide data classifications, RAG and agent flows, representative payloads, memory and tool configuration, logs, retention rules, tenant and purpose boundaries, and prior-step findings. **Carry forward** Produce the final Ready, Restricted, Revalidate, or Hold record with control work, restrictions, regression criteria, owners, evidence gaps, and re-review triggers. **Review note** Knowledge, data, product, and release owners make the readiness decision with security and privacy review for material exposure. **Prompt** Sensitive Context Propagation and Cross-Agent Contamination Audit **Prompt ID** AMO-P-000286 **Prompt URL** https://amo.ng/prompts/sensitive-context-propagation-and-cross-agent-contamination-audit Completion criteria: The workflow is complete when: - Decision-critical knowledge has an evidence-based freshness state, SLO or trigger, owner, breach response, and revalidation priority. - Conflicting or superseded sources have an authority disposition and downstream exposure decision. - Retrieval configuration is supported by measured evidence or an explicit controlled experiment. - Effective entitlements are reconciled across source, ingestion, index, cache, retrieval, citation, and response layers. - Sensitive-context propagation is bounded and the final state is Ready, Restricted, Revalidate, or Hold with observable conditions. - Uninspected systems, unrun tests, and unavailable evidence remain explicit.Copy workflow includes every step and the full linked Prompt content. Use with AI copies a shorter guide with Prompt links; neither action runs the Workflow.
Outcome
A Ready, Restricted, Revalidate, or Hold package containing corpus decay findings, freshness objectives, source-authority decisions, retrieval evidence, entitlement controls, sensitive-context lineage, and accountable revalidation work.
Before you begin
Have all or some of the following available before you start. The more relevant context you can provide, the stronger the workflow output will be.
- Knowledge use case, decision risk, users, owners, corpus scope, and current RAG architecture
- Source inventory, ownership, authority, effective dates, review history, ingestion records, and change evidence
- Freshness expectations, incident history, current monitoring, and revalidation capacity
- Representative documents, query logs or benchmarks, retrieval configuration, and answer standards
- Identity, tenant, purpose, region, document ACL, index, cache, citation, and data-flow evidence
- Sensitive-data classifications, memory and tool boundaries, retention rules, and release constraints
Ordered sequence
Workflow steps
Complete the steps in order. For each step, provide the listed context, carry its result into the next step, and pause wherever a review note is shown.
-
Step 1 Assess corpus freshness and knowledge decay
Map decision-critical knowledge assets to source change, effective date, review evidence, usage and retrieval exposure, accountable ownership, decay risk, and revalidation triggers.
Prompt: Enterprise Knowledge Corpus Freshness and Decay ReviewInput for this step
Supply the source inventory, content and decision uses, ownership, authoritative systems, ingestion dates, source changes, review history, usage exposure, and known stale-content incidents.
Carry forward
Carry the freshness map, decay-risk register, priority assets, authority gaps, and owner assignments into freshness-control design.
Review note
The knowledge owner and domain owner confirm which sources are decision-critical and which stale or unowned assets require restriction.
-
Step 2 Define retrieval freshness controls
Turn the decay findings into risk-based freshness objectives, measurement rules, source-change triggers, breach responses, revalidation evidence, and sustainable ownership.
Prompt: Retrieval Freshness SLO and Revalidation DesignInput for this step
Provide the freshness map, risk tiers, source-change cadence, ingestion and validation history, current monitoring, incident evidence, owner capacity, and operating constraints.
Carry forward
Carry the freshness SLO register, breach and exception rules, revalidation queue, evidence requirements, and owner commitments into source-authority review.
Review note
Knowledge and service owners approve risk tiers, achievable objectives, breach responses, and temporary restrictions.
-
Step 3 Resolve source authority and supersession conflicts
Determine which conflicting or superseded sources govern each use by tracing authority, effective dates, scope, lineage, exceptions, and current downstream retrieval exposure.
Prompt: Knowledge Source Supersession and Conflict Resolution BriefInput for this step
Supply conflicting source versions, authority rules, effective dates, owners, lineage and ingestion records, retrieval or citation exposure, and decision constraints.
Carry forward
Carry the authority matrix, supersession chains, affected content and decisions, remediation or exception states, and unresolved conflicts into retrieval validation.
Review note
The domain and knowledge owners approve authoritative-source dispositions; legal or compliance reviewers decide requirements within their remit.
-
Step 4 Validate retrieval configuration when material
Define a controlled experiment when chunking or metadata choices lack decision-grade evidence or are changing. If representative current evidence already supports the configuration, record it and mark a new experiment Not applicable.
Prompt: Retrieval Chunking and Metadata Experiment DesignInput for this step
Provide representative documents, source-authority decisions, current and candidate configuration, query logs or benchmarks, answer standards, source-version fields, and constraints.
Carry forward
Carry the experiment or verified-configuration boundary, query slices, measures, guardrails, acceptance criteria, and untested assumptions into entitlement review.
Review note
The retrieval, data, and domain owners approve the evidence standard and any configuration selected for testing or release.
-
Step 5 Reconcile effective knowledge entitlements
Compare authoritative access policy with effective permissions across source, ingestion, index, cache, retrieval, citation, and response layers; identify stale grants, missing restrictions, and recertification gaps.
Prompt: Knowledge Entitlement Drift ReviewInput for this step
Provide identity and tenant models, source ACLs, group and role data, ingestion and index mappings, cache behavior, retrieval traces, exception registers, recertification history, and prior findings.
Carry forward
Carry the entitlement matrix, drift findings, exposed scope, containment needs, owner actions, and regression requirements into context-lineage review.
Review note
The data owner, security reviewer, and identity or service owner authorize access removal, exception continuation, and recertification decisions.
-
Step 6 Trace sensitive context beyond retrieval
Trace sensitive context from source and retrieval through agent handoffs, prompts, memory, tools, logs, shared workspaces, and downstream outputs. Reconcile propagation with freshness, authority, retrieval, and entitlement evidence.
Prompt: Sensitive Context Propagation and Cross-Agent Contamination AuditInput for this step
Provide data classifications, RAG and agent flows, representative payloads, memory and tool configuration, logs, retention rules, tenant and purpose boundaries, and prior-step findings.
Carry forward
Produce the final Ready, Restricted, Revalidate, or Hold record with control work, restrictions, regression criteria, owners, evidence gaps, and re-review triggers.
Review note
Knowledge, data, product, and release owners make the readiness decision with security and privacy review for material exposure.
Completion criteria
The workflow is complete when:
- Decision-critical knowledge has an evidence-based freshness state, SLO or trigger, owner, breach response, and revalidation priority.
- Conflicting or superseded sources have an authority disposition and downstream exposure decision.
- Retrieval configuration is supported by measured evidence or an explicit controlled experiment.
- Effective entitlements are reconciled across source, ingestion, index, cache, retrieval, citation, and response layers.
- Sensitive-context propagation is bounded and the final state is Ready, Restricted, Revalidate, or Hold with observable conditions.
- Uninspected systems, unrun tests, and unavailable evidence remain explicit.
Was this useful?
Related Workflows
Browse WorkflowsInvestigate an AI Agent Security Incident
Reconstruct an AI agent incident, trace delegated authority and sensitive context, conditionally investigate memory or RAG authorization, and prepare evidence-based containment and recovery gates.
Review Production AI Evaluation Reliability
Determine whether evaluation data, automated judges, production comparability, and retrieval experiments provide reliable evidence for an AI release or operating decision.
Allocate an AI Investment Portfolio Under Constraints
Compare AI initiatives using work-design evidence, reviewer burden, model-routing economics, vendor concentration, and option value to allocate constrained investment transparently.