Why does “all data” end up meaning no data at all?
An Authority that asks for “all data” in a contract may find that it has specified far less than it thinks.
People search for
In this article
A draft contract may say, “We will provide all data requested by the Authority”. That wording postpones the work of defining the obligation.
When a timetable changes at short notice, a performance report is disputed or ticket sales fall, the Authority needs to know which records are required, in what form, for what purpose and by when. A broad promise leaves those points unresolved. The parties may then argue about scope, cost and whether a request is reasonable when the information is most needed.
Build a catalogue, not a catch-all clause
A contract annex should name the datasets the Authority expects to receive. It may cover service schedules, vehicle-location feeds, cancellation and punctuality records, ticketing transactions, customer contacts or fleet-maintenance information. These datasets are materially different. They often come from different systems and may carry different commercial, security or data-protection considerations.
For every significant item, the catalogue should state the format and version, delivery method, frequency and cut-off time. “Regularly” is not a workable deadline. It should also identify the quality checks: for instance, whether every scheduled journey is present, vehicle IDs match the agreed reference list or a file contains unexplained gaps. The Authority needs a named recipient or system and an agreed process for flagging and correcting exceptions.
Standards are useful where they fit the data and the service. In England, the Bus Open Data Service uses TransXChange for timetable information, SIRI-VM for real-time vehicle locations and the UK NeTEx profile for fares data. Those formats may be a sensible starting point for an Authority’s schedule. They will not cover every contractual need, such as the detail needed in a commercial ticketing extract, a performance calculation or a financial report. State the version to use, or set out the process for managing a future standard change. Do not assume that “standard” resolves the issue.
The catalogue should distinguish the Authority’s right to receive and use data from the responsibilities for the underlying system or records. Where personal data is involved, the arrangement needs a clear purpose, the relevant Controller or Processor roles and security arrangements. It also needs retention and deletion rules, plus a route for dealing with individual-rights requests. A data schedule cannot itself make unnecessary sharing lawful.
Ask for data the Authority can use
Before procurement, the Authority should map the systems and data required for the functions and services that support the full operation.
An Authority in an Enhanced Partnership may need dependable service, punctuality and passenger-information data to oversee commitments and inform network decisions. An Authority that bears revenue risk under a gross-cost contract is likely to need more frequent and more detailed ticketing, revenue and patronage information. Neither position justifies collecting data simply because it might be interesting later.
An Authority should agree a realistic specification before procurement rather than spend months interpreting a general clause. For each item, identify the user, the decision it supports and the action to take if the data does not arrive or fails the agreed check.
That last point matters. An audit provision should allow the Authority to inspect a reasonable sample of source records, delivery logs and correction evidence. It should set out an escalation route: notification, a period to correct the problem and any proportionate contractual consequence agreed by the parties. The Operator should be able to cost and resource the obligation. The Authority should be able to receive, test and act on the data, not store it unread.
An Authority should not require a highly granular live feed before it has established basic reporting, people and tools to use it. An Authority planning to take on revenue risk should define the transaction-level data it will require before mobilisation. The specification should develop with the Authority’s responsibilities and capability.
Our LiteFranchise™ framework includes a 14-schedule contract suite, alongside Authority standards and policies for data governance. Authorities using this material should still check that each schedule suits their operating model, systems and data-protection arrangements. Pre-built material does not remove that responsibility.
Useful questions
Use these questions when reviewing the data annex, rather than relying on the wording of the headline clause.
- Does each required dataset have a stated purpose, format, deadline, quality test and named recipient?
- Which data will the Authority use to make service, performance or revenue decisions and who will review it?
- Are rights to access, use, retain and share the data clear, particularly where personal data or Supplier systems are involved?
- Can the Operator price and resource the requirement and can the Authority test the files it receives?
- Does the contract say how late, incomplete or inaccurate data will be evidenced, corrected and escalated?
More on Data & Governance