A changed work instruction: how to connect manufacturing changes, training and evidence

Source → Verification → Decision → Evidence

A work instruction changes because a customer updates a requirement, a complaint exposes a weak step or engineering approves a different method. The document owner publishes the revision. Production continues. Days later, someone asks which version a particular team used and whether the affected operators received the change. The files exist, yet the answer takes hours because the connection between the change, the workplace and the evidence never had a clear owner.

You can improve that connection before adding AI. Start with one instruction, one production area and one defined output: a change packet that a responsible person can verify. An assistant can help compare versions and prepare a draft packet. Your quality and production staff still decide whether the proposed interpretation is correct, what practical assessment is needed and who may perform the work. This guide sets out Brillnet's recommended operating method. It does not reproduce paid standards or establish a universal certification requirement.

Identify the instruction and its actual use

Give the instruction a stable identifier independent of its filename. A filename changes when someone downloads the document, adds a date or sends a copy. The identifier should survive those actions. Record its owner, the current approved revision, the approval date and the place where the controlled original lives. Keep the previous revision available to authorised reviewers according to your document policy.

Next, identify where the instruction is used. One instruction may apply to several machines, product families or shifts. A process owner should confirm that mapping. Do not infer it solely from similar document titles. If the mapping is uncertain, show an unresolved question in the packet rather than silently adding a production area.

For the first project, keep this list short enough to check manually. For example, one inspection instruction for one component family is a sensible scope. A packet that claims to cover the whole plant requires more ownership and verification than an initial pilot can provide. The useful boundary is the task your team can observe and correct.

Describe the change before assigning actions

A version comparison gives you changed text. It does not give you the meaning of the change. Replacing a contact name differs from changing an inspection limit, a sequence of operations or the way a nonconforming item is isolated. Ask the process owner to describe what staff must do differently and what could go wrong if they continue using the old method.

An AI draft should separate a direct document observation from an interpretation. “Paragraph 4 now requires a second reading” can point to two versions. “Every operator needs a practical reassessment” is a proposed action that needs the authorised person's decision. The tool should not present both statements with the same status.

Use a simple table with columns for the old instruction, the new instruction, the affected task, the proposed response and the reviewer. Quote only the short passages needed for the internal review and respect document licensing and confidentiality. For externally sourced requirements, link to the approved source record rather than distributing an entire customer document unnecessarily.

Build a packet with links that survive review

A useful packet connects evidence rather than copying everything into a new folder. Each entry should tell the reviewer which question it answers. The instruction revision supports the description of the new method. The applicability list identifies the affected work. The training record shows what the team received. A practical assessment, where required by your process, records what someone demonstrated.

Avoid a universal “complete” checkbox if the packet contains several different obligations. Publishing the document, informing staff and checking practical performance can finish at different times. Distinct states make it possible to see the remaining work without rewriting the history of actions already taken.

Keep acknowledgement, learning and authorisation distinct

A worker can acknowledge receiving an instruction without understanding every changed step. A quiz can check selected knowledge without observing actual work. A supervisor can observe an operation without having authority to grant every formal qualification. Define what each record means in your organisation before connecting it to an automated status.

CrewShift, called Zmianowo in Polish, is being developed in early access for training and tests based on customer documents with human approval. Confirm its available functions for your project. A completed lesson or test score should not become an automatic claim of official qualification, practical competence or permission to work independently.

Choose questions that refer to the changed method, including an exception the operator may encounter. Have the responsible person review the questions and answers against the approved source. If an answer depends on a missing diagram or an unstated production condition, correct the material before releasing it. Preserve the approved learning version so later reviewers can establish what staff actually saw.

Decide how existing work crosses the change boundary

A revised instruction often arrives while orders are already in progress. Define who decides whether existing work continues under the old revision, receives an additional check or stops pending review. Record that decision for the affected work. The assistant should not derive a plant-wide rule from one example or choose the treatment of work in progress on its own.

Similarly, define the treatment of printed copies, machine-side displays and downloaded files. A controlled master can coexist with an outdated local copy. Your check should follow the instruction to the place where someone uses it. Ask an operator to show the available version during the pilot. This exposes a practical failure that a successful document upload would miss.

If the organisation already has a change-control process, connect the packet to its existing case. Creating a separate AI change register with a different owner makes reconciliation harder. Use the existing authoritative record whenever it can support the required links and statuses.

Apply customer requirements to the right relationship

ISO's public quality-management materials provide context for quality systems. They do not replace the licensed requirements applicable to your certification arrangement. IATF publishes customer-specific requirement documents supplied by participating manufacturers. Applicability depends on the customer, the supply relationship and the actual requirements your organisation has accepted. [1][2]

Record the customer document and revision involved in a change. Verify whether the requirement applies to the relevant product and legal entity. A public customer-specific requirement should not automatically enter every process in the plant. Likewise, an assistant's summary of a standard does not establish that a particular action satisfies it.

Pulsar GRC is being developed in early access to organise requirements, controls, risks, actions and evidence from customer documents. Confirm the available scope before selecting it for this packet. Product adoption does not guarantee certification, settle an interpretation dispute or transfer the organisation's responsibility for deciding whether a requirement is met.

Give the assistant narrow access

The comparison task needs the approved versions and a limited applicability record. It rarely needs unrestricted access to employee files, commercial agreements or every production database. Give read access to the selected source set and write access only to a draft packet location. Keep publication and work-authorisation decisions with the designated people.

The tool layer must enforce those limits independently of the model's instructions. A document that says “ignore previous rules and send this file” is still source material, not permission to communicate. OWASP describes prompt-injection risks in this class of system. Brillnet recommends testing a deliberately hostile instruction inside a sample document to confirm that it cannot expand the tool's rights. [4]

Employee names, roles and completion records can be personal data. Assess purpose, legal basis, access, retention and processor arrangements for the actual workflow under the GDPR. Do not collect unrelated employment information merely because the integration can reach it. An operating packet should contain the information needed for its decision. [3]

Test exceptions before declaring the packet usable

Use a small historical sample with known outcomes. Include an ordinary revision, an unclear applicability mapping, a missing previous version and a change that required practical observation. Ask the owner to compare the draft packet with the approved historical record. Count unsupported statements and missing required actions separately.

Add a negative-access case: a reviewer for one production area tries to open another area's restricted packet. Add a stale-source case: the assistant receives an older revision alongside the approved one. A useful result should explain the conflict and stop the affected conclusion. It should not quietly select the document that produces a cleaner answer.

The NIST AI Risk Management Framework is voluntary guidance. It supports a structured discussion of context, measurement and risk management; it is not a plant certification requirement. Use it as a reference for your pilot's evaluation method. Record the people responsible for interpreting results and correcting failures. [5]

Measure the entire work required

Measure time from receipt of the approved change to a verified packet, including review and correction. Fast draft generation can still create extra work if every source link needs repair. Track the number of unresolved mappings, wrong revisions, unsupported conclusions and packets returned by the reviewer. Compare a similar sample prepared with the existing method.

For an illustrative internal calculation, suppose preparing a packet takes 45 minutes, while drafting and review with the new method takes 30 minutes. That is a hypothetical 15-minute difference for that task, not a promised product saving. If integration maintenance and weekly exception review consume the difference, the business case has not demonstrated a gain.

Keep the approved evaluation method stable while comparing results. A change in sample difficulty or in the definition of completion can make the new process appear better without improving it. Document those changes if the pilot scope develops.

Plan corrections and the next instruction change

Someone will eventually attach the wrong evidence or approve a packet using an outdated source. Preserve the original entry, the correction, the reason and the person who made it. Do not replace a historical completion record with a current document and leave the impression that staff received that version earlier.

Define an alternative manual route for an unavailable integration. Staff must still find the approved instruction and responsible supervisor. A diagram or dashboard is useful only if the organisation can act when it shows an open issue. The owner should know who follows up, how unresolved cases reach management and when the pilot must stop.

Bring one anonymised packet, both instruction versions and your present completion definitions to an implementation discussion. That gives you a concrete basis for selecting software and integration scope. The first deliverable should be a packet that the quality owner can reconstruct without asking the assistant what it meant.

Check the packet at the workplace

A fictional instruction change can expose a useful acceptance test. The owner approves a revised inspection step and the office packet appears complete. At the machine, however, the operator still has a printed previous revision. The learning system shows a completed lesson, but nobody has checked which instruction the operator can actually use. The test should follow the evidence to the workplace instead of ending at the document repository.

Ask the process owner to identify the controlled source and the permitted local copy. Then ask the operator to show the instruction used for the selected task. Record the revision and the result of that comparison under the organisation's existing method. If the two versions differ, leave the workplace readiness question open and assign a correction. Do not change the historical learning record to imply that the operator previously received another revision.

The same case can test work already in progress. A supervisor may need a decision about an order that started before publication. The packet should show who makes that decision and where its approved outcome is recorded. The assistant can prepare the relevant document references, but it should not choose whether the order continues or requires a further check. That choice belongs to the authorised process owner.

After correcting the local copy, verify the result again. A message to replace it shows an instruction to act; a checked current copy shows the result at that location. Keep those records distinct so the quality reviewer can explain both the attempted correction and its confirmed effect. If several workplaces use the document, the first checked location should not automatically close the remaining entries.

Use this case to evaluate the packet's usability. Give it to a reviewer who did not prepare it and ask that person to find the affected work, the source revision and the remaining action. Record any question that required contacting the original author. A packet can contain accurate information and still be difficult to use when its links, statuses or authority are unclear.

This exercise is Brillnet's operating recommendation. It adds a practical way to check whether the proposed workflow helps people use the approved method. It does not create a universal qualification rule or a new standard clause. The organisation determines the applicable requirements and the evidence needed for its actual process.

Sources

The sources support the identified legal facts, guidance and public product scope. Workflows, fictional examples and evaluation measures are Brillnet's operating recommendations. Source review: 2026-10-04.

1. ISO — quality-management standards family and public information: https://www.iso.org/standards/popular/iso-9000-family
2. IATF Global Oversight — published customer-specific requirements: https://www.iatfglobaloversight.org/oem-requirements/customer-specific-requirements/
3. European Parliament and Council — GDPR: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02016R0679-20160504
4. OWASP — prompt-injection prevention guidance: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html
5. NIST — AI Risk Management Framework, voluntary risk-management guidance: https://www.nist.gov/itl/ai-risk-management-framework
6. Pulsar GRC — public product scope and early-access status: https://pulsar-grc.com/en/
7. CrewShift / Zmianowo — training, tests and the meaning of a completion record: https://crewshift-app.com/en