Vocabulary
Rules that read like your industry
Somewhere in most governance projects there's a meeting where four people argue about what to call a payment status. It goes on longer than anyone expects, and the thing they agree on is usually wrong.
How this goes wrong
A developer connects the agent and picks a field name. Something reasonable, like payment_state. Values are whatever the payment provider happens to return.
A governance engineer writes a rule. They weren't in that conversation, so they write it against paymentStatus, with the values from the spec they were reading.
A compliance officer opens the record six months later and sees ACSP, which means nothing to them, so they ask an engineer, who has to go look it up.
Nobody did anything wrong. There was no shared answer to a question three different people each had to answer on their own.
It sounds like a small problem. It isn't, because most governance is still assembled per project, by whoever is nearest, under deadline, and naming is where that shows up first.
What it actually costs
Rules that quietly don't match. The policy checks a field the application never sends. It doesn't error. It never fires, and you find out during an incident.
Meetings that shouldn't exist. Every new workflow reopens the naming conversation, because the last one's answers lived in that workflow's code.
Records only engineers can read. If your compliance team needs a translator to interpret a decision record, the business doesn't really have visibility. It has a queue.
The fix is boring, which is why it works
Your industry already solved this. Banking has ISO 20022 and BIAN. Mortgage has MISMO. Insurance has ACORD. Healthcare has HL7 FHIR. Telecom has TM Forum. Manufacturing has ISA-95. These are decades of committee work by people who argued about naming so you don't have to.
So don't invent a vocabulary. Ship one, drawn from the standards those teams already follow, and have everything point at it.
Here's what that looks like for a single payment status:
The agent emits a standard field
banking.payment.iso20022_status = ACSP. The attribute name and the allowed values both come from the catalog, so the application isn't making either one up.The policy matches the same name
data.banking.payment.iso20022_status. The rule points at a published path rather than a string somebody agreed to in a meeting.The reviewer reads plain language
"Accepted Settlement in Process," with a citation to ISO 20022 pacs.002. Nobody has to have the code explained to them.
What you get out of it
One name, three audiences, no translation step in the middle to get wrong.
The knock-on effect is the one that matters over time. Your second application in the same industry doesn't reopen any of this. The vocabulary is already there, the rules already reference it, and your compliance team already knows how to read the output. That's a chunk of what makes the next workflow cheaper than the last.
You can still add your own fields. Most organizations have a few concepts that are genuinely theirs. The point isn't to stop you extending it. It's that nobody should be inventing a name for a payment status in 2026.
Look at the catalog for your industry
Fourteen industries, each drawn from published standards, each value carrying a plain-language label and a citation.