Coverage matrices
Rule coverage, returns completeness, and the connector matrix — three pages an evaluator can score.
By the end you’ll be able to
- Read the three coverage matrices and know which question each one answers.
- Use the matrices to score what is and isn't covered for a given institution.
- Understand how the freshness gates keep the matrices honest.
DataBridge ships three generated matrices that an evaluator can score against. They answer three different questions, and together they describe the platform's surface area without any sales-deck embellishment.
`docs/AUDIT_RULE_COVERAGE.md` is the audit-rule coverage report. It tells you, for every audit family (F1–F15 plus the source-native conformance families like BANNER-INTEGRITY, SITS-INTEGRITY, WORKDAY-INTEGRITY, TECHONE-FIN1-INTEGRITY), how many rules ship and how many remain `[UNVERIFIED:]`. The breakdown is also by jurisdiction (UK vs. AU) and by entity surface (Student, Staff, Programme, Module…), so you can match the platform's depth to the source systems and returns you actually run.
`docs/RETURNS_COMPLETENESS.md` is the statutory-return completeness matrix. It lists every return — see the live count in the doc — across HESA Data Futures (Student, Provider, Staff, EMR, GOS, AOS, Finance), the UK portal returns (OfS TEF, Research England KEF, SLC SBR, UCAS HEI) and AU TCSI (HE Student, HE Staff, Provider Information Request, Applications & Offers). For each return it shows whether the schema, the declared audit rules, the source-mappers, the builder, and the submission channel are present.
`docs/CONNECTOR_MATRIX.md` is the source-connector capability matrix. It tells you which student/finance/staffing systems DataBridge ingests from natively — see the live count in the doc — and for each one whether incremental sync, sampling, code-lists, and a data dictionary are supported, plus the preferred auth mode. Generic CSV/JDBC paths are covered separately in `docs/CONNECTORS.md`.
All three matrices are deterministic and wired into the CI freshness gate (`scripts/ci-local.sh`). If the code changes, the matrix has to be regenerated and committed — the gate enforces it. That's what stops the marketing version drifting from the engineering reality: there is only the one, generated version.
Walkthrough
- Open the guide
1.Open the operator guide as a starting point
The guide is the in-app index of where coverage shows up by pillar. Use it to orient before you open the matrices on disk.
- Open integrations
2.See connectors in practice
Open the integrations area to see the connector descriptors that the connector matrix is generated from. Each one is a live integration with its capability shape.
- Open codesets
3.See the codesets that underpin coverage
Codesets are the enumerations rules cite. The reference page is the easiest way to see how published codelists become enforceable rules.
Your turn
Open the operator guide and use it to locate one return your institution submits and one source system you run. Use those entries to find the corresponding rows in the rule-coverage, returns-completeness, and connector matrices on disk.
Hint: Use the 'Open the guide' step above — the guide is the in-app index that points to the three matrices.