symfonic.services.privacy.registry¶
registry ¶
PRIV-1 — coverage is a registry, not a list somebody remembers to update.
SEC-PRIV-1 defines coverage as "keyed to tenant". The only way that can be checked is if the set of subject-bearing stores is declared where a check can read it — which is what makes "the erasure path MUST be extended before the store accepts tenant data" an architecture rule (T4.4.1) instead of a habit.
SubjectDataStoreRegistry ¶
The set of stores the erasure saga enumerates.
An instance, not a module global: HOST-3 forbids process-global mutable state for per-deployment facts, and two hosts in one process (a test suite, a sidecar, an adopter mounting two agents) must not share an erasure surface neither of them declared.
Source code in src/symfonic/services/privacy/registry.py
participants ¶
Stable order, so a resumed saga sweeps in the same sequence.
register ¶
Add a participant. A duplicate id is an error, not an overwrite.
Silently replacing would drop a live store out of the erasure path and leave a registry that looks complete — the worst of both.