Rules & Compliance Checks

Reusable rules that decide which records a control applies to, and the compliance checks that hold an approval until evidence is in place.

Rules

A rule is a named, reusable yes-or-no question about a record, such as "is this applicant under 18?" or "is this placement in a hospital setting?". Other parts of the platform ask a rule by its key instead of each carrying its own logic, so the answer is defined once, tested once and changed in one place.

Where to find it

Architect Panel → Automation:

Rules — build, check against real records, and publish the rules that decide who a control applies to

What asks a rule

Today the main user of rules is compliance checks: each requirement type can name a rule in its Applies When setting, and the check is asked only of records where that rule is true. A rule on its own does nothing until something names its key.

How a rule is built

The Rules screen edits a rule as one or more groups of conditions:

Within a group, every condition must be true ("All of these").
Across groups, any one group being true is enough ("...or all of these"). Add a group with Add an alternative group.

Each condition has three parts: a field, an operator and a value. The field is the field's row name on the datastore (as shown in its Fields list), not its friendly name. A rule with no conditions at all applies to everything.

The operators

= and !=: equal, not equal. Numbers compare as numbers; text must match exactly, including capitals.
>, >=, <, <=: work on numbers and on dates written as year-month-day (2026-09-01). Anything else cannot be compared.
contains and startswith: text tests that ignore capitals.
isset and notset: whether the field has a value at all. The value box is greyed out.
in and notin: on this screen these take a single value, so they behave like = and !=. To accept one of several values, put each in its own group.
between: cannot be saved from this screen. Use two conditions in one group instead, for example >= 14 and <= 17.

Three answers, not two

A rule answers match, do not or cannot be decided. "Cannot be decided" happens when the field is empty on that record, when the field name is not on the datastore at all, or when a value cannot be compared (text against a number, or a date not written year-month-day).

The rule does not decide what "cannot be decided" means: whatever asks it does. Compliance checks treat it as "yes, ask for this check", which is the safe reading for a safeguarding control. So a misspelt field in a rule behind a check does not let anybody through; it makes the check apply to everyone.

Creating a rule

Open Rules and click New rule.
Enter a Name people will recognise ("Parental consent applies") and a Key ("parental-consent-applies"). The key is what configuration refers to and never changes once saved; use lower-case letters, numbers, dashes and underscores.
Under When does this apply?, fill in the first condition. Use + condition to add more to the group, and × to remove one.
Check it against real records and save it as a draft, then publish it. See Checking and Publishing a Rule.

Rules the screen will not edit

A rule can be stored with "not" or with groups inside groups (for example, one supplied with a product). The screen shows such a rule as it is stored, with a notice that it is more deeply nested than the screen edits, and does not let you change it, because flattening it would change its meaning.

Worked example

A work-experience scheme needs parental consent only for applicants under 18. The architect creates a rule named "Parental consent applies" with the key parental-consent-applies and one condition: ageatstart < 18, where ageatstart is a number field on the applications datastore. A second scheme also wants consent for anyone with declared support needs, so a second group is added with supportneeds isset. The rule now matches anyone under 18, or anyone with support needs recorded.

Recommendations

Name rules as the question they answer, so the list reads as a set of decisions.
Choose keys carefully; they cannot be renamed.
Compare numbers and dates, not formatted text, and store dates year-month-day.
Remember dropdowns store an ID, so compare against the ID, not the label.
Always check a rule against real records before publishing it.

Checking and Publishing a Rule

A mistyped rule does not raise an error: it silently matches nobody, or everybody. The Rules screen therefore lets you run a draft against real records before you save it, and keeps every version, so a rule is checked before anything relies on it and can always be traced back afterwards.

Where to find it

Architect Panel → Automation:

Rules — the list of rules, the editor, its preview and the Versions card

Checking a rule against real records

The Check it before you save it card sits under the conditions.

In Datastore, type the name of the datastore the rule will be asked about, for example applications.
Leave Field prefix blank for a rule used by compliance checks, which name fields directly.
Click Preview. The screen shows "Checking..." and then a line such as "Against 1,240 records: 212 match, 1,006 do not, 22 cannot be decided."

Read the extra notes it adds:

"Nothing matches." Almost always a field name that is not on this datastore, or a dropdown that stores an ID being compared with text.
"Most records cannot be decided." At least half the records have no usable value. Remember that a compliance check treats "cannot be decided" as "ask for the check", so all of those records will be asked.
"Not on that datastore: ..." lists field names in the rule that the datastore does not have. Fix the spelling, using the row name from the Fields list.

The preview reads up to 2,000 records and does not filter by organisation, so on a very large or multi-tenant datastore treat the numbers as a sample.

Saving and publishing

Click Save as draft. The message reads "Saved as draft version N. It is not in use until it is published." Saving never changes what is in use.
Go back with ← All rules and click Open on the rule. The Versions card lists every version with a published or draft badge.
Click Publish beside the version you want and confirm. From then on, anything asking for that key gets this version. Verdicts already recorded keep the version they were made under.

Every save writes a new version; nothing is edited in place. To change a published rule, open it, change the conditions, save a new draft and publish that. The list's In use column shows the published version (for example "v3"), or "draft only" for a rule that has never been published.

Platform rules and your own

On a multi-tenant system a rule can exist at platform level (shared by every organisation) and as an organisation's own version with the same key. When an organisation has its own published version, that one wins. You can only save and publish your own organisation's versions; trying to publish a platform version reports "No such ruleset version."

What goes wrong and how to tell

"Asked for but not here." at the foot of the list: a compliance check names a rule key that does not exist. Create the rule with exactly that key.
A draft-only rule is treated as missing. Until a version is published, anything asking for the key gets "cannot be decided", so a compliance check behind it is asked of everyone.
"This rule is not valid": usually a between condition, which this screen cannot save. Use two conditions instead.
"A key is required" or "Give it a name somebody else will recognise.": fill in Key and Name.
An error window and the preview stuck on "Checking...": the datastore name was wrong ("There is no datastore called ..."). Correct it and click Preview again.
Edits made outside this screen: the Rulesets datastore is also visible under Data → Datastores, but editing a row there bypasses every check described here. Use the Rules screen.

Worked example

An architect writes "Parental consent applies" as ageatstart < 18 and previews it against applications: "Against 640 records: 0 match, 0 do not, 640 cannot be decided", with "Not on that datastore: ageatstart". The field is actually called agestart. They correct it and preview again: 96 match, 538 do not, 6 cannot be decided. The six have no start date yet, and since the consent check will be asked of them anyway, that is acceptable. They save version 1 as a draft, open the rule and publish it.

Recommendations

Preview every draft, even a one-line change.
Investigate a large "cannot be decided" count before publishing.
Publish deliberately; a saved draft does nothing until then.
Keep rule edits on the Rules screen, never in the raw datastore.

Compliance Checks

Compliance checks are the things that must be done before a record can go ahead: a signed parental consent, an in-date insurance certificate, a declaration. You define each kind of check once, say which records it applies to, and the platform lists the checks on every record that needs them and holds the approval stage until they are met.

Where to find it

Architect Panel → Data:

Datastores — the Requirement Types datastore, where each kind of check is defined

Architect Panel → Automation:

Rules — the rules that decide which records a check applies to

How the pieces fit

A requirement type describes one kind of check and what proves it.
A rule (optional) decides which records it applies to.
A user input view stage with the Require Compliance stage action works out which checks each record needs when it reaches that stage, and holds the stage until they are met. Setting up the stage is covered in User Input Views.
The Checks pane on the record lists each check and is where evidence is recorded. See The Checks Pane.

Nothing is supplied: the platform ships with no requirement types and no rules, because the checks belong to your organisation.

Defining a requirement type

Open the Requirement Types datastore and add a record. The fields are:

Key: a stable identifier, such as parental-consent.
Name: what people see, and what appears in the sentence that blocks progress. Write it as a thing to be done: "Parent/guardian consent".
Description: what the check is and why it is asked.
Applies To: the kind of record that carries it, for example application, placement, student or employer. It must match the value the stage uses, or the check is never asked.
Evidence: what proves it. See below.
Blocks Confirmation: on, and the stage cannot be approved until the check is met. Off, and the check is listed as optional and blocks nothing.
Applies When: the key of a rule. Blank means the check applies to every record of that kind.
Chase Clock: optionally, an obligation type key, so outstanding checks are chased like any other deadline. See Obligations & Deadlines.
Valid For: for declarations only, how long one lasts, written calmonths:12, caldays:30 or hours:48.
Enabled and Order: switch a type off without deleting it, and set the order checks are listed in.

The kinds of evidence

document: met by an approved, in-date controlled document. Its expiry comes from the document. See Document Control.
consent: met by a signature request that every signer has completed. See Electronic Signatures.
declaration: met when somebody with edit rights records it as done. The weakest kind, so use it only where nothing better exists.
assessment and verification: offered by the field, but not currently usable, because no assessment or verification can yet satisfy a check. Do not choose them.

How "Applies When" behaves

When a record reaches the stage, each type's rule is asked about that record's own fields. If the rule matches, or cannot decide (an empty field, a missing rule, a rule never published), the check is asked for. That is deliberate: for a safeguarding control, asking too often is the safe mistake. The Rules screen shows "Asked for but not here." when a type names a rule key that does not exist.

Which checks apply is worked out when the record reaches the stage. Changing a rule later does not add or remove checks on records already past that point.

What goes wrong and how to tell

The stage approves with no checks listed: no enabled type has an Applies To matching the stage's "This Record Is A" value.
Everybody is asked for a check meant for a few: the Applies When rule is missing, draft only, or cannot decide (check it with Preview on the Rules screen).
No chase clock opens: check your first test record; leave Chase Clock blank if you do not use obligations.

Worked example

A work-experience scheme needs parent/guardian consent from applicants under 18, and an in-date employer's liability certificate for every placement. The architect publishes a rule parental-consent-applies (ageatstart < 18), then adds two requirement types: "Parent/guardian consent" (Applies To application, Evidence consent, Blocks Confirmation on, Applies When parental-consent-applies) and "Employer's liability insurance" (Applies To placement, Evidence document, Blocks Confirmation on). The confirmation stage of the application form is set to Require Compliance for the application, also checking the linked placement. A 16-year-old's application now waits for both; a 19-year-old's waits only for the insurance.

Recommendations

Publish and preview the rule first, then name it in Applies When.
Use Blocks Confirmation only for genuine controls; leave the rest optional.
Prefer document or consent evidence to declarations.
Test with one record of each kind before going live.

The Checks Pane

The Checks pane appears on a record's screen once compliance checks have been worked out for it. It shows which checks are done and which are still needed, and it is where staff record the evidence, or set a check aside with a reason, so the approval stage can go ahead.

Where to find it

There is no panel tile. The pane appears on the record screen of any record that carries checks, which happens when the record reaches a user input view stage set to Require Compliance (see User Input Views). The kinds of check are defined in the Requirement Types datastore:

Architect Panel → Data:

Datastores — Requirement Types, and the Requirements datastore that records each check's status

Reading the pane

The heading line says either "Everything required has been completed." or how many items are still needed before the record can go ahead. Each check shows its name and a badge:

Done: evidence is in place. Where the evidence expires, "until" and the date follow.
Outstanding: nobody has done this yet.
Expired: it was done, but the evidence has run out and must be renewed.
Set aside: somebody overrode the check, with a recorded reason.

Checks that do not block the stage are marked "(optional)". Checks that no longer apply to the record are hidden.

Recording evidence

People with Edit Existing permission on the record's datastore see controls under each check that is not yet done.

For a document check, enter the controlled document's number in Document ID and click Attach. It counts once the document is approved and while it is in date.
For a consent check, enter the number in Signature request ID and click Attach. It counts when every signer has signed.
For a declaration, click Record as done. Its expiry comes from the requirement type's Valid For setting.

"Evidence attached and this check is now met." means it is done. "Evidence attached, but this check is still outstanding" means the reference was found but does not count yet: an unapproved or out-of-date document, or a signature that is not complete. The check updates by itself once it does count.

Setting a check aside

Sometimes a check genuinely does not apply to one record. Type the reason in Set aside because and click Set aside, then confirm. The confirmation warns that this overrides a safeguarding control and that your name and reason are recorded. A reason is required. People without edit rights see "Set aside:" followed by the reason.

How the stage uses it

While any blocking check is outstanding or expired, the approver's actions on the stage are withdrawn, and the approver sees which items must be completed (or renewed) first. When every blocking check is done or set aside, the stage can be approved as normal. If the checks cannot be read at all, the stage stays blocked and asks the user to contact an administrator; it never fails open.

What goes wrong and how to tell

"You do not have access to record evidence against this requirement.": you need Edit Existing on the record's datastore.
"This check is a declaration - use Record as done rather than attaching a reference.", or the reverse message for an evidenced check: use the control the check asks for.
"Enter the reference before attaching.": the ID box was empty.
A set-aside check stays set aside after evidence is attached: by design, a set-aside check is not re-evaluated.
The pane is missing: the record has not reached a Require Compliance stage, or no requirement type applied to it.

Worked example

A 16-year-old's work-experience application reaches the confirmation stage. The Checks pane shows "2 items are still needed before this can go ahead": Parent/guardian consent and Employer's liability insurance, both Outstanding. The co-ordinator sends the consent form for e-signature and attaches its signature request number; it shows "still outstanding" until the parent signs, then turns to Done. They attach the employer's approved insurance certificate by document number, which shows Done until its expiry date. The stage's approve button appears, and the placement is confirmed.

Recommendations

Attach evidence as soon as it exists; it counts automatically once approved or signed.
Set aside sparingly, and write a reason someone will understand in a year.
Grant Edit Existing only to the people who verify evidence.
Watch for Expired: renewed evidence is a new document or signature, not an edit.