Humanity Collective and Humanity Ledger are two names for the same system. Collective is what families and the public see. Ledger is what operators use underneath. Both read from the same recorded events.
Humanity Collective is the public face. Families register a need, receive a private link, and see their place held in view. Visitors can explore Gaza by place, follow help in progress, and join in solidarity — without seeing private contact details.
Humanity Ledger is the operator spine. Coordinators, validators, and implementing partners move each need across a visible lifecycle: who holds it, what is blocking it, what happens next. The workbench is for signed-in operators — not a public browsing surface.
The public surface only shows what the ledger actually recorded. It does not invent outcomes the engine has not stored.
/h/<token>). Only people with the link can open it.The numbers on Collective come from a seeded demo database, not live operations. In the current reviewer seed:
2 families (cases) · 2 tracks (one per sector) · 0 tracks pending confirmation · 0 families with a recorded receipt confirmation · 0 ledger events
Family-sourced confirmations: 0. Source provenance was not recorded for these legacy confirmations, so they are not counted as family-sourced.
Treat every figure as illustrative unless you are running against a live deployment.
Ledger stores the full coordination record: case intake, track state per sector, partner routing, funding allocation, implementer delivery claims, family feedback, and an append-only event log. Operators work in queues, tracks, reports, and the ledger itself.
The public surface never shows phone numbers, full contact names, or internal operator notes. Signed-in operators open the workbench; visitors without credentials are not dropped into operator screens.
If you are reviewing the product, the guided walkthrough at /demo (operator sign-in required in non-demo mode) shows one household’s journey end to end. This about page is the public explanation.
This deployment is a demo. Records are seeded or illustrative. Registrations submitted here are for testing and are not yet acted on by real partners. No real aid delivery results from anything in this demo.
The demo banner at the top of every public page repeats the same warning. Contact email on /contact may not be monitored in demo mode.
In this demo, the operator workbench is open for inspection without sign-in. In a real deployment it requires operator credentials.
When help reaches delivery, the public story uses exactly these words:
The implementer or system recorded that delivery happened. This is a deliverer’s claim — not proof the family received help.
Delivery was recorded; the family has not confirmed receipt yet. The track waits at this stage until feedback exists.
The family’s own feedback is recorded in the ledger. Only when that feedback confirms that assistance arrived, in full or in part, may the public story speak of confirmed receipt.
The event was stored append-only — proof of what was recorded, and when. The ledger does not judge truth beyond the record.
Product canon — spine definition, locked vocabulary, Arabic status lines, and the never-change list — lives in BOARD.md at the repository root. Read it before proposing changes.
Automated proof checks live in tools/proof_test.py. A passing run confirms public registration, solidarity signup, privacy boundaries, and workspace gating behave as documented. The script uses a temporary database — it does not modify the frozen reviewer seed.
Run instructions and the full route inventory are in README.md. This page is the on-site explainer; the README remains the handover document for repository reviewers.
Whether you want to deploy Collective in your area, partner on coordination, or ask a product question — use the contact page.
Get in touch →Implementing partners can also apply via Join as implementer (/join/implementer).