Procedure retrieval at task start

Operators lose minutes at the start of a task hunting for the right SOP, runbook, or checklist. That time stacks across shifts: wrong version opened, tribal knowledge remembered instead of documented steps, or a related procedure used because the exact one was hard to find.

Procedure retrieval at task start uses retrieval-augmented generation (RAG) to surface the relevant procedure as work begins. The system matches the task context (type, asset, site, severity, or ticket fields) to the SOP library and presents the best-fit document or section. The operator still reads, follows, and adapts the procedure. The AI does not execute steps or certify completion.

When task type is unknown or the SOP library is empty or unreachable, the system returns no procedure. Empty output is safer than a confident guess from the wrong document.

Retrieval starts from structured task signals available at start: task type or work order code, equipment or location identifiers, priority or incident class, and any free-text summary already on the ticket. Those signals become a query against an indexed corpus of procedures, runbooks, and checklists.

The index typically stores chunked sections (purpose, prerequisites, steps, rollback, escalation) with metadata such as site, asset class, version, and effective date. Ranking prefers exact metadata matches first, then semantic similarity on the task description. The response can be a full document link, a ranked shortlist, or the most relevant section excerpt with a pointer to the source of truth.

Human-in-the-loop stays explicit. RAG proposes which procedure applies; the operator confirms it fits the live situation, follows the steps, and records deviations. Downstream automation may later draft notes or run narrow sub-tasks, but retrieval itself only delivers the procedure package.

Useful retrieval depends on two inputs: a recognizable task type (or equivalent classifier) and a maintained SOP library. If either is missing, the correct behavior is empty output, not a fabricated procedure.

Return nothing when:

• Task type, work order category, or incident class is blank, ambiguous, or below the confidence threshold your ops model requires.
• The SOP library is not configured, failed to sync, or has no documents tagged for that task family.
• Metadata filters (site, asset, regulatory regime) exclude every candidate and no safe fallback policy exists.

Empty output should be visible to the operator as “no matching procedure,” with a clear path to manual search or escalation. That keeps lookup honest and avoids operators treating a weak match as authoritative.

Optional soft fallbacks (show nearest siblings, suggest similar task types) belong behind an explicit “related procedures” control, not as the primary answer when the match fails.

At task open, the operator receives a procedure card or panel: title, version, effective date, why it matched (task type, asset, keywords), and a link into the controlled document. If several candidates score closely, a short ranked list with match reasons is better than a single silent pick.

The operator’s job does not change in substance:

1. Confirm the surfaced procedure matches the job in front of them.
2. Follow prerequisites and safety steps before acting.
3. Adapt for local conditions the document cannot enumerate.
4. Log exceptions when practice diverges from the written procedure.

Retrieval cuts the search loop; it does not replace judgment. If the match is wrong, the operator discards it and searches manually or requests a library update. Feedback (accepted, rejected, wrong version) improves ranking over time when you capture it.

Corpus hygiene matters more than model cleverness. Prefer a single controlled source of truth per procedure, with version and retirement dates indexed. Stale or duplicate SOPs produce plausible but unsafe matches.

Chunk and label for how people work. Operators often need the start-of-task section (tools, PPE, lockout) before the full narrative. Exposing the right section with a path to the full document reduces scroll time without hiding context.

Keep provenance on every result: document ID, version, last reviewed date, and the query signals used. That supports audit and helps the operator spot a site-specific or superseded variant.

Separate retrieval from execution. Do not auto-advance steps, auto-close work orders, or imply compliance from “procedure shown.” Compliance remains a human (or separate controlled system) decision after the work is done.

Measure what you care about: time from task open to first procedure view, accept/reject rate, and incidents where the wrong SOP was followed. Avoid vanity metrics like “procedures retrieved” without acceptance data.

Procedure retrieval sits at the front of the execute stage. Once the right SOP is in hand, related patterns take over: drafting status updates or handoff notes from completed steps, and agentic help on narrow sub-tasks the procedure allows to automate under supervision.

Intake-time knowledge matching is the sibling pattern earlier in the flow: similar retrieval against knowledge bases when a request first lands. At task start the corpus is operational procedures, and the consumer is the person about to do the work.

Keep the contract consistent across these patterns. Match when inputs and library exist; return empty when they do not; leave final action and adaptation with the operator.