Social Resource FloorA floor beneath which no person should fall.
The Social Resource Floor is an open, contracts-first blueprint for a universal structure through which people can access the resources needed for basic survival — grounded in being human, not in financial status.
The idea
Human survival should not depend on financial access.
Today, survival is largely financial: people generally need money, banking, employment, or purchasing power to obtain food, housing, energy, healthcare, and other necessities. This project explores a different starting point.
Access to basic survival resources should be grounded in being human, not in financial status.
This does not mean abolishing money, banking, markets, or the wider financial system. The aim is narrower and more fundamental: financial systems should not be the condition that determines whether a person can access the basic resources required to survive. Money becomes one possible resource or delivery method — not the organizing principle of survival.
What is genuinely new here is not reusability — the same platform deployed separately by many institutions, which existing infrastructure already handles well. It is a shared umbrella that independent providers join: several governments among them, alongside municipalities, cooperatives, community groups, and philanthropy — all under one setup, each still delivering to its own people, coordinated against one common, locally-defined floor. The structure is scale-independent: it works run by a single community provider alone, and grows into a union of many providers without changing shape.
What this is
- A blueprint expressed as language-neutral JSON Schemas — the normative source of truth.
- A conformance suite that machine-checks every example against those schemas and their cross-references.
- A coordination layer that sits above existing social-protection systems, not a replacement for them.
- Open interfaces first, so any component — database, identity provider, policy engine — can be swapped without lock-in.
What this is not
- Not yet a deployed, real-world universal social-resource infrastructure.
- Not a replacement for benefit-delivery platforms like OpenSPP or OpenG2P.
- Not a single mandatory product, instance, or vendor everyone must connect to.
- Not blockchain, ledgers, or tokens. Trusted institutions stay at the heart of it.
How it's built
Contracts first. The schemas are the source of truth.
Rather than a single application everyone must run, the project defines the contracts — what a participant must be able to do — and lets anyone implement them. Every part of the repository depends inward toward the schemas. Nothing depends on the reference implementation, which is deliberately non-authoritative.
The payoff of this direction is that the blueprint can be trusted without trusting any one codebase. Two people can build entirely separate implementations, in different languages, and the schemas, not either program, are the shared reference they both work from.
The core data model
Three nouns, one opaque reference to a person.
A provider publishes resources. An entitlement allocates a resource to a subject and names the provider responsible for fulfilling it. The subject is referenced only through an opaque handle held by an external identity system — so personal data never enters the coordination layer.
- id · PK
- type · gov / ngo / community …
- jurisdiction
- delivery_methods []
- id · PK
- type · food / housing …
- provider_id · FK →
- quantity · availability
- delivery_methods []
- id · PK
- resource_id · FK →
- provider_id · FK →
- subject_ref · opaque
- status · delivery
- subject_ref
- held by an external
- identity system
- never resolved here
- never checked
The conformance suite resolves every reference a schema declares, from a resource's
provider_id to an event's consent_ref, and checks that linked records
agree: an entitlement and the decision behind it concern the same person and the same resource,
in the same unit, through a delivery method both sides can operate. subject_ref is
deliberately never resolved: it is a pseudonymous handle resolved elsewhere,
which keeps personal records out of the floor entirely. It is only ever compared with the
records that must agree with it.
Resource types are broad and non-monetary-first
An entitlement moves through a defined lifecycle
// an entitlement, validated against schemas/entitlement/entitlement.schema.json { "id": "ent-food-0001", "subject_ref": "subj-opaque-9f2a", // resolved by an external identity system "resource_id": "res-food-parcel-noord", "provider_id": "prov-communitykitchen-noord", "status": "granted", "delivery": { "method": "in_kind" } }
How it fits
A coordination layer, not a replacement.
The Floor works alongside existing digital public infrastructure — coordinating across providers and resource types through open schemas, events, and adapters, while each underlying system keeps its own mission.
Federation, precisely
Not "decentralized" — four separate properties, each held on purpose.
The word decentralized collapses several distinct questions and often gets read as "blockchain." The blueprint keeps the four properties apart, and states plainly which it does and does not adopt.
Who defines the rules
No single institution governs every deployment. Locally legitimate authority defines a local floor while the structure stays shared.
Who runs it, and where
Locally deployable. There is no mandatory central instance; a locality, network, or provider runs its own and stays interoperable.
Where information lives
Data-minimizing. Personal records stay with the systems that already hold them; participants exchange only what an interaction requires.
How systems communicate
Open, published interfaces any participant can implement. Participation is by capability — no central hub sits in the path of every interaction.
Taken together this is federation — the pattern of email and the web, where no one owns the protocol and anyone can run a participant. It uses no blockchain, ledgers, or tokens, and it does not remove trusted parties: providers, auditors, and operators remain accountable actors in defined roles.
Design commitments
The properties that let strangers trust a shared floor.
These are as much a part of the mission as the vision — they are what makes it safe for many independent parties to join one setup.
Contracts over implementations
Open interfaces and schemas, not one mandatory app. The blueprint says what a component must do, never which product must do it.
Zero vendor lock-in
No required database, cloud, identity provider, payment rail, policy engine, or observability platform. Every subsystem is replaceable.
Federated, not centralized
Independent systems interoperate through published interfaces. No single owner of the protocol — and no blockchain.
Locally deployable
Universal structure, local configuration. Every deployment runs to local policy, resources, eligibility, and law.
Data-minimizing by design
Coordination without centralizing personal data. A subject is an opaque handle; records stay where they already live.
Capability-based participation
A provider implements only the roles relevant to it — publish, evaluate, deliver, record — and joins on that basis.
Governance kept out of the software
Who funds the floor, defines it, and settles questions about it are institutional matters. The software supports governance; it doesn't encode one politics.
The finished structure
What's actually built.
The blueprint is complete and machine-verified end to end. Below is the whole shape as it stands in the repository today.
(the contracts)
documents
passing, 0 failures
implementations
adapter
end to end
Checked in the open
Two runners. Different languages. Same verdict on every check.
Interoperability is the whole point of a shared floor, so it is shown working rather than described. Two conformance runners, built in different languages on different JSON-Schema engines, run the same contracts over the same examples. A cross-check confirms they agree, line by line, a differential test gives both engines generated inputs beyond the examples, and CI checks what each of the two implementations actually produces.
schemas
& fixtures
→ ←
Build order
Nine phases, all complete.
Phases are an order, not a calendar: smallest useful thing first, and standing before scale. Every phase now passes its exit criteria.
Foundations Done
Contracts-first repository layout, licensing, and the dependency-inward structure established.
Core data contracts Done
Provider, resource, and entitlement schemas and specs. Resource publication and discovery pass conformance, including a cross-provider union demonstration.
Decision & policy Done
A policy interface that binds existing rules engines rather than inventing one, and a traceable decision record with eligibility folded in as an outcome.
Trust: identity, consent, provenance Done
Identity and authorization as interfaces only (subject stays opaque), append-only consent records with supersedes chains, and provenance for who did what, when.
Events & interoperability Done
An event envelope and capability discovery, aligned to the G2P Connect precedent — a provider declares which areas it publishes, consumes, or both.
Reference implementation & first adapter Done
A self-validating reference implementation and an OpenSPP adapter, both with self-tests running in continuous integration.
Observability & transparency Done
Three telemetry tiers, and a public transparency report that is itself a conformant schema, so a published report can carry no subject. Rebuilt in Phase 8 around a named disclosure method, srf-sdc-1.
Governance & honest pilot Done
A governance model separating the specification from any deployment, the smallest honest pilot scoped out, and a second independent implementation passing the same suite — the standing-to-propose milestone.
Hardening & pilot rehearsal Done
Every rule declared once, in the contracts, and shown to work. The two validation engines brought into full agreement. Room for local needs without a fork. The smallest honest pilot rehearsed end to end, with each implementation checked on its own output. Every event names its publisher, and each publisher works within the roles it declares. And a public report that shares just enough, so every small count stays private, even when figures are set side by side: distinct households, a floor of 10, rounded to 5, one quarter at a time, and derived again from the records in CI.
What comes next
Ship exists. Now: propose, and prove it in the world.
The contracts are done and verified. The remaining work is no longer building the blueprint — it's carrying it into a real setting, carefully and honestly.
Run the honest pilot
One municipality, one resource type, two independent providers, consent-gated end to end, with a real transparency report. It already runs in CI on synthetic records; what remains is a real setting.
A third implementation
Interoperability strengthens with every independent build that passes the same suite. The contracts, not any codebase, remain the authority, and the vocabulary and scenario specifications are written to build one from.
Feed it into policy
Contribute the structure where resilience and social-protection questions are actually being asked — problem-framed, not a finished-product pitch.
Open to contribution
Help sharpen the structure.
The blueprint is complete, machine-checked, and open. That's exactly the point where more minds help: exploring the contracts, building on them, and sharing what you notice. Whether your background is social protection, engineering, policy, or lived experience, there is a way in.