Role Bar and policy
Author, version, preview, and adopt the screening policy that maps CETS recommendations to verdicts across your workspace.
Role Bar and policy
The Role Bar is the workspace's versioned, scoped screening policy. It is the authoritative answer to "what is good enough?" — the rules that map a candidate's analysis into a verdict, with the option to apply the verdict unattended.
This page covers what the policy is, how to author it, and how to preview and adopt a new version.
Why a versioned policy
A bar nobody can see is a bar that becomes folklore — which is the exact problem the versioned policy was built to fix. A few properties make it useful:
- Versioned — every adoption creates a new version. Past decisions keep the bar they were made under, so "why was this candidate rejected in March" is answerable.
- Scoped — a policy applies at one of three scopes: the whole organisation, one role, or one assessment. The narrowest scope that still makes sense wins.
- Authored once, applied many times — define the bar, then either review against it manually or let automation apply it.
- Honest about automation — a verdict that the policy decided is recorded with
source: POLICYand thepolicyVersionId, so it cannot be confused with a human judgement.
What the policy controls
| Section | What it is |
|---|---|
| Required evidence | Which of (score, CETS, video, integrity) must be present before a candidate is judged. |
| Recommendation mapping | Each of the six CETS buckets mapped to a screening verdict (CLEAR, REVIEW, or REJECT). |
| Flag disposition | Each integrity flag set to DISQUALIFY (reject on its own), ESCALATE (send to a person), or INFORM (shown, changes nothing). |
| Thresholds | The probability, natural-evolution, and low-score cut-offs. |
| Automation | Whether the policy may auto-clear and / or auto-reject candidates. |
| Fallback verdict | What happens when the policy cannot settle. Fixed to REVIEW — ambiguity resolves to a human, never to a pass. |
Scopes
| Scope | When to use |
|---|---|
ORGANIZATION | The default. The bar applies to every role and assessment in the workspace. |
ROLE | Override the organisation bar for one role title (e.g. "Senior Backend Engineer"). |
ASSESSMENT | Override for one specific assessment. |
The narrowest scope that still makes sense wins. An assessment-scope bar is the most specific; the platform walks up the scope chain until it finds a version in force.
Authoring a policy
- Open Screening → Scorecard (admin only).
- Choose a scope and (if applicable) a scope key.
- The form is seeded with the in-force definition, or the built-in default if there is no version in force yet.
- Edit the sections you want to change. Other fields round-trip untouched.
- Read the plain-English summary at the bottom of the page. If the sentence is odd, the configuration is usually wrong.
- Click Preview impact to see how the proposed bar would re-judge existing
candidates. The preview shows counts of changed verdicts, transitions keyed
BEFORE->AFTER, and a separate count of candidates who would newly be rejected — flagged on its own because that is the number that should stop someone adopting a bar. - When you are ready, click Save new version. A new version is created and the previous version is marked superseded. Past decisions keep the bar they were made under.
What the policy will not do
A few rules are enforced by the platform and the UI makes them visible:
- Integrity flags may never reject on their own. Probabilistic model outputs
(
llm_assisted,bulk_paste,transcription,phone_detected,tab_switch,multiple_faces) are suspicions, not proof. The platform refusesDISQUALIFYfor these flags. The UI does not offer it. - Automation never decides an integrity concern. Even when the policy is allowed to auto-clear or auto-reject, the policy will not act on a flag in the integrity-fraud set.
- Ambiguity resolves to a human. The fallback verdict is fixed to
REVIEW.
History and supersession
Open the policy's history to see every version for the scope, newest first. Each version records:
- The scope and scope key
- The label and notes
- The definition (the full set of rules)
- The user who created it, and when
- The version it supersedes (if any)
A superseded version is not editable. New versions are the only way to change a bar.
Read the plain-English summary
The summary at the bottom of the author page renders the form as a sentence. It deliberately states inert settings (e.g. "All are shown for information only") rather than omitting them, because an omission would read as the setting being absent rather than inert.
Common errors and what they mean
| Error | What it means | What to do |
|---|---|---|
TENANT_UNRESOLVED | Your sign-in does not carry an organisation we can derive one from. | Account setup problem. Ask an admin to set the organisation and reload. |
POLICY_INVALID | One or more rules are not valid. | The platform returns the failing rules in the error details. Correct them and preview again. |
POLICY_SCOPE_KEY_REQUIRED | You picked a scope narrower than the whole organisation, so it needs a key. | Select a role (or switch back to organisation) and try again. |
UNAUTHORIZED | The session is no longer valid. | Reload to sign in again. |
403 | You can read and preview a bar, but adopting a new version is admin-only. | Ask an admin to adopt it, or use Preview impact to show them what it would do. |
5xx | The policy system is unavailable. | Try again in a moment. If it persists, the service may need attention. |