Competence. One of the three C's. Live in FIELD.

Competence Management Software That Answers the Question When It Is Asked

"Who did this work, and what qualified them?" The Building Safety Act makes that a question every dutyholder has to answer. XO Comp is the competency register for the people on your projects: one versioned requirement set per framework, role and risk level, eligibility evaluated before an assessment is created, overrides on the record, and card numbers that never enter your systems.

Questions the register has to answer
Is this person eligible for this assessment?

Evaluated at a point in time: allow, warn or block, with a reason code and an as-of date

Where is the card number?

Not in BrieXO. A hash and an encrypted lookup payload, with every check attempt logged

Which requirement set was this assessed against?

Framework version 3, the version in force on the day, still attached to the assessment

Card numbers never stored

Competence Management Software Built for the Competence Duty

Under the Building Safety Act, individuals must have the skills, knowledge, experience and behaviours their role requires, and dutyholders must not appoint anyone who does not. That turns competence from something you assert into something you have to show, against a defined requirement, on a given date.

Most contractors track it in a spreadsheet per role, a folder of scanned cards, and a calendar reminder somebody set two years ago. Nobody finds out a requirement lapsed until someone asks at the worst moment. XO Comp replaces that stack with one competency register: a versioned requirement model, a per-person scope with a lifecycle, and an eligibility evaluation that runs before the assessment, not after the question.

BrieXO supports your competence duties; it does not discharge them.

Card Checks That Never Store the Card Number

Every construction business holds a spreadsheet of CSCS-style card numbers somewhere, and every one of them is a data-protection liability waiting for a lost laptop. XO Comp is built so that the number never enters your systems.

When a card is recorded, XO Comp stores a hash and an encrypted lookup payload, not the number. Every check attempt is written to an audit trail. The check happens; the number never lands. If your systems are ever compromised, there is no list of card numbers to take.

  • Card credentials held as a hash plus an encrypted lookup payload
  • Every check attempt logged, with its outcome
  • Nothing to export, copy or lose, because the number is not there
Recording a card in XO Comp
You enter
Card number, scheme, recorded expiry
XO Comp keeps
card_hash, encrypted lookup payload
XO Comp discards
the card number
Every check attempt
logged: who, when, outcome

Eligibility Evaluated Before the Assessment, Not After the Question

Somebody was assessed who should not have been. It happens because the check comes after the fact. In XO Comp, the eligibility evaluation runs before an assessment can be created at all.

Allow

The person's scope, lifecycle status and risk tier meet the requirement set on the as-of date. The assessment proceeds, and the evaluation is recorded with its reason code.

Warn

Something needs a human decision. The assessment is refused until the warning is explicitly acknowledged, and that acknowledgement is written as an event: who overrode it, and when.

Block

The result is blocking. The assessment is refused outright, with a reason code. There is no setting that turns this off within XO Comp's own assessment route.

"You can override it. You cannot override it quietly."

The exception is deliberate, and it is on the record.

One Versioned Requirement Model Instead of a Spreadsheet Per Role

Requirements differ by role and by risk, and they change. A spreadsheet per role cannot cope with either. XO Comp holds one requirement model and versions it.

Frameworks, role profiles, function requirements

A competency framework defines the items. Role profiles say which functions a role must cover. Function requirements say what evidence each function needs. One model, read the same way by everyone who assigns work.

Policy that resolves scope, then risk preset, then organisation

A high-risk cohort can carry stricter validity and coverage rules without reconfiguring everyone. Policy resolves from the person's scope to the risk preset to the organisation default, so the exception is local and the rule stays global.

Versions that keep the history

When the requirement set changes, a new framework version is created. Old assessments stay attached to the version they were made against. You can change the rules without rewriting what was true when someone was assessed.

A lifecycle that moves on schedule

Each person's scope carries a lifecycle status and a recorded expiry. Lifecycle scheduling moves people through expiring and expired states on those dates, so the register shows who is approaching a lapse before the lapse, not after. Training records from an external provider can be ingested through XO Integrations, so the register does not depend on re-keying.

What XO Comp Does Not Do

Competence software is sold on words like verified, tamper-proof and enforced. We would rather you knew exactly what the register holds before you rely on it.

It records the details of evidence. It does not store the certificate file.

A competency record in XO Comp holds what the evidence is, who it relates to and its recorded expiry. There is no certificate upload. A document held in XO Docs can be referenced from the record.

It records claims about competence. It does not verify them.

XO Comp does not contact card schemes, awarding bodies or training providers to confirm a credential. A recorded expiry is the date the person recording the decision typed in, not a date derived from the issuer. What the register gives you is a consistent, versioned, dated record of what was claimed and what was decided.

It refuses an assessment. It does not stop work.

The eligibility evaluation gates XO Comp's own assessment route. It does not, by default, prevent a person being assigned to a task or a shift elsewhere in BrieXO. If you need that, it is a configuration conversation, not something this page promises.

It holds competence against the person, not the element.

XO Comp does not carry a project or location reference. Which projects a person's competence is relevant to is derived from their project membership, not stored as a competency-by-zone record. Site records and photo evidence are anchored to the building in XO Field; competence is anchored to the person.

Decisions can be edited. We do not call them tamper-proof.

A validation decision can be changed or removed by someone with the right permission. Framework versions preserve which requirement set an assessment was made against, but the decision itself is not immutable, and this page does not describe it as such.

Last capability review: 10 Sep 2026, against the XO Comp claims register.

Competence Management Software: Questions We Get Asked

Straight answers, including the ones that are not a yes.

Does XO Comp store CSCS or other card numbers?

No. When a card is recorded, XO Comp stores a hash and an encrypted lookup payload, never the number itself. Every check attempt is logged with its outcome. If your systems were compromised there would be no list of card numbers to take.

Can we upload competency certificates?

No. XO Comp records the details of the evidence (what it is, who it relates to, its recorded expiry) but does not store the certificate file. A document held in XO Docs can be referenced from the record.

Does XO Comp stop someone working if their card has lapsed?

Not by default. XO Comp evaluates eligibility before an assessment is created in its own assessment route, and refuses the assessment when the result is blocking. It does not, on its own, prevent a person being assigned work elsewhere in BrieXO. Say the word if you need that and we will talk through configuration honestly.

Where do recorded expiry dates come from?

They are entered by the person recording the decision. XO Comp does not fetch them from card schemes or awarding bodies. We therefore describe them as the recorded expiry, and lifecycle scheduling moves a person through expiring and expired states on those recorded dates.

Can a competency decision be changed after the fact?

Yes, by someone with the right permission. Framework versions preserve which requirement set an assessment was made against, but the decision record itself is editable and we do not describe it as tamper-proof.

What does the eligibility evaluation actually check?

At a point in time, against the versioned requirement set, it evaluates the person's scope, lifecycle status and risk tier and returns allow, warn or block with a reason code and an as-of date. Block is refused. Warn is refused until explicitly acknowledged, and the acknowledgement is recorded as an event.

Can requirements differ by role or risk level?

Yes. Frameworks carry role profiles and function requirements, and policy resolves from the person's scope to a risk preset to the organisation default. A high-risk cohort can have stricter validity and coverage rules without changing everyone else.

Is XO Comp available today?

Yes. XO Comp is part of the BrieXO FIELD bundle, which is live, alongside XO Field, XO Capture, XO Prog and XO Time.

Ready to Answer "What Qualified Them"?

XO Comp is live today in the BrieXO FIELD bundle, alongside site records, photo evidence, programme and time. See a requirement set, an eligibility evaluation and a card record that never held the number.

Claims on this page are checked against the XO Comp claims register. BrieXO supports your competence duties under the Building Safety Act; it does not discharge them.