Social Resource FloorBlueprint · pilot rehearsed end to end on synthetic records · seeking a first pilot in a real setting
Blueprint Explorer
This is the Social Resource Floor blueprint, visualized: a way to see how it works, not a system to deploy. Every record on this page is synthetic, taken from the project's own conformance suite, and nothing you do here leaves your browser.
- ·contracts
- ·fixture records
- ·scenarios
- ·checks, running in your browser
Each view starts with a picture. Select anything in it to see the records behind it and what the runner says about them.
Loading the repository's files…
Where it sits
Social Resource Floor a coordination layer · this blueprint
- Provider registry, government and non-government
- Resource discovery and publication
- Entitlements across every resource type
- Locally defined policy and eligibility
- Identity and consent bridge
- Governance, audit and provenance
open interfaces and adapters
Existing digital public infrastructure
- OpenSPP social-protection orchestration
- OpenG2P benefit delivery rails
- OpenCRVS civil registration
resources delivered
A person or household
A coordination layer above existing systems
The floor does not replace OpenSPP, OpenG2P or OpenCRVS. Each keeps its own mission, and the floor coordinates across them through open interfaces and adapters.
- Government Aown programs, rules, deliverydelivers to its own recipients
- Government Bown programs, rules, deliverydelivers to its own recipients
- NGO, cooperative or community providerdelivers to its own recipients
Each participant joins the same shared layer and keeps delivering to its own recipients.
One participant is already a valid deployment
A single government can run the floor on its own, and it grows into a union of independent providers without changing shape. Every participant keeps delivering to its own people.
- Person or household
- Registry
- Needs and circumstances
- Eligibilitylocal policy
- Entitlementany resource type
- Deliverycash, goods, a service, or access
and back to the person
The same path for every resource type
Food, housing, energy or money: a person moves through the same steps. Money is one delivery method among several, not the organizing principle.
- A recordone JSON document
- 1StructuralIt validates against its area's JSON Schema.
- 2ReferentialIts cross-references resolve to known records.
- 3SemanticInvariants a schema cannot express, such as a figure in a report reaching the threshold the same report declares.
- A verdictthe same one from both runners
Every rule is read from the schemas
No runner keeps its own list of areas, references or invariants. That is what makes adding one a schema edit rather than a code change in every implementation.
schemas/JSON Schema, the source of truthdepends on nothingspecification/the prose intent of each contractconformance/two runners, the fixtures and the scenariosreference/andimplementations/non-authoritative demonstrationsadapters/OpenSPP, a first sliceexplorer/this page
Every other part of the repository depends inward on the schemas.
Everything depends inward on the schemas
The contracts come first. The demonstrations in reference/ and implementations/ are deliberately non-authoritative, and this explorer holds no rules of its own: it runs the project's Node runner.
- Phase 0Foundations✓ done
- Phase 1Core data contracts✓ done
- Phase 2Decision and policy✓ done
- Phase 3Trust: identity, consent, provenance✓ done
- Phase 4Events and interoperability✓ done
- Phase 5Reference implementation and first adapter✓ done
- Phase 6Observability and transparency✓ done
- Phase 7Governance and honest pilot✓ done
- Phase 8Hardening and pilot rehearsal✓ done
Every phase is done
Phases are an order, not a calendar. What the blueprint needs next is not more building but a real setting: a first pilot.
The contracts map
Each box is one contract, drawn from its schema with the version the schema declares. An arrow means a field must name a record of the area it points to. The dashed lines are subject_ref: a person is only ever an opaque handle that leaves the floor and is never resolved, which keeps personal data outside the coordination layer.
Show as a table
Follow the pilot
Show as a table
What if?
Each row is one deliberate change the scenario declares, and the mark sits under the check it should trip. A ✓ means the runner applied the change in your browser and that check, and only that check, noticed it. Choose a row to see the change and everything the runner found.
The verdict map
The suite has not run yet.
Every mark is one verdict the Node runner reached in your browser: a check on the contracts themselves (★), a valid record that passed (●), a record built to be wrong that was rejected for exactly the expected reason (■), a sweep that changed a valid record every way its rules describe (◆), or a scenario verdict (▲). A failure would show as ✕. The line above the marks is the runner's own summary, word for word.
That the Python runner reaches the same verdict on every check is proven in CI, not here: see the cross-check script and the project's pipelines.
Show every verdict as a table
Try your own
Choose a record and the runner checks it in your browser, layer by layer.
Open the editor
Press Ctrl + Enter to check. Nothing is saved: closing the page forgets your edits.