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 — and not an attempt to remove trusted institutions.
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 — decide who is right.
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
- capabilities []
- 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 enforces three references — a resource's provider_id, and
an entitlement's resource_id and provider_id — each must resolve to
a known record. subject_ref is deliberately not checked: it is
a pseudonymous handle resolved elsewhere, which keeps personal records out of the floor
entirely.
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, defines, and disputes the floor are institutional questions. 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
Proven, not asserted
Two implementations. Different languages. Same verdict on every fixture.
Interoperability is the whole point of a shared floor, so it can't just be claimed. Two implementations — built in different languages, on different JSON-Schema engines — run the same contracts over the same examples. A cross-check asserts they agree fixture by fixture.
schemas
& fixtures
→ ←
Build order
Seven 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 discipline 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 — proving a published report can carry no subject and no small cell (floor of 5).
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.
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, the two providers already in the fixtures — consent-gated, end to end, with a real transparency report.
A third implementation
Interoperability strengthens with every independent build that passes the same suite. The contracts, not any codebase, remain the authority.
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 matter — to stress-test the contracts, build against them, and challenge the assumptions. Whether your background is social protection, engineering, policy, or lived experience, there is a way in.