Map the work before you automate it.

Agree what the investigation must answer.

Find out how the work happens, what the current rules require and which decisions need a person. Give developers more than a sequence of steps.

For each decision, list the records available, actions allowed, approvals needed and result to check. Use cases to explain the rules and exceptions.

This guide describes a working method. Record any information you cannot establish; discovery cannot reveal every missing fact.

Choose one workflow.

1. Choose a specific request, such as replacing a part, changing an account or approving an invoice.
2. Define what starts the work, what counts as completion, who is responsible and which systems are involved.
3. Ask the people who will use the findings what they need. Give developers action and data requirements, process owners rules to approve, and reviewers cases to test.
4. Agree how those people will check the work before collecting records.

Reconstruct each case before drawing the process.

Connect the order, ticket and messages only when the records support that link. A shared customer and nearby timestamps are not enough on their own.

Keep the source ID, time, person or system involved and information available at each step. Explain why you linked two records. Ask someone to review uncertain matches.

Keep parallel actions and missing steps visible. Compare cases only after checking each one. Ask whether repeated behavior follows an approved rule or reflects a workaround.

Compare the records, policy and explanations.

• Check the records: What happened?
• Read the current policy: What was supposed to happen?
• Ask the person: What did they notice and consider?
• Ask the process owner: What should an agent be allowed to do next time?

Investigate differences. Check for outdated documents, unauthorized shortcuts, missing information and allowed exceptions. Do not combine conflicting accounts into one rule without resolving them.

Choose the source that can answer the question.

Use system logs to check recorded transactions. Observe the work to find steps the logs miss. Read documents for written instructions. Interview people to understand their reasons and alternatives.

Compare these sources. If the records cannot answer a question, ask for specific evidence or record the limit. Research on process knowledge also distinguishes these methods and the practical knowledge interviews can help explain.

Write the instructions developers need.

1. Specify the required records, allowed actions, approval rules and person to contact when the agent must stop.
2. Link each rule to records that support or challenge it. Name the approver and record when the rule takes effect.
3. Prepare tests for routine work, exceptions and failures. Confirm that the required system actions and data fields exist.
4. Have the process owner approve the rules. Ask developers to identify anything they would still have to guess.
5. Resolve those gaps, narrow the work or keep the decision with a person before proceeding.

Apply the method to an example.

• Inspect the replacement case and draft test.
• Use the interview questions.
• Turn approved rules into tests.

Research reference: Large Language Models for Process Knowledge Acquisition, Business & Information Systems Engineering. This informs the choice of evidence methods; it does not validate FieldSignal’s performance.