Identity ledger

@@ -23,7 +23,7 @@ references:
 url: "https://dl.acm.org/doi/10.1145/360825.360855"
---

`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 ledger from raw payloads without operator input.
`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

@@ -35,7 +35,7 @@ references:
| 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.
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

@@ -44,14 +44,14 @@ The three-entity design, abbreviated ACS, is event sourcing applied to identity:
| 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 Chart-of-Accounts socket can be regenerated by replaying the claims |
| 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.
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.
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