Evidence, limitations, and roadmap

12.1 What the evidence supports

The repository and production records support the following bounded findings:

• The canonical ~WellbeingIdentity model defines one document anchor and eight nodes with person-controlled disclosure states. Specified.
• Word Wallet operates identity authentication, the active private projection, and owner disclosure controls. Implemented and production-operated for the founding identity.
• Value Log can begin a private session through a short PKCE-bound identity handoff without receiving email or an identity profile in the handoff. Implemented; founding-account production evidence recorded.
• ~Cortisol Checker~ uses a separate audience-bound, one-use, PKCE-bound handoff and creates its own protected session. Implemented; authenticated production canary evidence recorded.
• Checker reflection text and identity facets are absent from the handoff redemption table and structured observation persistence contract. Code-verified and canary-verified within the recorded scope.
• Authentication, application consent, storage consent, public disclosure, projection sync, and protocol update remain separate operations. Implemented across the documented paths.

12.2 What remains unproven

The evidence does not establish:

• independent security, privacy, legal, accessibility, or standards certification;
• full OAuth 2.0, OpenID Connect, DID method, Verifiable Credentials, OpenID4VP, or WebAuthn conformance;
• population-scale reliability, usability, inclusion, comprehension, or cultural validity;
• resistance to every phishing, insider, infrastructure, browser, dependency, or operational attack;
• clinical meaning, biological cortisol measurement, diagnosis, treatment effect, or health outcome;
• that a Wellbeing Identity completely represents a person;
• that continuity should be required by every application;
• that a DID, credential, score, or application record is true merely because it is technically valid;
• coordinated logout or consent propagation across applications; or
• a finalized public developer SDK or canonical relying-application specification.

!Figure 7. Current evidence supports bounded operational feasibility and architectural separation; standards compliance, independent assurance, population validity, and clinical claims remain unproven.

12.3 Roadmap

The next responsible sequence is:

1. complete the author interview and approve the first-person preface;
2. conduct independent identity/security, privacy/ethics, and accessibility reviews;
3. run multi-participant usability research focused on consent comprehension and safe failure;
4. consolidate the handoff implementations into a reviewed shared library with explicit versioning;
5. add automated conformance fixtures for every scenario in Chapter 11;
6. decide whether pairwise identifiers are required to reduce correlation across relying applications;
7. evaluate passkeys for identity-side authentication;
8. evaluate an OIDC-compatible profile without placing private identity projections in default claims;
9. evaluate OpenID4VP only for application purposes that genuinely need credential presentation;
10. propose normative Spec work only after implementation, threat, governance, and migration reviews; and
11. preserve the existing applications and handoff version during any compatibility transition.

12.4 Evaluation framework for the next gate

The next version should be evaluated as a relationship system, not only as a successful redirect. A redirect can complete while the person misunderstands what happened, while the relying application retains too much, or while operators cannot distinguish an expected denial from an infrastructure fault. Evaluation therefore needs multiple units of analysis: the transaction, the application session, the person’s understanding, the operator’s evidence, and the longer lifecycle of correction and withdrawal.

Transaction integrity. Testers should exercise the complete scenario matrix with instrumented synthetic accounts. For each attempt, the evidence record should identify the expected result, observed result, application audience, expiry class, and a sanitized correlation handle. No evidence fixture should contain a live code, verifier, state value, cookie, email address, full identity reference, or participant content. A successful-path percentage alone is insufficient. Reviewers need to know whether every unsafe path failed closed, whether failures were distinguishable without disclosing account existence, and whether retry behaviour created a fresh transaction rather than reviving invalid material.

Disclosure integrity. For each relying application, reviewers should compare four independently derived inventories: what the initiation request permits, what the exchange response actually contains, what the relying application stores, and what the user interface tells the person. The inventories should agree. Network inspection, server schema review, log inspection, and database sampling should all be performed with synthetic identities. This catches a class of errors that interface review alone misses: a field can be invisible to the person yet still be transferred, logged, cached, or retained. Any new field should require an explicit purpose, data owner, retention rule, correction path, and prohibition on unrelated reuse.

Comprehension and agency. Participant research should ask people to predict the consequences of pressing the sign-in button before they press it, then explain the result afterward in their own words. Can they tell which organisation authenticated them, which application now owns the session, what crossed the boundary, what did not cross, and whether a separate consent decision remains? Can they refuse and still understand what functionality is unavailable? Can they later find logout, revocation, correction, and deletion controls? These questions test whether architectural separation is legible rather than merely present in code. Research must include people with varied technical literacy, language, device access, disability experience, and trust in institutions. The present founding-account evidence cannot answer those questions.

Operational accountability. Operators need runbooks that preserve minimization during support and incident response. A support agent should not request a handoff code, verifier, identity document, or private narrative to diagnose a sign-in failure. Dashboards should aggregate error categories without becoming a shadow identity graph. Incident review should establish which authority acted, which audience was affected, how long the condition existed, what records were exposed, and what person-facing remedy is available. Access to evidence stores should be role-limited and reviewed. Retention should be short enough to prevent indefinite behavioural reconstruction while remaining adequate for security investigation and governance obligations.

Lifecycle behaviour. Evaluation should extend beyond initial sign-in. Tests should cover application logout, identity-side logout, session expiry, identity unavailability, relying-application compromise, revoked access, corrected account association, deletion requests, and recovery after loss of an authentication method. Where the system does not coordinate a lifecycle event, the interface must not imply that it does. For example, ending a Value Log session must not be described as ending every Word Wallet relationship unless a verified coordination mechanism exists. Likewise, withdrawing observation-storage consent must not silently delete or alter canonical identity state.

Interoperability discipline. Standards alignment should be assessed property by property, with repeatable evidence, rather than inferred from familiar parameter names. A future OIDC, passkey, credential-presentation, or pairwise-identifier profile would introduce new issuers, keys, claims, ceremonies, metadata, recovery assumptions, and conformance obligations. Each change should be evaluated against the central purpose of the system: continuity without default profile transfer. Compatibility work is successful only if it reduces bespoke risk or increases accountable interoperability without weakening purpose, audience, consent, and disclosure boundaries.

Decision rule. Assurance must combine these dimensions rather than allowing one to compensate for another. Strong cryptography does not excuse confusing consent. Clear copy does not excuse replay. A passing usability study does not certify standards compliance. Production uptime does not prove privacy. Each claim should match the implementation evidence, participant findings, and independent review available for it. When the evidence conflicts, the claim must narrow or the system must change.

Evaluation should also be version-specific. Evidence gathered for one return path, audience, deployment, database policy, or interface revision should not be generalized automatically to another. Every review packet should record the source commit, application version, Spec version, evidence date, environment, and known deviations. When any boundary changes, reviewers should identify which conclusions remain valid and which must be repeated. This makes assurance slower than a marketing declaration, but it keeps a working demonstration from quietly becoming an unlimited claim. A public revision history should eventually describe material security, privacy, consent, and data-contract changes in language that both builders and affected people can understand.

12.5 Conclusion

Sign in with Wellbeing Identity is not valuable because it can make every application know more about a person. Its value is the opposite: it can let a person continue across applications while each application knows only what its bounded relationship requires.

The implementation is modest. Word Wallet authenticates and resolves an eligible identity binding. A relying application proves possession of transaction material and receives a short-lived audience-specific handoff. The application creates its own session. Consent and projection remain separate. Value Log and ~Cortisol Checker~ demonstrate that the same anchor can support materially different private relationships without carrying the same records.

This is not yet an internet standard or an independently assured identity system. It is a testable architecture with two working relying applications, explicit non-claims, and a path toward interoperability. Its governing discipline is simple to state and demanding to maintain: continuity belongs to the person; disclosure belongs to the purpose.