SINE Strategy Wiki

Data Commons

14 min read

SINE Foundation’s core governance framework for shared, multi-stakeholder data ecosystems. Treats a pool of shared data (e.g. product sustainability data) as a commons in the Ostrom sense: a resource that needs deliberate governance to avoid free-riding and collapse, rather than either pure market exchange or a single central platform.

Established in the original 2022 whitepaper with Deutsche Bank, Systemiq and TLGG (sine-data-commons-2022), then operationalized for Digital Product Passports in the 2023 follow-up (sine-dpp-data-commons-2023).

Origin: the problem it solves

Carbon accounting, digital product passports, and ESG reporting all share one structural problem: they run on insufficient third-party data — averages, cumulated values, estimates — because (a) stakeholders apply inconsistent, non-interoperable methods and tooling, and (b) firms are wary of vendor lock-in and of losing control over sensitive, competitively relevant data if they share it. A Data Commons is never pursued as an end in itself — it starts from a concrete business case: a clear answer to “what do we want to do with the data.”

Three core values (2022 whitepaper)

Adapted from Ostrom’s commons design principles for data-sharing specifically:

  • Reciprocity — every connection between stakeholders in a Data Commons must be a mutually beneficial relationship with a clear, measurable business-value incentive to participate. No aligned incentive, no participation.
  • Security — cryptographic measures (the 2022 paper cites secure multi-party computation) let parties compute/analyze on combined data without revealing their private input, lowering the transaction cost of sharing and ensuring sensitive data is never exposed.
  • Openness — open, interoperable software lowers the barrier for new members to join and lets existing members leave via data portability (“vote with their feet”) — what actually drives network scalability. Also framed as sovereignty-enabling.

Architecture choice: the technical core can range from centralized software to decentralized blockchain to fully distributed peer-to-peer networks. The 2022 paper argues fully distributed, peer-to-peer designs best serve all three values simultaneously — centralized or even blockchain designs tend to cost openness/portability — giving the best mix of data quality, implementation speed, and scalability.

Use cases from the 2022 whitepaper

Key questions (building blocks, 2023 DPP paper)

The 2023 DPP whitepaper operationalizes Data Commons into ~17 questions a DPP ecosystem must answer, grouped loosely as:

  • Identity — who is part of the commons?
  • Sovereignty — what must stakeholders know about each other?
  • Relationships — how are stakeholders related; do power hierarchies affect this?
  • Onboarding — how does a stakeholder join, and at what cost?
  • Portability — can data be reused elsewhere / across DPPs?
  • Coalitions — how does the commons integrate existing/new initiatives?
  • Use Case — what business value, and what data does it require?
  • Collective-Choice Arrangements — how do stakeholders participate in rule-making?
  • Data Use — for what purposes may data be used/analyzed, and by whom?
  • Data Benefits & Costs — who benefits, who bears sharing costs?
  • Data Protection — what are the sharing risks; how is data protected?
  • Data Standards — what ensures accessibility and reliability?
  • Data Provenance — what do members need to know about data origin/changes?
  • Data Exchange Protocol — how does data flow between IT systems?
  • Data Quality — how is high data quality ensured?
  • Fraud — what would fraudulent behavior look like, and how is it prevented?
  • Monitoring Costs — how are monitoring costs kept low given complexity?
  • Members’ Involvement — how are stakeholders involved in monitoring?
  • Power Balance — how is misbehavior by a powerful value-chain player sanctioned?
  • Speed & Costs — how is quick, low-cost conflict resolution ensured?

Governance principles surfaced

  • Cryptographic measures (incl. homomorphic encryption) to let data be used/analyzed without exposing sensitive underlying inputs.
  • Relationships among stakeholders must be reciprocal, with clear incentives to participate; smaller companies’ autonomy must be protected.
  • Open, interoperable interfaces are required to prevent new data silos — intermediaries can translate between DPP formats where needed.
  • Clear group boundaries are needed to solve the free-rider problem and produce a stable governance structure — this maps directly onto Ostrom’s first design principle, “clearly defined boundaries” (Table 3.1); see Ostrom’s Commons Design Principles & SINE’s governance approach for the principle in full and how it was derived.

Applied to: Digital Product Passports

See Digital Product Passport for the problem this framework is applied to, and Scope 3 for a concrete use case (PACT, GBA, Catena-X).

Applied to: smallholder farmer data (prospective)

GIZ Tender 10036847 — Data Governance in Agricultural Value Chains (2026, under SAFE) frames the same problem — control over personal/farm data currently sitting with intermediaries rather than the data subject — for smallholder farmers in deforestation-free supply chains. ⟨Inference: the tender does not cite Data Commons or Ostrom; the fit is SINE’s own read of the opportunity, not a stated connection in the source.⟩

External corroboration — and a rival architecture (ICC, 2026)

The Carbon Accounting Landscape Review (ICC, 2026) touches this framework at three points, without citing it.

It arrives at the same architectural bet from the regulatory side. Its §3.5 conclusion — regimes will not converge, so “harmonise the data layer rather than the regulatory designs that sit on it: a single underlying set of verified, transferable embedded-emissions records from which each regime draws what its rules require” — is the Data Commons move (infrastructure below the policy layer, neutral to what sits on top), reasoned from CBAM/LCFS/CFMS rather than from Ostrom. See Product-level carbon regulation.

It states the Security value as a requirement and supplies no mechanism. Its Criterion B asks for verification “while limiting unnecessary disclosure of underlying operational data” and then drops the requirement — see the confidentiality gap.

It proposes a different technical core for the same use case. The 2022 whitepaper argues fully distributed peer-to-peer designs best serve all three values simultaneously; the Review advocates ledger-based carbon accounting — double-entry records transferred with legal title, reconciling transaction to product to entity. ⟨Inference: these are not straightforwardly opposed — a ledger is a data model, P2P is a topology, and the Review explicitly leaves the exchange layer to PACT. But the ledger’s conservation requirement (every unit assigned to one entity, never removed except by transfer) puts constraints on the topology that the 2022 paper did not consider, and the wiki should not assume the two compose until someone has shown it. This is part of the open task on SINE’s response.⟩

Partly defused ⟨2026-08-17⟩. The topology objection is narrower than it looked. Man & Kleppmann (2026) build a full verifiable-accounting system and state: “Our proposal does not depend on a blockchain or distributed ledger, except for publishing a single hash commitment per accounting period – a task that can also be fulfilled by a simpler system such as a transparency log.” ⟨Inference: what conservation actually requires of the topology is one public, append-only, non-retractable commitment per period — so that no party can show different records to different counterparties. A blockchain satisfies that; so does a certificate-transparency-style log; a fully peer-to-peer design with no shared append-only artefact does not. That is a much smaller concession than “you need a ledger”, and it is the concession the 2022 whitepaper’s architecture section should now be read against. Heiss et al. (2023) still verify in an Ethereum smart contract, so the contradiction is live for that design and resolved for this one — recorded, not smoothed over.⟩

A second independent arrival — with no governance layer (GEO BON, 2026)

Kim et al., From Data to Decision reaches the same architecture from biodiversity monitoring, again without citing Data Commons, Ostrom, or anything adjacent. Its §5.3 answer to states unwilling to let observation data leave their jurisdiction is a federated system: data stays with its holder, interoperability is achieved by shared vocabularies and self-describing formats, and what moves is the derived essential-variable product rather than the raw records.

That is the Data Commons architectural bet arrived at a third time — after the 2022 whitepaper reasoned it from Ostrom and the ICC Review reasoned it from CBAM/LCFS. Three independent derivations of “harmonise the data layer, leave the applications above it plural” is about as much external corroboration as an architectural claim gets.

What is conspicuously absent is the governance half. The paper’s treatment of everything the 2023 DPP paper turns into 17 questions — identity, onboarding, collective-choice arrangements, data use, fraud, monitoring costs, power balance, conflict resolution — amounts to a mention of “data licensing, and user agreements”. No membership rules, no monitoring design, no graduated sanctions, no conflict-resolution mechanism.

⟨Inference: the reading that matters is why, and the coordination/bargaining split answers it — see that page’s second worked case. Ostrom’s design principles are a response to free-riding and appropriation conflict. In a pure-coordination commons among states there is little to appropriate and no rent to fight over, so the governance layer is genuinely less load-bearing — it is not simply an oversight. Which sharpens a claim this wiki makes loosely: Data Commons’ governance apparatus is not universally required infrastructure; it is the answer to the bargaining component specifically. Where that component is absent, vocabularies and file formats appear to be enough, and the field is saying so by building it that way. The honest version of the pitch is therefore narrower and more defensible than “shared data needs governance”.

The untested half: whether a governance-free federation actually holds up over time or merely has not failed yet. The paper is a position paper about a system still being built, so its silence is weak evidence either way. ⟨Lint 2026-09-28: the same paper’s silence is read as strong evidence on coordination vs. bargaining failure, which looked like a contradiction between two pages written the same day. Why both readings stand — the governance silence is self-serving and the confidentiality silence is unmotivated — is argued there, not here.⟩ It is also worth noting that Security — the one of the three values that carries SINE’s distinctive technology — is the value this case has no use for at all.⟩

A third independent arrival — the OECD, with the governance layer intact (2026)

⟨2026-10-27, from OECD, Data Spaces between Co-ordination Challenges, Financial Viability and Public Policy (2026).⟩

The ICC and GEO BON arrivals recorded above each reached a commons-shaped architecture and then either proposed a rival governance design or left the governance layer out. The OECD does neither: it reaches the Data Commons thesis directly, states it as the finding, and brings 235 registered initiatives to back it.

The thesis, in its words:

“Governance structure, not technology, is the binding constraint.”

It says this after tracing four technology waves that each promised multi-party data sharing and each delivered single-party control — EDI (buyer coercion over suppliers; Hart & Saunders, 1997), service-oriented architecture (hub-and-spoke in practice despite the promise; Löhe & Legner, 2010), APIs, and supply-chain control towers (visibility confined to the focal firm’s immediate partners; Swink et al., 2024). Each “enabled data exchange where one dominant party set the terms”; each failed where governance had to be shared. Covisint is the named failure: GM, Ford and DaimlerChrysler, 2000, abandoned by 2004, and “the failure was not technological but rather institutional”.

What this adds that we did not have:

  • An economic derivation of the commons layer, not an assertion of it. Price formation for data fails (context-dependent value; Arrow’s information paradox — “a prospective buyer cannot assess the value of information without first possessing it, yet once disclosed the information has effectively been transferred”), and centralised co-ordination fails wherever participants compete or sit in different jurisdictions. With neither prices nor hierarchy available, Williamson’s hybrid form is what remains — “not a loose amalgam of market and hierarchy but possesses its own disciplined rationale”. That is the Data Commons, arrived at by elimination.
  • A boundary. The commons layer is not always the right answer. Four conditions have to hold jointly, and where they do not, “simpler data-sharing mechanisms may be sufficient and may not justify the co-ordination costs that data spaces entail”. See data space boundary conditions. This is the first disciplined statement in the wiki of when our own thesis does not apply.
  • The failure rate. Of 235 initiatives, 25 are operational and none is scaling; only 15 % of European data-sharing initiatives have a clear revenue model. The governance layer being necessary is not the same as its being sufficient, or fundable — see data space business models.
  • Why this keeps being rediscovered. The report’s own answer is the measurement gap: “no single entity observes all transactions”, so “the data-sharing infrastructure that data spaces provide is itself under-measured because the principles that make it distinctive also make it hard to observe.” ⟨Inference: a thesis whose evidence is structurally unobservable will be arrived at repeatedly and independently, which is exactly the pattern this page has now recorded three times.⟩

One divergence worth keeping visible. The OECD’s commons is federated governance plus open interoperability plus contract-based usage control; SINE’s is federated governance plus open interoperability plus cryptographic control. The report does consider the cryptographic route — it is the first source in this wiki to do so at length — and places it as complementary rather than substitutive: the connector negotiates “through which PET the data must be processed”, so “the provider no longer needs to trust the recipient’s compliance because the technology structurally limits what can be done with the data”. It also states the limit of its own mechanism plainly: “once data leave the provider’s infrastructure, enforcement depends on the data user’s compliance”. See cryptographic trust infrastructure and the confidentiality gap.

The architecture asked for, with the governance question left blank (POLYPROBLEM 06, 2023) ⟨2026-11-06⟩

Source: Der Circularity Code.

This report is a useful negative case: it reaches the Data Commons conclusion and stops exactly where the framework begins. Its Zwischenfazit (p. 53):

Eine gemeinsame Architektur anstelle von Insellösungen – diese Forderung tauchte im Verlauf der Recherchen immer wieder auf.

and Christoph Kugler (SKZ, p. 11): “Eine übergeordnete, also unternehmensübergreifende, digitale Infrastruktur ist etwas, das wir immer wieder propagieren.”

Nowhere in 60 pages does the report ask who owns it, who may access it on what terms, who adjudicates disputes, or how the costs are shared. Its own explanation for why the architecture does not exist is “Haltung” — attitude. The report’s recommendation is that politics establish such infrastructure “als ein Gemeingut … wo es noch keine tragfähigen Geschäftsmodelle gibt”, which names the Ostromian category and supplies none of its content.

⟨Inference: the 17 questions of the 2023 DPP paper are precisely the blank this report leaves. For the Röchling engagement that makes the gap legible without contradicting the counterpart: the foundation has published the demand for a commons three times over and has never specified one. The corroboration here is weaker than the ICC/GEO BON/OECD arrivals recorded above — those reconstructed parts of the architecture independently, this one only states the need — but it is corroboration from the operating side of an industry rather than from a standards body.⟩

One concrete mechanism does appear, and it belongs in the commons toolkit rather than in the governance layer: federated learning, used so that “Produzent A keinen Einblick in die Daten des Produzenten B erhält” (Kugler, pp. 10–11, naming the Hamburg supplier Katulu and running model projects). ⟨Inference: in Data Commons terms this is an implementation of the security value that does not require solving reciprocity or openness — it lets a pool produce a shared model while leaving the question of what members owe each other untouched. That is why it ships and the governance does not.⟩ See the confidentiality gap for why it is not a general answer.

Sources

  • sine-data-commons-2022 — sources/whitepapers/2022-04-25-data-commons-final.pdf (original framework, incl. the three values above)
  • sine-dpp-data-commons-2023 — sources/whitepapers/2023-04-12-sine-whitepaper-final.pdf (DPP-specific operationalization, the 17 questions above)
  • Kim et al. (2026) — sources/whitepapers/2026-09-24-kim-essential-variables-biodiversity-standardization.pdf (§5.3, the federation section)
  • sources/research/2026-10-27-oecd-data-spaces-co-ordination-viability-public-policy/2026-10-27-oecd-data-spaces-co-ordination-viability-public-policy.md (§3.1, §3.2, §3.3, Box 1.1) — see the paper page.

Graph View

Backlinks