Review an AI-Written Procedure Against Approved Source Instructions

An AI-written procedure can look complete while changing the work it is supposed to describe. A model may omit an approval, invent a shortcut, move a decision earlier or turn a conditional step into a universal instruction. Readability is useful, but it does not establish that the draft faithfully represents the approved process. Review the proposed instructions against the actual source before treating them as operational guidance.

This guide explains a source-to-step comparison for a low-risk fictional internal request process. It does not report an observed model result, certify a procedure or authorize changes to a real workflow. The invented source and proposed draft make specific differences visible so a reviewer can practice identifying them. Actual procedures need the organization's appropriate process owners and any specialist review their consequences require.

The output is a comparison that says what the source requires, what the draft says and what disposition the responsible reviewer recommends. It is different from asking an AI to write a more polished SOP or scoring whether a paragraph sounds professional. The important question is whether the proposed instructions preserve the approved actions, conditions, responsibilities and limits.

Establish the authoritative source set

Identify the approved materials that define the work. These might include a current process document, a controlled form or other authorized instructions. Do not assume that every file in a shared folder has the same status. A draft, a superseded version and an informal explanation may all be useful context without being authority for the procedure being reviewed.

Record the versions and scope of the source set. If the source applies only to a particular request type, preserve that boundary. An AI draft should not broaden it to every customer or every department merely because a general title is easier to write. If source ownership is unclear, ask the responsible team rather than letting the model choose the document that produces the cleanest narrative.

Keep access and disclosure permissions in view. A reviewer may be authorized to consult an internal source without being permitted to paste it into every AI product or publish it in a public procedure. Use the approved environment and minimum necessary information. The fictional source in this guide contains no customer or employee data and does not describe an actual Elixir operating policy.

Separate rewriting from process redesign

Clarify whether the assignment is to restate approved instructions or propose a change. Those are different jobs. A readability rewrite should not silently introduce new authority, remove a required control or alter who performs the work. If the team wants to redesign the process, establish that scope and approval path separately rather than hiding changes inside an editorial draft.

Give the model and reviewers a bounded task description. For example, ask for a draft that uses only supplied approved instructions, preserves conditions and marks missing information. That request can reduce ambiguity but does not guarantee faithful output. NIST's Generative AI Profile discusses confabulation and other risks of generated material; it does not validate a prompt or this comparison method.

Keep proposed improvements in a clearly labeled section outside the restatement. An idea may be worth discussing without belonging in the current procedure. Review it through the actual change process before implementation. Mixing approved instructions with unapproved suggestions can leave a reader unable to tell which actions are required, optional or merely proposed.

Define the unit of comparison

Break the source into meaningful instructions or requirements. A unit may include an action, its responsible role and the condition that triggers it. Avoid splitting the wording so aggressively that an approval condition becomes detached from the action it limits. Conversely, a long paragraph containing several actions may need more than one row to make omissions visible.

Assign identifiers to the source requirements and the proposed draft steps. A one-to-one relationship is convenient but not always appropriate. One source requirement may appear in several draft steps, or a draft step may summarize several related requirements. Preserve the mapping rather than assuming equal step counts prove fidelity. Two documents can each contain four steps while describing different work.

Keep the source wording or an authorized precise reference available for the review. A summary of the source can itself introduce an error. The comparison should allow another authorized person to inspect what the source actually requires, not merely trust that the reviewer remembered it accurately. This is especially important for qualifications such as only, unless and before.

Read the fictional approved process

The fictional source contains four requirements. First, log the internal request with its supplied reference. Second, check whether the request includes the required information. Third, obtain the designated reviewer's approval before marking a complete request ready for the next stage. Fourth, return an incomplete request for clarification rather than marking it ready. These are invented teaching instructions for a limited administrative task.

The proposed fictional draft also has four steps: record the request, check the information, mark complete requests ready automatically and send a general confirmation. The matching count can make the draft look orderly, but it does not establish fidelity. The approval requirement has been changed, the incomplete-request branch is missing and the confirmation step has no supplied authority in this source set.

The worksheet maps the two aligned actions, the altered approval action, the omitted branch and the added confirmation. No actual model produced the draft as part of a measured evaluation. It is a hand-authored example of differences a reviewer should be able to discuss. Its labels are teaching judgments under the stated fictional source, not a quality score for a deployed system.

Check responsibilities as well as verbs

A procedure can preserve an action while assigning it to the wrong role. “Approve the request” is incomplete if the source specifies a designated reviewer and the draft implies that the sender may approve it. Compare who performs, reviews and authorizes each relevant action. Do not infer delegated authority from a polished imperative sentence.

Keep named individuals and organizational roles distinct. A source may refer to a role that continues when staffing changes, while a draft may insert a person's name from an old example. Verify the intended responsibility through the actual process owner. Do not manufacture a permanent role assignment from an incidental mention in meeting notes or a copied template.

Where the source does not identify a responsible role, flag the gap. The model should not fill it with a plausible manager title and present that as approved. A procedure may need clarification before it can be used. Recording the missing responsibility is more useful than supplying confident instructions that no one is authorized or prepared to carry out.

Preserve sequence when order matters

Compare the order of actions where the source establishes a dependency. In the fictional process, approval must precede marking a request ready. Moving approval to a later review changes the process even if both words appear somewhere in the document. A keyword search can miss this difference, so read the relationship between the steps.

Some source actions may be independent or allow more than one order. Do not invent a rigid sequence where the source does not require one. Ask the responsible owner if the intended relationship is unclear. The review should preserve approved flexibility as carefully as it preserves approved constraints. More detailed instructions are not automatically more accurate instructions.

If a draft adds an automatic action, determine whether the source actually authorizes automation and under what conditions. A procedure that says notify a reviewer does not necessarily authorize a system to make the review decision. Keep drafting, routing, execution and approval distinct. The guide does not deploy a workflow, connect tools or change anyone's permissions.

Compare conditions and exception branches

Read every if, unless, only and otherwise statement with attention. A draft can describe the normal path accurately while omitting the exception that protects the process from an incomplete or unusual request. In the fictional example, returning incomplete requests for clarification is part of the supplied process, not an optional courtesy that can be removed for brevity.

Ask what a reader should do when the stated condition is not met. If the source supplies a branch, preserve it. If it does not, mark the missing guidance and seek clarification. Do not let an AI invent a fallback that appears reasonable but changes how work is handled. An undefined exception should remain an unresolved process question until the appropriate owner addresses it.

Test the explanation with a small fictional case for each relevant branch. One complete request and one incomplete request can reveal whether the document tells a coherent story. That exercise does not establish operational safety or full coverage of real cases. It helps locate ambiguities for review without using actual customer work as an unauthorized experiment.

Identify additions without assuming they are improvements

A generated draft may add a checklist, a confirmation message or a reporting requirement. Some additions may be sensible proposals, but the source comparison should still identify them as additions. Do not mark an unsupported step accepted simply because it sounds helpful. It may create workload, disclose information, imply a commitment or conflict with another approved process.

For the fictional confirmation step, ask what is to be confirmed, by whom, to whom and under what authority. The approved source supplied no such instruction. The correct comparison result is that the addition needs a separate decision. It is not evidence that confirmations are inherently wrong or that the actual organization should never send one.

Separate editorial aids from behavioral changes. A heading that helps a reader navigate may not change the work, while a new required field or automatic communication does. Explain the distinction rather than treating every textual addition as equally consequential. The relevant question is how the proposed wording changes what a reader or system would do.

Check removals and simplifications

A shorter procedure can be easier to use, but it can also remove material instructions. Compare the source requirement inventory with the proposed draft and account for every relevant requirement. Do not rely only on reviewing the draft from top to bottom, because omitted material is often difficult to notice when the remaining prose flows smoothly.

A requirement may be preserved through a clear reference to another approved document if the actual process allows that structure. Verify the reference and the reader's appropriate access. Do not assume that saying follow policy is enough when the relevant policy is unnamed, unavailable or inconsistent. A cross-reference should help the user find the actual instruction, not conceal missing guidance.

Keep simplification decisions traceable. If the process owner decides a detail belongs in a separate job aid, record that disposition and verify the resulting user path. An editorial reviewer should not independently delete a requirement because it feels repetitive. Readability and fidelity need to be addressed together through the actual approval process.

Distinguish ambiguity from a confirmed mismatch

An unclear draft step may have more than one plausible interpretation. Identify the ambiguity rather than choosing the interpretation that makes the comparison pass. Ask whether the intended reader could reasonably act differently under the wording. A procedure should not require private knowledge of the author's intention to preserve an important approval or exception.

A confirmed mismatch has clearer evidence: the source requires approval first, while the draft explicitly says to proceed automatically. An ambiguous phrase may need revision even when the author says it was meant to preserve the rule. Keep those categories separate so the team can understand whether the issue is missing clarity, contradictory instruction or an unresolved source question.

Do not use a general quality score to hide the distinction. A high average can coexist with one material control failure. The comparison should make consequential differences visible in their own terms. This guide does not prescribe a universal acceptance threshold or suggest that a certain percentage of aligned steps makes a procedure safe or approved.

Keep source changes separate from draft corrections

If the source itself is outdated or inconsistent, the answer is not to edit the AI draft until it looks more sensible. Raise the source issue through its owner and approval process. A faithful restatement of an unsuitable source may still be unsuitable for use, while a useful-looking draft that departs from the source may still be unauthorized.

Record whether an issue requires source clarification, draft correction or a proposed process change. These paths can involve different people and evidence. Combining them under a vague instruction to fix the SOP makes it harder to know what has actually been approved. Preserve the distinction until the responsible decisions are made.

When a revised source becomes authoritative, rerun the relevant comparisons against that version. Do not assume every earlier judgment carries over. A source update can change applicability, responsibilities or exceptions. Keep the final procedure linked to the actual approved source version and identify what review was completed before it was released.

Review the corrected draft again

A correction can resolve one mismatch while introducing another. After replacing automatic readiness with the approval requirement, check the surrounding sequence and the incomplete-request branch. Do not stop at confirming that the word approval appears. Read what a user following the revised steps would actually do under the supplied conditions.

Use the same defined comparison units and labels where appropriate so revisions can be understood. Mark issues resolved only when the revised wording and evidence support that status. A comment saying fixed is not the same as a reviewed correction. Keep unresolved questions visible rather than deleting their rows to make the issue list shorter.

If AI assists with the correction, keep its output as another draft to review. Do not assume the system has learned the rule permanently because one revision looks better. The review applies to the specific output and source set. A later generated procedure may need its own checks, especially when the task, source or model configuration changes.

Plan release and use separately from comparison

A completed source-to-step review is an input to release, not automatic publication authority. Follow the organization's process for approving, distributing and maintaining operational instructions. Identify who owns the procedure and how users find its current version. Avoid leaving an unapproved draft in a location where it can be mistaken for the active instruction.

If a limited rehearsal or trial is appropriate, define its scope and permissions separately. Do not test consequential instructions on real work merely because a table labels them aligned. The Built to Run process-trial guide addresses a bounded learning exercise, but neither guide authorizes an actual operational change. The people responsible for the work must decide the appropriate method.

Keep the released version and its approval evidence traceable through the actual system. When the process changes, update the relevant user-facing instructions and retire superseded drafts appropriately. A beautifully formatted procedure is useful only if people can distinguish it from old or provisional material and know where to raise a question.

Make an implementation discussion concrete

If repeated mismatches occur, bring examples of the source, prompt, proposed steps and review findings to the responsible team. Ask whether the problem involves source quality, task scope, generation behavior or unclear authority. A general request for better AI procedures is harder to diagnose than a specific example of a missing approval branch.

Choose help according to the unresolved work. The organization may be able to correct a template internally, or it may need process and implementation support. Elixir's service pages describe potential scope, not proof that a particular engagement is appropriate or that the fictional method produces results. Confirm actual deliverables and responsibilities through the normal commercial process.

The useful conclusion is bounded: these proposed steps were compared with these approved requirements, these differences were identified and these dispositions were authorized. That is more accountable than calling the document AI-verified. The goal is understandable instructions that preserve the actual process, with explicit ownership for changes and unresolved questions.

Frequently asked questions

Does a clear AI-written SOP faithfully represent the process?

Clarity alone does not establish fidelity. Compare actions, roles, conditions, sequence and exceptions with the approved source set. A polished draft can omit an approval or introduce an unauthorized step. Keep the specific output under review until the appropriate people have addressed its differences and completed the actual release process.

Do equal numbers of source and draft steps prove alignment?

No. The fictional source and draft each have four steps, but the draft changes approval, omits the incomplete-request branch and adds a confirmation. Step count is a structural observation, not a semantic comparison. Map the actual requirements and explain how the draft preserves or changes each relevant part.

Can I accept a helpful addition that is not in the source?

Treat it as a proposal requiring the appropriate decision. A useful-sounding step may create new workload, communications or authority. Distinguish editorial aids from changes to behavior and obtain process-owner review where needed. The source-comparison task should identify the addition rather than silently promote it into an approved instruction.

What if the approved source is itself unclear?

Record the ambiguity and ask the responsible source owner to clarify it through the actual process. Do not let the model invent a role, exception or fallback and present it as approved. A source may need revision before a usable procedure can be released. Faithful wording and source suitability are separate questions.

Can AI perform the comparison automatically?

It can suggest differences, but those suggestions can be unreliable and need evaluation appropriate to the workflow. This guide supplies no validated automated verifier or acceptance threshold. Keep generated judgments distinct from accountable decisions, use authorized sources and preserve specialist review where the consequences of an error require it.

Does a completed comparison authorize rollout?

No. It documents a review against a stated source set. Approval, distribution, training, access and maintenance remain part of the organization's actual release process. A limited rehearsal also needs appropriate scope and permission. Do not treat a worksheet status or an AI-generated summary as authority to change operational work.