Skip to main content
Pillar

Govern

Govern is the policy envelope the other three pillars operate inside. Sector posture, consent, sign-off, fairness monitoring, instrument health, audit, and the SFIA reference. Day-to-day report production is Understand; recommending what to do next is Grow. Govern is the rails, not the train.

The Govern overview — sign-off queue, contests, fairness monitoring, defensibility, sector posture, audit log

The Govern overview — sign-off queue, contests, fairness monitoring, defensibility, sector posture, audit log
The Govern pillar overview gathers the policy and accountability surfaces — queues, fairness, defensibility, audit, and consent.

What this pillar is for

The work in Govern is keeping the platform accountable to the people it measures and to the regulators it answers to — not producing reports. A practitioner who knows which pillar a task belongs to almost never confuses Govern with Understand: reading a report is reading; signing it off is governing. The surfaces in this pillar are deliberately separated from the day-to-day work so that the discipline of accountability isn't dissolved into the discipline of measurement.

Govern is where the platform answers an auditor. The audit log is hash-chained; the consent ledger is per-grant; the AI provenance ledger records the lineage of every AI-derived artefact; the counterfactual audit shows the cases where a rating would have moved had a demographic attribute been different. The defensibility bundle pulls all of this together into a single artefact a tribunal or a regulator can read.

Govern is also where Trust & Safety owners arrive. The T&S landing is shaped around five questions — is the platform operating, are people being treated fairly, is consent being respected, are appeals being heard, is anything anomalous right now. Five questions, five tiles, one click to drill in. T&S does not need to know what a SFIA skill code is to do the work this pillar surfaces.

What sits here

Sign-off queue

Reports awaiting expert sign-off, with reviewer routing and SLAs.

Sign-off is the moment a report leaves the working state and becomes a defensible artefact. The queue routes each report to the right reviewer, surfaces the evidence bundle and decision history, and locks the report's content into the audit trail at the moment of approval.

Sign-off is not a rubber stamp. The reviewer can request changes, return the report to the assessor, or escalate to an integration session if the dissent is material. The platform tracks the SLA; signed-off reports carry the reviewer's identity, the timestamp, and the hash.

Sign-off queue — Reports awaiting expert sign-off, with reviewer routing and SLAs.

Sign-off queue — Reports awaiting expert sign-off, with reviewer routing and SLAs.

Contests

Participant disagreement with a rating.

A contest is the participant's formal disagreement with a rating. The contest surface presents the participant's position, the evidence the rating sat on, the AI's rationale, and the practitioner's decision history. The practitioner can adjust the rating, hold it with reasons, or escalate to integration.

Contests are visible to the participant from any participant surface — one-click reach. The platform's posture is that the right to push back is part of the rating's defensibility, not separate from it.

Contests — Participant disagreement with a rating.

Contests — Participant disagreement with a rating.

Corrections

Factual fix to the participant's record.

Corrections are different from contests. A correction is a factual fix — name spelled wrong, transcript misattributed, the wrong example linked to a rating. The pathway is lighter than a contest because the question is not whether the rating is right; it is whether the record is accurate.

Every correction is logged. The original is preserved alongside the corrected version; the audit trail makes clear what changed and why.

Corrections — Factual fix to the participant's record.

Corrections — Factual fix to the participant's record.

Reassessment requests

Participant asking for a fresh measurement.

A reassessment is the participant asking for a fresh measurement, usually because circumstances have changed — new experience, new responsibilities, a contest that was upheld. The platform routes the request to the practitioner queue and surfaces the original rating alongside.

Approved reassessments return to Measure; rejected reassessments carry the reasoning back to the participant. The decision is logged either way.

Reassessment requests — Participant asking for a fresh measurement.

Reassessment requests — Participant asking for a fresh measurement.

Fairness monitoring

Per-attribute disparate impact, equalised odds, calibration, counterfactual.

The fairness surface watches the platform's behaviour across demographic attributes — disparate impact at the four-fifths rule, equalised odds across true-positive and false-positive rates, calibration against the underlying distribution, and counterfactual fairness through attribute-swap audits.

Each metric ships with an anchored plain-language band — typical, worth a look, investigate — and a one-paragraph explanation of what causes drift. The platform's posture is fairness as a posture pointed at itself, not at the practitioner. Alerts route into an open-investigation surface with a recommended response.

Fairness monitoring — Per-attribute disparate impact, equalised odds, calibration, counterfactual.

Fairness monitoring — Per-attribute disparate impact, equalised odds, calibration, counterfactual.

Instrument health

Drift, bias, and reliability indicators per instrument.

Instrument health watches every instrument the platform runs — how often the reliability flag is firing, how the score distribution compares to the norm, whether the rate of contested ratings is moving. The surface is the platform's self-check on the tools it is asking practitioners to trust.

When an instrument starts behaving differently, the platform names it. The default response is conservative — a flag, a quarantine, an investigation — not silent recalibration. Practitioners need to know when a familiar instrument has shifted.

Instrument health — Drift, bias, and reliability indicators per instrument.

Instrument health — Drift, bias, and reliability indicators per instrument.

Sector posture

The sector overlay applied to the deployment.

Seven sector packs flex tone, palette, distress thresholds, consent shape, audit posture, and example phrasings — government (Australian and international), corporate, community, healthcare, education, finance. The Indigenous-led overlay adds Acknowledgement of Country, relational pacing, and additional cultural primitives.

Sector posture is one choice per deployment. The setting flows through every other surface — the welcome the participant sees, the consent layers, the safety thresholds, the audit-ready posture of defensibility bundles. Practitioners do not author sector copy ad hoc; the pack is platform-managed.

Sector posture — The sector overlay applied to the deployment.

Sector posture — The sector overlay applied to the deployment.

Defensibility bundles

The artefact a tribunal, regulator, or board will read.

The defensibility surface ships two shapes. Quarterly assurance bundles aggregate a period's measurement — evidence trails, ratings, AI provenance, validation, sign-offs, consent, policy versions, contest history — into an auditor-ready document. Case-specific bundles pull the same shape down to one decision, for the cases where a tribunal or a regulator is asking about a specific assessment.

The bundle is the platform's answer to "prove it." It is built to be exported, signed, and handed across; the format is stable quarter-on-quarter so external readers learn the shape.

Defensibility bundles — The artefact a tribunal, regulator, or board will read.

Defensibility bundles — The artefact a tribunal, regulator, or board will read.

Audit log

A hash-chain record of consequential actions.

Every consequential action — consent change, role change, programme state transition, sign-off, key admin move — lands in the audit log. Entries are hash-chained so any post-hoc edit is detectable; the log is filterable, exportable, and retained for the period the organisation's policy specifies.

The audit log is not marketing language. It is the artefact an internal auditor or an external regulator reads when they want to know what actually happened, in what order, by whom.

Audit log — A hash-chain record of consequential actions.

Audit log — A hash-chain record of consequential actions.

AI provenance ledger

Coming soon

Lineage record for every AI-derived artefact.

Every AI-derived artefact — an extracted skill, a rating suggestion, a draft report paragraph, a recommendation — has a row in the provenance ledger. The row names the input the model saw, the model family that produced the output, the surface that consumed it, and any human edit downstream.

Provenance is a posture, not a footnote. The platform's intent is that any AI output is contestable on the evidence in the ledger, not on impression. Every reference to an AI-derived artefact in the platform links to its provenance row.

AI provenance ledger — Lineage record for every AI-derived artefact.

AI provenance ledger — Lineage record for every AI-derived artefact.

Counterfactual audit

Re-run an evidence bundle with one attribute changed.

The counterfactual audit takes an evidence bundle, swaps a demographic attribute, and re-runs the rating. The surface reports the cases where the rating moves. A rating that moves under a counterfactual swap is the rating to look at — not the rating to defend.

Counterfactual audits ship on a routine cadence. The surface is built for cohort review, not for individual remediation. The platform's intent is to catch attribute-driven drift before it lands as a contest.

Counterfactual audit — Re-run an evidence bundle with one attribute changed.

Counterfactual audit — Re-run an evidence bundle with one attribute changed.

Consent ledger

Every consent grant in one auditable place.

The consent ledger records every grant — interview tokens, magic-link grants, programme enrolments, retention scope, passport sharing — with the surface that captured the consent, the version of the consent text, and the scope the participant agreed to.

Revocation is visible. A consent withdrawn by the participant is recorded with the timestamp; downstream surfaces respect the revocation immediately. The platform refuses to retain data outside the consented scope, and the ledger is the proof.

Consent ledger — Every consent grant in one auditable place.

Consent ledger — Every consent grant in one auditable place.

When to use which destination

Govern is the rails. If you know whose accountability the question lives in, you know which destination to open.

I'm setting up the platform for a new sector or organisation.
Open Sector posture and Organisation settings.
I need to sign off a report before release.
Open the Sign-off queue.
A participant disagrees with a finding.
Open Contests — or Corrections, if the question is a factual fix.
A participant has asked for a fresh measurement.
Open Reassessment requests.
I need to show an external auditor the platform is fair.
Open Fairness monitoring and Defensibility reports.
I'm checking that instruments are still behaving correctly.
Open Instrument health.
I'm an individual checking my rights, inbox, or email settings.
Open Rights & choices, Inbox, or Email preferences.

How this pillar connects to the other three

Govern sits across Measure, Understand, and Grow. Sector posture and the consent ledger shape what Measure can run; sign-off lives in Govern but the artefact being signed is what Understand produced; the consent that lets a development plan flow into an external personnel record is recorded here. When the loop closes — a contest upheld, a reassessment approved — Govern is the surface where that closure is recorded, before the work returns to Measure for a fresh session.

See it live

We'll walk you through the surfaces above on a deployment that matches your sector.