Standards, explained

Clear questions.
Decisions you can explain.

A workforce decision needs more than an answer. People need to understand the question, see the reason, know what happens next and have a way to resolve exceptions.

Explore the frameworks behind country content, then see how plain language, decision rules, processes and human review fit together.

Country content frameworksHow we apply the framework Nine references. Current evidence and next steps.

This is a guide to the standards and their relevance to Triage. It does not claim ISO certification, a conformant modelling engine or tested model interchange. Read our approach ↓

Country compliance content

How we apply
the framework.

Clear content. Traceable sources. Reviewable releases.

These standards and frameworks guide how we write, trace, version and review country compliance content. Implementation varies by framework and jurisdiction. The record below separates what is evidenced from what is still being completed.

Statement version 1.016 October 2026Draft for jurisdiction review

Compliance-lead confirmation is pending for every jurisdiction listed below. This is a dated implementation snapshot, not certification, a legal determination or approval to start work.

1 evidenced Supporting release artefacts exist.

6 partial Practice exists, with gaps to close.

2 not yet A target, not a completed claim.

Statuses follow the 16 October evidence register. “Evidenced” describes the stated practice, not compliance with an entire standard. Open each framework for its purpose, evidence and remaining work.

ISO 37301Compliance management systemsPartial

Purpose. ISO 37301 addresses how an organisation establishes, maintains and improves its compliance management system. For country content, the relevant discipline is connecting obligations to controls, evidence and ongoing review.

Current evidence. Assurance releases contain obligation and evidence registers, supported by a country-release checklist. Source checking dates and precise provision references are present in some packs, including the Germany draft.

Next step. Apply the same source fields across jurisdictions and record legal changes for each release. We do not yet claim complete obligation-to-control mapping or a uniform law-change review process for every country.

ISO 37301 official overview ↗
ISO/IEC 31010Risk assessment techniquesPartial

Purpose. Published as IEC 31010:2019, this joint ISO/IEC reference helps select and apply risk assessment techniques. The choice of method, its assumptions and its limitations need to be clear.

Current evidence. Country models document screening methodology and state that scores are not probabilities or legal determinations. These are operational screening signals that identify matters for review, not permission to proceed.

Next step. Make calibration status explicit in older model versions and resolve how unknown information affects screening bands. A numeric result must not imply precision the method has not established.

ISO introduction to IEC 31010 ↗
DDIData Documentation InitiativePartial

Purpose. DDI supports structured documentation of concepts, questions, answer codes and data through their lifecycle. We draw on these principles to separate the fact being collected from the words used to ask for it.

Current evidence. Country packs use stable fact identifiers, canonical wording and fixed answer codes, with presentations for different journey stages. The identity and evaluation of a fact should stay stable when its presentation changes.

Next step. Publish a mapping between the pack schema and DDI-Lifecycle concepts, plus a shared fact registry. This is an application of DDI principles, not a DDI conformance claim. The website demonstration continues to use its existing questions.

DDI-Lifecycle overview ↗
DMNDecision Model and NotationNot yet

Purpose. DMN gives business and technical reviewers a shared notation for decisions. Decision tables make the input conditions and resulting outputs visible together.

Current evidence. Country rules have structured conditions and explanation traces. They are not yet presented as DMN decision tables in the country review records.

Next step. We are moving our rules towards reviewable DMN decision tables. The review HTML and Word audit records need table views that compliance leads can challenge without reading code. The illustrative table further down this page does not establish country-pack implementation or engine conformance.

Try the illustrative decision table ↓
ISO 24495-1Plain languageNot yet

Purpose. Plain-language design helps readers find, understand and use the information they need. It considers the audience, wording, structure and presentation together.

Current evidence. Requestor messages have a title, explanation and next step. Copy checks support consistent presentation. ISO 24495-1 informs our writing, but a recorded plain-language test for every release is not yet in place.

Next step. Record a reader task test or structured plain-language review for each release, with a named tester and findings. We do not claim that all country content has been tested against the standard. Automated copy checks alone do not establish that people can use it.

Explore the four plain-language principles ↓
ELI / ECLITraceable legislation and case lawPartial

Purpose. The European Legislation Identifier and European Case Law Identifier help identify and cite legislation and judgments. Their availability depends on the issuing jurisdiction and source.

Current evidence. Source registers link to official texts. Some jurisdiction packs include section or article references. Persistent ELI/ECLI identifiers are not yet consistently captured as dedicated source fields.

Next step. Add ELI and ECLI identifiers wherever they exist, alongside the official text, precise provision and checking date. Use the appropriate national citation where these identifiers are unavailable; a link alone does not establish that a rule is current or applicable.

ELI overview ↗ ECLI overview ↗
Semantic VersioningIdentify a release and preserve its historyEvidenced

Purpose. Semantic Versioning describes version numbers and their meaning. Applying it to country content also requires a documented policy explaining which content changes affect each part of the version.

Current evidence. Country packs carry release versions, including draft identifiers. Release manifests and audit artefacts are checksum-locked, with historical releases preserved and integrity checks run in CI.

Next step. Formalise the major, minor and patch policy for legal, behavioural and editorial changes. Versioned history is evidenced; the exact change-classification policy remains to be written. A version number is not a legal approval.

Semantic Versioning specification ↗
W3C PROVProvenance and reproducibilityPartial

Purpose. PROV describes provenance through the things produced, the activities that produced them and the people or systems responsible. It helps explain where a release came from.

Current evidence. Release provenance records include source references, source commits and checksums for runtime bundles and review artefacts. These provide a basis for tracing content and the implementation used in review.

Next step. Complete the runtime toolchain record, including Node and build-tool versions, and make required authorship and review metadata consistently checkable. We work within provenance principles; we do not claim a conformant PROV export or a complete record for every release.

W3C PROV overview ↗
ISRS 4400Review structure onlyPartial

Purpose. ISRS 4400 governs practitioner agreed-upon-procedures engagements. Such an engagement reports factual findings from agreed procedures; it does not express an assurance opinion.

Current evidence. The 16 October review records procedures, factual findings and the provenance of checks. Our review structure is informed by ISRS 4400. This does not establish that an independent practitioner has performed an ISRS 4400 engagement.

Next step. Commission a practitioner engagement before claiming one. If performed, its practitioner, scope and date must be published with the claim. The reference here describes review structure only, not product certification or an assurance report.

IAASB ISRS 4400 (Revised) ↗

Scope of this statement

A country release
needs its own review.

The evidence register covers the following draft releases. It does not establish uniform implementation across countries. Every compliance-lead confirmation of this statement was pending at the 16 October 2026 snapshot.

Country-content scope at 16 October 2026
JurisdictionRelease in the registerStatement review
United Kingdom0.2.0-draft.1Pending
United States2.0.0-draft.1
Federal + California
Pending
Germany3.0.0-draft.1
Includes Works Council; unmerged draft
Pending
Austria0.1.0-draft.1 foundationPending
Australia0.1.0-draft.1 foundationPending
France, Ireland, Netherlands, Spain, Singapore0.1.0-draft.1 review candidatesPending for each

Reviewing this statement confirms the accuracy of the wording for a named jurisdiction and release. Legal review of a pack’s content, scoring and sources remains a separate record tied to that release. Any change to a statement sentence reopens the affected jurisdiction reviews.

This page describes content practices and their limits. Screening results identify matters to review. They do not supply legal advice or the organisation’s separate authorisation decision.

01 / ISO 24495-1:2023

The first decision is
how to ask.

Plain language starts with the person who needs to act.

ISO 24495-1:2023, Plain language — Part 1: Governing principles and guidelines, addresses the wording, structure and design of written information. Its four principles are relevance, findability, understandability and usability. A short sentence alone does not make a question useful.

RELEVANT

Ask what matters.

Give a requester the information they need for this decision. Explain why a question matters when its purpose is not obvious.

FINDABLE

Make the next step visible.

Use clear headings, a sensible order and help beside the question it explains. Keep essential conditions in view.

UNDERSTANDABLE

Use words people recognise.

Ask about the work, its direction and its result. Explain specialist terms before expecting someone to use them.

USABLE

Check that people can act.

Evaluate the question with intended users. Can they choose an answer, understand the result and take the next step?

AN EXAMPLE OF QUESTION DESIGN

“Does the engagement exhibit operational direction and control by the end client?”

A clearer question

“Who will decide what the person works on each day?”

The wording is easier to answer because it asks about an observable working arrangement. It is an illustration, not a replacement for the approved Triage question library.

In Triage, this is relevant to questions, answer guidance, mismatch explanations and Desk actions. Questions and answer guidance must preserve their intended meaning. A change of wording must not silently change the decision being made.

Evaluation should be ongoing: watch where people hesitate, ask for clarification or misunderstand a result, then review the wording and design. A recorded test for each country release remains planned, as the implementation status above explains. Reading-age scores can be useful prompts, but they do not prove that a person can complete the task. Digital accessibility also needs its own technical checks.

Read the ISO standard’s official description ↗

02 / Decision Model and Notation

Make the reasoning
open to inspection.

DMN describes how facts and rules produce a decision.

DMN is maintained by the Object Management Group (OMG). It gives business and technical teams a shared way to describe decision logic, separately from the process that acts on the result.

Inputs
The facts a decision needs: for example, who directs the work and whether the supplier owns a defined result.
Decision tables
Rows of conditions and outputs. A row shows what should happen when its conditions are met.
Decision requirements
The relationships between inputs and decisions. A more complex decision can depend on several smaller decisions.
FEEL
The Friendly Enough Expression Language: a standard way to express conditions and calculations, including comparisons involving numbers and dates.
Hit policies
The rule for handling matching rows. “Unique” expects at most one matching row. “Collect” can return several results. The policy is an explicit modelling choice.

What this means for workforce decisions

A channel recommendation and a mismatch signal answer different questions. One compares delivery arrangements. The other identifies answers that need review. They can be described as separate decisions, so a risk flag does not secretly change the channel score.

Triage’s website diagnostic uses its published workbook questions, weights and mismatch rules. A scoring tie stays a tie for human review. DMN provides a useful language for describing such logic; a weighted questionnaire is not automatically a DMN model.

Explore OMG’s DMN overview ↗

Try a decision table

Illustrative example

Change the answer.
Follow the reason.

A requester has selected Service via SoW. This small example checks whether two answers call for review. Change either answer to see the matching rule and next action.

U = Unique: at most one rule should match. “Any” means this input does not affect that rule.

Review a Service via SoW request
RuleDaily directionAcceptanceDecision
R1 Our teamAnyReview the delivery arrangement
R2 The supplierClearNo mismatch on these two checks
R3 The supplierUnclearClarify acceptance criteria
R4 Not agreedAnyAsk Triage Desk to resolve

R1 MATCHED

Review the delivery arrangement

Your team directs the work, although the request is labelled Service via SoW. Review whether the proposed arrangement matches how the work will actually be delivered.

Next action

Triage Desk reviews the arrangement with the requester before it moves on.

This example uses four authored rules running in your browser. It is not the Triage scoring model or a DMN execution engine. “No mismatch” is limited to these two checks; it is not approval or a legal conclusion. Nothing you select here is sent anywhere.

03 / Business Process Model and Notation

An answer needs
a next action.

BPMN describes the work that follows a decision.

BPMN provides a common notation for business processes. Events mark things that happen; tasks describe work; gateways show branches; and flows connect them. Pools and lanes can make participants and responsibilities visible.

For a workforce request, a process might gather answers, evaluate the decision, send an unresolved issue to Triage Desk and then hand an agreed outcome to the chosen system. An approval task belongs in that process only when the organisation’s policy calls for it.

AN ILLUSTRATIVE REQUEST PROCESS

Request answered
Evaluate the rules
A clear outcome

Continue to the chosen route

Carry the decision reference and the information the next step needs.

A tie, gap or mismatch

Review with Triage Desk

Resolve the open point. Reassess if the underlying answers change.

A simplified explanation of branching, not a formal BPMN diagram.

A BPMN business rule task can call decision logic represented in DMN. The decision supplies an output; the process uses it to choose the next step. The exact engine connection and supported model elements need implementation and testing.

In a Triage programme, this separation helps teams review the policy rule without burying it inside every handoff. It also makes operational questions visible: who owns an exception, when should it be escalated, and what happens if a downstream system does not accept the request?

Explore OMG’s BPMN overview ↗

04 / Case Management Model and Notation

Leave room for
human judgement.

CMMN describes cases where the next action depends on what people learn.

A case can evolve as evidence arrives. CMMN models the case file, activities and milestones, including work that may become relevant only after something changes. It complements a process with a known sequence.

Consider a request with conflicting answers. Triage Desk may need to speak to the requester, ask for a delivery plan or involve a country specialist. The useful next action depends on the information available. Forcing every case through the same sequence can add work without resolving the issue.

EXAMPLE CASE / DELIVERY RESPONSIBILITYNeeds review

Who actually owns delivery?

The proposed route says Service via SoW. The answers suggest the client may direct the work.

Evidence to consider
The requester’s answers, delivery responsibilities and proposed acceptance criteria.
Possible actions
Ask for clarification, consult a specialist, correct an answer or document an exception.
Completion milestone
The arrangement is clear and the reviewer has recorded the outcome and reason.

This is a useful reference for human-led Desk work. It does not mean every request needs a case, or that the website runs a CMMN engine. A clear request can continue through the ordinary process.

Explore OMG’s CMMN overview ↗

One decision, several perspectives

The same disciplines.
Five ways to work.

Plain language helps a requester provide useful facts. Decision rules assess those facts. A process moves the result forward. A case gives a reviewer room to resolve uncertainty. These roles can work together without making every activity automated.

The examples below show where each discipline could help. They are programme design examples, not predefined rules or claims about connected systems.

Illustrative applications across five workforce channels
ChannelDecision to explainProcess to organiseCase to resolve
PermanentIs the need enduring and directed internally?Follow the agreed headcount and recruitment steps.Resolve unclear ownership or a mixed work package.
ContingentIs temporary capacity the right arrangement?Start the relevant sourcing and engagement steps.Review conflicting supervision or duration answers.
Service via SoWIs there a supplier-owned result with clear acceptance?Define deliverables and follow the contracting process.Resolve a mismatch between the contract label and delivery.
OutsourcingIs an ongoing service being delegated?Plan service design, transition and ongoing review.Resolve uncertain service boundaries or responsibilities.
AI AgentsIs this task a candidate for an AI feasibility review?Assign an owner and run the required evaluation.Review exceptions, unclear accountability or missing evidence.

AI Agents is one of the five delivery channels. In the current website workbook demo, AI/automation is a review signal rather than a fifth scored channel. An AI suitability signal does not authorise autonomous action.

From an answer to an explanation

Keep enough evidence
to review the decision.

A model explains the logic. A decision record explains what happened on a particular request. For a reviewable implementation, agree what to record and retain:

  1. The inputs. The answers used, their source and any unresolved information.
  2. The policy and version. Which question set, rules and relevant policy applied at that time.
  3. The result and reasons. The outcome, matched rules, mismatch signals and any tie.
  4. The human action. Who reviewed or overrode the result, what changed and why.
  5. The handoff. The decision reference and the next system’s receipt or error, where an integration is enabled.

DMN, BPMN and CMMN do not by themselves create a complete audit trail, set retention periods or prove that an outcome is correct. The implementation must capture the evidence and make it available to the right people. Policies, permissions and country requirements still need their own owners.

Our approach

Be precise about
what a standard means.

A reference for design

We use ISO 24495-1 as a plain-language reference. DMN, BPMN and CMMN provide established ways to discuss decision logic, process responsibilities and case work.

Evidence for conformance

A conformance claim needs a defined version, supported features and tests. Model import, export and execution need to be verified with the tools involved.

A clear product boundary

The marketing website contains browser demonstrations. This page does not claim a production DMN, BPMN or CMMN runtime, ISO certification or endorsement by ISO, OMG or Camunda.

Are these Camunda standards?

No. OMG maintains DMN, BPMN and CMMN. Camunda publishes useful explanations and products that implement supported standards. Referencing its DMN tutorial does not mean Triage uses Camunda or has a commercial partnership.

Are the standards public, and why do their names carry trademarks?

OMG publishes the specifications for public access. Trademarked names identify the standards; they do not make them exclusive to one software vendor. Access to a specification is separate from the licence of a product that implements it. ISO publishes the description of ISO 24495-1, while the full standard is distributed under ISO’s licence.

Does standards alignment guarantee legal compliance?

No. These standards help describe communication, decisions and work. They do not supply employment law, validate a country policy or provide legal clearance. Triage mismatch and country-screening signals identify matters for review.

Does DMN require generative AI?

No. A decision table can apply defined rules to structured inputs without generating text. The interactive example on this page uses explicit local rules and makes no model call.

Can a model move between systems without changes?

Shared formats can help, but supported versions, engine features and vendor extensions differ. Test the actual model, inputs, outputs and process connections before claiming compatibility. A standards reference alone is not evidence of a working integration.

Go to the source

Read more.

Official specifications are the authority for formal definitions. The workforce examples on this page are Triage illustrations.

ISO 24495-1:2023Plain language — Governing principles and guidelines ↗ OMG · DMN 1.6Decision Model and Notation — formal specification ↗ OMG · BPMN 2.0.2Business Process Model and Notation ↗ OMG · CMMN 1.1Case Management Model and Notation ↗ Camunda · DMN tutorialAn introduction to decision tables, FEEL and decision requirements ↗

References checked 13 October 2026. OMG lists DMN 1.6 as a formal version and 1.7 as beta. Versions listed here identify reading references, not Triage’s supported engine versions. The supplied ISO preview informed this explanation; it is not reproduced or offered for download.

Explore the platform

See the questions.
Follow the decision.

Explore Triage