The end-to-end story
Audit → repair → build returns → submit → prove, in five minutes.
By the end you’ll be able to
- Follow the platform's end-to-end workflow from raw source to submitted return.
- See where each of the five pillars (audit, repair, build, submit, prove) lives in the product.
- Understand why the same platform owns both the data-quality story and the submission story.
DataBridge tells one end-to-end story: Audit → Repair → Build returns → Submit → Prove. The same platform that finds the data-quality issues also fixes them, then assembles the statutory return, then submits it through the right gateway, then proves the whole chain happened. Each step hands evidence to the next, so the registrar's confidence isn't built on trust — it's built on artefacts.
Audit runs cited Quality Rules across the F1–F15 audit families over your source systems (SITS, Banner, Workday, Callista, TechOne, PeopleSoft, SJMS — see `docs/CONNECTOR_MATRIX.md` for the live capability matrix). Repair turns each finding into a tracked remediation: a code-set fix, a field correction, or a waiver with an expiry. Build assembles the canonical record into the schemas the regulator expects — HESA Data Futures XML, OfS / Research England / SLC / UCAS CSV-and-manifest, TCSI JSON envelopes.
Submit drives the regulator's gateway directly where the channel is API-shaped (HESA Data Futures Gateway, TCSI API via PRODA) and prepares an operator-upload packet where the channel is portal-shaped (OfS TEF, Research England KEF, SLC SBR, UCAS HEI). Prove is the cross-cutting pillar: every step appends to a tamper-evident audit log (a SHA-256 hash chain) so the whole submission story is independently verifiable after the fact.
The procurement payoff is that a single platform owns both halves of the work. Most institutions string together a data-quality vendor, a returns builder, a portal uploader, and a separate audit tool — and at submission time spend weeks reconciling them. DataBridge collapses that chain: the canonical record the audit ran over is the one the return was built from, and is the one the audit log signed.
This lesson walks the existing `/explain` tour, then surfaces the two evidence screens (`/guide` and `/audit-log`) that anchor the end-to-end story. You'll see how each pillar shows up in the product without doing any heavy lifting yourself.
Walkthrough
- Open the product tour
1.Walk the product tour
Open the existing one-page tour. It lays out Audit, Repair, Build, Submit, Prove in order with short worked examples — the same arc this lesson follows.
- Open the operator guide
2.See where the pillars live in the navigation
Open the operator guide — it's the in-app index of every screen by pillar, so you can see which routes implement audit vs. repair vs. build vs. submit vs. prove.
- Open the audit log
3.Glance at the proof layer
Open the audit log. Even before the next lesson covers it in depth, notice that every action is appended and chained — that's the 'Prove' pillar made tangible.
Your turn
Open the `/explain` tour and read through the five pillars. Note for yourself which pillar a single source-system field correction touches: is it just Repair, or does it ripple into Audit and Prove too?
Hint: Use the 'Open the product tour' step above — the answer is in the worked example near the top.