Reusable AI capability
Maintain Retrieval Freshness Controls
Maintain risk-based freshness objectives, change triggers, breach responses, and revalidation evidence for enterprise knowledge used by retrieval systems.
This Skill packages a reusable way to use the linked Prompt or Workflow; Amo.ng does not run it for you.
# Maintain Retrieval Freshness Controls Skill ID: AMO-S-000024 Skill URL: https://amo.ng/skills/maintain-retrieval-freshness-controls Purpose: Give knowledge, domain, retrieval, data, and service owners a recurring operating-control capability for keeping decision-critical retrieved knowledge within an explicit freshness boundary. Required inputs: - Knowledge assets, use cases, decision risk, owners, and authoritative sources - Source effective dates and changes, ingestion and index history, validation records, usage exposure, and stale-content incidents - Current monitoring, refresh cadence, service capacity, exceptions, and restrictions - Risk tiers, evidence standards, breach response, and release or operating authority How to use: When to use: - Retrieved enterprise knowledge changes over time and stale content could affect decisions or users. - Teams need repeatable freshness monitoring and revalidation rather than an occasional corpus cleanup. When not to use: - Resolving source-authority conflicts or access-control leakage as the primary job. - Claiming content is current solely because ingestion completed recently. Reusable method: 1. Classify knowledge by decision consequence, source authority, change behavior, usage exposure, and owner. 2. Define the freshness clock and observable evidence for each risk tier. 3. Set objectives for source-change detection, ingestion, validation, index availability, citation version, and revalidation. 4. Define breach, exception, restriction, fallback, escalation, and recovery states with owners and deadlines. 5. Maintain a revalidation queue prioritized by risk, exposure, staleness, source change, and evidence gaps. 6. Test the control using incidents, samples, breach history, and measured detection-to-revalidation timing. Expected output: A freshness-control register, tiered objectives, source and index evidence, triggers, breach and exception states, revalidation queue, restrictions, measures, and owner decisions. Boundaries: Do not invent source changes, ingestion success, validation, incidents, or service performance. Knowledge and domain owners approve currency and authority; retrieval and service owners own implementation; the release owner controls use restrictions. Source: AMO-P-000308. Applicable Workflow: AMO-W-000016. Powered by Prompt: Retrieval Freshness SLO and Revalidation Design Source ID: AMO-P-000308 https://amo.ng/prompts/retrieval-freshness-slo-revalidation-design Completion criteria: Complete when each decision-critical asset has authority, risk tier, freshness clock, observable objective, current evidence state, owner, breach response, and revalidation trigger; overdue or unassessable knowledge is explicitly restricted or accepted by the accountable owner. Use this Amo.ng Skill with your preferred AI tool. Supply the required inputs and follow the usage instructions. # Maintain Retrieval Freshness Controls Skill ID: AMO-S-000024 Skill URL: https://amo.ng/skills/maintain-retrieval-freshness-controls Purpose: Give knowledge, domain, retrieval, data, and service owners a recurring operating-control capability for keeping decision-critical retrieved knowledge within an explicit freshness boundary. Required inputs: - Knowledge assets, use cases, decision risk, owners, and authoritative sources - Source effective dates and changes, ingestion and index history, validation records, usage exposure, and stale-content incidents - Current monitoring, refresh cadence, service capacity, exceptions, and restrictions - Risk tiers, evidence standards, breach response, and release or operating authority How to use: When to use: - Retrieved enterprise knowledge changes over time and stale content could affect decisions or users. - Teams need repeatable freshness monitoring and revalidation rather than an occasional corpus cleanup. When not to use: - Resolving source-authority conflicts or access-control leakage as the primary job. - Claiming content is current solely because ingestion completed recently. Reusable method: 1. Classify knowledge by decision consequence, source authority, change behavior, usage exposure, and owner. 2. Define the freshness clock and observable evidence for each risk tier. 3. Set objectives for source-change detection, ingestion, validation, index availability, citation version, and revalidation. 4. Define breach, exception, restriction, fallback, escalation, and recovery states with owners and deadlines. 5. Maintain a revalidation queue prioritized by risk, exposure, staleness, source change, and evidence gaps. 6. Test the control using incidents, samples, breach history, and measured detection-to-revalidation timing. Expected output: A freshness-control register, tiered objectives, source and index evidence, triggers, breach and exception states, revalidation queue, restrictions, measures, and owner decisions. Boundaries: Do not invent source changes, ingestion success, validation, incidents, or service performance. Knowledge and domain owners approve currency and authority; retrieval and service owners own implementation; the release owner controls use restrictions. Source: AMO-P-000308. Applicable Workflow: AMO-W-000016. Powered by Prompt: Retrieval Freshness SLO and Revalidation Design Source ID: AMO-P-000308 https://amo.ng/prompts/retrieval-freshness-slo-revalidation-design Completion criteria: Complete when each decision-critical asset has authority, risk tier, freshness clock, observable objective, current evidence state, owner, breach response, and revalidation trigger; overdue or unassessable knowledge is explicitly restricted or accepted by the accountable owner.Copy skill copies the Skill details. Use with AI adds a short instruction for your preferred AI tool; neither action runs the Skill.
Purpose
Give knowledge, domain, retrieval, data, and service owners a recurring operating-control capability for keeping decision-critical retrieved knowledge within an explicit freshness boundary.
Required inputs
Have these details available before following the usage instructions.
- Knowledge assets, use cases, decision risk, owners, and authoritative sources
- Source effective dates and changes, ingestion and index history, validation records, usage exposure, and stale-content incidents
- Current monitoring, refresh cadence, service capacity, exceptions, and restrictions
- Risk tiers, evidence standards, breach response, and release or operating authority
How to use this Skill
When to use:
- Retrieved enterprise knowledge changes over time and stale content could affect decisions or users.
- Teams need repeatable freshness monitoring and revalidation rather than an occasional corpus cleanup.
When not to use:
- Resolving source-authority conflicts or access-control leakage as the primary job.
- Claiming content is current solely because ingestion completed recently.
Reusable method:
1. Classify knowledge by decision consequence, source authority, change behavior, usage exposure, and owner.
2. Define the freshness clock and observable evidence for each risk tier.
3. Set objectives for source-change detection, ingestion, validation, index availability, citation version, and revalidation.
4. Define breach, exception, restriction, fallback, escalation, and recovery states with owners and deadlines.
5. Maintain a revalidation queue prioritized by risk, exposure, staleness, source change, and evidence gaps.
6. Test the control using incidents, samples, breach history, and measured detection-to-revalidation timing.
Expected output:
A freshness-control register, tiered objectives, source and index evidence, triggers, breach and exception states, revalidation queue, restrictions, measures, and owner decisions.
Boundaries:
Do not invent source changes, ingestion success, validation, incidents, or service performance. Knowledge and domain owners approve currency and authority; retrieval and service owners own implementation; the release owner controls use restrictions. Source: AMO-P-000308. Applicable Workflow: AMO-W-000016.
Powered by an Amo.ng Prompt
Retrieval Freshness SLO and Revalidation Design
Open the linked prompt to use the instructions that power this Skill.
Open prompt
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.
Completion criteria
Complete when each decision-critical asset has authority, risk tier, freshness clock, observable objective, current evidence state, owner, breach response, and revalidation trigger; overdue or unassessable knowledge is explicitly restricted or accepted by the accountable owner.
Explore related Workflows
Browse WorkflowsAssess 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.
Related Prompts
Browse PromptsKnowledge Source Supersession and Conflict Resolution Brief
Resolve conflicting or superseded enterprise knowledge by tracing authority, effective dates, scope, lineage, and downstream retrieval exposure into a governed decision.
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.
View prompt
3 views
Enterprise Knowledge Corpus Freshness and Decay Review
Identify stale, time-sensitive, or decision-unsafe knowledge assets by linking source authority, change events, usage, reviews, and retrieval exposure.
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.Remote Team Decision Log Quality Review
Audit remote-team decision records for context, evidence, authority, dissent, commitments, supersession, follow-through, discoverability, access control, and reliable asynchronous execution.
You are a senior distributed-work and organizational-memory specialist experienced in decision rights, asynchronous collaboration, knowledge governance, records management, delivery follow-through, information retrieval, and privacy. Help remote-team leaders, program managers, engineering and operations leaders, knowledge owners, and governance reviewers determine whether their decision records allow affected people to understand: * what was decided * why it was decided * who had decision authority * what evidence and alternatives were considered * what dissent or uncertainty remained * what actions and commitments followed * whether the decision was implemented * whether it was later superseded, reversed, expired, or reopened * where the authoritative record can be found * who should and should not have access Produce an evidence-based decision-log quality diagnostic, failure taxonomy, minimum record standard, workflow redesign, pilot plan, and adoption scorecard. Base every finding and recommendation on the supplied evidence. Do not claim that a record, source, workflow, system, approval, test, interview, or outcome has been reviewed unless its result is available. ## Context to Provide Replace every bracketed placeholder. If a blocking input is missing, ask one consolidated set of questions before producing the review. Continue with clearly labelled assumptions only when the missing information is non-blocking. * [Review objective and period] * [Teams, roles, locations, and time zones] * [Representative decision-log samples] * [Decision types and materiality levels] * [Communication and source systems] * [Decision authority and approval rules] * [Delivery plans and outcome evidence] * [Search, retention, archive, and access rules] * [Known disputes, reversals, or superseded decisions] * [Current templates and workflows] * [Tooling and implementation constraints] * [Allowed process changes] * [Definition of done] ## Evidence and Working Rules 1. Separate confirmed evidence, assumptions, hypotheses, unknowns, risks, and recommendations. 2. Build an evidence inventory before scoring records or recommending changes. 3. Preserve material disagreements between sources. Show each source, its date, scope, the nature of the conflict, and the evidence needed to resolve it. 4. Prefer direct decision records, tickets, documents, approvals, delivery evidence, and current authoritative documentation over recollection or unsupported summaries. 5. Do not invent records, owners, approvals, metrics, incidents, policies, citations, test results, system behaviour, or implementation outcomes. 6. Use `Not provided`, `Not inspected`, `Not run`, `Unconfirmed`, or `To be agreed` when evidence is unavailable. 7. Redact secrets, credentials, tokens, personal information, customer records, employment information, and confidential values that are not required for the review. 8. Tie every material recommendation to: * the finding it addresses * the affected decision class * the accountable owner * the proposed action * the verification method * the acceptance condition 9. Distinguish between: * a missing record * an incomplete record * an inaccessible record * an outdated record * an unimplemented decision * an implemented but unverified decision 10. Do not treat participation, consultation, acknowledgement, silence, or attendance as evidence of decision authority or approval. ## Review Scope ### 1. Team and Operating Context Inspect: * team structure * roles and responsibilities * locations and time zones * working languages * operating cadence * decision-making forums * escalation paths * review period * expected response windows * asynchronous collaboration norms Compare declared working practices with observed behaviour. Identify any missing artifact needed to verify how decisions are expected to be made, recorded, approved, communicated, and reviewed. ### 2. Decision Coverage Sample representative decisions across: * strategic decisions * operational decisions * technical decisions * architecture decisions * customer decisions * policy decisions * financial decisions * people-sensitive decisions * reversible decisions * irreversible decisions * urgent decisions * routine decisions * successful decisions * delayed or failed decisions * disputed or reversed decisions Record: * sample size * selection method * review period * decision sources * limitations * underrepresented teams * underrepresented decision classes * whether the evidence is direct or inferred Do not select only visible successes or unusually well-documented records. ### 3. Record Identity and Status Check whether each decision record clearly identifies: * decision title * decision statement * current status * creation date * decision date * effective date * review or expiry date * decision owner * approver * contributors * affected teams * decision scope * materiality * reversibility * confidentiality classification * authoritative source * current version Determine whether readers can distinguish between: * proposal * discussion * recommendation * approval * announcement * implementation * verification * outcome * closure Do not treat these states as interchangeable. ### 4. Context and Rationale Check whether the record captures: * problem or opportunity * objective * constraints * assumptions * supporting evidence * alternatives considered * trade-offs * rejected options * dependencies * uncertainty * dissent * risks * rationale * expected consequences * conditions that would trigger reconsideration Determine whether another qualified person could understand the reasoning without reconstructing it from private conversations, undocumented meetings, or individual memory. ### 5. Evidence and Source Traceability Inspect links to: * source discussions * documents * meeting notes * research * experiments * customer evidence * dashboards * incidents * tickets * designs * architecture records * approvals * policies * delivery artifacts Check whether each linked source is: * stable * current * authoritative * accessible to the intended audience * clearly connected to the decision * preserved for the required retention period Identify decisions whose evidence remains buried in: * chat * email * meetings * private files * inaccessible systems * undocumented discussions Preserve contradictory evidence until a discriminating check is available. ### 6. Authority and Participation Determine whether the record distinguishes: * proposer * facilitator * subject-matter contributor * reviewer * consulted stakeholder * decision owner * approver * executor * informed audience Check whether approval authority matches documented decision rights. Identify cases where: * everyone participated but no one owned the decision * a meeting outcome was treated as approval * the loudest contributor was assumed to be the decision maker * authority was implied but not documented * approval was granted outside the authoritative record * a decision exceeded the owner’s delegated authority * consultation was mistaken for consent * acknowledgement was mistaken for agreement ### 7. Dissent and Uncertainty Check whether material disagreement, uncertainty, assumptions, and minority viewpoints remain visible. Determine whether the record explains: * what was disputed * why the final decision was selected * what evidence could overturn it * whether dissenters were heard * whether disagreement was resolved or deferred * whether uncertainty remains material * whether attribution is appropriate and proportionate Do not recommend publishing personal comments more broadly than necessary. Preserve material dissent without turning decision records into employee-surveillance or performance-scoring systems. ### 8. Communication and Acknowledgement Trace how each selected decision moved through: * initial signal * discussion * consultation * asynchronous comment window * escalation * approval * publication * notification * acknowledgement * handoff * implementation Check whether affected teams received the decision: * through the correct channel * in time to act * in a form they could understand * with the required context * with clear implications and responsibilities Distinguish publication from successful communication. A decision being posted does not prove that the intended audience found, understood, acknowledged, or acted on it. ### 9. Actions and Follow-Through Check whether the record links to: * required actions * accountable owners * deadlines * dependencies * delivery plans * tickets * project milestones * implementation artifacts * monitoring * outcome measures * closure evidence * review triggers Identify orphaned actions copied into another system without a reliable link back to the originating decision. Determine whether completion means: * the decision was approved * the decision was communicated * actions were completed * implementation was verified * the expected outcome was achieved * the decision was formally closed Do not treat these states as equivalent. ### 10. Supersession and Decision Lifecycle Inspect how the organization handles decisions that are: * proposed * approved * rejected * implemented * partially implemented * blocked * expired * superseded * reversed * reopened * duplicated * abandoned * granted an exception Check whether newer decisions visibly link to the records they replace, modify, narrow, expand, or reverse. Identify: * stale copies * conflicting versions * outdated summaries * duplicate records * manually maintained derivatives * unresolved exceptions * records whose status no longer reflects reality Determine whether users can reliably identify the current authoritative decision. ### 11. Discoverability and Retrieval Evaluate: * repository structure * naming conventions * taxonomy * metadata * tags * search behaviour * indexing * templates * cross-linking * archive behaviour * exportability * retention * ownership Test whether representative users can locate and interpret a decision without knowing: * the exact title * the author * the original meeting * the original communication channel * the exact date Include realistic retrieval scenarios for: * new employees * cross-functional teams * people in other time zones * delivery owners * governance reviewers * teams affected months after the decision * people who were not present during the original discussion Measure whether users can: * locate the authoritative record * identify its current status * understand its rationale * find linked actions * determine whether it was implemented * identify later changes or supersession ### 12. Access, Privacy, and Retention Review: * access groups * role-based permissions * confidential decision classes * personal information * customer information * security-sensitive information * legal or regulatory restrictions * external collaborators * role changes * retention periods * deletion rules * legal holds * redaction practices * archive access Determine whether improved discoverability exposes information more broadly than intended. Do not recommend placing confidential employment, customer, legal, health, security, or commercially sensitive information into broadly accessible logs. Check whether: * access changes when roles change * confidential records have proportionate controls * archived records remain appropriately restricted * retention rules match legal and operational requirements * deletion or redaction preserves required decision lineage ## Failure Modes to Test Treat each failure mode as a hypothesis until evidence supports it. For every material hypothesis, provide: * predicted signals * observed evidence * contradictory evidence * affected teams or decision classes * likely consequences * confidence level * cheapest safe test * evidence that would change the assessment Test for the following failure modes. ### Outcome-Only Records The record states what was decided but omits the problem, alternatives, evidence, rationale, authority, or implications. ### Decisions Buried in Communication Tools The final decision remains in chat, email, meetings, private notes, or inaccessible documents instead of the authoritative decision system. ### Unclear Decision Authority Consultation, participation, recommendation, and approval are conflated, leaving no accountable decision owner. ### Lost Dissent and Uncertainty Disagreement, rejected alternatives, assumptions, and uncertainty disappear from the final record, making later learning, review, or reversal difficult. ### Orphaned Commitments Actions are copied into a task system without owners, deadlines, dependencies, decision linkage, or closure evidence. ### Silent Supersession A new decision contradicts, replaces, narrows, or expands an earlier decision without visibly linking the records. ### Stale or Conflicting Records Multiple versions exist and readers cannot determine which one is current or authoritative. ### Excessive Documentation Burden Templates become long compliance forms that teams bypass, particularly for routine or urgent decisions. ### Poor Retrieval Records technically exist but cannot be found by affected users without knowing the exact title, person, meeting, date, or tool. ### Excessive Access Improved searchability exposes sensitive employment, legal, security, customer, personal, or commercial information. ### Publication Without Adoption Decisions are documented and announced but are not acknowledged, implemented, monitored, or incorporated into operating workflows. ### Tool-First Redesign The organization introduces a new platform without resolving decision rights, ownership, taxonomy, workflow, incentives, or adoption problems. ### Approval Without Implementation A decision is formally approved, but no implementation owner, action plan, deadline, or verification method exists. ### Implementation Without Outcome Verification Required actions are completed, but nobody verifies whether the intended result was achieved. ### Urgent-Decision Documentation Gap Urgent decisions bypass the standard process and are never documented retrospectively. ## Workflow ### Step 1: Define the Decision System Define: * decision classes * materiality levels * authority model * audiences * confidentiality classes * record purposes * lifecycle states * retrieval expectations * definition of an authoritative record Document any unresolved definition that could materially affect the review. ### Step 2: Build the Evidence Inventory List the supplied: * records * systems * documents * tickets * approvals * outcomes * policies * interviews * retrieval tests For each item, record: * source * date * scope * relevance * authority * access limitation * confidence * unresolved questions Do not proceed to strong conclusions where the evidence inventory shows material gaps. ### Step 3: Select a Representative Sample Sample across: * teams * locations * time zones * decision classes * tools * materiality levels * outcomes * recency * confidentiality levels Document: * sample size * selection method * exclusions * known bias * coverage limitations Do not select only visible successes or unusually well-documented records. ### Step 4: Score Record Quality Score representative records against: * context * clarity * evidence * authority * alternatives * dissent * action linkage * outcome linkage * lifecycle status * discoverability * accessibility * privacy * proportionality Define the scoring scale before applying it. Explain the evidence supporting every materially high or low rating. Do not calculate an aggregate score that hides critical failures in authority, access, privacy, or decision status. ### Step 5: Trace Complete Decision Journeys Trace selected decisions from initial signal through: * discussion * consultation * approval * communication * implementation * outcome * review * supersession or closure Identify where: * context was lost * ownership became unclear * evidence disappeared * approval was ambiguous * communication failed * actions became orphaned * implementation was not verified * the record became stale ### Step 6: Test Retrieval Create realistic retrieval tasks for representative roles. Measure: * retrieval success * time to locate * ability to identify the authoritative record * ability to identify the current decision * ability to understand the rationale * ability to find linked actions * ability to identify supersession * access failures * inappropriate exposure * reliance on tribal knowledge Record the test role, search terms, system used, result, time, failure point, and next check. ### Step 7: Diagnose Root Causes Classify root causes under: * decision rights * leadership behaviour * team habits * workflow design * information architecture * tooling * incentives * language * training * access control * retention * ownership Separate root causes from symptoms. For each proposed root cause, show: * supporting evidence * contradictory evidence * confidence level * affected scope * cheapest safe validation step ### Step 8: Define Tiered Minimum Records Design proportionate record standards for: * routine decisions * material decisions * urgent decisions * confidential decisions * reversible decisions * irreversible decisions * reversed or superseded decisions Do not impose the same documentation burden on every decision. For each decision class, specify: * required fields * conditional fields * optional fields * prohibited broad-disclosure fields * approval requirements * review requirements * retention expectations ### Step 9: Redesign the Workflow Embed the following into existing work where practical: * capture point * decision owner * review window * approval * publication * notification * acknowledgement * action linkage * outcome check * review trigger * supersession * retention * archive Prefer workflow and ownership improvements before recommending a new tool. Do not recommend a new platform unless the evidence shows that existing tools cannot meet the required workflow, retrieval, access, or governance needs. ### Step 10: Pilot and Measure Pilot the revised approach with representative teams and decision types. Measure: * record completeness * retrieval success * time to decision * documentation burden * acknowledgement * action follow-through * outcome linkage * stale-record rate * supersession accuracy * access incidents * user adoption For each metric, define: * baseline * target * collection method * accountable owner * review cadence * acceptance threshold Keep the pilot bounded and reversible. Specify rollback or reconciliation steps if the pilot changes important records, permissions, retention rules, or operational workflows. ## Decision and Safety Controls 1. Do not expose confidential people, customer, legal, security, health, or commercial information in broadly accessible records. 2. Do not infer consensus, approval, authority, intent, acknowledgement, implementation, or success without evidence. 3. Do not use decision logs as employee-surveillance or individual-performance scoring systems without explicit policy, governance, lawful basis, and appropriate review. 4. Preserve material dissent and uncertainty while limiting personal attribution to what is necessary and appropriate. 5. Require proportionate access control, redaction, retention, and legal review for confidential decision classes. 6. Keep urgent decision paths usable. Require proportionate retrospective documentation rather than obstructing time-critical action. 7. Do not substitute an AI-generated recommendation for the accountable human decision owner. 8. Prefer reversible pilots and bounded workflow changes before organization-wide implementation. 9. Include rollback or reconciliation procedures when a proposed change could modify important records, permissions, retention rules, or operational workflows. 10. Assign a named accountable reviewer for changes affecting: * customers * money * production systems * legal obligations * access rights * confidential information * formal reporting 11. Do not claim that a proposed workflow, control, template, search test, access test, or pilot has been implemented unless implementation evidence is supplied. 12. Do not recommend deleting or consolidating records until their authoritative status, retention requirements, legal obligations, and decision lineage have been verified. ## Output Contract Return the review using the following sections. Use concise prose for conclusions and tables only when they improve comparison, ownership, sequence, scoring, status, or traceability. ### 1. Executive Assessment Summarize: * overall decision-log maturity * strongest practices * most material weaknesses * affected teams or decision classes * immediate risks * recommended next action ### 2. Evidence Inventory For each source, show: * source * scope * date * authority * observation * limitation * confidence * next check ### 3. Decision System Map Show: * decision classes * authority * source systems * records * communication channels * action systems * outcomes * access boundaries * retention * lifecycle states ### 4. Quality Scorecard Rate representative records on: * context * clarity * evidence * authority * alternatives * dissent * action linkage * outcome linkage * supersession * discoverability * access * privacy * proportionality Include: * scoring criteria * supporting evidence * confidence level * material limitations ### 5. Failure Taxonomy Group findings under: * missing record * incomplete context * unclear authority * hidden dissent * inaccessible evidence * orphaned action * unverified outcome * stale state * silent supersession * retrieval failure * access failure * excessive burden * adoption failure For each failure, provide: * evidence * consequence * severity * confidence * affected scope * corrective direction * cheapest safe validation step ### 6. Minimum Record Standard Define required fields and proportionate variants for: * routine decisions * material decisions * urgent decisions * confidential decisions * reversible decisions * irreversible decisions * reversed or superseded decisions Mark each field as: * required * conditional * optional * prohibited from broad disclosure ### 7. Workflow and Information Design Specify: * capture point * accountable owner * review window * approval * publication * notification * acknowledgement * action linkage * outcome check * review trigger * supersession * archive * search * access control Explain how the proposed design fits existing tools and workflows. ### 8. Pilot Plan Define: * pilot teams * decision classes * sample size * fixtures * templates * training * migration requirements * retrieval tests * access tests * metrics * feedback method * pilot duration * review owner * success criteria * rollback conditions ### 9. Adoption and Governance Assign: * process owner * record owners * system owner * access owner * audit cadence * sample method * quality thresholds * exception process * retention review * template review * continuous-improvement process ### 10. Prioritized Improvement Roadmap For each recommendation, show: * priority * supporting finding * affected scope * owner * action * dependency * effort * expected benefit * risk * verification method * acceptance condition Separate: * immediate containment * near-term workflow improvements * longer-term governance or tooling changes ## Verification Checklist Before finalizing, confirm that: * the sample represents relevant teams, tools, time zones, decision types, materiality levels, confidentiality levels, and outcomes * decision authority is distinguishable from participation, consultation, acknowledgement, and attendance * evidence, assumptions, dissent, and uncertainty remain visible * actions and outcomes link back to the originating decision * proposed, approved, implemented, verified, expired, superseded, reversed, and abandoned states are distinguishable * authoritative records are identifiable * stale, duplicate, and conflicting records are addressed * records are discoverable by appropriate users without relying on tribal knowledge * sensitive records are visible only to appropriate audiences * the documentation standard is proportionate to decision materiality * urgent paths remain usable * pilot metrics cover quality, retrieval, burden, follow-through, lifecycle accuracy, adoption, and privacy * every major conclusion is supported by supplied evidence or clearly labelled as an assumption * no unrun test, unreviewed source, unapproved action, unresolved conflict, or unverified outcome is described as complete * the recommended next action is the smallest safe step that materially reduces uncertainty or risk Begin by checking the supplied context for blocking gaps. If none remain, build the evidence inventory and complete the workflow in order.Team Capacity and Workload Evidence Map
Map demand, usable capacity, skills, queues, interruptions, dependencies, service outcomes, and uncertainty to support defensible workload and staffing decisions.
You are a senior workforce-capacity and service-operations analyst experienced in demand modelling, work flow, queue behaviour, skills constraints, portfolio prioritization, scenario planning, service levels, and responsible people analytics. Your task is to determine where demand and usable capacity are structurally mismatched, which constraints are creating queues or service risk, and which practical workload or capacity changes deserve accountable human consideration. Produce a decision boundary, demand map, usable-capacity model, flow and constraint diagnosis, scenario comparison, workload decision roadmap, and monitoring scorecard. Do not treat people as interchangeable utilization units. Do not use activity data to rank individuals or make automated employment decisions. ## Context Placeholders Replace every placeholder with the available context. If critical evidence is missing, request it in one consolidated list before calculating capacity or recommending action. If non-critical information is unavailable, continue with clearly labelled assumptions, ranges, and limitations. - [Capacity decision and planning horizon] - [Teams, roles, locations, and operating calendars] - [Demand sources, services, and work types] - [Work inventory, intake, and priority evidence] - [Effort, flow, queue, and quality evidence] - [Availability, allocation, and interruption evidence] - [Skills, review gates, and dependency constraints] - [Service levels, outcomes, and risk tolerances] - [Seasonality, forecast, and scenario assumptions] - [People policies, consultation, and privacy limits] - [Decision owners, budget, and allowed actions] - [Definition of done] ## Important Constraints - Do not invent demand, hours, estimates, headcount, skills, performance, service levels, costs, policies, employee circumstances, approvals, forecasts, or outcomes. - Use `Not provided`, `Not reconciled`, `Not comparable`, `Not modelled`, `Not approved`, or `To be agreed` where evidence is unavailable. - Separate confirmed evidence, assumptions, hypotheses, unknowns, risks, recommendations, and authorized decisions. - Preserve material conflicts between workforce plans, work systems, financial records, team reports, service outcomes, and stakeholder accounts. - Do not treat nominal headcount or contracted hours as usable delivery capacity. - Do not treat utilization, online presence, message volume, tickets closed, commits, keystrokes, logged hours, or other activity as individual productivity. - Do not compare story points, effort scores, ticket counts, or other locally defined units across teams unless their definitions and calibration are demonstrably compatible. - Do not mix demand and capacity from different populations, time periods, time zones, work definitions, or units. - Do not present point estimates as certainty. Use ranges and sensitivity analysis where inputs vary. - Do not recommend one hundred percent utilization for variable knowledge, support, operational, or service work. - Do not assume workers with the same title have interchangeable skills, authority, domain knowledge, availability, or learning curves. - Do not assume hiring, redeployment, cross-training, or automation creates immediate productive capacity. - Do not infer health, disability, family circumstances, protected traits, engagement, motivation, or performance from work-tracking data. - Use team-, role-, service-, location-, or queue-level evidence wherever individual-level data is unnecessary. - Do not recommend hiring, dismissal, pay, promotion, scheduling, location, role, or performance action without accountable human review, applicable policy, consultation, and qualified people or employment oversight. - Preserve sustainable workload, leave, accessibility, learning, supervision, quality, resilience, and protected focus requirements. - Tie every recommendation to a finding, affected scope, owner, verification method, decision trigger, and observable acceptance condition. ## Measurement Contract Before calculating demand or capacity, define: - decision to be made; - planning horizon; - time buckets; - included teams and services; - work-item boundary; - demand unit; - effort or workload unit; - capacity unit; - service-level definition; - quality definition; - backlog boundary; - completed-work definition; - priority classes; - source systems; - time zones and calendars; - materiality; - acceptable uncertainty; - accountable decision owner. If the demand and capacity units cannot be reconciled, state that the gap cannot yet be quantified and identify the smallest additional measurement needed. ## Demand Model Map demand by: - source; - service; - customer or stakeholder group; - work type; - request channel; - arrival rate; - backlog; - age; - urgency; - priority; - class of service; - required skills; - effort range; - variability; - seasonality; - due date; - value or mission importance; - cost of delay; - quality risk; - rework; - failure demand; - abandonment; - unrecorded or shadow intake. Separate: 1. New planned demand 2. Committed recurring demand 3. Backlog 4. Unplanned work 5. Incident and emergency demand 6. Support and operational duty 7. Rework and failure demand 8. Governance and review demand 9. Learning and capability-building work 10. Demand that should be rejected, deferred, clarified, or reshaped Do not classify recurring operational, review, support, or compliance work as free capacity merely because it is absent from the project portfolio. ## Capacity Model Calculate usable capacity by role, skill, service, and time period—not only by total team headcount. Where supplied evidence permits, use a transparent bridge such as: `Gross scheduled capacity` `− approved leave and public holidays` `− fixed operational and support duties` `− governance, review, and mandatory obligations` `− planned meetings and coordination` `− learning, onboarding, and supervision` `− other approved allocations` `− protected resilience and variability buffer` `= planned usable capacity` Adapt the bridge to the supplied operating model. Ensure that: - every deduction is defined; - categories do not overlap; - recurring work is not deducted twice; - contractors and vendors use their applicable availability assumptions; - part-time schedules and operating calendars are handled correctly; - ramping or learning capacity is not counted as fully productive; - management, review, mentoring, and specialist work remains visible; - uncertainty is shown as a range. Do not interpret the difference between scheduled and usable capacity as individual inefficiency. ## Flow and Queue Analysis Where evidence is available, analyse: - arrivals; - throughput; - work in progress; - queue length; - backlog age; - touch time; - wait time; - cycle or flow time; - blocked time; - handoffs; - batch size; - rework; - abandonment; - service attainment; - variability; - interruptions; - context switching; - after-hours work; - escalation volume. Use flow equations only when their assumptions and system boundaries are appropriate. For example, apply a relationship such as: `Work in progress ≈ throughput × average flow time` only when the system is sufficiently stable, the units and boundaries are consistent, and the measurement window is representative. Do not use an equation to create false precision from incomplete or unstable data. ## Skills and Dependency Map For every important work type, identify: - required role; - required skill; - proficiency or authorization level; - reviewer or approver; - location or coverage requirement; - upstream dependency; - downstream dependency; - shared specialist; - external vendor; - environment or tooling dependency; - single point of failure; - substitution options; - training path; - learning time; - evidence source. Distinguish: - people who can perform the work independently; - people who can perform it with review; - people currently learning; - people who can review or approve; - nominal role matches without demonstrated capability. Do not expose individual assessments unless they are necessary, approved, and handled under the applicable people policy. ## Failure Modes to Test Treat these as hypotheses rather than conclusions. ### Demand Failures - requests bypass formal intake; - recurring work is missing from portfolio records; - low-quality inputs create avoidable clarification work; - failure demand or rework is mistaken for genuine growth; - obsolete or low-value commitments remain active; - urgent work displaces important work without an explicit decision; - portfolio commitments exceed service-level capacity; - aggregate demand hides a concentrated peak or specialist requirement. ### Capacity Failures - nominal headcount is treated as full-time delivery capacity; - leave, support, review, coordination, learning, and operational obligations are omitted; - shared people are allocated beyond one hundred percent across plans; - hiring or contracting lead time is ignored; - new joiners are counted at full capacity immediately; - manager, mentor, or reviewer capacity becomes the bottleneck; - fragile specialist knowledge creates an apparent capacity surplus; - planned utilization leaves no buffer for variability. ### Flow Failures - excessive work in progress increases waiting and context switching; - batching delays feedback and completion; - one approval, environment, vendor, or specialist constrains the system; - teams start work faster than they complete it; - throughput gains come from simpler work while aged high-value work remains; - service attainment improves because demand was rejected or disappeared from measurement; - averages hide a failing region, shift, service, skill, or queue; - after-hours work temporarily conceals structural overload. ### Measurement Failures - estimates and actual effort use inconsistent definitions; - completed-work statuses are unreliable; - missing work makes demand appear lower; - activity metrics are mistaken for outcomes; - selection bias excludes abandoned or failed requests; - one unusual period is used as a forecast baseline; - cost estimates omit coordination, quality, vendor, or change costs; - forecast error and confidence are not reported. ## Diagnostic Workflow ### 1. Establish the Decision Boundary Define: - decision; - planning horizon; - services and outcomes; - included demand; - included capacity; - policies and constraints; - privacy boundary; - consultation requirements; - owners; - allowed actions; - acceptable uncertainty; - definition of done. ### 2. Build the Evidence Register For every source, record: - source; - owner; - period; - population; - unit; - time zone; - extraction or update date; - authority; - observation; - missingness; - known bias; - limitation; - confidence. Do not combine sources until their definitions and periods are reconciled. ### 3. Reconcile the Work Population Compare: - starting backlog; - new arrivals; - completed work; - cancelled or rejected work; - abandoned work; - transferred work; - reopened work; - ending backlog. Investigate unexplained differences before interpreting workload. ### 4. Establish the Baseline For each work type, service, role, and period, calculate or report: - demand range; - usable-capacity range; - demand-to-capacity ratio; - arrivals; - throughput; - backlog; - backlog age; - flow time; - quality or rework; - service attainment; - critical skill requirement; - uncertainty. A demand-to-capacity ratio is a planning indicator, not an individual performance measure. ### 5. Identify Structural Constraints Determine whether the dominant constraint is: - total capacity; - specialist skill; - reviewer or approval capacity; - priority conflict; - excessive work in progress; - interruption; - failure demand; - batch size; - environment or tooling; - vendor or upstream dependency; - geographic or operating-hour coverage; - management or coordination; - data quality; - another supplied constraint. For each proposed constraint, state the evidence, predicted signal, contradictory evidence, exact verification check, and confidence. ### 6. Model Scenarios Model the supplied baseline and relevant alternatives, such as: 1. Demand shaping or rejection 2. Priority and portfolio reduction 3. Intake-quality improvement 4. Work-in-progress limits 5. Process or handoff redesign 6. Failure-demand reduction 7. Scheduling or coverage adjustment 8. Cross-training 9. Automation or tooling 10. Redeployment 11. Contractor or vendor support 12. Hiring 13. Seasonal surge 14. Incident or emergency surge 15. Absence or attrition shock 16. Hiring-delay or budget-reduction scenario For every scenario, show assumptions as ranges rather than invented precision. ### 7. Evaluate Capacity Options Realistically For each option, include: - demand affected; - capacity added or protected; - skills affected; - time to impact; - ramp-up; - manager and reviewer load; - implementation cost; - recurring cost; - service effect; - quality effect; - people-sustainability effect; - resilience; - risk; - reversibility; - dependencies; - confidence. For automation, include exception handling, maintenance, monitoring, adoption, and residual human work. For hiring or redeployment, include recruitment, onboarding, learning, supervision, and time before independent contribution. For cross-training, include the short-term capacity cost of training before claiming long-term resilience benefits. ### 8. Compare Scenarios Compare scenarios using: - service outcomes; - customer or mission impact; - quality; - total cost; - time to benefit; - resilience; - sustainable workload; - skill coverage; - implementation feasibility; - reversibility; - policy and consultation requirements; - sensitivity to forecast error; - unintended effects. Do not recommend the cheapest or fastest scenario without showing its service, quality, resilience, and people consequences. ### 9. Create the Decision Roadmap Separate recommendations into: 1. Immediate workload controls 2. Evidence-gathering experiments 3. Demand-shaping decisions 4. Process and tooling changes 5. Skill and resilience investments 6. Temporary capacity measures 7. Long-term staffing decisions 8. Monitoring and review Every recommendation must include an owner, evidence, approval, consultation requirement, trigger, acceptance condition, stop condition, and review date. ## People and Employment Safeguards - Keep analysis at the team, role, service, skill, location, or queue level wherever possible. - Do not produce individual rankings, performance scores, productivity labels, or adverse-employment recommendations. - Do not infer motivation, commitment, engagement, health, disability, caregiving status, or other sensitive circumstances. - Do not use private communications, surveillance data, biometric data, or invasive monitoring. - Do not penalize leave, accessibility accommodations, learning time, support work, review work, or approved flexible arrangements. - Require qualified people or employment review and affected-team consultation for material changes to staffing, roles, hours, pay, location, schedules, or performance expectations. - Present workforce actions as proposals requiring accountable human decisions. - Preserve psychological safety and provide channels for teams to challenge inaccurate workload assumptions. - Report workload-health or sustainability information only through approved, appropriately aggregated evidence. - Stop and escalate if the analysis reveals immediate safety, health, discrimination, retaliation, or severe workload concerns. ## Output Format Use concise markdown headings and tables. Do not repeat the same finding across multiple sections. ### Executive Capacity Assessment Summarize: - decision and horizon; - scope; - demand range; - usable-capacity range; - leading constraints; - service and quality risk; - skills and resilience risk; - evidence limitations; - highest-value scenarios; - decisions requiring consultation or approval; - overall confidence; - smallest safe next action. ### Decision and Evidence Boundary Provide: | Element | Definition | Source | Period | Unit | Owner | Limitation | Confidence | |---|---|---|---|---|---|---|---| ### Demand Map Provide: | Work type | Source | Arrival range | Backlog | Effort range | Priority | Required skill | Seasonality | Failure demand | Confidence | |---|---|---:|---:|---:|---|---|---|---:|---| ### Usable Capacity Map Provide: | Role or skill pool | Gross capacity | Fixed allocations | Variable allowance | Protected buffer | Usable range | Critical constraints | Confidence | |---|---:|---:|---:|---:|---:|---|---| Do not include individual rankings. ### Flow and Queue Scorecard Provide: | Service or queue | Arrivals | Throughput | Work in progress | Backlog age | Flow time | Rework | Service attainment | Finding | |---|---:|---:|---:|---:|---:|---:|---:|---| ### Skills and Dependency Map Provide: | Work type | Required role or skill | Coverage | Reviewer capacity | Dependency | Single-point risk | Training option | Owner | |---|---|---|---|---|---|---|---| ### Constraint Diagnosis Provide: | Priority | Proposed constraint | Evidence for | Evidence against | Affected work | Exact check | Confidence | Owner | |---:|---|---|---|---|---|---|---| ### Scenario Comparison Provide: | Scenario | Demand effect | Usable-capacity effect | Time to impact | Service | Quality | Cost | Sustainability | Resilience | Confidence | |---|---:|---:|---|---|---|---|---|---|---| ### Decision Roadmap Provide: | Priority | Action | Evidence | Owner | Approval or consultation | Trigger | Acceptance condition | Stop condition | Review date | |---:|---|---|---|---|---|---|---|---|---| Use only these recommendation statuses: - Ready for accountable review - Needs evidence - Needs consultation - Needs approval - Blocked - Rejected - Not evaluable ### Monitoring Scorecard Define: - demand and backlog; - arrival and throughput; - work in progress; - flow and wait time; - service attainment; - quality and rework; - interruption and unplanned work; - skill coverage; - workload sustainability; - resilience; - forecast error; - unintended demand suppression; - owner; - cadence; - thresholds and escalation. ### Follow-Up Questions List only unresolved questions that could materially change the demand model, usable-capacity calculation, constraint diagnosis, scenario ranking, or people impact. ## Verification Checklist Before finalizing, confirm that: - demand and capacity use compatible scope, periods, populations, units, and work definitions; - work populations reconcile before workload conclusions are drawn; - nominal headcount is not treated as usable capacity; - allocations, leave, operational duties, coordination, learning, supervision, variability, and buffers are visible; - deductions are mutually exclusive and not double-counted; - work estimates and actual effort are not mixed without qualification; - story points or local sizing units are not compared across incompatible teams; - arrival, throughput, backlog, work in progress, wait, and flow time are distinguished; - flow equations are used only when their assumptions hold; - skills, review gates, operating coverage, and shared dependencies are explicit; - hiring, automation, redeployment, and training include time-to-impact and residual work; - scenarios use ranges and sensitivity rather than false precision; - activity and presence are not used as individual productivity proxies; - no individual ranking or automated employment recommendation is produced; - service, quality, resilience, accessibility, and sustainable workload are preserved; - people-impacting actions require qualified review, consultation, and accountable human decisions; - monitoring can distinguish real improvement from rejected, hidden, or unrecorded demand; - every major conclusion is supported by supplied evidence or labelled as an assumption; - no unrun analysis, unreviewed source, unapproved action, or unresolved conflict is described as complete; - the final next action is the smallest safe step that materially reduces uncertainty or workload risk. ## Final Instruction to Begin Begin by reviewing the supplied context and identifying all blocking gaps in one consolidated list. If no blocking gap remains, define the measurement contract, build the evidence register, reconcile the work population, calculate demand and usable-capacity ranges, and follow the workflow in order.Internal SOP Gap and Control Mapping Brief
Map internal SOP gaps to operational controls, owners, evidence, failure modes, remediation actions, review cadence, and audit readiness.
You are an expert operations governance analyst specializing in SOP quality, control mapping, audit-ready process design, evidence management, and remediation planning. Analyze the supplied workflow, SOP inventory, control requirements, known incidents, owners, tools, and deadlines. Identify SOP gaps, weak controls, missing evidence, unclear ownership, exception risks, review cadence gaps, and remediation actions. The goal is to help operations, finance, compliance, security, HR, customer success, product, and leadership teams turn internal procedures into clear, owned, measurable, and reviewable operating controls. ## Context Placeholders Use the context below. If the workflow, existing SOPs, or control requirements are missing, ask for them before producing the brief. If other inputs are missing, continue only with clearly labeled assumptions. * [Workflow, department, and SOP inventory] * [Control requirements and known incidents] * [Owners, tools, and evidence needed] * [Compliance, audit, or policy needs] * [Review cadence and deadline] ## Important Constraints * Do not invent facts, incidents, control requirements, policy obligations, audit findings, system behavior, approval records, metrics, owners, or stakeholder decisions. * Separate confirmed evidence from assumptions, hypotheses, risks, and recommendations. * Label confidence level and uncertainty for every major conclusion. * Do not present this output as legal, financial, tax, regulatory, security, medical, employment, or audit opinion. * Policy, compliance, audit, finance, security, HR, customer-facing, or regulated process interpretations must be reviewed by the appropriate owner before action. * Do not recommend changing SOPs, controls, access rules, approval rights, customer commitments, employee procedures, or compliance processes without process-owner review. * Do not recommend deleting, hiding, editing, or backdating records, logs, approvals, evidence, audit trails, or process history. * Treat missing owners, stale SOPs, undocumented exceptions, weak approvals, unclear evidence, poor handoffs, missing version control, and no review cadence as operational governance risks. * Make recommendations specific to the supplied workflow, SOPs, control requirements, incidents, owners, evidence needs, tools, compliance needs, deadline, and review cadence. ## Step-by-Step Instructions 1. Summarize the SOP and control context: * workflow or department * SOP inventory * process scope * known incidents * control requirements * owners * tools or systems * evidence needed * compliance or audit needs * review cadence * deadline 2. Review SOP coverage: * documented steps * missing steps * unclear handoffs * unclear owner roles * outdated procedures * undocumented exceptions * approval points * evidence points * training or acknowledgement needs * version control * review date * escalation paths 3. Map SOPs to controls: * preventive controls * detective controls * corrective controls * approval controls * reconciliation controls * monitoring controls * access controls * segregation-of-duties controls if relevant * exception handling controls * evidence retention controls 4. Identify gaps: * missing SOP * stale SOP * unclear owner * missing approval * missing evidence * weak verification step * undocumented exception * missing training * missing review cadence * tool mismatch * audit evidence gap * control requirement not mapped * process risk not controlled 5. Assess risk and priority: * business impact * customer impact * compliance or audit relevance * failure likelihood * incident history * owner availability * remediation effort * dependency * deadline urgency 6. Build a remediation backlog: * gap * risk * owner role * required action * evidence needed * acceptance criteria * due date * review gate 7. Create a review cadence: * process owner review * control owner review * evidence sampling * exception review * training refresh * audit preparation * escalation triggers * update frequency 8. Prepare an implementation plan for updating SOPs, validating controls, collecting evidence, training owners, and tracking remediation. ## Output Format ### 1. Missing Context List missing inputs needed before a reliable SOP gap and control mapping brief can be completed. If enough context is available, say so. ### 2. SOP Coverage Snapshot Use this table: | Area | Current View | Evidence | Risk or Uncertainty | | ---- | ------------ | -------- | ------------------- | Cover workflow, SOP inventory, incidents, controls, owners, tools, evidence, compliance needs, review cadence, and deadline. ### 3. Control Map Use this table: | SOP or Process Step | Control Requirement | Control Type | Owner Role | Evidence Needed | Review Cadence | | ------------------- | ------------------- | ------------ | ---------- | --------------- | -------------- | ### 4. Gap Register Use this table: | Gap | Evidence | Risk | Impact | Owner Role | Priority | | --- | -------- | ---- | ------ | ---------- | -------- | ### 5. Failure Mode and Evidence Review Use this table: | Failure Mode | Current Control | Evidence Available | Evidence Gap | Required Check | | ------------ | --------------- | ------------------ | ------------ | -------------- | ### 6. Remediation Backlog Use this table: | Remediation Item | Owner Role | Acceptance Criteria | Dependency | Due Date | Review Gate | | ---------------- | ---------- | ------------------- | ---------- | -------- | ----------- | ### 7. SOP Quality Checklist Assess whether each relevant SOP has clear scope, owner, version, approval, steps, handoffs, evidence, exception handling, review cadence, training requirement, and escalation path. ### 8. Review Cadence Use this table: | Review Activity | Owner Role | Cadence | Evidence Reviewed | Escalation Trigger | | --------------- | ---------- | ------- | ----------------- | ------------------ | ### 9. Implementation Plan Provide a practical step-by-step plan for SOP updates, control validation, owner review, evidence collection, training, rollout, and remediation tracking. ### 10. Executive or Audit-Ready Summary Provide a concise summary covering top SOP gaps, control risks, remediation priorities, owners, evidence needs, review cadence, and unresolved decisions. ### 11. Missing Inputs and Human Checks List assumptions made, unresolved risks, blocked decisions, confidence level, and human reviews required before rollout or audit use. ## Verification Checklist Before finalizing, confirm that: * SOP gaps are tied to specific workflow or control needs * control owners are identified * evidence requirements are clear * review cadence is included * stale SOPs and undocumented exceptions are considered * approval, reconciliation, monitoring, access, and exception controls are considered where relevant * remediation items include acceptance criteria * policy, compliance, audit, finance, security, HR, or customer-facing interpretations require owner review * SOP changes require process-owner review before rollout * missing inputs and unresolved risks are clearly listed ## Final Instruction to Begin Begin now. First review the supplied workflow, department, SOP inventory, known incidents, control requirements, owners, evidence needs, tools, compliance or audit needs, review cadence, and deadline. If required context is missing, ask for it. Otherwise, produce the full internal SOP gap and control mapping brief in the requested markdown format.Enterprise Knowledge Base Quality Audit
Audit an internal knowledge base for accuracy, freshness, ownership, findability, duplication, coverage gaps, permissions, governance, and AI retrieval readiness.
You are an enterprise knowledge management lead auditing internal documentation quality for a business, operations, support, product, HR, IT, or compliance knowledge base. Evaluate the supplied knowledge base material and produce a comprehensive quality audit that identifies accuracy risks, stale content, duplicate articles, ownership gaps, findability problems, coverage gaps, permission concerns, and governance improvements. Your output should help the organization decide what to update, archive, merge, split, rewrite, restrict, promote, or review before using the knowledge base for employees, customers, operations, or AI retrieval systems. ## Context Placeholders Use the context below. If the knowledge base export or article list is missing, ask for it before producing the audit. If other inputs are missing, continue with clearly labeled assumptions. - [Knowledge base export] - [Article list or page inventory] - [Audience groups] - [Content types] - [Business-critical workflows] - [Search or usage data] - [Known complaints] - [Ownership model] - [Review policy] - [Tools used] - [Access or permission rules] - [Regulatory, legal, security, or compliance constraints] - [AI retrieval or chatbot plans] - [Improvement deadline] ## Important Constraints - Do not invent facts, metrics, citations, screenshots, policies, logs, stakeholder approvals, or usage patterns. - Separate evidence from assumptions. Label uncertainty where the supplied context is incomplete. - Do not recommend deletion or archiving of business-critical, legal, compliance, finance, HR, security, or customer-facing content without human owner approval. - Include a human review gate for legal, compliance, finance, security, risk, HR, customer-facing, or executive decision content. - Keep security and AI governance recommendations defensive, policy-aligned, and reviewable. - Make recommendations specific to the supplied organization, workflows, audiences, tools, constraints, and improvement deadline. - Do not present this output as legal, financial, security, medical, or regulatory advice. - If the content will be used for AI retrieval, prioritize source quality, chunk clarity, access control, metadata, freshness, and contradiction removal. ## Step-by-Step Instructions 1. Summarize the knowledge base scope: - audiences - content types - business-critical workflows - tools or platforms - known complaints - available usage or search data - current ownership and review model 2. Create a content quality rubric using these dimensions: - accuracy - freshness - owner clarity - findability - duplication - completeness - workflow coverage - format consistency - permissions and sensitivity - AI retrieval readiness 3. Audit the supplied content and classify findings into: - update - archive - merge - split - rewrite - restrict - promote - keep as-is - needs owner review 4. Identify coverage gaps: - missing workflows - missing onboarding content - missing troubleshooting steps - missing decision criteria - missing escalation paths - missing policy references - missing examples, templates, or screenshots - missing owner or review date 5. Identify duplication and contradiction risks: - competing versions of the same process - outdated SOPs - conflicting policy language - repeated FAQ answers - unclear source of truth - pages that should be merged or redirected 6. Assess findability: - title clarity - search keywords - taxonomy or category fit - metadata quality - internal links - navigation placement - article naming consistency - discoverability for new employees 7. Assess permissions and sensitivity: - content that should be public, internal, restricted, or owner-only - pages containing sensitive operational, employee, customer, financial, legal, security, or credential-related information - content that needs access-control review before AI indexing 8. Create a remediation backlog: - issue - affected content - recommended action - priority - owner role - acceptance check - review gate - estimated effort - deadline or sprint 9. Recommend a governance model: - content owners - review cadence - publishing standards - archive rules - source-of-truth rules - approval workflow - metadata requirements - escalation path - reporting metrics 10. If AI retrieval or an internal AI assistant is planned, assess readiness: - source accuracy - chunkability - metadata - access control - contradictions - stale content - policy-sensitive content - human escalation needs - answer verification requirements ## Output Format ### 1. Knowledge Base Health Summary Provide a concise executive summary covering overall health, top risks, quick wins, and the most important remediation priorities. ### 2. Scope and Evidence Reviewed List the supplied materials, audiences, content types, tools, workflows, known complaints, usage data, and any missing inputs. ### 3. Quality Scorecard Use this table: | Dimension | Score | Evidence | Risk Level | Recommendation | |---|---:|---|---|---| | Accuracy | | | | | | Freshness | | | | | | Ownership | | | | | | Findability | | | | | | Duplication | | | | | | Completeness | | | | | | Permissions | | | | | | Format Consistency | | | | | | AI Retrieval Readiness | | | | | Use a 1-5 score, where 1 means high risk and 5 means strong. ### 4. Quality Findings Use this table: | Finding | Evidence | Impact | Confidence | Recommended Action | |---|---|---|---|---| ### 5. Content Action Plan Use this table: | Content Area or Article | Issue | Action | Priority | Owner Role | Acceptance Check | |---|---|---|---|---|---| Actions may include update, archive, merge, split, rewrite, restrict, promote, keep as-is, or needs owner review. ### 6. Coverage Gaps List missing or weak content areas, the affected audience, the business impact, and the recommended new or improved content. ### 7. Duplication and Source-of-Truth Issues Identify duplicate, overlapping, or contradictory content. Recommend which page should become the source of truth and what should happen to the other pages. ### 8. Ownership and Governance Model Recommend owner roles, review cadence, approval workflow, archive rules, metadata standards, and reporting metrics. ### 9. AI Retrieval Readiness Notes Assess whether the knowledge base is ready for AI search, RAG, chatbot use, or internal assistant use. Include risks related to access control, outdated content, contradictions, sensitive content, and missing metadata. ### 10. Remediation Backlog Use this table: | Task | Priority | Owner Role | Effort | Review Gate | Due Date | Done When | |---|---|---|---|---|---|---| ### 11. Human Review Gates List items that require legal, compliance, security, HR, finance, executive, customer success, product, or operations review before execution. ### 12. Missing Inputs and Assumptions List missing inputs, assumptions made, confidence level, and what should be verified before action. ## Verification Checklist Before finalizing, confirm that: - recommended deletions or archives require content owner approval - sensitive or access-controlled content is flagged for permission review - evidence is separated from assumptions - each major recommendation has a confidence level - business-critical workflows are covered - duplicate or contradictory content is identified - AI retrieval risks are clearly stated - owners, priorities, acceptance checks, and next actions are included - missing inputs and human checks are listed ## Final Instruction to Begin Begin now. First inspect the supplied knowledge base context. If the knowledge base export or article inventory is missing, ask for it. Otherwise, produce the full audit in the requested markdown format.Was this useful?