services/service-people
TopicFrom the PointSav Documentation
service-people maintains the Totebox's deterministic identity ledger. It is the F2 surface in os-console and the source of truth for "who" appears in any payload across the Totebox. The data model is built around the Anchor-Claim-Socket (ACS) pattern: identity never overwrites state, claims accumulate over time, and the current picture of any person can always be recomputed from the history. This article covers the three-entity data model, the ACS pattern, and the Infinite Net — the mechanism through which identities enter the WORM ledger from raw payloads without operator input.
[edit]The three-entity data model
service-people organises identity into three distinct entity types:
| Entity | Role | Storage rule |
|---|---|---|
| Target (the Anchor) | A unique person or organisation, anchored by a high-fidelity identifier (email hash, phone hash, professional network URN) | Minimal — a stable Sovereign-ID and the anchor only; volatile fields (job title, employer) are not stored here |
| Claim (the Observation) | Every piece of data attached to a Target: `Target_UUID | Attribute |
| Semantic Socket (the Bridge) | A classification tag mapping the Target to a Chart-of-Accounts row | Recomputed deterministically from claims plus operator overrides |
If an email contact's role is listed differently in two sources, both claims exist in the Totebox. The query layer (service-content and service-slm) decides which claim is current at query time. This prevents data overwrites and preserves the full evolution of every identity.
[edit]The Anchor-Claim-Socket model
The three-entity design, abbreviated ACS, is event sourcing applied to identity: never overwrite state; always append observations; recompute the present from the history. [^1]
| Property | Why it matters |
|---|---|
| Claims are immutable | The audit trail captures the full history of how the system came to know a fact |
| Sockets are reproducible | Any [[archetypes-and-chart-of-accounts |
| Targets are stable | The Sovereign-ID never changes; volatile attributes never trigger a re-keying |
[edit]The Infinite Net
Identity does not enter service-people only through manual operator input. service-extraction runs Aho-Corasick over every incoming payload — email body, PDF text, DOCX text — and pulls every name, email address, phone number, and organisation it finds. [^2] Each extracted entity receives a Sovereign-ID and enters the ledger in Discovery status.
Over time, service-slm cross-references discovered entities against the Gravity Vectors produced by service-content. If an entity accrues gravity — appearing in payloads aligned with Domains, Archetypes, and Themes — it is socketed to a Chart-of-Accounts row and elevated to active status. If it never accrues gravity (a promotional newsletter sender; a one-time signature), it ages out of the active index after 30 days, remaining in the WORM record but invisible to active search.
[edit]The flat-file substrate
The ledger is a directory of JSON flat files rather than a relational database — portable across infrastructure changes, auditable with standard filesystem tools, and natively compatible with local-model training pipelines that need a stable schema. No database migration is required when fields are added; existing records remain valid as the schema evolves.
[edit]See also
- service-email — the email ingest service that feeds sender records into service-people via service-extraction
- service-content — the Gravity Engine that produces the Gravity Vectors service-slm uses to socket entities
- archetypes-and-chart-of-accounts — the Chart of Accounts that Semantic Sockets map to
- totebox-os — the Totebox that hosts service-people and its WORM storage