System services: schema-authority data services, computed capability profiles, the egress-reachability badge

[lannbot]

Design recorded in NOTES.md — System services: one component kind, capability profiles (from the 2026-08-17 design discussion; leaning, not ruling). This issue tracks making it real.

The design, in brief

• Data services are schema-authority components: a versioned service (polymorph-data:tasks) owns a doc partition — schema, policy, migrations — and multiple apps project it. Engine owns CRDT/crypto/sync mechanics behind the Data services: the polymorph:automerge surface - document as ACL unit, host-side ownership, indexing, encrypted backup #8 surface; one schema authority per doc; singleton service instance per partition serving multi-version facades; apps never touch doc surfaces.
• One component kind: data services and egress providers are not structural types but computed capability profiles. The load-bearing badge is transitive egress-reachability over the composition graph ("pure: this code cannot reach the network") — derived by the linker, cannot lie, handles compositions. Obligations attach to capabilities: doc authority ⇒ singleton/schema/facade rules; egress ⇒ scoping/proxied-fetch/audit + the compound prompt with data authority (Network capabilities: per-destination grants, the app manifest, proxied fetch and the audit log, exfiltration stance #7's flow matrix is the badge's complement for data-mediated flows).
• Splitting (pure-data + egress-adapter) is an engineering choice where it buys failure tolerance — cheap via composition, incentivized (purity earns lighter review) — never a forced classification.
• Defaults: per-app partitions everywhere (shared scopes are explicit grants); refs-by-id across ACL units; blob-attachment pattern via the storage layer.

Deliverables

• polymorph-data:tasks@0.1.0 — the first data service, doubling as TodoMVC end-to-end demo: integrating the UI surface with the engine, both sync paths, and revocation #20's G1 contract (redirect noted there)
• Engine doc-surface capability shape (Data services: the polymorph:automerge surface - document as ACL unit, host-side ownership, indexing, encrypted backup #8): partition-scoped doc handles a service holds; the singleton/schema-authority enforcement point
• The egress-reachability badge: linker-computed transitive property, surfaced at install/review; "pure" as the optimized-for state
• Compound-grant prompt integration with Network capabilities: per-destination grants, the app manifest, proxied fetch and the audit log, exfiltration stance #7 (doc authority × destination)
• Schema-migration decision memo (the data-layer analog of the Group crypto: decision memo - MLS vs DCGKA vs Keyhive/BeeKEM for E2E sync and sharing #9 memo): forward-compatible schemas / read-both windows / migration-as-new-doc / Cambria lenses, under multi-version multi-peer skew
• Curated core-set plan: contacts, calendar, tasks, files/photos — each shipped with a proving app; namespacing for community services
• Threat-model entries (Threat model: the adversary table and the "nothing is both live and trusted" invariant #1): the service principal class, install-time consent weight, partition blast radius, badge caveat (code paths vs data-mediated flows)
• Follow-on demo: three apps, one service (todomvc + kanban + velocity chart over one task partition; chart reads automerge history)

Related: #8 (engine surface), #20 (demo; G1 = tasks service), #7 (flow prompts), #6 (linker enforcement), #13 (apps become thin: UI + service bindings), #10/#19 (sharing/storage under partition = doc).

[lannbot]

Extension recorded in NOTES (§System services, "The consent surface and kernel capabilities"): the unification holds for the consent dialog at the mechanism level (a component with grant-table + trusted-surface and nothing else — pure badge on the thing that grants everything) but not at the trust level — self-reference, the badge bottoming out at its own display layer, and failure-in-kind make grant-table write TCB membership. Resolution: stratified capabilities, one component kind — ordinary (consent-grantable) vs kernel (appointment path: signed release + ceremony; holders enumerated in the #1 TCB statement), with a gradient via attenuation: scoped grant-minting (grant-mint(tasks:*)) enables service-shipped picker components, the powerbox pattern realized. New deliverables implied: the kernel-capability list + appointment-path design (feeds #3 and #6), and the picker pattern in the tasks service plan.