---
schema: foundry-doc-v1
title: "Identity ledger"
slug: service-people
category: services
type: concept
content_type: topic
quality: complete
status: active
audience: vendor-public
bcsc_class: public-disclosure-safe
language_protocol: PROSE-TOPIC
last_edited: 2026-05-15
editor: pointsav-engineering
paired_with: service-people.es.md
short_description: "service-people maintains the Totebox's deterministic identity ledger — the F2 surface in os-console and the source of truth for who appears in any payload across the Totebox, using an Anchor-Claim-Socket data model that never overwrites state."
cites: []
references:
 - id: 1
 text: "Fowler, M. 'Event Sourcing.' martinfowler.com, 2005."
 url: "https://martinfowler.com/eaaDev/EventSourcing.html"
 - id: 2
 text: "Aho, A. V. & Corasick, M. J. 'Efficient String Matching: An Aid to Bibliographic Search.' Communications of the ACM, 18(6):333–340, 1975."
 url: "https://dl.acm.org/doi/10.1145/360825.360855"
---

`service-people` maintains the [[totebox-os|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-design|WORM ledger]] from raw payloads without operator input.

## 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 | Value | Source | Timestamp` | Append-only — claims accumulate over time; no claim is ever deleted |
| 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.

## 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|Chart-of-Accounts]] socket can be regenerated by replaying the claims |
| Targets are stable | The Sovereign-ID never changes; volatile attributes never trigger a re-keying |

## 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-ledger-design|WORM record]] but invisible to active search.

## 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.

## 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