Child of Humanity · Unified Stack · Working Draft
The public page describes eight layers modeled on living systems. The architecture brief describes components, readiness states, and a staged path. This document locks the two together: every nature layer mapped to the component that implements it, the interface it appears on, the technology that runs it today, and a straight feasibility verdict on each.
01 · The single stack
The eight layers are not eight products. They are eight concerns of one system, and each resolves into a specific component in the launch architecture. Select any layer to see how it is built at each stage — A (ships now), B (standards), C (research) — and to see it light up across the interface and the exchange trace further down the page.
02 · One product
This is the integration test the architecture has to pass: if the layers can't collapse into a handful of comprehensible surfaces, the system is a research programme, not a product. They can. Select a layer above to see which surfaces it feeds.
03 · One exchange, all eight layers
A single, ordinary transaction — a neighbour books the church kitchen for a canning weekend, paid in Unity — traced through every layer in order. If each layer fires cleanly in one flow, the architecture is coherent. Layers you select above light up here.
The kitchen already exists in the graph as an asset with a steward, availability windows, food-safety terms, and a location. The request "I need a kitchen for Saturday" resolves against that vocabulary rather than a keyword search.
Both parties act under their own identifiers. The church's steward role is a credential, not a database flag. The requester's food-handling certificate is a credential they choose to present, revealing nothing else.
The kitchen's terms require a stewardship history for keyed access. The requester's record — twelve completed exchanges, two returned assets in good condition, one vouch from the garden circle — clears the threshold. Had it not, the NI would have proposed accompanied access instead of refusing.
The NI proposes the church kitchen over two alternatives, and surfaces something nobody searched for: another member is canning the same weekend and has surplus jars. One request becomes a three-party exchange.
Unity moves to the church's commons balance for the access right, and to the jar-holder for goods. Because the church's balance carries demurrage, that value will itself move — into the elder-visit agreements it funds.
The booking is confirmed by both parties and written to the shared record. At launch the nonprofit trust holds that record; the log is built as an append-only event stream precisely so the holder can change without the history breaking.
Access right and Unity transfer in one atomic operation: the right does not exist unless the value moved, and the value does not move unless the right was granted. No one is exposed in between.
The price came from the published index — an eight-hour access block, adjusted for a shared-use discount the church itself set — and the member can see exactly which factors produced the number.
04 · Feasibility
For each layer: can it be built now, what ships in its place if the full version can't, and where the public narrative currently promises more than the stack delivers. The gap notes are the useful part — they are the sentences a technical reviewer will reach for first.
A shared schema is ordinary engineering. What makes it critical is that every other layer inherits it: identity, trust, pricing, and settlement all reference the same entities. Getting the five value classes right in the schema — time, goods, services, access, agreements — is the single highest-leverage decision in the build, because a schema change after launch is a migration of everything.
WatchModelling it HSML-shaped costs design time up front and buys a cheap standards migration later. If that discipline slips in the first quarter, Architecture B becomes a rebuild rather than a migration, and the interoperability story quietly dies.
Member-controlled identifiers and verifiable credentials are mature enough to build on, and the standards work referenced on the public page has landed. The genuine difficulty is not cryptography but recovery and usability: what happens when a member loses their device, and how consent scopes stay comprehensible to someone who has never thought about data permissions.
Gap"No one can extract from you without consent" is true of the credential layer and not yet true of the custodial ledger, which the operator can read. Say custodial phase out loud rather than letting the membrane metaphor imply otherwise.
Behavioural reputation is well-trodden and Bliive-proven. The hard part is not the score; it is the human layer around it — review circles, dispute handling, and elevated vetting for care roles, which touches background checks, safeguarding law, and liability in every jurisdiction differently.
GapThe elevated-vetting design ("elders and community give the final word") is right in principle and unbuilt in practice. It needs a named policy, a documented process, and legal review per jurisdiction before any child- or elder-care matching goes live. Treat it as a launch blocker for those categories only, not for the platform.
Conversational capture plus vector retrieval plus a scored ranking policy is a well-understood build. The uncertainty-reduction term that makes matches feel alive rather than transactional is implementable today as an explicit scoring component — it does not require an active-inference engine, it requires deciding that surprise has value and weighting it.
GapThe efficiency figures quoted publicly come from vendor benchmarks on bounded enterprise tasks. They are not measurements of this workload and should not be presented as predictions for it. Cite them as evidence the approach is real, never as our expected numbers.
Recurring flows, demurrage, commons funds, and cross-community aggregate signals are all standard ledger and data engineering. Nothing here is technically hard.
GapThe binding constraint is legal, not technical. Unity denominating access to housing, vehicles, and land raises questions — barter income, rental income, currency classification, insurance — that differ by jurisdiction and gate business and institutional participation. This workstream, not any engineering task, sets the launch date.
The agent-centric peer-to-peer substrate is live and real, but large social deployments are still proving out, and running domain governance on it from day one would put the riskiest component underneath everything else. The staged answer is right: custodial record with an append-only log designed for exit, then migrate.
GapThis is the widest narrative-to-reality distance in the whole stack. The public page says truth is confirmed peer to peer with no single point to capture; the launch system has a single point, held by the nonprofit trust. Both are defensible — but only if the custodial phase and the migration commitment are stated on the same page as the murmuration.
Both-or-neither settlement inside one ledger is a database transaction — the mutualism property holds completely from day one. Between domains it needs the trustless swap rails, tracked to late 2026.
WatchNothing in the launch depends on those rails. Until they land, inter-domain exchange clears through a published reference rate with the federation as counterparty — slower and less elegant, but sufficient, and it should be described that way rather than deferred to silently.
An administered, published, auditable index covering all five value classes ships immediately and is genuinely defensible: transparent, adjustable by community governance, and legible to members. Pricing derived from measured contribution to collective coherence is a research programme that should be prototyped in simulation on synthetic communities long before it touches a live ledger.
Gap"Value rises as the living world regenerates" describes the research horizon, not the launch. The published version needs a sentence distinguishing the index we run from the physics we are working toward — otherwise the most beautiful claim on the page becomes the one a technical donor tests first and finds unsupported.
Four public claims should be re-checked against primary sources on the day any version of this goes out, because they are the ones a reviewer will verify: the standards ratification dates and their current implementation status; the credential standard's recommendation status; the efficiency benchmark figures and exactly what task they measured; and the cross-domain settlement timeline. All four are load-bearing for credibility and all four are the kind of fact that moves.
05 · Interoperation
Integration is really a question about interfaces. If each layer talks to its neighbours through a stable contract, components can be replaced underneath without touching the product. These are the seams the build should be organised around.
| Seam | What crosses it | What can be swapped behind it |
|---|---|---|
| Schema ↔ everything | Entity records: members, offers, goods, assets, access rights, agreements, places. | Storage moves from relational tables to a graph on the ratified standard without the product changing, provided the entity shapes were right from the start. |
| Identity ↔ trust | Credentials and consent scopes, presented per interaction. | Credential issuance and verification can move to portable, cross-domain form without the trust layer's logic changing. |
| Matcher ↔ everything | A scored list of candidate exchanges, each with the factors that produced the score. | The single most important seam. Behind it: today's ranking service, later an active-inference matcher, eventually per-member agents. The interface — scored candidates plus reasons — never changes. |
| Pricing ↔ ledger | A price, plus the factors that produced it. | The administered index can be replaced by coherence-derived pricing without touching settlement, as long as pricing is always a callable service and never inlined into transaction code. |
| Ledger ↔ consensus | Append-only settlement and governance events. | The custodial record becomes distributed validation. This is the migration that makes the decentralisation promise real, and the event log is its precondition. |
| Domain ↔ domain | Portable identity and trust standing; aggregated, signed community summaries; inter-domain value. | Reference-rate clearing gives way to trustless swaps. Aggregation stays as-is — privacy-preserving summaries were never a stopgap. |