Capability Supply Sourcing and Unified Interaction Request Plane

Audience: Developers sourcing capability, scoring claims, or serving interaction requests. Status (2026-11-09): All capability-sourcing cards done in the backlog; all interaction-request cards done except one deferred location pack awaiting a public-safety customer.

Blueprint sources

Capability supply sourcing unification design note and its backlog.
Unified interaction request plane design note and its backlog.
Seeded declarative values for origin overlays, capability events, request events, soft packs, and the adapter allowlist.

Facts

The platform already has the hooks for a full capability journey — lifelong non-fungible storage, purpose leases, indexability scrubbing, selective presentation, presence, organisation affiliations, sourcing requirements, offers, bindings, criteria-to-match, solver stages, and entitlement values.
The missing piece is one coherent subject model so a labourer, an organisation, and a non-fungible entity (home, car, pump, parcel) are all sourcable the same way, changes emit events that update match indexes without hot-path matching, and redaction, search, extract, and hydrate sit under one disclosure control plane.
The request side mirrors the same discipline: one name-typed claim records who asked for what, messages, assignments, forks, meter clocks, fulfilment, and closure, so support, emergency, commerce, community, claim-assist, and government share one spine instead of parallel vendor-shaped desks.

1. Unified thesis — adapter neutrality

Do not invent labourer-specific, provider-specific, or asset-specific tables. Unify on the canonical claim plus the lifelong entity face plus the resource face plus organisation affiliation plus indexability, lease, and query-profile values plus the sourcing and criteria outbox.

Do not invent a parallel accumulator or meter engine. Hot capacity and counters stay on the event-bus counter plane and changes normalise to entity state, then facet watch, then a fired match. The gap is wiring the change to the delta plus pack-declared meter keys.

Disclosure is one plane across search and prefilter, match explain, lease grant, selective presentation and predicate, hydrate, and intelligence extract. Child scopes and packs may only narrow allow lists under a ceiling invariant.

Public interfaces, open API, and customer documentation must not name third-party workbench, ticketing, enterprise-resource, or commerce products. Vendor systems exist only behind the integration plane, addressed by opaque adapter classes. The allowlist of opaque classes is the single source of truth — twelve classes covering workbench, commerce, fleet, housing, enterprise-resource, payments, identity registry, content authority, credential board, safety, notify, and public-safety answering point — with the quota meter internal-only. Pack stubs must stay within it.

2. Baseline data-source concept

The baseline data source is the declarative entity profile: indexability values that declare which facets are searchable and which sensitive facts are denied by default; lease-purpose values that declare which bounded disclosure purposes exist; and query-profile values that declare what a given consumer may see and whether hydrate is forbidden. A person profile covers capability facets only; a building and an organisation profile deny owner, financial, and occupant details. A sourcing consumer forbids hydrate and applies to every principal kind. Rules resolve by region key, validate traits against the allowlist plus required-any, and refuse unknown regions or traits; the service never branches on a country.

3. Use-case page — onboard a provider

A provider with an existing organisation plus affiliation is onboarded in three steps, each with its own ledger entry: affiliation, bounded-TTL lease grant under the sourcing purposes, and expose-plus-publish of a sourcable offer with a scrubbed claim and an outbox delta. Missing indexability or query-profile values refuse rather than inventing. After onboarding, the provider is searchable and matchable like any other principal.

4. Use-case page — score a claim

A capability or entity change is scrubbed through indexability, published as an offer or capacity delta only when the principal opted into sourcing exposure, enriched with criteria (geography, trait, entitlement), then fired as matched or rejected with a reason. An optional solver stage may run before bind plus execution proof. Presence going offline deactivates the offer with a negative meter delta and a wake; a down counter plane refuses rather than inventing. The sourcing query profile forbids hydrate and applies through a shared enforcer.

5. Use-case page — serve an interaction request

An interaction request is a name-typed claim under the request hierarchy with one of seven scenarios (support, emergency, commerce, community, claim-assist, government, plus the base request). Create, message, and assign are soft; the transition and outbox reuse the claims lifecycle rather than a parallel stack. Forking creates a parent with one or more children on one correlation identity, with ceiling enforced and fork and child events emitted. Links attach to claims, orders, sourcing, entities, or incidents and merge without clobbering. Meter clocks resolve hierarchically up the organisation ancestry: child narrows parent, widening is reported not applied, unknown scopes fail closed. Threading binds opaquely to a chat room without exposing article identities; vendor identities refuse. Emergency requests carry urgency, certainty, event codes, geography, onset, and expiry in a soft schema. Regional alerting profiles derive outbound formats, ingest inbound formats with sender allowlists and structural validation, and refuse spoofed or invalid input. Distribution to multiple agencies, resource availability from links plus meter-plane readback, and situation reports from the voyage share the same sanitised projection. Participant roles resolve on fork children; a cannot-fork role refuses. External workbenches mirror only through the universal mirror; vendor references are demoted to opaque references. The legacy desk is a shim to this spine with deprecation and successor headers.

6. Event and pack shapes

Capability events: entity minted or changed, indexable facet patched, credential or capability updated, presence changed, lease granted revoked or expired, entitlement delta, requirement or bind. Request events: a ten-kind catalogue including the gate receipt. Capability packs extend dictionary emission lists for starter, sourcing, property, and dispatch lines, validated as a subset of the capability catalogue. Request packs hold four soft packs: multi-agency emergency, support escalation, commerce issue-order, and industrial hire-house-haul with fleet, housing, and content-authority stubs; instantiation refuses unknown emissions and non-allowlisted stub classes. Outbound shapes derive from declarative profiles rather than schema forks.

7. Origin concept

Origin as a trait is first-class data: region-keyed overlay values covering Kenya, Tanzania, and a default, resolved by region key with allowlist validation. Origin as a transport header is checked for state-changing requests and used for cross-origin allowance; the optional device-identity header is transport-only. No unified app-key contract exists in the read set beyond a single lookup; the map asserts none.

Open items / gaps

The optional location pack for public-safety jurisdictions is deferred until a public-safety customer exists.
The integrator docs journey ladder plus event list plus disclosure modes remain unchecked in the sourcing acceptance.
Request value names follow the request, capability, pack, and adapter conventions; no separate interaction prefix family exists.