Compliance rules & position requirements
Most of Oho answers questions about a credential: is this WWC check real, is it current, when does it expire. Compliance rules answer a different question — is this person where they need to be? That means saying what "compliant" means for your organisation, which is a policy decision Oho can't make for you.
There are two ways to express it, and they answer different questions:
| You want to say… | Use |
|---|---|
| "Anyone in this position must hold these credentials" | Position requirements |
| "Anyone matching this pattern must satisfy this condition" | Compliance checks |
| "Any one of these credentials will do" | Equivalence sets, used by both |
Most organisations start with position requirements, because "a support worker needs an NDIS screening check" is how the policy is actually written down. Compliance checks are the escape hatch for rules that don't follow the org chart.
Position-based requirements
A position requirement attaches to a position (a job), not to a person. Say what the position needs once, and every worker in it is measured against it — including people who join it later.
Each requirement names one of:
- a credential type —
POLICE_CHECK,AHPRA, a WWC check for a particular state; or - an equivalence set — where holding any one member counts.
A requirement can also carry exemptions: credential types that waive it. And separately, a worker with an exemption on file has the matching requirement ignored for them — the requirement itself is unchanged, and still applies to everyone else in the position.
What a worker sees
Oho compares what the position requires against what the worker holds. Anything required and not held shows as a missing credential on their profile and counts against their compliance status. Anything held but lapsed is already flagged on the credential itself — it isn't double-counted as missing as well.
A requirement is a presence check. An active credential satisfies it even when its verdict is poor, because the bad verdict is already raised against that credential. The exception is a credential whose scanning has been paused while its last-known verdict was expired, superseded, or problematic — that no longer counts as held, so a paused problem can't quietly read as compliance.
Where requirements come from
| Source | How |
|---|---|
| Your HR system | A connector reads the position's requirement flags and maps each to an Oho credential — see Sync position requirements |
| The API | PUT /jobs/{jobUrn}/requirements, or the bulk variant — see API Reference: Job Requirements |
Under the hood a single shared check ("Position Role Requirement Check") reads every position's requirements at evaluation time. There is no per-position rule to create or maintain, which is why adding a requirement takes effect without anything else being switched on.
Equivalence sets
An equivalence set is a named group of credential types that are interchangeable for a requirement. Hold any one member and the requirement is satisfied.
The usual reason to want one is that the policy is written in terms of an outcome rather than a document: "right to work" is satisfied by a passport or a visa or a citizenship certificate; "current first aid" is satisfied by any of several accepted certificates. Without a set you'd write the requirement once per acceptable credential and keep every copy in step.
Create and manage sets under Compliance Rules → Equivalence Sets in the app. A set has:
- a name and optional label — what it's called;
- members — the interchangeable credential types, at least one;
- guiding text — what a person is told when asked to supply one;
- an active flag — an inactive set stays readable but isn't offered for new requirements.
Once a set exists it becomes selectable wherever a requirement is set, alongside individual credential types.
Oho derives the set's code from its name at creation and never changes it afterwards. Rename the set freely — the code stays as it was, and anything pointing at the set keeps working.
Prefer deactivating a set you've stopped using over deleting it: deactivation is reversible, and requirements that already point at it stay legible either way.
Compliance checks
A compliance check is a rule you define directly: a scope that picks the workers it applies to, a condition tree that says what must be true of them, and an action to take on the outcome. Reach for one when the rule doesn't follow from a position — "every worker in Queensland must hold a Blue Card", "anyone whose visa carries work conditions gets tagged for review".
Availability: Compliance checks are a Premium capability.
A check has four parts:
| Part | What it does |
|---|---|
| Scope | Which workers it applies to — all workers, workers matching a filter, or a specific list |
| Conditions | What must be true, as an AND/OR tree over worker and credential fields |
| Severity | CRITICAL, WARNING, or INFO — how loudly a failure is reported |
| Actions | What happens on pass or on fail — apply a tag, remove a tag, or notify |
Conditions read fields on the worker (jobTitle, status) or on their credentials
(credentialProperties.expiryDate), with the usual comparisons plus EXISTS / NOT_EXISTS and
BETWEEN. A credential condition can be narrowed to particular credentials, and can ask whether
any or all of them satisfy it. Trees are capped at five levels deep and 100 conditions —
past that, the rule is usually better expressed as two checks.
Checks come from two places. Oho ships a set of standard checks (OHO_STANDARD) that you can tune,
enable, and disable but not recreate; anything you write yourself is NATIVE.
Evaluation
Each check records, per evaluation: how many workers were in scope, how many passed, how many failed, and how many errored — where the rule couldn't be evaluated at all, usually because a field it reads is missing. A check reporting mostly errors is a misconfigured rule rather than a compliance problem, and it's worth reading the run history before acting on it.
A disabled check doesn't participate in evaluation runs; a deleted one is soft-deleted and stays readable in history.
To evaluate on demand, poll results, or read the per-worker run history from your own system, see Evaluating Compliance.
How this relates to the rest of Oho
- Credentials — what a requirement is asking the worker to hold
- Exemptions — when a requirement doesn't apply to a particular person
- Compliance dashboards — where the resulting picture is read
- Review & Decide — what happens when an outcome needs a person
- Evaluating Compliance — driving all of this over the API