Multi-jurisdiction (UK + AU)
One platform, two regulatory regimes — HESA and TCSI.
By the end you’ll be able to
- Understand the `@databridge/jurisdiction-core` abstraction: one canonical record, two regimes.
- See the UK return families (HESA Data Futures plus the OfS / Research England / SLC / UCAS portal returns).
- See the AU TCSI return families and the AU console that drives them.
Multi-jurisdiction in DataBridge is not two products with a shared logo — it's one codebase with a jurisdiction abstraction. The `@databridge/jurisdiction-core` package defines the shape every regime plugs into; UK and AU are the two regimes shipped today. The canonical record is the same on both sides; what differs is the rules that audit it, the schema that builds the return, and the gateway that submits it.
On the UK side, the return families are HESA Data Futures (Student, Provider, Staff, EMR, GOS, AOS, Finance — XML over the HESA Data Futures Gateway) plus four operator-upload portal returns: OfS Teaching Excellence Framework (TEF), Research England Knowledge Exchange Framework (KEF), SLC Student Borrower Return (SBR), and UCAS HEI data return. Each appears as a row in `docs/RETURNS_COMPLETENESS.md` with its declared rules, mappers, builder, and submission channel.
On the AU side, the TCSI family covers HE Student, HE Staff, Provider Information Request, and Applications & Offers — JSON envelopes submitted to the TCSI API via PRODA. The AU console (`/au`) is where AU operators drive their cycle: `/au/cycles` for the submission cycle, `/au/prisms` for the AU-specific data prisms.
What makes the abstraction load-bearing is that it isn't a switch — it's a seam. The same audit log, the same hash chain, the same codeset machinery, the same connector registry serve both regimes. Adding a third jurisdiction means defining its rules, schemas and gateway and plugging into the seam — not duplicating the platform.
For a procurement audience that matters because most peers ship either a UK-only HESA tool or an AU-only TCSI tool; DataBridge is the same platform for a multi-country group or a UK provider planning an AU campus. The UK byte-freeze invariant in `CLAUDE.md` (no existing UK API response may change its bytes) is what keeps the AU work from regressing UK behaviour — the seam is enforced, not aspirational.
Walkthrough
- Open the AU console
1.Open the AU console
The AU console is the entry point for the TCSI return families — HE Student, HE Staff, PIR, Applications & Offers. Notice the navigation parallels the UK side.
- Open AU cycles
2.Look at an AU submission cycle
Cycles is where an AU operator drives a submission window. The lifecycle (open → repair → build → submit → prove) is the same arc you saw in lesson 1 — applied to TCSI rather than HESA.
- Open HESA streams
3.Look at the UK HESA streams alongside
Open the HESA streams workspace. The shape — a list of streams, each with its schema, rules and builder — mirrors the AU console. That parallel is the jurisdiction abstraction made visible.
Your turn
Open the AU console and note the TCSI return families listed there. Compare against the HESA streams workspace — same shape, different regime. That parallel is the seam doing its job.
Hint: Use the 'Open the AU console' step above; switch to '/hesa' afterwards to compare.