A workflow makes a good RL environment when code can check its result, its rules are written down, the work happens through tools, tasks vary, a better agent is worth something to the buyer, and the data can be used without privacy problems. The first condition decides whether to build at all; the others decide when and how well.
This article turns those conditions into a scorecard with a decision rule and applies it to five back-office domains. It belongs to the series that starts with Why AI agents still struggle with back-office work.
What is the core test for a workflow?
The core test is whether code can decide, for any end state an agent might produce, whether it meets every condition a correct result must meet. If it cannot, the reward has to come from a judge or a person, which is noisier, slower and easier to game.
Most workflows have many correct end states, so the check is a list of conditions, not a single target. Two questions settle it:
- Can every condition of a correct result be written down? "The invoice is on hold and the duplicate line is flagged" can. "The supplier is satisfied" cannot.
- Can the verifier decide each condition without judgement? A verifier is the code that checks the final state, and where needed the episode's action log, and computes the score. If deciding needs a person or a model to weigh quality, the check is not exact.
The conditions must also cover what the agent was not allowed to do. A recorded approval, for example, must come from an authorised approver, not from the agent itself. Checks on forbidden actions and side effects belong in the core test, and Reward hacking in AI agents explains why.
A check that code can compute is what reinforcement learning with verifiable rewards needs; RLVR, explained covers the method.
What belongs on the scorecard?
The scorecard has six criteria: a checkable outcome, encodable rules, actions through tools, variation, value to the buyer, and data and privacy. Score each from 1 (weak) to 3 (strong); a 2 means workable with limits, for example most conditions decidable by code but some needing judgement or unwritten rules.
| Criterion | What it means | A strong workflow |
|---|---|---|
| Checkable outcome | Code can decide whether any end state meets every condition | Every condition, including forbidden actions, is written down |
| Encodable rules | The rules can be written as code | Law, policy and limits are documented |
| Actions through tools | The work happens in software the agent can use | Records, documents and messages live in systems |
| Variation | Many structurally different tasks can be generated | Which rules interact and which exception applies varies |
| Value to the buyer | A better agent on this work is worth something | The work recurs often, errors are costly, and current agents fall short |
| Data and privacy | Realistic data can be used safely | The world can be generated without personal data |
Two criteria are easy to underrate. Variation decides whether the environment can train an agent or only test it. A seed is a number that fixes every random choice when a task is generated, and a task family is a group of tasks that share a structure but differ in their details, generated from different seeds. Seeds that change only names and amounts let an agent memorise one fixed policy; real variety comes from which rules interact and which exception fires.
A workflow also needs headroom, the room between what current agents already do and what the work requires: if current agents already solve its typical task every time, or never, an environment gives little training signal. What makes a good RL environment? explains how to calibrate difficulty.
How do you decide from the scores?
Decide by checking the rows below in order and taking the first that applies; if none applies, build. The rule is a starting point, not a formula.
| Check, in this order | Decision |
|---|---|
| Checkable 1 | Narrow sharply, or use rubrics and human review in evaluation only |
| Tools 1 or data 1 | Keep for later, until the work moves into systems or the data question is solved |
| Rules 1 | Write the rules down first, then score again |
| Variation 1 | Use the workflow for evaluation cases only |
| Value 1 | Do not build |
| Checkable 2 | Narrow the task to its checkable parts, then score again |
| None of the above | Build the environment |
What does a scorecard look like for one workflow?
A scorecard for one workflow is six scores with one line of evidence each, plus a decision. The example below scores a workflow outside the five domains.
Illustrative example. Month-end supplier statement reconciliation: a supplier sends a statement of open invoices, and the agent must match it with the company's records, flag differences and prepare the payment run.
| Criterion | Score | Evidence |
|---|---|---|
| Checkable outcome | 3 | Each statement line ends matched, disputed or paid; the records decide which |
| Encodable rules | 3 | Matching rules, payment terms and approval limits are written down |
| Actions through tools | 3 | Records, statements and the payment run live in the accounting system |
| Variation | 3 | Credit notes, partial payments and duplicates combine in different ways |
| Value to the buyer | 2 | Errors cost money, but the workflow recurs only monthly per supplier |
| Data and privacy | 3 | Supplier and invoice data can be generated without personal data |
Illustrative example.
Under the decision rule, this workflow is built, starting with a task family such as "statement with one duplicate and one missing credit note".
A workflow such as negotiating a supplier's price increase scores 1 on the core test, because a good outcome depends on what the supplier would have accepted. Under the decision rule it is narrowed to its checkable core: flag every price above the agreed cap and prepare an approval request with the figures, while the negotiation stays with a person.
How do five back-office domains score?
Four of the five domains below score 3 on the core test, and hospital ward operations scores 2 until it is narrowed to its checkable parts. They are the domains on Vencur's own list; all five are Planned, not yet available. The scores are an assessment made to show the scorecard at work, not a measurement.
| Domain | Checkable | Rules | Tools | Variation | Value | Data | What gets checked |
|---|---|---|---|---|---|---|---|
| Payroll and HR administration | 3 | 3 | 3 | 3 | 3 | 2 | Every payslip line follows the rules |
| E-invoicing and VAT | 3 | 3 | 3 | 3 | 3 | 3 | The invoice meets the standard and, with the facts fixed, the VAT is right |
| Hospital ward operations | 2 | 2 | 2 | 3 | 3 | 2 | Every patient gets a bed with the care level they need |
| Warehouse and logistics planning | 3 | 3 | 3 | 3 | 3 | 3 | Every order ships within its constraints |
| Procurement and purchasing | 3 | 3 | 3 | 2 | 3 | 3 | Every order follows policy and budget, approved by an authorised person |
An assessment, not a measurement.
Payroll and HR administration
Payroll ends in payslips whose every line can be recomputed from contracts, hours, absences and rules. The rules are dense but written down. Data scores lower because real payroll data is highly personal. A first task family could be "a mid-month change of hours", where the verifier recomputes the affected payslip lines.
E-invoicing and VAT
E-invoicing is unusually well suited, because the format itself is standardised. EU Directive 2014/55/EU defines an electronic invoice as one issued, transmitted and received in a structured electronic format that allows automatic processing. It requires contracting authorities and contracting entities to receive and process invoices that comply with the European standard on electronic invoicing.
That standard is EN 16931; according to the European Commission, its data model has syntax bindings for formats such as UBL 2.1, and a 2026 version replaces the 2017 one after a migration period.
The rules are also moving towards more structure. Council Directive (EU) 2025/516, part of the VAT in the Digital Age (ViDA) package, states that electronic invoicing should become the default system for issuing invoices.
The EU-wide e-invoicing and digital reporting rules of Directive (EU) 2025/516 apply from 1 July 2030, with 1 January 2035 for domestic e-invoicing in Member States that had real-time reporting in place, authorised or legislated for by 1 January 2024; since 14 April 2025, Member States may already require taxable persons established in their territory to issue electronic invoices for domestic supplies. For a verifier, two kinds of check follow:
- Format checks are exact against a pinned version. The standard's semantic data model defines the core elements an invoice must contain, and a syntax binding maps them to a file format such as UBL 2.1. An invoice either matches the pinned version and binding, or it does not.
- VAT checks are exact only when the world fixes the underlying facts, such as where the customer is established, whether it has a VAT number and the type of supply. The VAT treatment that follows from them is what the agent has to work out.
A first task family could be "an incoming invoice with one field that breaks the standard", where the correct end state is a rejection with the right reason code.
Hospital ward operations
Ward operations score 2 on the core test because many of their rules are local and partly unwritten. Narrowed to bed allocation and staffing, with the rules written down, the checks become exact.
Handovers need a checkable proxy, such as a complete handover note for every patient; whether a handover was safe cannot be checked exactly. A first task family could be "an admission when the ward is full", where the verifier checks that every patient ends in a bed with the care level they need.
Warehouse and logistics planning
Warehouse work, such as stock, pick routes and loading, is planning with hard constraints and clear costs, which suits a reference solution. A reference solution is a known good plan, computed by a solver and used as the target when scoring. The verifier checks that every order ships within its constraints and scores the plan against the reference. Solver-computed reference solutions explains the method.
Procurement and purchasing
Procurement ends in orders that follow policy and budget. Variation scores slightly lower because approval chains repeat a similar structure, so task families need deliberate variety. A first task family could be "a request just above an approval limit", where the order must end with the second approval recorded by an authorised approver.
How do you handle data access and privacy?
Generate the world instead of copying real records, so it contains no real people:
- Study real documents, then generate. Look at real invoices, rosters or orders to learn their formats, their typical errors and their edge cases, and write a generator that reproduces those features with invented content. The study itself still involves real data, so it needs the usual care.
- Keep personal data out of the world. Names, IDs and addresses in the world are invented. Where a workflow needs realistic personal details, such as a payslip, generate them.
- Write down where every template came from. A buyer will ask whether any real document or record was used, and the answer should be a list, not a guess.
What makes work hard to verify, and what can you do?
Work is hard to verify when its success depends on judgement, taste or outcomes far in the future. Parts of it can still be trained: narrow the task to checkable sub-tasks, and use rubrics and human review for the rest, outside the pass or fail decision.
A rubric is a written list of criteria with a description of what earns which score.
| Situation | Example | What to do |
|---|---|---|
| Success depends on tone or persuasion | Writing to a supplier about a dispute | Check the facts in code; grade tone with a rubric, with a small, capped weight |
| Success depends on future outcomes | Choosing which supplier will deliver on time next year | Narrow to checkable decisions made with today's information |
| Rules are unwritten | Local habits on a ward | Write the rules down first, or leave them out of the world |
| One case per task, little variation | A one-off migration project | Use it as an evaluation case, not as training data |
Narrowing is often the most effective option: "handle the supplier dispute" becomes "put the right invoices on hold, record the reason and draft a message listing the disputed lines", with only the message's tone left to a rubric.
Rubrics and human review are useful, but they belong outside the pass or fail decision. Scored by a model, a rubric brings the documented biases of LLM judges, such as favouring longer answers (Zheng et al., 2023), into the reward; scored by people, it is slow and expensive.
Give rubric points only to episodes that pass the exact checks, cap them, and compare them with human ratings, or use the rubric only in evaluation. A small weight alone is weak protection: when every attempt passes the exact checks, the rubric is the only part of the reward that still differs, so training concentrates on it. Deterministic verifiers vs. LLM-as-a-judge explains the trade-off.
How do you run the scorecard on your own workflow?
Run the scorecard in a short session with someone who does the work every day. The aim is to find the core of the workflow that can be checked, not to score the whole job.
- Write the conditions a correct result of one typical task must meet, including what must not happen.
- List the rules behind those conditions, and where each rule is written.
- List the tools the work happens in, and which of them an agent could use.
- List what varies between instances of the task, and which variations change the decisions; try to write down five task families that need different decisions.
- Score the six criteria, check the headroom, and mark the weakest criterion.
- Apply the decision rule: build, narrow, or keep for later.
The ten properties of a good RL environment are the next step once a workflow passes; Vencur Environments describes Vencur's worlds. For rules that come from law, Labour-law rules as code shows how to encode them. To discuss a workflow you would like to train agents on, tell us about it.
This article is general information, not legal advice. The EU texts cited were checked on EUR-Lex on 17 October 2026.