DEV Community

Doby Baxter
Doby Baxter

Posted on

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

#opensource #architecture #socialgood #distributedsystems

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 is early, exploratory, and open. This is why it exists, what it is careful not to be, 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.

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 — what does the layer above them look like, and can it be defined in the open?

Where it actually is right now

Early. Genuinely early. The current scope is deliberately conceptual, in four stages:

  1. Define the concepts — a shared vocabulary for people, providers, resources, policies, and entitlements.
  2. Map the relationships — how needs, eligibility, entitlements, and delivery connect across providers.
  3. Find the interfaces — the minimum contract two independent systems need to participate.
  4. Name the open questions — keeping governance, funding, privacy, and authority as explicit questions rather than buried assumptions.

I'm resisting the urge to jump straight to code, because the most valuable thing I can produce right now is a clear, honest structure — including a clear list of the things it cannot yet answer.

How to get involved

This is exactly the stage where a few extra minds change the shape of a thing. 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 README and specification drafts in the repository.
  • Open an issue with a question, a gap, or a hard challenge — governance, privacy, and funding are open by design.
  • Sharpen the models, or research adapters for OpenSPP, OpenG2P, and OpenCRVS.

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

And if you disagree with the premise, that is a useful contribution too. I would rather have the assumptions challenged now, while the whole thing is still a document.

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)