Evidence and approval checklist

For each requirement below, record a source or artifact ID, version, observation period, owner, permitted use, verification status, and next action with a due date. The workbook provides editable fields for these items. Use “not applicable” only with a reason; a blank or “not checked” remains unresolved.

Shared requirements

• Baseline and assisted effort cover the same unit of work and follow-up window.
• Volume, eligibility, and adoption are traceable to a defined population.
• Hourly capacity value has an explicit basis; recurring costs exclude already-counted handling effort.
• Any avoidable cash expense has a specific mechanism and responsible owner.
• Cash spending and setup costs are distinguished from existing staff capacity.
• Source permissions cover both access and the intended reuse.
• Model, prompt, source, and integration versions are recorded.
• Acceptance rules, severity definitions, sampling plan, and pause authority were set in advance.

Support

• Product instructions have current applicability, effective dates, and article owners.
• Account boundaries are enforced before retrieval exposes private content.
• Clarification and escalation paths cover missing or conflicting evidence.
• Repeat contacts, reopened requests, and rejected drafts are retained in the evaluation.

Proposals

• Each credential has supporting evidence and permission for this prospect-facing use.
• The requirements matrix reflects the latest buyer request and addenda.
• Staffing, start dates, scope, exclusions, and price refer to the same approved revision.
• Unresolved mandatory conditions prevent final submission approval.

Order intake

• Customer identity, PO identity, duplicates, and amendments have explicit rules.
• SKU and unit mappings are customer-specific where required and have owners.
• Quantity and price bases reconcile without overwriting original document values.
• Missing delivery details and ambiguous products block submission.
• Retries, concurrent workers, lost acknowledgements, and destination reconciliation have been tested.

Incident triage

• Log fields allowed into model context are listed, redacted before retrieval, and covered by a retention rule.
• Runbooks have owners, versions, service applicability, and review dates; conflicts route to the service owner.
• The brief reports source health and uses explicit, adjustable time windows.
• Evidence of a possible security event hands the case to the security process and its owner.

Onboarding

• The entitlement record is a structured source of truth, and plan steps are checked against it by rules.
• Implementation guides have owners, product versions, edition applicability, effective dates, and retirement rules.
• Milestones are confirmed by product completion signals where they exist, not by a closed conversation.

Knowledge retrieval

• Access filtering happens before ranking and context assembly, for every query.
• Documents carry access labels; unlabeled material is denied by default until curated.
• Entitlement changes reach the index, embeddings, caches, and stored conversations within a tested interval.
• Each passage records document ID, version, date, owner, and reuse status.

Meeting follow-up

• Recording permission is confirmed for each meeting and audience before it starts.
• Transcript and audio access, storage location, and retention period are set and recorded.
• Off-record segments are excluded before extraction, not filtered afterward.
• Tasks are created only after approval, with identifiers that prevent duplicates.

Forecasting

• Demand history records stockout periods and unmet requests where observable.
• Service target, safety buffers, pack sizes, minimums, and lead times sit in an owned policy layer.
• The service-level definition was agreed before the trial.
• History, flags, method version, forecast, and orders are snapshotted for each decision date.

Catalog enrichment

• Supplier sources are authorized, and agreements permit reuse in the catalog and in provider processing.
• Item identity and pack level are confirmed, including GTIN changes when case quantity changes.
• Safety and compliance attributes have designated source documents and owners.
• Imports are staged, batches sampled before bulk publication, and rollback tested.

Resolve a gap

Permission statuses are approved, restricted, unknown, or not applicable. Verification statuses are not checked, verified, missing, or not applicable. A verified document can still be restricted. Both fields must be assessed before reuse; the template does not calculate an automatic release approval.

Return to the pilot kit and evaluation scorecard.