DEV Community

Doby Baxter
Doby Baxter

Posted on Edited on

The Layer Above the Safety Net: Starting the Social Resource Floor

TL;DR: A day after I shipped my first contribution to OpenSPP, an open-source social protection platform, I couldn't stop looking up. Fixing a two-line bug meant tracing how one field moves through a system that decides what real people receive, and when I lifted my eyes from that field, I saw a gap that isn't a bug in any single project. There is no open, shared layer above the delivery systems that coordinates one person's whole access to survival resources, across many providers and many resource types. So I started one: a blueprint, not a product, called the Social Resource Floor. It began early, exploratory, and open. It is now a complete, machine-checked blueprint, still open, and still not a running network. This is why it exists, what it is careful not to be, where it stands now, and where you can help.

It started one layer down

My first OpenSPP contribution was small on paper. A beneficiary's date of birth could be set to a date in the future, which made their computed age render as a negative number across the registry. The fix was a constraint. The education was everything around it: following every path that can write that field, and remembering that on a social protection platform a wrong age isn't cosmetic, because age feeds eligibility.

Doing that work put my hands on the machinery that decides whether a person is seen correctly by the program meant to help them. And it left me with a question that had nothing to do with birthdates. This system delivers benefits well within its mission. But what sits above it? Who coordinates when a single household needs food from one provider, energy help from another, and housing support from a third, across organizations that have never heard of each other?

The thing I couldn't unsee

Right now, for most people, survival routes through financial access. To reach food, housing, energy, or healthcare, you generally need money, and to hold or move money you need banking, employment, or purchasing power. Financial access has quietly become the gate standing in front of the resources a person needs to stay alive.

I want to be exact here, because this idea attracts a more dramatic version of itself that I don't hold. I am not saying money is bad. I am not proposing we abolish banks, markets, or the financial system. Those can keep existing and doing what they do.

The claim is narrower: financial access should not be the condition that determines whether a human can reach the basic resources required to survive. Money becomes one possible resource, and one possible delivery method, not the organizing principle of survival itself. That is a smaller thesis than "replace the economy," and a far more buildable one.

What the Social Resource Floor is, and what it refuses to be

The Social Resource Floor is an open blueprint for a coordination layer that sits above existing social-protection infrastructure. Its job is to let independent systems (government programs, municipalities, NGOs, cooperatives, community providers) coordinate access to survival resources through shared, open interfaces, while each keeps its own mission and its own data.

It is defined just as much by what it does not try to be:

  • Not a replacement for OpenSPP, OpenG2P, OpenCRVS, or any delivery platform. Those systems keep delivering; the Floor coordinates above them.
  • Not universal basic income, and not a bank, a government, or an NGO. It is a structure, not an institution that owns resources.
  • Not anti-money. Cash stays a first-class resource and delivery method.
  • Not, yet, working infrastructure. It is a blueprint: definitions, relationships, and interfaces, developed in the open and checked by machine rather than taken on trust.

Stating the negatives this loudly is the point. Ambition without boundaries is just noise; the boundaries are what make it possible to actually build something.

"Decentralized" was hiding four different questions

Early on I kept reaching for the word decentralized, and I kept confusing myself, until I realized the word was doing four jobs at once. Pulling them apart was most of the clarity:

  • Authority: who defines the rules? No single institution should govern every deployment; the floor is defined locally.
  • Operation: who runs it, and where? It should be locally deployable: anyone can run their own instance and stay interoperable with others.
  • Data: where does personal information live? It should be data-minimizing: data stays with the systems that already hold it, and only what a given interaction needs is exchanged.
  • Coordination: how do independent systems talk? Through open interfaces anyone can implement, with no central hub sitting in the path of every interaction.

Put together, that is not "decentralization" in the crypto sense. It is federation: the same pattern as email and the web, where independent parties implement open standards and no one owns the network. No blockchain, no tokens, no trustless consensus. Just open interfaces and independent systems that agree to speak them.

I expected a crowd. I found building blocks.

I assumed a hundred people were already building exactly this. What I found was better, and more humbling: a lot of serious, excellent work on the pieces, and an open question about the layer above them.

The delivery systems (OpenSPP, OpenG2P, OpenCRVS) are strong and explicitly interoperability-minded. There is real standards work underway too: the Digital Convergence Initiative is developing interoperability standards between identification and social-protection systems, with that same open stack in its demonstrations. None of this is siloed neglect waiting to be rescued, and I won't pretend it is.

What I didn't find was an open, shared abstraction for one person's whole survival floor, coordinated across many providers and many resource types at once. That is the specific question the Floor exists to ask. Framed honestly, it is less "nobody has done this" and more: these are building blocks, so what does the layer above them look like, and can it be defined in the open?

Where it is now

When I first wrote this, the scope was deliberately conceptual, in four stages: define the concepts, map the relationships, find the interfaces, and name the open questions. All four are done, and each turned into something that can be checked rather than only read:

  • The concepts are ten language-neutral JSON Schemas: providers, resources, entitlements, eligibility decisions, consent, provenance, events, capability descriptors, and a public transparency report, sharing one set of common definitions. Money is one resource type among ten, alongside food, drinking water, housing, energy, and healthcare, not the organizing principle.
  • The relationships are declared inside those schemas, beside the fields they govern: a resource must name a provider that exists, and an entitlement must draw on a real resource, in that resource's own unit, and agree with the decision that allowed it.
  • The interfaces are specified in twelve prose documents, and each participant publishes a capability descriptor saying, area by area, what it publishes and what it consumes. A small community kitchen and a national ministry can join the same floor on very different terms.
  • The open questions are still open, on purpose. Each specification ends with its own list, and governance, funding, and privacy stay questions rather than buried assumptions.

Two independent implementations, one in Python and one in Node, check every document against those contracts, and they agree on all 338 verdicts. A first adapter maps OpenSPP providers and resources into the Floor, which brings this full circle to where it started. And the smallest honest pilot (one municipality, one resource type, two independent providers, consent-gated end to end) has been rehearsed in CI on synthetic records. That rehearsal even caught the pilot's own public report leaking two households' outcomes, which is why the report now follows a named disclosure method and says less.

What it still isn't: a running network, a funded pilot, or anything real people depend on yet. The next step is a real pilot in a real place.

How to get involved

The blueprint is complete, which makes this a good moment for outside eyes: it is concrete enough to challenge, and still early enough to change. Whether your background is social protection, engineering, policy, or lived experience of these systems, there is a way in:

  • Read the idea on the live site.
  • Read the specifications and schemas in the repository.
  • Open an issue with a question, a gap, or a hard challenge. Governance, privacy, and funding are open by design.
  • Build a third implementation. The contracts, not my code, are the authority, and the conformance suite judges your output exactly the way it judges mine.
  • Research adapters for OpenG2P and OpenCRVS, or sharpen the OpenSPP one.
  • Tell me about a setting where one municipality and one resource type could host a small, honest pilot.

Live website: https://social-resource-floor-5a9cc0.gitlab.io/
Repository: https://gitlab.com/dobybaxter127/social-resource-floor
Open an issue: https://gitlab.com/dobybaxter127/social-resource-floor/-/work_items

References


The bug I started with was about one field being seen correctly. The Floor is the same concern at a different scale: whether a person can be seen, and reached, by the systems meant to help them, without money being the price of admission.

Top comments (0)