One person, many bounded relationships

The implementation uses a common identity anchor and distinct application relationships. A relationship can be described by the tuple:

identity reference × audience × purpose × consent state × session × projection

The identity reference answers which represented subject. Audience answers which relying application. Purpose answers why the relationship exists. Consent state answers which proposed operations the person accepted. Session answers which local authenticated continuity is active. Projection answers which bounded reading, if any, the application may receive.

This is a conceptual decomposition, not a new canonical equation. Its value is diagnostic. When an application proposes “Sign in with Wellbeing Identity,” reviewers can ask whether each element has been made explicit or improperly inherited from another context.

4.1 Stable anchor, contextual projection

The document-level DID provides the internal identity anchor. The implementation does not present it as a public human-readable identifier and does not claim a standardized decentralized-resolution method. Value Log uses a short-lived handoff to associate the verified identity reference with an existing private account. ~Cortisol Checker~ uses a separate audience-specific handoff to create its own bounded member session. The Foundation’s public profile route receives a public-purpose projection from Word Wallet only after owner disclosure settings permit it.

The application never upgrades its own input. A renderer cannot decide that a private facet would be useful and fetch it. A relying application cannot treat authentication as publication consent. A public endpoint cannot infer disclosure from the existence of a private projection. Absence is semantically meaningful: it may reflect privacy, inapplicability, unknown state, expiry, revocation, or lack of authorization.

4.2 Purpose limitation in system form

Purpose limitation is often expressed as a policy statement. Here it is also represented by separate routes, audiences, continuation state, sessions, consent records, and projections. Value Log and ~Cortisol Checker~ do not share a relying-application session. Their handoff codes use different audiences. Their approved return locations differ. Their downstream data and consent models differ.

This architecture does not prove that every purpose is legitimate or understandable. It does make inappropriate inheritance easier to identify. If a future application asks to receive an identity facet, that request must be justified in its own projection and consent contract rather than borrowed from the fact that the person authenticated elsewhere.

4.3 Projection is an interface, not a view filter

In weak selective-disclosure designs, a server sends a large profile and the client hides fields it does not intend to display. That is presentation filtering, not disclosure minimization. The omitted data still crossed the boundary, entered caches or logs, and became available to compromised code.

The current Foundation public identity contract takes the stronger approach: Word Wallet constructs the minimized response before delivery. Foundation renders exactly the meaningful fields returned. It has no checked-in private fallback, does not restore omitted facets, and does not use a semantic denylist as a substitute for owner choice. Safe-link validation and output escaping protect rendering; they do not decide disclosure.

The same principle governs sign-in. The absence of profile data is not an incomplete handoff waiting for enrichment. It is the intended contract. If personalization is desired, the application can request a separate projection after explaining the purpose and receiving the relevant authorization. This makes interface review possible: engineers can inspect the sign-in payload independently from the projection schema.

4.4 Continuity without automatic convergence

A shared identity anchor does not mean every application event should update ~WellbeingIdentity. The private ~Cortisol Checker~ V2 interface explicitly reports “Identity update: None.” Value Log’s experimental ~~IdentityState projection is not automatically a canonical identity write. Public profile rendering does not recalculate or ratify state. These distinctions prevent cross-application continuity from becoming automatic behavioural aggregation.

An identity update requires a governed route with declared evidence, authority, method, provenance, and consent. The sign-in handoff merely opens the bounded application relationship from which such a route might later be proposed. Treating login as permission for convergence would undo the architecture’s main privacy benefit.

!Figure 2. Authentication, identity binding, application authorization, consent, disclosure, and session creation are separate layers.