Lab 08A · 15 min

Lab for business analysts

Turn a process narrative into a BPMN diagram, then classify thirty-five data fields against a policy.

By the end

You can ask Codex to draw a process and sort data fields by risk, and you can check both results.

You can turn a written process into a BPMN diagram and classify data fields against a policy with Codex, then check both outputs against an answer key.

You can have an agent derive a BPMN 2.0 model from prose and apply a classification policy to a schema, and you can verify both outputs against a known-good key.

Reading level

Workplace terms for professionals.

Codex facts checked on 12 October 2026

What you will make

You will do two jobs that analysts do all the time.

In part 1, Codex reads a story about how a company adds a new supplier. It draws the story as a process diagram. In part 2, Codex sorts 35 data fields into four risk levels.

Codex does the first draft. You check it.

Part 1: Codex reads a narrative of a supplier onboarding process and produces a BPMN 2.0 diagram. BPMN is Business Process Model and Notation, the standard way to draw a process with lanes, tasks and decisions. Codex also writes a web page that shows the diagram in your browser.

Part 2: Codex classifies 35 customer data fields against a four-level policy and flags the fields the policy does not settle.

Both parts follow the same routine: brief, plan, act, check.

Part 1 generates a BPMN 2.0 XML model from unstructured prose. The model needs a process with a lane set, tasks, exclusive gateways, end events and sequence flows, plus a diagram section that gives each element a position. The page loads the bpmn-js viewer from a CDN so you can inspect the result without a modelling tool.

Part 2 applies a four-level classification policy to a field list. The policy has an explicit escape hatch: fields it does not settle go to a person. A good output uses that hatch rather than guessing.

Both outputs have a known correct form, so you can verify them.

Files you will use
FileWhat it holds
business-analyst/supplier-onboarding-process.docxA narrative of the supplier onboarding process
business-analyst/data-classification-policy.mdA four-level data classification policy
business-analyst/customer-fields.csvThirty-five customer data fields to classify

Part 1, draw the process

  1. 01

    Open the project folder

    Open Codex. Open the CodexWork folder as your project. Check that the mode says Ask for approval.

    Then open a new thread.

    Open Codex with CodexWork as the project folder. Check that the mode under the message box says Ask for approval.

    Start a new thread so earlier work does not crowd the context.

    Open CodexWork as the project folder and confirm the mode is Ask for approval. Start a new thread: a fresh context keeps unrelated earlier turns from steering the output.

  2. 02

    Send the brief and read the plan

    Copy the brief below into Codex and send it. Codex will write a plan first. It will not make any file yet.

    Read the plan. Look for the five roles. If one is missing, say so before you go on.

    Copy the brief below into Codex and send it. Codex writes a plan and stops. Read it. It should name one lane for each role in the narrative. If it does not, correct the plan before you approve.

    Send the brief. The plan should map roles to lanes and decisions to gateways, and list its ambiguities. If the plan invents a step that the narrative does not state, correct it now: a wrong structure is cheaper to fix in the plan than in the XML.

    Codex shows a plan and waits. No file exists yet.Illustration. Your screen may differ.
  3. 03

    Approve, then open the diagram

    Reply: Approved. Go ahead. Approve each file Codex asks to create.

    Open outputs\view-process.html in your browser. You need an internet connection for the picture to load.

    Reply: Approved. Go ahead. Approve each file Codex asks to create in outputs.

    Open outputs\view-process.html in your browser. The page loads the viewer from a CDN, so your browser needs internet access. Codex does not.

    Reply: Approved. Go ahead. Approve each write to outputs. Then open outputs\view-process.html. The viewer script loads from a CDN in your browser. The sandbox restriction on network access applies to Codex commands, not to your browser.

    If the diagram does not render, ask Codex to validate the XML for well-formedness and for sequence flows that point at missing elements.

Brief for part 1

Goal: Turn the supplier onboarding narrative into a BPMN 2.0 diagram.
Inputs: business-analyst/supplier-onboarding-process.docx
Output: outputs/supplier-onboarding.bpmn with one lane for each role. Also outputs/view-process.html that shows the diagram with the bpmn-js viewer loaded from a CDN.
Constraints: Do not change any source file. Write only in outputs/. Ask before you install anything.
Done when: the diagram has every task, every decision and every end event in the narrative.
How to check: List every lane, task, gateway and end event with a count for each. List anything in the narrative that is unclear.
Make a plan first. Do not create any file until I approve the plan.

Codex may list steps it cannot read clearly. Answer each listed step before you approve the plan.

Expect a short list of unclear points. A list of questions is better than a quiet guess.

Asking for ambiguities forces the agent to separate what the text states from what it infers. Review that list before you review the diagram.

Part 2, classify the fields

  1. 01

    Send the brief and read the plan

    Start a new thread. Copy the brief below and send it. Read the plan.

    The policy has a rule for fields it does not cover. Check that the plan uses it.

    Start a new thread and send the brief below. Read the plan. The policy says what to do with a field it does not settle. Check that the plan follows that rule and does not guess.

    Start a new thread and send the brief. Check the plan for the policy's review rule. An agent that assigns a level to every field is optimising for completeness, not for the policy.

  2. 02

    Approve and open the result

    Reply: Approved. Go ahead. Approve the file Codex asks to create.

    Open outputs\field-classification.csv in Excel. Look at the needs_review column.

    Reply: Approved. Go ahead. Approve the new file, then open outputs\field-classification.csv in Excel. Sort by level and read the reason for each row.

    Reply: Approved. Go ahead. Open outputs\field-classification.csv and read the reason column first. A reason should cite the policy section, not restate the field name.

    Codex finished. Three fields are marked for review.Illustration. Your screen may differ.

Brief for part 2

Goal: Classify each customer data field against the data classification policy.
Inputs: business-analyst/customer-fields.csv and business-analyst/data-classification-policy.md
Output: outputs/field-classification.csv with the columns field, level, reason, personal_information, needs_review.
Constraints: Use only the four levels in the policy. Do not guess. If the policy does not settle a field, mark needs_review as yes and say why in reason. Do not change any source file. Ask before you install anything.
Done when: all 35 fields have a row.
How to check: Count the rows by level and list the fields that need review.
Make a plan first. Do not create any file until I approve the plan.

Answer key

Open each question below. Compare the answer with your own result.

Open each question below and compare the answer with your own result. A match is evidence. A mismatch is a reason to ask Codex to show its working.

Compare each answer with your outputs. The key came from the data that built the starter pack, so a mismatch points to a defect in the output.

Check yourself

Part 1. How many lanes, tasks, gateways and end events should the diagram have?

5 lanes, which are the roles: Requester, Procurement, Supplier, Risk and compliance, Finance. 11 tasks. 4 decision points (gateways). 3 end events, which are the final outcomes: Existing supplier used, Supplier rejected, Supplier active. If your counts differ, ask Codex which step it merged or missed.

5 lanes (Requester, Procurement, Supplier, Risk and compliance, Finance), 11 tasks, 4 gateways and 3 end events (Existing supplier used, Supplier rejected, Supplier active). If a count differs, ask Codex to show where the missing or extra element came from in the narrative.

5 lanes (Requester, Procurement, Supplier, Risk and compliance, Finance), 11 tasks, 4 exclusive gateways and 3 end events (Existing supplier used, Supplier rejected, Supplier active). A different count means a merged step, a missed branch or an invented element. Ask Codex to trace each element to a sentence in the narrative.

Part 1. Which tasks and decisions should the diagram name?

Tasks: Submit new supplier request; Check for an existing supplier; Send onboarding pack; Return completed forms; Check documents are complete; Request missing documents; Rate supplier risk; Review high-risk supplier; Verify bank details by call-back; Create supplier record; Notify requester. Decisions, as questions: Supplier already exists? Documents complete? High risk? Approved?

Tasks: Submit new supplier request; Check for an existing supplier; Send onboarding pack; Return completed forms; Check documents are complete; Request missing documents; Rate supplier risk; Review high-risk supplier; Verify bank details by call-back; Create supplier record; Notify requester. Gateways: Supplier already exists? Documents complete? High risk? Approved?

Tasks: Submit new supplier request; Check for an existing supplier; Send onboarding pack; Return completed forms; Check documents are complete; Request missing documents; Rate supplier risk; Review high-risk supplier; Verify bank details by call-back; Create supplier record; Notify requester. Gateways: Supplier already exists? Documents complete? High risk? Approved? Check that each gateway has labelled outgoing flows and that every branch reaches an end event.

Part 2. Which level should the ten anchor fields get?

tax_file_number (Restricted), bank_account_number (Restricted), health_condition_notes (Restricted), password_hash (Restricted), date_of_birth (Confidential), personal_email (Confidential), contract_value (Confidential), internal_cost_centre (Internal), account_manager_name (Internal), company_website (Public). Other fields should follow the same rules.

tax_file_number (Restricted), bank_account_number (Restricted), health_condition_notes (Restricted), password_hash (Restricted), date_of_birth (Confidential), personal_email (Confidential), contract_value (Confidential), internal_cost_centre (Internal), account_manager_name (Internal), company_website (Public). Use these ten as anchors. If any differs, ask Codex to quote the policy line it used.

tax_file_number (Restricted), bank_account_number (Restricted), health_condition_notes (Restricted), password_hash (Restricted), date_of_birth (Confidential), personal_email (Confidential), contract_value (Confidential), internal_cost_centre (Internal), account_manager_name (Internal), company_website (Public). These ten fall clearly under one section of the policy. A wrong level here is a misreading of the policy, not a judgement call.

Part 2. Which three fields should be marked for review?

general_notes, call_recording_url, ip_address. The policy does not say which level they have. A person must decide. Codex should not guess.

general_notes, call_recording_url, ip_address. The policy says these can hold more than one level, or are personal information only in some contexts. A good answer flags them for the data owner and does not pick a level.

general_notes, call_recording_url, ip_address. Each can hold content of more than one level, or is personal information only in some contexts. The policy sends these to the data owner. An output that classifies all 35 fields without a flag has filled a gap that the policy meant to leave open.

Go further

Ask Codex to add a new field to the list and sort it. Then ask it to explain how it chose the level.

You can also ask Codex to write a short guide that tells a new teammate how to use the policy.

Turn part 2 into a reusable skill. Ask Codex to use $skill-creator to make a classify-fields skill that takes any field list and any policy, and always flags unsettled fields.

For part 1, ask Codex to compare the diagram with a changed narrative and list what moved.

Package part 2 as a skill with $skill-creator, with a script that validates the CSV schema and rejects a level outside the policy. A deterministic validator catches errors the agent would not.

For scripted runs, codex exec can run the same brief non-interactively. Then diff the lane, task and gateway counts across runs to measure how stable the output is.

Syllabus

OtterBlock is not affiliated with OpenAI. Codex and ChatGPT are OpenAI products.