Procedure map for process owner approval

Create a source register for the current-state procedure called [procedure name]. The process owner is [name and role].

Review these source materials:
- Staff notes: [paste notes]
- Screen captures or screen-recording descriptions: [paste descriptions, including filename or image number]
- Staff explanations: [paste interview notes or transcripts]
- Existing procedure or policy, if any: [paste document]

Return a document titled `Source register: [procedure name]` with these sections:

1. `Scope stated in the evidence`
   - Process trigger
   - Process end point
   - Teams, systems and suppliers mentioned
   - Explicit exclusions

2. `Source register` as a table with these columns: Source ID, source type, date or version if stated, contributor, process area covered, reliability concern, and key evidence.

3. `Evidence gaps` as a table with these columns: Gap ID, missing fact, why it matters to the procedure, source that may answer it, and priority (blocking, important, useful).

4. `Terms needing confirmation` as a table with these columns: Term used, possible meanings from the evidence, where it appears, and question for the process owner.

Do not create process steps yet. Do not treat an old procedure as proof that the process still operates that way. Give every source a unique ID such as `S01`. If two sources conflict, record both views and identify the conflict. If a screen capture does not show a field, button or outcome clearly, write `not visible in evidence` rather than guessing.

Draft the current-state procedure map for [procedure name], using only the evidence below. The intended approver is [process owner name and role].

Source register:
[paste source register]

Source materials:
[paste notes, screen-capture descriptions, staff explanations and existing documents]

Return a document titled `Current-state procedure map: [procedure name]` in this exact structure:

1. `Document control`
   - Process owner
   - Draft date
   - Process trigger
   - Process end point
   - In scope
   - Out of scope
   - Systems and records used
   - Source IDs used

2. `Procedure map` as a numbered table. Use one row for each action, decision, hand-off or control. Include these columns: Step, activity, owner role, input or trigger, action and system used, output or record created, hand-off to, control or check, evidence source, and status.

Use only these status values: `confirmed`, `conflicting evidence`, `assumption to confirm`, `evidence missing`.

3. `Known gaps and risks` as a table with these columns: Gap ID, affected step, issue, operational effect, evidence source, and question requiring an answer.

4. `Approval questions` as a numbered list. Ask only questions that block approval or materially change ownership, sequence, controls, records or scope.

Map the process as it is described, not as it should work. Keep exact field names, queue names, report names and approval names where evidence supplies them. If timing, ownership, decision rules or system actions are unclear, mark the relevant row `assumption to confirm` or `evidence missing`. Do not fill gaps with standard practice.

Review the draft document `Current-state procedure map: [procedure name]` below for hand-offs, controls and exceptions.

Draft procedure map:
[paste procedure map]

Additional staff evidence, if available:
[paste additional notes]

Return an addendum titled `Control and hand-off review: [procedure name]` with these sections:

1. `Hand-off register` as a table with these columns: Hand-off ID, sending role, receiving role, item or information transferred, transfer method, evidence of receipt, delay or failure point, source ID, and confirmation needed.

2. `Control register` as a table with these columns: Control ID, procedure step, control objective, control activity, owner role, evidence retained, frequency if stated, failure consequence, source ID, and status.

3. `Exceptions and rework` as a table with these columns: Exception ID, trigger, decision owner, action taken, record updated, route back into the procedure, source ID, and missing detail.

4. `Changes needed to the procedure map` as a numbered list. For every change, name the affected step number and provide replacement wording.

Do not call something a control merely because a person performs a task. A control must be a check, approval, restriction, reconciliation, record or other activity that reduces a stated risk. If the evidence does not identify the purpose or owner of a check, retain the activity but mark its objective or owner as unconfirmed.

Prepare a validation interview guide for the document `Current-state procedure map: [procedure name]`.

Procedure map and gap register:
[paste current draft]

People available to answer questions:
[paste names, roles and teams]

Return a document titled `Validation questions: [procedure name]` with these sections:

1. `Questions by person or role` as a table with these columns: Question ID, person or role, exact question, procedure step or gap ID, why the answer matters, evidence already available, and answer format required.

2. `Walk-through script` as a numbered sequence that asks the staff member to demonstrate one real recent case from trigger to completion. Include prompts to identify the input, system record, decision, hand-off, check, exception and final record at each stage.

3. `Conflict questions` as a table with these columns: Conflict ID, statement A and source ID, statement B and source ID, question to resolve the difference, and process owner decision needed.

4. `Update rules` as bullet points stating exactly how an answer should change the procedure map, source register or control register.

Prioritise questions that affect scope, step order, ownership, approvals, customer or supplier communication, records, controls and exception handling. Ask one fact at a time. Do not ask broad questions such as `Can you explain the process?`. Where a named person is unavailable, direct the question to their role and mark it as pending.

Prepare the approval version of `Current-state procedure map: [procedure name]` for [process owner name and role].

Current draft:
[paste validated procedure map]

Validated answers and decisions:
[paste interview answers, owner decisions and corrected evidence]

Return a document titled `Approval version: [procedure name]` in this exact structure:

1. `Approval summary`
   - Process owner
   - Purpose of approval
   - Process trigger and end point
   - What changed during validation
   - Outstanding items that do not block approval

2. `Current-state procedure map` as a numbered table with these columns: Step, activity, owner role, input or trigger, action and system used, output or record created, hand-off to, control or check, and evidence source.

3. `Known gaps accepted for follow-up` as a table with these columns: Gap ID, description, affected step, interim operating approach if evidenced, accountable role, and review point if stated.

4. `Approval decision` with these three options, each followed by a blank line: `Approved as current state`; `Approved subject to stated follow-up`; `Not approved, changes required`.

5. `Owner comments and sign-off` with fields for process owner name, role, decision, comments, and approval date.

Remove resolved assumptions from the final map. Retain unresolved material only in `Known gaps accepted for follow-up`, not disguised as a confirmed step. Do not invent dates, review points, accountable people or interim controls. If a blocking question remains unanswered, state `Not ready for approval` at the start and list the blocking question.