What DataBridge does — and how to use each part.

Why it matters

It is the procurement story: provable, defensible data quality you can show an auditor, a registrar or a governance committee. Each rule cites its published source, so findings are not opinions.

How to use it

1. 1.Open Audits to see every audit run with its rule families and finding counts.
2. 2.Open a run to read the rules that executed and the violations they found.
3. 3.Hand the findings to Repairs, or sign them off — every step is hash-chained.

Why it matters

Turns thousands of individual findings into one Data Health Picture leadership can read at a glance, and shows how you compare to the sector benchmark.

How to use it

1. 1.Open Data quality to see the six-dimension scorecard for the demo institution.
2. 2.Drill into any dimension or entity to see the findings behind the score.
3. 3.Watch the benchmark overlay to see where you sit against the UCISA reference.

Why it matters

Finding bad data is only half the job. Repairs closes the loop with safe, explainable remediation you can review before anything changes.

How to use it

1. 1.Open Repairs to see the proposed fixes queued from the latest audit.
2. 2.Read a proposal's justification and its undo statement before acting.
3. 3.Mark a repair applied — the status flips in your demo session.

Why it matters

Before a migration or a return you need to know which records are the same person. Reconciliation makes the overlaps and gaps explicit instead of guessed.

How to use it

1. 1.Open Reconciliation to see the match runs across the demo systems.
2. 2.Open a run to see matched / only-in-A / only-in-B counts and conflicts.
3. 3.Use the result to decide which records collapse before you migrate or submit.

Why it matters

Source systems change quietly. Drift detection tells you a feed looks different from yesterday before that difference breaks a return.

How to use it

1. 1.Open Drift to see the latest schema- and value-drift findings with severity chips.
2. 2.Open Drift history to walk every capture over time.
3. 3.Note that escalations are written to the audit log for the record.

Why it matters

When a number in a return is questioned, lineage answers 'where did this come from?' in one view — the difference between defending a figure and re-deriving it by hand.

How to use it

1. 1.Open Lineage to pick a record from the demo institution.
2. 2.Follow the chain from source through canonical entity to the submission it feeds.
3. 3.Inspect the Quality-Rule outcomes attached at each hop.

Why it matters

Real returns ship with explained exceptions. Waivers keep those exceptions auditable instead of invisible — every waiver is part of the tamper-evident trail.

How to use it

1. 1.Open Waivers to see the waiver audit trail for the demo institution.
2. 2.Create a waiver against a finding with a reason — it appears immediately.
3. 3.Note the entry is recorded in your demo session (not a real backend write).

Why it matters

Repairs proposes a fix; Remediation governs it. Approvals, idempotent apply, automatic verification and one-click rollback mean fixing data is itself controlled, measured and audited — not a risky manual edit.

How to use it

1. 1.Open Remediation to see the case queue with each case's lifecycle status.
2. 2.Open a case to read its timeline — proposed, approved, applied, verified.
3. 3.Watch the metrics and alert panels track throughput and SLA breaches.

Why it matters

A coded field is only valid against its published codeset. These are the cited reference the audit checks against, so a CODESET finding is defensible rather than an opinion.

How to use it

1. 1.Open Codesets to see every registered codeset and translation map.
2. 2.Open a codeset card to read its valid entries and how many values it holds.
3. 3.Note which ship as a representative subset versus the full published list.

Why it matters

HESA is the UK sector return every provider must file. DataBridge takes it from raw extract through Quality-Rule clearance to tamper-evident sign-off in one place.

How to use it

1. 1.Open HESA to see all seven streams and their submission status.
2. 2.Open a submission to read its Quality-Rule findings and year-on-year deltas.
3. 3.Sign it off — the submittable status flips once CRITICAL findings clear (in-session).

Why it matters

These ship alongside HESA. Each builder emits a CSV plus a SHA-256 manifest, so what an institution uploads to each portal is provable byte-for-byte.

How to use it

1. 1.Open Sector returns to see each builder with its cycle, cadence and rule coverage.
2. 2.Review a return's columns and audit-rule count before you build.
3. 3.Build the portal bundle (CSV + manifest) for the operator to upload.

Why it matters

One codebase, two jurisdictions: an AU operator gets the same cited-rule audit, repair and submission-ready-packet story a UK operator gets, through the right gateway (PRODA for TCSI).

How to use it

1. 1.Open the OfS Regulatory Advice builder to see the jurisdiction-aware return engine in action.
2. 2.Compare its shape to the UK HESA console — the same lifecycle, a different jurisdiction's rules.
3. 3.Read How it works for the full UK + AU jurisdiction story.

Why it matters

The OfS RA return is high-stakes and disclosure-sensitive. The builder applies suppression automatically so you do not publish a re-identifiable small cohort.

How to use it

1. 1.Open OfS RA to see Tables 1–5 generated from the demo institution's canonical data.
2. 2.Check the small-number suppression applied to low-count cells.
3. 3.Export the bundle when the tables read clean.

Why it matters

Statutory returns are deadline-driven and the dates move. The cycle tracker turns a wall of regulator dates into one countdown you can plan against.

How to use it

1. 1.Open Cycles to see the next HESA deadline and its days-to-due.
2. 2.Read the full table of scheduled windows with their status colours.
3. 3.Check AU Cycles for the parallel TCSI / PRISMS calendar.

Why it matters

International-student reporting to PRISMS is a hard compliance obligation. The log makes every submission and its accept / reject outcome visible, with the error shown inline when one is rejected.

How to use it

1. 1.Open AU PRISMS to see total submitted, accepted and rejected counts.
2. 2.Scan the State column for rejected rows and read the error message inline.
3. 3.Cross-reference the AU Cycles calendar for the reporting deadlines.

Why it matters

A single return is a snapshot; the multi-cycle view is the trend. It answers 'are we getting better year on year, and what regressed?' — the question a governance committee actually asks.

How to use it

1. 1.Open Multi-cycle to see the per-cycle finding trend bars.
2. 2.Read the cycle-over-cycle delta — new versus resolved versus persistent.
3. 3.Open a pairwise comparison to drill into the field-level diff.

Why it matters

Across six regulators 'are we ready to submit?' is otherwise six separate checks. This normalises them into one worst-of status so you know the whole portfolio's state at a glance.

How to use it

1. 1.Open Submission readiness to see the overall status and per-return cards.
2. 2.Open a blocked or warnings return to read the findings stopping it.
3. 3.Use Check your data to run a live readiness check on your own extract.

Why it matters

DataBridge reads your systems where they are — no migration required to start auditing. The map shows which entity flows where, its direction, freshness and health.

How to use it

1. 1.Open Adapters to see each connector and sample the data it returns.
2. 2.Open Integrations to see the system-of-record matrix and dependency graph.
3. 3.Use freshness and direction on the map to spot a stale or mis-wired feed.

Why it matters

Mapping is the slow, error-prone part of any integration or migration. The mapper gives you a reviewed starting point grounded in the real dictionaries.

How to use it

1. 1.Open Schema mapper and pick a source and a target dictionary.
2. 2.Review the proposed field mappings and their confidence.
3. 3.Accept or adjust mappings — your choices persist in the demo session.

Why it matters

You can't audit or migrate what you can't see. The estate map and SOR matrix make 'which system owns Student?' and 'is any feed unhealthy?' answerable in one view.

How to use it

1. 1.Open Integrations to see the systems, the dependency graph and health counts.
2. 2.Tap a node to open that system's detail.
3. 3.Read the SOR matrix to see which system is master (M) versus replica (r) for each entity.

Why it matters

A profile is what makes DataBridge understand a given system out of the box. It is the difference between 'configure everything' and 'point it at SITS and go'.

How to use it

1. 1.Open Profiles to see every supported system and its status.
2. 2.Read a card for its target system, rule-pack count and package name.
3. 3.See how profiles pair with Adapters — the profile is the knowledge, the adapter is the connection.

Why it matters

Returns and remediation don't happen in a vacuum — downstream systems need to know. Signed webhooks let your estate react to a sign-off automatically, with proof of delivery.

How to use it

1. 1.Open Webhooks to see whether a destination is configured (Live / Stub).
2. 2.Read the events emitted, the env vars that wire it and the retry logic.
3. 3.Approve a submission under HESA to fire one and watch it land in the history.

Why it matters

A dry-run shows exactly what would create, update or skip — writing nothing — so you cut over with evidence instead of hope, and every row carries its lineage.

How to use it

1. 1.Open Migrations to see the available migration pairs and their policies.
2. 2.Run the Dry-run to see row-level diffs and provenance — nothing is written.
3. 3.Review the parallel-run verifier to confirm source and target agree.

Why it matters

A dry-run shows what one pipeline would do; the parallel-run verifier proves the new pipeline agrees with the old one before you trust it in production. It is the cutover sign-off.

How to use it

1. 1.Open Parallel-run verifier to see the overall Data Health Picture agreement.
2. 2.Read the per-entity agreement table for missing-in-A / missing-in-B counts.
3. 3.Scan the field-level divergences to decide if the differences are acceptable.

Why it matters

Erasure is a legal obligation with a compliance trail. Doing it inside the platform keeps the proof — what, when, by whom — alongside everything else.

How to use it

1. 1.Open Right to erasure to see the erasure requests for the demo institution.
2. 2.Open a request to see the records in scope across systems.
3. 3.Action the request — the outcome is recorded in your demo session.

Why it matters

Audit and returns are the procurement story; metrics are the operations story. They tell you the platform is healthy and which connector is slow.

How to use it

1. 1.Open Metrics to see per-adapter performance and pipeline health.
2. 2.Read the throughput and latency panels for the demo estate.
3. 3.Use them to spot a degraded connector before it affects a return.

Why it matters

The integrity proof underneath everything else. If a single entry were altered, the chain would break — that is what makes the data-quality story defensible.

How to use it

1. 1.Open Audit log to see the chained entries for every action taken.
2. 2.Verify the chain in-browser to confirm nothing has been tampered with.
3. 3.Filter by action type to trace a specific audit, repair or sign-off.

Why it matters

Not every question has a dashboard. Query lets an operator interrogate the canonical entities directly when something specific needs checking.

How to use it

1. 1.Open Query and run one of the example queries against the demo data.
2. 2.Adjust it to ask your own question of the canonical entities.
3. 3.Read the results inline — no external SQL client needed.

Why it matters

The audit engine is extensible. The marketplace is how a provider turns on the rule families relevant to its jurisdiction and obligations.

How to use it

1. 1.Open the Rule-pack marketplace to see every registered pack and its metadata.
2. 2.Toggle a pack on or off for the demo tenant — the state updates immediately.
3. 3.Note the change applies to your demo session (not a real backend write).

Why it matters

It shows the platform is genuinely multi-tenant: two institutions, one deployment, zero data crossing between them — the isolation a real sector deployment depends on.

How to use it

1. 1.Open Demo institutions to compare students, staff, faculties and source systems side by side.
2. 2.Open a pilot card to drill into that institution's full profile.
3. 3.Note the tenant isolation — no figure on one side leaks to the other.

Why it matters

It lowers the floor for a new operator: you do not have to know which rule or runbook to read — ask, and get a grounded, cited answer.

How to use it

1. 1.Open the AI Assistant and ask a question about the demo institution's data.
2. 2.Read the answer and follow its citations into the underlying docs.
3. 3.Ask a follow-up — the conversation runs in your demo session.

Why it matters

It sets expectations honestly: what you can do free (everything, against synthetic data) versus what shipping live returns and running real integrations needs.

How to use it

1. 1.Open Pricing to compare the three tiers feature by feature.
2. 2.Read the FAQ on what Free, Pro and Enterprise each include.
3. 3.Note that this open demo already runs as Enterprise, so you can try everything.

Why it matters

It is the path from demo to live: the same platform you are exploring, provisioned as a real tenant when you are ready to ship.

How to use it

1. 1.Open Billing to see your current tier and the upgrade options.
2. 2.Read 'what happens after you pay' for the provisioning steps.
3. 3.Note that in this demo nothing is charged — it shows the real upgrade flow.