Roadmap ✅ / 🛣️

What's live, what's next, and what's further out — so you can build with confidence and design toward what's coming. This is directional, not a commitment of dates; the changelog records what has actually shipped, and the contract is the source of truth for what exists today.

Legend: ✅ live · 🔜 in progress / next · 🛣️ planned · ⏳ trigger-gated (waits for a specific milestone).

Live today ✅

• Identity (L1): DIDs (did:web/JWK), passkey onboarding, resolution, trust-partner-approved key rotation, human-anchored recovery.
• Consent (L2): purpose-bound grants, ISO/IEC-27560-style receipts, a hash-chained tamper-evident ledger, a public revocation registry.
• Authorization (L3): UMA-pattern data-access tokens, token-type-aware introspection (user vs access; a third delegated shape is defined and unissued), purpose binding on the DPV term, revocation that kills dependent tokens in < 500 ms.
• Sign in with LifeCare.ID: OAuth 2.0 + PKCE federation.
• Consent panel API (/v1/panel/*) — the embeddable data-rights surface.
• Public node verifier at lifecare.id/verify.
• Developer quickstarts, recipes, per-language docs, and the verify-attestation library — clone-and-run, copy-paste, drop-in.
• Self-service sandbox — register your own client and mint a passkey-free test identity, then run the full loop with no access request.
• Sandbox data source: synthetic health data (five personas, interpreted outputs only) served under sandbox consent over REST and MCP, by a reference source that introspects, enforces, records and honours revocation. A test fixture.
• Email magic-link access — unlock the gated docs and sandbox with a one-time email + terms acceptance; operator-controlled whitelist.

Node capability surface — served by the node, not LifeCare.ID ✅ / 🛣️

The health capabilities your app reads live on the node (the resource host), not on LifeCare.ID. They are documented in Build a healthspan app, end to end; their maturity:

• Sense — interpreted context (/dashboard, /workout, /journey, /sources, /profile): ✅ live · a broader queryable context API 🛣️.
• Learn — experience contribute (/experience): ✅ live · consume the network's distilled learning: 🛣️.
• Watch — proactive events (subscribe; the node notifies you): 🛣️ (taxonomy + the events.subscribe grant exist; the watch loop + delivery are next).
• Reason — on-node intelligence over the full context: 🛣️.
• Guard — safety / standard-of-care as a service: 🛣️.

Next 🔜 (developer-experience focus)

Remaining high-impact items from the DX strategy:

• Self-service production registration — issue and rotate production client_id/secret and manage redirect URIs (the sandbox covers this already), the next slice of the developer portal.
• Official SDKs (TypeScript + Python) generated from the contract, and a "try it" console.
• Structured errors (problem+JSON: machine code + message + docs link).
• Scriptable consent states in the sandbox (a synthetic data source is live).

Planned 🛣️

• Push revocation webhooks for data sources (learn of revocation without polling).
• Idempotency keys on mutating endpoints for safe retries.
• Drop-in consent-panel widget (one-snippet embeddable component).
• Source conformance kit & catalogue — verify correct introspection / direct-serve / revocation timeliness; a "LifeCare-compatible source" badge.
• App conformance & attestation governance — the network's immune system: apps are verified to honor the rules (zero-PHI to the AS, honor revocation, no exfiltration), and conformance can be withheld or revoked for a clearly-defined violation, which removes a non-compliant app. This is rules-based removal for cause, not operator discretion — see the bill of rights. When it lands, the rules, evidence, and a due-process / appeal path are defined in the developer terms + conformance spec (the terms must not promise "never removed", which would let bad actors stay). Today only nodes self-attest; app conformance is future work.
• Status page, broader open-source of SDKs/CLI/quickstarts, and a community/feedback front door.
• SOC 2 / formal BAA posture and a vulnerability-disclosure policy (at commercialization).

Trigger-gated ⏳

• Node-DID anchoring: anchor a node's node_key as a resolvable DID via LifeCare.ID. Today a verifier compares the key with the list each node's operator declared (GET /v1/node-keys); with node DIDs it resolves the key from the node's own identity document. Designed (docs/node-did-design.md); waits for the 2nd node.
• Hardware-rooted node attestation — closes the adversarial-operator gap; lands with the hardware backend.
• Personal agents: delegated tokens, agent identities, vouching — the contract shapes are published and inert today: the delegated introspection shape, the reserved did:web:<domain>:agent:<id> namespace, and the manifest + vouching-status schemas in Agent trust. Issuance, registration, and the vouching process wait for the first real agent integration. Write the token_type branch now; nothing will hand you one until then.

Building something and want a capability moved up — or have feedback? See Security & compliance for how to reach the operator, and the developer portal for the self-service future.