Context

Delivery systems for social protection already exist and are strong: OpenSPP orchestrates programs and registries, OpenG2P provides delivery rails, and OpenCRVS handles civil registration. What is missing is an open, shared layer above them that coordinates one person's whole survival floor across many providers and many resource types at once, so help can find a person regardless of which organizations happen to serve them.

The Social Resource Floor is a blueprint for that missing layer. The first version is finished, and this record captures the architectural decisions that give it its shape.

Problem

A layer that sits above independently-run systems and coordinates them without owning them faces a specific set of constraints. It must serve a single community provider running alone and a union of many governments joined under one floor, without changing shape between the two. It must not duplicate the delivery platforms beneath it. And because it coordinates across many providers, it is a tempting place for personal data to accumulate, which for a system meant to serve vulnerable people would be exactly the wrong outcome.

Decision

The Floor is defined as a coordination layer, not a delivery system and not a rival to the platforms above it. Three architectural decisions follow, each answering one constraint.

  1. Contracts are the source of truth, not a product. The authoritative artifact is a collection of language-neutral schemas. A reference implementation exists only to demonstrate them, and nothing in the project is allowed to depend on that reference. The rule is interface over implementation: the blueprint says what a component must be able to do, never which software must do it. If the reference implementation were authoritative, "conformant" would quietly come to mean "matches my code," and every participant would inherit one project's language and stack.

  2. Personal data stays out of the coordination layer entirely. A subject is referenced only through an opaque, pseudonymous handle meaning "the same person" without carrying who they are. The coordination layer must not become a place where personal information about vulnerable people piles up.

  3. The Floor is owned by no one and auditable by anyone. No single organization owns the layer that coordinates survival access, and its openness is what lets any participant verify it rather than trust it.

The same structure serves one provider and a union of governments without changing, because it coordinates independent systems through shared interfaces while each keeps its own mission, rules, and data.

Alternatives Considered

Build a new delivery platform

Rejected. The delivery platforms already exist and are strong. A rival would duplicate OpenSPP, OpenG2P, and OpenCRVS instead of filling the missing coordination layer above them.

Make a reference implementation the source of truth

Rejected. It collapses "conformant" into "matches my code" and forces every participant to inherit one stack, which defeats independent interoperability.

Store subject data in the coordination layer

Rejected. Concentrating personal data about vulnerable people across many providers creates precisely the harm the system exists to avoid. An opaque handle is used instead.

Consequences

Positive

  • Independent systems can build to the contracts and interoperate without inheriting one another's stacks.

  • The coordination layer holds no personal data to leak or misuse.

  • No single owner can capture the layer that coordinates survival access.

  • One structure scales from a lone provider to a union of governments.

Trade-offs

  • Contracts-first design is more upfront specification work than shipping a product.

  • Coordinating on an opaque handle constrains what the layer can do directly and pushes identity resolution to the edges.

  • An unowned, auditable blueprint depends on a community to sustain it rather than a single vendor.

Implementation Evidence

  • Repository:

https://gitlab.com/dobybaxter127/social-resource-floor

  • Related article:

https://dev.to/dobybaxter127/a-floor-beneath-every-person-design-choices-in-the-first-social-resource-floor-blueprint-2hb5

Builds On

  • OpenSPP:

https://openspp.org/en/

  • OpenG2P:

https://www.openg2p.org/

  • OpenCRVS:

https://www.opencrvs.org/

Relationship to the Broader Engineering Approach

The same discipline that keeps invalid state out of an execution layer here keeps two things out of a coordination layer: implementation coupling and personal data. Making the contracts authoritative is a boundary decision, and keeping subjects pseudonymous is a decision about what must never be allowed to accumulate at that boundary.

Decision Outcome

The Floor is treated as an authoritative set of open contracts over independent systems, holding no personal data:

Independent delivery systems → shared open contracts (interface over implementation) → coordinated survival floor, no central data, owned by no one

This ADR should be revisited if real deployments show a coordination need that cannot be met without either implementation coupling or holding subject data, in which case the least-harm boundary must be re-derived rather than assumed.