Guide 11 min read

Procedure version control for plant AI

How plant teams keep AI-assisted SOP answers tied to approved procedures, scope, obsolete versions, and human verification.

By WizeeMind Team Published on June 21, 2026 Updated on June 29, 2026

Plant team checking approved procedure revisions before using an AI assistant

The wrong procedure usually looks reasonable until someone asks who approved it.

A night-shift operator searches a shared drive for a restart instruction. The first file has the newest revision number, a clean title, and the exact equipment name. The second file lives in the quality document system, carries an older revision number, and shows an effective date for the current line. Production is waiting. Maintenance wants to clear the job. Quality wants traceability. The assistant has both files in front of it.

This is where plant AI earns trust or loses it. A fluent answer that picks the newest file can turn a draft, training copy, or future revision into an operational instruction. Procedure version control is not filing hygiene. It is the boundary between useful retrieval and unauthorized advice. WizeeMind should assemble evidence, expose approval status, show scope, and stop before it turns document text into permission. The accountable person still makes the plant decision.

The newest file can be the wrong instruction

Recency is useful evidence. It is not authority.

A later timestamp may mean the file was exported last night. A higher revision number may mean the procedure is waiting for final approval. A title match may mean the document came from the right equipment family, not the right plant, asset, product, or operating condition. In regulated manufacturing, even small differences matter. The eCFR requirement for production and process control points to written procedures that are drafted, reviewed, and approved by the quality control unit (21 CFR 211.100). That language is specific to drug manufacturing, but the control logic travels well: the instruction used for work has to be the instruction approved for that work.

The FDA data integrity guidance makes the same point from the record side. It frames reliable records around completeness, accuracy, authorized change, and review for accuracy and completeness (FDA data integrity guidance). A document that lacks visible approval status, effective date, or change history cannot carry the same weight as a controlled procedure from the system of record.

For WizeeMind, the first answer should not be a step list. It should be a document status check. The assistant should ask which source is the system of record, whether the revision is approved and effective, whether a future effective date exists, and whether the procedure scope matches the site, line, asset, product, and operating mode. If those fields are missing, the assistant can summarize uncertainty. It should not convert uncertainty into an instruction.

Consider a filler restart after a short stop. Revision 7 in an engineering folder describes the new valve sequence after a controls change. Revision 6 in the document system is approved and effective, but it does not include that new sequence. The right answer is uncomfortable: Revision 7 may be relevant engineering context, yet Revision 6 remains the controlling instruction until the controlled process says otherwise. That discomfort is the product doing its job.

Authority has to travel with the procedure

A procedure answer needs more than the paragraph that matched the question. It needs the authority around that paragraph.

Plants store instructions across quality systems, maintenance systems, MES screens, engineering packages, training decks, vendor manuals, and shared folders. Those sources can all help explain a situation. They do not have equal decision weight. ISO 9001 uses the concept of documented information as part of a managed quality system (ISO 9001:2015). ISA-95 describes the integration boundary between enterprise systems and manufacturing control activity (ISA-95). Put those together and a practical rule appears: plant AI must preserve the source layer, not flatten it.

Flattening is the quiet failure mode. A vendor manual may explain a fault code. A maintenance note may describe what happened yesterday. A training deck may paraphrase an SOP. A quality procedure may govern what the operator is allowed to do. If an assistant merges those into one answer without source status, the user sees confidence where the evidence is mixed.

WizeeMind should carry authority metadata beside every procedure citation:

controlled identifier and title,
revision and effective date,
approval status and owner,
document system or repository,
scope text and exclusions,
related procedures,
obsolete or superseded versions found,
and conflicts with other retrieved records.

This is also where AI governance becomes concrete. NIST AI RMF 1.0 says organizations using AI need practical ways to manage risks and promote trustworthy use across the AI lifecycle (NIST AI RMF). The GovInfo AI RMF record supports the same reading: trustworthy AI depends on valid, reliable, accountable, transparent, and context-aware risk management rather than fluent output alone (GovInfo AI RMF record). In plant procedure work, that means authority metadata is not decoration. It is part of the answer.

The working principle is plain: retrieve broadly, authorize narrowly.

That principle should also shape the screen. The answer should not bury status in footnotes after the generated text. Put the source class, revision, and effective status above the summary, because those fields decide how the summary may be used. If the controlling source is not approved, the user should see that before reading any operational step.

Build a packet before generating the answer

A procedure-supported answer should arrive as a small packet before it becomes prose.

The packet does not need to look impressive. It needs to be reviewable by the person who owns the risk. A supervisor, maintenance lead, process engineer, or quality reviewer should be able to see what the assistant found, what it treated as controlling, what it treated as context, and where the answer stops. NIST’s concept note for trustworthy AI in critical infrastructure focuses on AI used across IT, OT, industrial control systems, and operational settings where trustworthiness has to be communicated to operators, developers, and stakeholders (NIST critical infrastructure concept note). A visible packet is one way to make that communication real.

The packet should include the question, affected site, line, asset, product, batch or work order, controlled document identifier, revision, approval status, effective date, exact section used, related procedure references, and any missing evidence. It should also state what the assistant is not deciding. That last field matters. The FDA guidance treats record review and reliability as quality-system controls, not afterthoughts (FDA data integrity guidance). A packet with blank fields makes weakness visible before a human acts.

A restart question might produce this:

Question:
Can Line 2 restart after clearing an infeed jam?

Controlling document:
SOP-PKG-014, Line 2 filler restart after short stop

Revision:
Rev. 5, approved and effective

Section used:
4.2 restart verification

Scope:
Normal production mode, short infeed jam, no guard removal

Context found:
Alarm cleared at 09:42
No maintenance work order opened

Limits:
Procedure excludes restart after mechanical intervention, guard bypass, repeated jam pattern, or quality hold

Human verification:
Operator and supervisor confirm scope conditions before restart
Quality reviews if product-contact or hold criteria apply

That packet is stronger than a confident paragraph because it can be challenged. The operator can say the guard was opened. The supervisor can notice the procedure excludes repeated jams. Quality can ask for the batch status. The assistant has not removed human judgment; it has given that judgment a better surface.

The same packet can carry weak evidence without promoting it. A vendor manual can sit under “supporting context.” A shift note can sit under “recent observations.” An obsolete checklist can sit under “risk signal.” The controlled procedure remains the only controlling instruction unless the plant’s own governance changes that status. This is the difference between helpful context and accidental authorization.

Obsolete versions should stay visible

Obsolete documents should not vanish from the assistant view. They should be marked, separated, and treated as risk signals.

An obsolete SOP may explain why the team is confused. It may show that a training slide still points to the wrong section. It may reveal that a maintenance checklist, shift note, or old work instruction is still circulating. Hiding obsolete versions can make the immediate answer cleaner, but it also hides the pathway that led people toward the wrong instruction. The eCFR procedure requirement gives approval and review a formal role in controlled manufacturing (21 CFR 211.100). ISO 9001 gives organizations a broader quality-management frame for documented information and control (ISO 9001:2015).

The assistant should show obsolete material with a hard label:

Document found:
SOP-CIP-022 Rev. 3

Status:
Obsolete. Superseded by Rev. 4.

Use in answer:
Not used as the controlling instruction.

Why shown:
The search result opened this file first. Rev. 3 differs from Rev. 4 in final rinse verification.

That format does two useful things. First, it prevents the obsolete revision from silently controlling the answer. Second, it gives document control, training, and supervisors a trail to clean up. If operators keep opening Rev. 3, the problem is not only the question asked today. The plant may have an old folder shortcut, outdated training material, or a copied checklist in circulation.

ISA-95 is relevant because procedure authority often crosses systems (ISA-95). The approved procedure may sit in quality document control. The execution prompt may appear in MES. The maintenance record may use an old asset alias. The engineering change package may explain why the revision changed. WizeeMind should help connect those records without pretending they are the same source.

The practical test is simple: can a reviewer tell which document controlled the answer, which documents were only context, and which obsolete records created risk? If not, the assistant is still acting like search with a nicer voice.

The clean-up work that follows should stay inside normal document-control channels. WizeeMind can flag repeated obsolete access, list conflicting folders, and show where old procedure numbers still appear. It should not retire the file, rewrite the SOP, or decide that a training deck is approved evidence. Those actions need the people and records the plant already uses for controlled change.

Human verification is part of the control

The strongest procedure answer is often the one that refuses to finish the decision.

That refusal should be specific. “Ask a human” is too vague to help during a production stop. The assistant should name the missing condition, the role that owns it, and the reason the procedure cannot support the requested action yet. NIST AI RMF 1.0 ties trustworthy AI to valid and reliable behavior, accountability, transparency, and human oversight in context (NIST AI RMF). The critical-infrastructure concept note sharpens that for operational environments where AI touches IT, OT, and industrial control settings (NIST critical infrastructure concept note).

In procedure work, the stop conditions are usually concrete:

the retrieved procedure is approved, but its scope excludes the current operating mode,
the newest revision is draft and the approved revision lacks the requested step,
the procedure applies to Line 1 while the question references Line 2,
the assistant found a vendor manual but no approved site procedure,
the batch is on hold and quality disposition is required,
or the step requires a qualified role to verify isolation, clearance, or release.

WizeeMind should convert those conditions into a controlled handoff:

Evidence found:
Approved SOP section for normal restart.

Evidence missing:
No confirmation that the jam cleared without guard removal.
No quality record confirming the batch is free of hold.
No maintenance sign-off for repeated jam condition.

Boundary:
I can summarize the approved normal restart checks.
I cannot support a restart decision until the responsible roles verify the missing conditions.

That is not timid. It is operationally useful. The next human action becomes clear, and the assistant avoids the oldest automation trap: making a weak source sound stronger because the wording is tidy.

The same pattern applies outside regulated drug manufacturing. Written procedure approval, record reliability, and source status still matter for food, packaging, chemicals, energy, water, and discrete manufacturing. The regulatory source may change, but the plant question remains: what evidence proves this instruction governs this condition?

This is where the assistant should be blunt. If a lockout condition, permit status, sanitation release, quality hold, or engineering change is unknown, the answer is not ready. The right output is a short summary of the approved section plus the exact checks that must happen next. That saves time without pretending that missing evidence is harmless.

Start with one narrow rollout

Procedure version control should begin with a narrow workflow, not a grand document search project.

Pick one operational question where the cost of a wrong version is visible: restart after a jam, cleaning verification, maintenance return to service, batch hold response, alarm response, or changeover release. Map the documents that can appear in the answer. Identify the controlled procedure system, the supporting systems, the common obsolete copies, and the roles that approve or verify. Then force every assistant answer to carry the packet.

The first rollout should measure boring things. How often did the assistant find multiple revisions? How often was the newest file not the approved one? Which folder produced obsolete copies? Which procedure lacked clear scope? Which answers stopped because a hold, permit, lockout, engineering change, or abnormal condition changed the path? Those measures fit the NIST AI RMF idea that risk management has to work inside the context where AI is used (NIST AI RMF). They also fit the FDA record reliability theme: complete, accurate, reviewable evidence beats fast unsupported answers (FDA data integrity guidance).

For WizeeMind, a good first release would do five things well. It would identify the controlling procedure, show approval and effective status, cite the exact section, surface obsolete or draft versions, and state the human verification boundary. That is enough to change the quality of the conversation on the floor.

Do not start by promising autonomous procedure execution. Start by making it harder for a plant team to act on the wrong version. That is the useful milestone.

Once the packet is trusted, expand carefully. Add more procedure families. Connect engineering change references. Add training material as context but not authority. Bring in maintenance records and MES prompts where they help scope the question. Keep the same rule: WizeeMind can gather, compare, and explain evidence. It cannot approve a restart, release a batch, bypass a safety step, retire a procedure, or decide that a local controlled instruction no longer applies.

The first win is modest and valuable: every procedure-supported answer points to the approved version, the exact scope, the section used, the conflicting or obsolete records found, and the reason the assistant stopped. That is how plant AI becomes useful in controlled work.