Diff: services/service-people
From af1a599 to af1a599
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| title: "Identity ledger" | title: "Identity ledger" |
| slug: service-people | slug: service-people |
| category: services | category: services |
| type: concept | type: concept |
| quality: complete | quality: complete |
| status: active | status: active |
| audience: vendor-public | audience: vendor-public |
| bcsc_class: public-disclosure-safe | bcsc_class: public-disclosure-safe |
| language_protocol: PROSE-TOPIC | language_protocol: PROSE-TOPIC |
| last_edited: 2026-05-15 | last_edited: 2026-05-15 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| paired_with: service-people.es.md | 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." | 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: [] | cites: [] |
| references: | references: |
| - id: 1 | - id: 1 |
| text: "Fowler, M. 'Event Sourcing.' martinfowler.com, 2005." | text: "Fowler, M. 'Event Sourcing.' martinfowler.com, 2005." |
| url: "https://martinfowler.com/eaaDev/EventSourcing.html" | url: "https://martinfowler.com/eaaDev/EventSourcing.html" |
| - id: 2 | - 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." | 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" | 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'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. |
| ## The three-entity data model | ## The three-entity data model |
| `service-people` organises identity into three distinct entity types: | `service-people` organises identity into three distinct entity types: |
| | Entity | Role | Storage rule | | | 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 | | | 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 | | | 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 | | | 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 | ## 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] | 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 | | | Property | Why it matters | |
| |---|---| | |---|---| |
| | Claims are immutable | The audit trail captures the full history of how the system came to know a fact | | | 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 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 | | | Targets are stable | The Sovereign-ID never changes; volatile attributes never trigger a re-keying | |
| ## The Infinite Net | ## 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 record but invisible to active search. |
| ## The flat-file substrate | ## 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. | 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 | ## See also |
| - [[service-email]] — the email ingest service that feeds sender records into service-people via service-extraction | - [[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 | - [[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 | - [[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 | - [[totebox-os]] — the Totebox that hosts service-people and its WORM storage |