Five sectors that reduced a data coordination deadlock, each by a different mechanism.
A reference set of case studies prepared for the California Data Collaborative engagement. Each case documents the constraining tensions, the mechanism that worked, and what the experience suggests for California urban water reporting. Each section opens with a summary. Use "Extend" to reveal the full case study and its sources in place.
GTFS — Public Transit
A free listing on Google Maps made non-participation costly. No mandate was required.
Before 2005, US transit agencies held schedule and route data in proprietary, vendor-specific formats. Riders could not plan multi-agency trips. Developers wanting to build trip planners faced bilateral negotiations with every agency. An earlier industry standard (TCIP), developed by APTA, was technically comprehensive but had achieved essentially zero adoption.
The breakthrough came from outside the standards process. In summer 2005, TriMet's Bibiana McHugh approached MapQuest, Yahoo!, and Google about adding transit data. Only Google responded. Chris Harrelson, a Google engineer using 20% time, partnered with TriMet and built a prototype on the CSV dump TriMet's Tim McHugh sent him overnight. Google Transit launched December 7, 2005 with TriMet as the only operator.
Any agency that produced a GTFS feed got a free listing on Google Maps. By 2007, Google Maps was the default trip planner for hundreds of millions of users. Agencies that did not publish were invisible to those users; agencies that did got an immediate, visible benefit. By 2010, over 800 agencies had adopted. The name was changed from "Google Transit Feed Specification" to "General Transit Feed Specification" the same year to signal community ownership rather than a Google product.
What this means for California water data
The GTFS mechanism requires an aggregator with enough distribution reach to make non-participation economically costly. California water data has no equivalent consumer-facing aggregator. The applicable question is whether a platform exists or could exist (drought emergency tools, water trading platforms, regulatory dashboards) whose value would change agency behavior. The mechanism is transferable if that platform can be identified.
Three secondary lessons translate directly: format simplicity is a governance decision rather than a technical compromise; naming and ownership of a standard signal whether it is a community resource or a vendor product; and scope discipline (rider-facing schedule data only) is what kept GTFS adoptable.
The problem
In the early 2000s, public transit data in the United States was a coordination disaster. Every transit agency maintained its own schedule and route data in its own proprietary format, tailored to whichever scheduling or operations vendor it had contracted with. There was no shared standard, not even a de facto one. A developer who wanted to build a trip planner across multiple agencies had to negotiate custom data exports from each one, figure out each agency's idiosyncratic schema, and redo that work every time schedules changed.
Riders could not plan multi-agency trips using any digital tool. Regional trip planning was impossible. Developers who wanted to build transit applications faced a wall of incompatible data sources with no economic justification for climbing it. Agencies that wanted to serve riders better had no practical path: publishing their data required customizing an export for every consumer who asked.
The San Francisco Bay Area Rapid Transit District (BART) captured the situation plainly: before GTFS, BART had to provide different data consumers with different formats for every application, a manual, bespoke process repeated indefinitely.
What failed first
Before GTFS, there was one serious attempt at a transit data standard: the Transit Communications Interface Profiles (TCIP), developed by the American Public Transportation Association (APTA) roughly twenty years before GTFS emerged. TCIP was technically rigorous and comprehensive, and it achieved essentially zero adoption.
TCIP was designed by committee, through a standards body, to be complete and defensible. That made it complex. It required significant technical resources to implement, which excluded smaller agencies. It had no external forcing function: no application, no service, no incentive that made adoption attractive rather than burdensome. Vendors had every reason to participate in shaping the standard and no reason to implement it in ways that threatened their proprietary systems.
The technically sound specification could not get into production. Without a deployment path, the standard existed on paper and nowhere else.
The mechanism that worked
A free listing on Google Maps broke the impasse — no mandate, no standards body, no grant program.
In summer 2005, Bibiana McHugh, an IT Manager at Portland's TriMet transit agency, returned from international travel frustrated that she could navigate by car on digital maps but not by transit. She sent inquiries to MapQuest, Yahoo!, and Google, asking whether they had plans to incorporate transit data and whether TriMet could partner in the effort. Only Google replied.
The person who replied was Chris Harrelson, a software engineer at Google who had been quietly working on transit directions during his 20% independent project time. Harrelson connected with Bibiana and her husband Tim McHugh, then Manager of Enterprise Systems Development at TriMet, who had designed TriMet's internal database. Tim did a CSV dump of TriMet's schedule tables that night and sent it to Harrelson. That CSV dump became the prototype of what would eventually become GTFS.
Google Transit Trip Planner launched on December 7, 2005. At 9 pm, Harrelson sent the McHughs an email: "Google Transit trip planner is live." For most of the following year, TriMet was the only operator on the service.
McHugh later explained the format choice: "We chose to keep the files in CSV format. We wanted it to be as simple as possible so that agencies could easily edit the data, using any editor." Critics called the format "technically old-fashioned and brittle," but a spreadsheet editor was the lowest common denominator for agency IT staff across the country.
In September 2006, five more cities were added to Google Transit: Eugene, Honolulu, Pittsburgh, Seattle, and Tampa. Each had formatted their data to the specification TriMet and Google had developed together. Google simultaneously released the format specification publicly as the Google Transit Feed Specification. The offer was explicit: any agency that formatted and maintained its data in GTFS and submitted it to Google would get a free listing in Google Maps.
By 2010, the name was changed from "Google Transit Feed Specification" to "General Transit Feed Specification" — a deliberate move to reduce the perception of Google ownership and increase adoption by agencies wary of a single company controlling the standard. This rebranding was itself a governance insight: agencies would adopt a community-owned open standard more readily than a Google product.
Outcome
GTFS became the global standard for static transit schedule data. Today, over 10,000 transit operators in more than 100 countries publish their data in GTFS format. The Mobility Database catalogs over 6,000 active feeds across more than 75 countries. Trip planners, accessibility tools, research platforms, and real-time trackers have been built on the standardized substrate.
Once Google Maps became the de facto trip planning interface for riders, agencies that had not yet published GTFS faced constituent pressure to do so.
GTFS addresses what riders need to know: where vehicles go, when they stop, and how services connect. Internal operational data (driver assignments, CAD/AVL system state, scheduling software outputs) remains locked in proprietary formats. A separate standard, the Transit Operational Data Standard (TODS), was eventually built to address that gap.
Sources
FHIR / ONC Cures — Health Records
Defining information blocking as illegal inverted the cost structure of non-sharing.
For most of the 2000s and 2010s, a patient's health record lived inside a hospital EHR system, and getting it out required printing and faxing or negotiating a six-figure custom integration. By 2015, 96 percent of hospitals had electronic health records, funded by the 2009 HITECH Act, but the data was not moving between them.
The 21st Century Cures Act (Public Law 114-255, December 2016) introduced the concept of "information blocking" and prohibited it. The ONC Final Rule (May 2020) operationalized the prohibition with specificity: any practice that restricted access to electronic health information through contracts, technical limitations, throttling, pricing, or delay was a violation unless it fell within one of eight enumerated exceptions. Civil monetary penalties of up to $1 million per violation applied to health IT developers and networks; OIG was given parallel authority over healthcare providers with penalties up to $100,000 per violation.
Before Cures, refusing a data request created no legal jeopardy while sharing carried HIPAA and competitive risk. After Cures, refusal could require demonstrating that an enumerated exception applied; the absence of a legitimate exception was itself the violation. Presumptive legal exposure moved from sharers to withholders.
What this means for California water data
Penalty inversion is effective when the behavior to be changed is currently rational for the actors involved: they are not sharing because it serves their interests not to. Legislation of this scope requires a coalition and several years of advocacy. Replicating the mechanism in California water would require defining specific information-blocking behaviors, enumerating narrow exceptions, assigning enforcement authority to a named state agency, and setting penalties sufficient to make withholding legally expensive.
A narrower path follows the HITECH precedent: condition continued access to state grant funding on demonstrated data-sharing compliance. ONC's leverage came from making FHIR compliance a condition of certification, which in turn was a condition of federal payment program participation — not from new penalty authority.
The problem
For most of the 2000s and 2010s, a patient's health record lived inside a hospital EHR system (Epic, Cerner, Meditech), and getting it out required either printing and faxing it or negotiating a custom data integration that cost six figures and took months. When a patient moved between providers, records did not follow. When a public health researcher wanted population-level data, every request became a bilateral negotiation.
Medication errors from missing records contributed to roughly 7,000 preventable deaths annually in the US. Duplicate testing driven by inaccessible records cost an estimated $8 billion per year. By the mid-2000s, the technology to share structured health data existed; every actor in the system had reasons to keep data inside their walls (competitive advantage, liability avoidance, compliance uncertainty) and no reason sufficient to overcome those incentives.
What failed first
HIPAA (1996) created a floor for patient data privacy, but its effect on sharing was paradoxical. By establishing liability for improperly disclosed data, it gave legal teams a concrete reason to refuse sharing requests. There was no corresponding penalty for not sharing. HIPAA created an asymmetric risk environment: sharing incorrectly was visible and punishable; not sharing was invisible and unpunishable.
HL7 v2 (1980s–2000s). HL7 version 2 became the dominant messaging standard for moving data between clinical systems. It was a standard only in the loosest sense, defining message structures but leaving enormous implementation flexibility. Two systems that both claimed "HL7 v2 compliance" could not communicate without a custom interface engine.
CCDA / CCD (2011–2014). The Consolidated Clinical Document Architecture was document-oriented, not API-oriented. Providers could demonstrate compliance by exchanging a document and immediately ignoring it.
Meaningful Use (2009–2015). The HITECH Act provided up to $44,000 per physician and $11 million per hospital to adopt certified EHR technology. Hospital adoption went from 10% in 2008 to 96% by 2015. The incentive was for acquisition, not interoperability. Health systems used the funding to build sophisticated data silos.
FHIR (2012–2019). HL7's Fast Healthcare Interoperability Resources, R4 normative release October 2019. Built for web APIs rather than file exchange, modeling data as queryable resources accessible via REST. FHIR solved the technical problem. But technical availability does not compel adoption.
The mechanism that worked
The 21st Century Cures Act (Public Law 114-255, December 13, 2016) introduced the concept of "information blocking" and prohibited it. Section 4004 defined information blocking as a practice that "is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information."
The ONC Cures Act Final Rule (85 Fed. Reg. 25642, May 1, 2020) operationalized the prohibition. Any practice that restricted access through contract terms, technical limitations, throttling, pricing, or delay could constitute information blocking unless the actor demonstrated the practice fell within one of eight enumerated exceptions: Privacy, Security, Preventing Harm, Infeasibility, Health IT Performance, Content and Manner, Fees, and Licensing.
Under 45 CFR Part 171, health IT developers and health information networks face civil monetary penalties of up to $1 million per violation. The OIG received enforcement authority over healthcare providers under 86 Fed. Reg. 39236 (July 2021), with penalties for providers up to $100,000 per violation.
Prior to Cures, a hospital refusing a data sharing request faced no legal jeopardy. After Cures, refusal could require demonstrating that an enumerated exception applied; the absence of a legitimate exception was itself the violation.
Documented enforcement. In 2024, OIG issued Advisory Opinion 2024-03 addressing a complaint against Particle Health, a FHIR API aggregator, alleging that Epic had selectively throttled API access. Epic claimed the restriction was a security measure. OIG's analysis examined whether Epic's conduct met the Security Exception under 45 CFR 171.203. The OIG formally opened its information blocking complaint program in October 2022. By mid-2023 the agency had received over 800 complaints. The first formal referral for civil monetary penalties was made by ONC to OIG in 2023.
Outcome
By 2023, FHIR R4 patient access APIs had been deployed by all major EHR vendors under the ONC certification requirements tied to the Cures Final Rule. Apple Health, CommonWell Health Alliance, Carequality, and dozens of patient-facing applications were using FHIR APIs to pull patient records from hospital systems at patient request. Epic reported over 200 million patient records accessed via FHIR APIs by 2023.
The information blocking framework changed hospital legal advice. The standard counsel position shifted from "refuse unless compelled" to "document the exception you are relying on."
Several limitations are worth naming. The Cures Act applied only to electronic health information in certified EHR systems. The eight exceptions are broad enough that a sophisticated legal team can construct a defensible justification for most refusals; the Fees Exception in particular has been criticized. FHIR implementation quality varies widely. Terminology problems persist at the semantic layer. Payer data interoperability required a separate CMS rulemaking. The competitive dynamic between dominant EHR vendors and smaller developers has not been resolved.
Sources
UK Open Banking
Reframing data lock-in as a competition violation unlocked mandatory API access.
By 2016, the UK had roughly 68 million personal current accounts. Switching rates hovered around 3 percent annually. Barclays, HSBC, Lloyds, and RBS held over 70 percent of accounts, roughly the same concentration as a decade earlier. Customers could not easily export their transaction history, authorize third-party access, or transfer financial relationships, and the incumbents had no competitive reason to change that.
A prior voluntary program, Midata (2011–2014), had asked banks to provide CSV downloads of transaction data. The 2014 government review concluded it had been "only minimally effective." Implementations were narrow and there was no enforcement mechanism.
The Competition and Markets Authority opened a Market Investigation into retail banking in November 2014. Its August 2016 final report identified an "adverse effect on competition" — the legal threshold for imposing remedies under the Enterprise Act 2002. The CMA found that bank control over customer data was an instrument of anti-competitive entrenchment, which made it a competition matter rather than a data governance matter.
The Retail Banking Market Investigation Order 2017 required the nine largest banks (the CMA9) to fund the Open Banking Implementation Entity (OBIE) and comply with its standards. The first phase deadline was January 13, 2018, coinciding with PSD2 across the EU. When five of the nine banks missed key deadlines, the CMA issued formal enforcement Directions in April 2019.
What this means for California water data
The reframe from "data sharing problem" to "public-interest violation" is not rhetorical; it changes which legal instruments are available. California water law does not have a Competition Act, but the public trust doctrine and CEQA-driven environmental review processes could serve analogous functions. The strategic question is not "can we get agencies to share voluntarily?" but "what public-interest violation does non-sharing constitute?"
The sequencing lesson is direct: the CMA targeted the nine largest banks, not all banks at once. The water equivalent is identifying the three to five largest urban water suppliers whose participation alone would cover the majority of relevant data flows.
The problem
In 2014, if you wanted to switch your UK current account to a different bank, you faced a practical wall. Your transaction history lived inside your existing bank's systems. You could not export it in a usable format, authorize a third party to read it on your behalf, or take it with you.
Large incumbent banks (Barclays, HSBC, Lloyds, RBS, Santander, and four others, who together held roughly 80 percent of personal current accounts) had no competitive incentive to make customer data portable. Every piece of financial history that stayed inside their systems was a reason for the customer to stay.
What failed first
Midata launched in November 2011 by the Department for Business, Innovation and Skills. It asked banks, utility companies, and retailers to voluntarily allow consumers to download their transaction data as CSV files. The 2014 official review concluded it had been "only minimally effective." Implementations provided downloads of limited data ranges, in formats that were technically compliant but practically useless. There was no standard format, no real-time access, and no mechanism for third parties to retrieve data on a consumer's behalf — only manual CSV downloads that most consumers never used.
Firms had little incentive to invest in features that would make switching easier. Midata asked incumbents to fund and build the tools for their own competitive disruption. The Enterprise and Regulatory Reform Act 2013 included reserve powers to mandate data portability, but the 2014 review concluded there was "not a strong objective case" for using those powers in banking.
The mechanism that worked
In November 2014, the CMA launched a full-scale Market Investigation into retail banking, framed as a question about whether effective competition existed in the market.
On 9 August 2016, the CMA published its final report. The central finding was blunt: "Older and larger banks do not have to work hard enough to win and retain customers." The CMA identified an "adverse effect on competition" (AEC), the legal threshold required to impose remedies under the Enterprise Act 2002.
Low customer engagement plus barriers to searching and switching plus incumbency advantages produced entrenched market concentration. Data lock-in was not the only barrier, but it was a critical enabling condition. The CMA found that bank control over customer data was an instrument of anti-competitive entrenchment.
The Retail Banking Market Investigation Order 2017 required the nine largest banks to collectively establish and fund the Open Banking Implementation Entity (OBIE, now Open Banking Limited). OBIE was given a mandate to develop open, common, machine-readable API standards. The deadline for the first phase was January 13, 2018. The standards were technical and specific: RESTful APIs, OAuth 2.0 authentication, defined data schemas. The mandate covered both Account Information Services and Payment Initiation Services.
Five of the nine banks failed to meet the January 2018 deadline for key components. On 1 April 2019, the CMA issued formal enforcement Directions to all five, specifying actions required and timelines.
Banks had used data control to entrench their market position; the open-API requirement was the remedy. PSD2 (the EU's Second Payment Services Directive, in force from January 13, 2018) reinforced the same obligations through EU law.
Outcome
By 2021, 4 million UK consumers and small businesses were using open banking-powered services. By December 2024, 12 million active users, with 223.9 million open banking payments processed (a 72 percent increase on the prior year). By 2025, 294 licensed third-party providers were operating.
The competition problem that motivated the investigation did not fully resolve. Market concentration in UK retail banking remained broadly similar through 2024. Customer switching rates 2015–2019 were static at around 2 percent annually. API performance varied across the CMA9. Incumbent banks pivoted to acquiring or partnering with fintech companies the standard enabled.
Sources
Green Button / AMI — Energy
A consent architecture resolved the privacy tension; a CPUC mandate produced California adoption.
By 2010, nearly 50 million smart meters had been deployed across the US, producing 15-minute interval data on every customer's electricity consumption — held in proprietary utility systems. Third-party energy efficiency companies needed bilateral integrations with each utility, and the standards bodies (SGIP, NAESB) had developed the ESPI specification by 2011, which sat unused.
In September 2011, US Chief Technology Officer Aneesh Chopra issued a challenge: build a "Green Button" — a way for customers to download their own energy data in a standard format. PG&E, SDG&E, and Southern California Edison implemented Download My Data by January 2012, based on the existing ESPI standard.
CPUC Decision D.13-09-025 (September 2013), followed by D.14-05-016 (May 2014), required California's three investor-owned utilities to implement Connect My Data: a customer-authorized OAuth API for continuous third-party access. Customers, rather than utilities, authorized third-party access. Each authorization is explicit, data-scoped, and revocable.
What this means for California water data
This is the closest available analog to AMI / conservation analytics sharing for water utilities. The data type, the actors, the privacy tension, and the incentive structure are nearly identical. A consent framework for water AMI data, where customers authorize a regional analytics platform to access their consumption data, would replicate the mechanism that worked in energy.
The salient lesson is the 4.5 percent national adoption ceiling. Consent architecture resolves the privacy tension but not the collective action problem. California's success came from CPUC mandate, not voluntary uptake. The water-side equivalent requires identifying what mandate authority exists; a small number of large urban water suppliers covers most of the relevant data flows.
The problem
By 2010, nearly 50 million smart meters had been deployed across the US, giving electric utilities access to granular, 15-minute interval data on every customer's electricity consumption — held in proprietary formats (Oracle Utilities MDM, SAP IS-U, Itron, Landis+Gyr), none of which spoke to one another.
A third-party energy efficiency company wanting to analyze a customer's consumption needed a separate integration with each utility. Utilities were receiving thousands of manual data requests, processed by hand. Each utility had reason to keep its data model proprietary: customer data was a business asset, sharing required building integration infrastructure with no clear return, legal teams worried about third-party liability, and regulators worried about privacy.
What failed first
Before Green Button, the dominant approach was bilateral negotiation, which excluded all but the largest technology companies. The Smart Grid Interoperability Panel (SGIP) and the North American Energy Standards Board (NAESB) had been working on technical standards for years. By 2011, NAESB had ratified the Energy Services Provider Interface (ESPI) standard. ESPI existed on paper and had no deployment path.
The mechanism that worked
In September 2011, US CTO Aneesh Chopra issued a direct challenge: build a "Green Button" — a simple, secure way for customers to download their own energy data in a standard format. The challenge had no penalties, only White House visibility.
The California IOUs (PG&E, SDG&E, and Southern California Edison) responded first. By January 2012, all three had implemented Green Button Download My Data on their customer portals: a button that produced a standardized XML file of the customer's usage history, based on NAESB's ESPI standard.
Two-tier architecture. Green Button had two distinct products from the start. Download My Data (DMD): the customer clicks a button and downloads an XML file. Connect My Data (CMD): the customer authorizes a third party to retrieve data automatically and continuously via an OAuth-based API.
Green Button CMD launched in 2013 after the California CPUC issued Decision D.13-09-025 requiring the three investor-owned utilities to provide third-party data access. Follow-on D.14-05-016 (May 2014) created the Energy Data Request and Release Process and formally mandated CMD implementation.
Third parties received customer data only upon explicit, revocable customer authorization via OAuth. The framework requires opt-in consent for each third party, allows revocation at any time, restricts third-party access to the specific data the customer authorized, and prohibits utilities from unilaterally terminating third-party access once authorized. Utilities share data because a customer asked them to; the utility's liability is bounded by the consent framework.
Outcome
By 2015, more than 150 utilities and service providers had committed to Green Button access for over 60 million US households. By the Ontario mandate in 2023, hundreds of certified implementations existed across the US, Canada, and South Korea.
Approximately 3,200 utilities operate in the continental US. By 2022–2023, approximately 150 had implemented Green Button — about 4.5 percent of all utilities. Among these, only 35 were investor-owned utilities, 100 were rural electric cooperatives, and 15 were public utilities. Municipal utilities (roughly 2,100 publicly owned) were almost entirely absent. The distribution reflects the mandate structure: California's CPUC mandate reached three IOUs serving most of the state's utility customers. Without a comparable mandate, smaller and publicly-owned utilities had no incentive sufficient to justify the implementation cost.
Sources
Bureau of Meteorology — Water (Australia)
A non-regulatory recipient dissolved the sovereignty tension that had blocked reporting to regulators.
Australia has a federal water governance structure that California would recognize: water rights are administered by states, water resources cross jurisdictional boundaries, and the data needed to manage shared systems is held by whoever collected it locally. Before 2007, there was no national picture of water availability, use, or quality. The Millennium Drought (2001–2009) made the gap acute. The 2004 National Water Initiative committed governments to voluntary improvement and produced limited change.
Section 126 of the Water Act 2007 and the Water Regulations 2008 require more than 200 named organizations to provide specified water information to the Bureau of Meteorology. The Regulations individually name the categories of organizations required to report and specify what data they must provide, in what format, by when.
The Bureau of Meteorology has no water rights enforcement authority. It cannot affect water allocations, cannot initiate regulatory actions, and has no role in interstate water disputes. State agencies that had withheld data from federal regulators — because submitted data could be used against them in allocation disputes or licence enforcement — complied with BOM because BOM had no power to act on the data adversarially. The sovereignty objection that had blocked reporting to regulators did not apply to a non-regulatory recipient.
What this means for California water data
The Australian programme is the closest institutional analog to CaDC's structural position. BOM's non-regulatory position is the mechanism of the programme's success, and CaDC occupies the same structural position relative to DWR and SWRCB. A California equivalent could separate the reporting obligation (held by SWRCB or DWR) from the data custodianship (CaDC or a CaDC-adjacent body). Agencies report because they must; they report to a body that cannot use the data against them.
The Regulations individually list which organizations must provide what data by when. AB 1755 establishes a framework but does not name agencies. A California equivalent of the Water Regulations would replicate the mechanism that produced Australia's 200+ reporting organizations.
The problem
Australia has a federal water governance structure: water rights are administered by states and territories, water resources cross jurisdictional boundaries, and the data needed to manage shared systems is held by whoever collected it locally. Before 2007, there was no national picture of water availability, use, or quality. The data existed, scattered across incompatible state systems using different formats, different measurement conventions, and different definitions of what counted as reportable information.
Droughts, including a decade-long drought from the late 1990s through 2009, demanded cross-basin management responses that required data on groundwater levels, extraction volumes, and storage across state lines. The Murray-Darling Basin, which spans five states and produces 40 percent of Australia's agricultural output, had no reliable national account of how much water was being used or what was left. Individual states defended their data as part of their water sovereignty.
What failed first
The National Water Initiative (2004) was the voluntary precursor to the Water Act 2007. As an intergovernmental agreement, the NWI could commit governments to principles but could not require individual agencies within those governments to change their data practices. State environment and water departments signed on; state data systems did not change. Three years of NWI-era effort produced consistent rhetoric and inconsistent reporting.
The mechanism that worked
The Water Act 2007 introduced what the NWI could not: mandatory reporting obligations on named organizations, administered by a federal body that could not use the data against the reporters.
The legislative mandate. Section 126 of the Water Act 2007, operationalized through the Water Regulations 2008, requires more than 200 named organizations to provide specified water information to the Bureau of Meteorology. The list includes state water authorities, catchment management bodies, irrigation corporations, water utilities, and environmental regulators across all eight states and territories.
The trusted intermediary. The mandatory reporting obligation went to the Bureau of Meteorology rather than to the Murray-Darling Basin Authority (MDBA) or a state water regulator. The MDBA holds enforcement authority over the Basin Plan and sustainable diversion limits. If the MDBA had been the data collection body, every number submitted would carry the implication of compliance evidence.
BOM holds no water rights enforcement authority. It cannot trigger compliance actions, curtailment orders, or licence reviews. Its mandate is to collect, quality-check, harmonize, and publish water information. An agency that submits groundwater extraction data to BOM is not providing evidence to a regulator; it is contributing to a national database that BOM publishes for all users.
Technical standard and infrastructure. The Bureau developed the Water Data Transfer Format (WDTF) in partnership with CSIRO as the standardized format for data submission. Phase One of AWRIS was funded as a $10 million, two-year project under the National Water Commission's Raising National Water Standards programme. The Bureau built the AWRIS database, the Australian Hydrological Geospatial Fabric (Geofabric), the data download service, and the National Water Account publication. State agencies that submit data get back quality-checked, integrated outputs.
Outcome
More than 200 organizations report water information to the Bureau under the legal obligations established by the Water Act and Regulations. AWRIS collects river flows, groundwater levels, reservoir storage volumes, water quality, water use, entitlements, and water trades. The National Groundwater Information System contains more than 988,000 bore locations, the most comprehensive national groundwater dataset in Australia's history.
The Bureau publishes an annual National Water Account covering 12 water accounting regions. The 2020 National Water Account reported total groundwater extraction in the Murray-Darling Basin of 1,701 GL — a number that could not have been produced without cross-jurisdictional data flows from state agencies that had no prior obligation to submit it to anyone.
Small water authorities with limited capacity still submit inconsistently. Data quality varies. The voluntary WDTF adoption rate has not reached 100 percent. The Act also created a tension between national transparency and state sovereignty that has not fully resolved.
Sources
About
What this is
This document presents five case studies in resolving data coordination friction across sectors. It was prepared as a reference resource for the California Data Collaborative engagement on urban water reporting coordination. Each case was selected to illustrate a distinct mechanism: market incentive (GTFS), penalty inversion (FHIR / ONC Cures), problem reframe (UK Open Banking), consent architecture (Green Button), and legislative intermediary (Australia BOM). The mechanisms are not interchangeable; each fits a specific structural condition.
How the cases were researched
Each case was source-verified against primary regulatory documents (statutes, regulations, agency decisions, advisory opinions) and corroborating secondary sources (peer-reviewed articles, journalistic accounts, official program publications). Source citations are listed at the end of each full case study. Where claims could not be verified against a primary source, the secondary source is named and the claim is qualified. The cases were prepared between March and June 2026.
About the Protocol Institute
The Protocol Institute is an independent research organization studying protocols — the rules and coordination structures that shape interaction across diplomacy, software, medicine, governance, and beyond. Evolved from the Ethereum Foundation-funded Summer of Protocols program (2023–2025), it continues that work through research, publishing, and community building across organizational theory, infrastructure studies, and governance design.
Protocolized is its flagship publication; the AI Capability Maturity Model is one of its practitioner-facing frameworks, produced by the Protocols for Business leads.