TL;DR — I've been building the Social Resource Floor: an open blueprint for coordinating one person's access to basic survival resources — food, housing, energy, healthcare, and more — across many independent providers, so that reaching those resources is grounded in being human rather than in financial access.
The first blueprint version is now complete: language-neutral schemas, prose specifications, a reference implementation, and a first adapter.
This post is about the engineering choices behind it, and the reasons for each — how it stays a contract rather than a product, how it keeps personal data out of the coordination layer, why it binds to existing standards instead of inventing new ones, and how I check that the contracts are implementation-independent rather than just claiming they are.
The problem the Floor is trying to help with Today, 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 become the gate standing in front of the resources a person needs to stay alive.
The goal of the Social Resource Floor is narrow and specific: to help make it so that financial status is not the condition that determines whether a person can reach the basic resources required to survive.
It does not try to abolish money, banks, or markets — money stays a first-class resource and delivery method.
It aims at one thing: a floor beneath which no person should fall, defined locally, reachable regardless of financial circumstances.
That's the mission.
Everything technical below exists to make that mission buildable by the institutions — governments, municipalities, NGOs, cooperatives, community providers — that would actually run it, without asking any of them to give up their own systems or hand over their data.
Where the Floor sits The delivery systems for social protection already exist and are strong: OpenSPP for orchestration, OpenG2P for delivery rails, OpenCRVS for civil registration.
The Floor is not a replacement for any of them.
It's a coordination layer above them, whose job is to let independent systems coordinate one person's whole survival floor — across many providers and many resource types at once — through shared, open interfaces, while each provider keeps its own mission and its own data.
The whole design follows from that position.
A layer that sits above independently-operated systems and coordinates without owning them has a specific set of constraints, and each of the choices below is an answer to one of them.
Choice 1: Contracts first, implementation second The source of truth is a set of language-neutral JSON Schemas.
Prose specifications describe their intent, a conformance suite validates against them, and a reference implementation demonstrates them — but nothing in the repository is permitted to depend on that reference implementation.
Every dependency arrow points inward, toward the schemas: The guiding rule is interface over implementation: the blueprint says what a component must be able to do, not which product must do it.
The reason is adoption.
If the reference implementation were the source of truth, then "conformant" would quietly come to mean "matches my code," and every participant would inherit my choices of language, database, and framework.
Keeping the schemas authoritative and the reference deliberately non-authoritative means an independent party can build to the same contracts in a different stack and still interoperate.
The concrete guardrail I hold myself to: if an adapter ever imports from the reference implementation, the dependency has inverted, and the project has started shipping a product instead of a contract.
Choice 2: A small data spine The core data model is three nouns: A provider publishes resources.
A resource is something a provider can supply — food, energy, housing, or money, which is one resource type