Implementation status legend

DemozPay's top-level docs (README.md, CLAUDE.md, SECURITY_CONTROLS.md, restructure-2026-05.md, INTERN_PROGRAM.md, per-service READMEs) tag every capability mention with one of the statuses below. Read the status before assuming a capability exists.

A capability that is documented is not necessarily running. Most fintech accidents start with someone reading "X is mandatory" and assuming "therefore X is enforced everywhere right now." These tags remove that ambiguity.

The six statuses

Tag	Meaning	Examples
Live	Implemented, runtime-verified on at least one host, exercised by tests or live boot. Safe to depend on for further work.	RLS migration + verify guard; better-auth sign-up; /api/metrics; Postgres + Redis + Kafka health probes; the 5 financial-tier RLS policies; the ledger's DB-level invariants (balanced commit, append-only triggers, partial unique on reverses_transaction_id).
Partial	Implemented at one layer but not end-to-end. Architecturally correct, but a downstream piece is missing. Do not assume the full capability works in production.	EWA domain package (Live: domain + use cases + unit tests; Pending: live ledger gRPC server). Lending (same shape). Organization plugin (Live: schema + plugin; Pending: auto-member-creation on first sign-up).
Planned	Designed in docs / proto / schema, but no implementation has shipped. Mentioning a Planned capability in a stakeholder conversation is a roadmap claim, not a runtime claim.	BNPL domain. Savings / Equb domains. WebAuthn. mTLS / SPIFFE / SPIRE. Vault dynamic creds. Per-tenant DEKs.
Deferred	Was planned for an earlier phase, intentionally postponed to a later one for a deliberate reason (recorded). Not abandoned, not next.	Legacy Wallet.balance removal (deferred to a domain-extraction sprint). Decimal(15,2) → santim migration on the remaining legacy tables.
Stub	Directory or file exists, the process boots, but the implementation is /health-only or a placeholder route. Looks alive on docker ps. Does nothing useful.	services/integration-gateway/ (Go /health only). services/notifications/ (Go /health only). apps/docs-web/ (Docusaurus template, no content).
Deprecated	Still in the codebase but slated for removal. Do not extend; new code should use the replacement. The replacement is named in the file's comments.	User.password column (replaced by Account.password from better-auth; preserved through the migration window). packages/shared/auth/ (replaced by better-auth in apps/api/src/identity/auth/).

How to apply the tag

Inline at the first mention of the capability in a doc:

- **EWA** `[Partial — domain Live, ledger gRPC server Pending]` — earned wage access…
- **Ledger** `[Live: schema + invariants; Partial: Go server compile-only]` — sole source of money truth…
- **BNPL** `[Planned]` — buy now, pay later…
- **Notifications service** `[Stub]` — `/health` only; SMS sender lives in `apps/api/src/identity/auth/sms-sender.ts`.

When to re-tag

• A Stub becomes Live only after at least one real request flows through it end-to-end on a host other than the developer's laptop.
• A Partial becomes Live only after the downstream piece it depended on is itself Live.
• A Planned becomes Partial the moment the first code lands, even a domain package skeleton.
• A Live should never quietly become Deprecated. The replacement gets its own ADR.

Why we tag

A senior engineer joining the team should be able to read the top-level docs in 30 minutes and know exactly which money paths actually move money today vs. which are aspirational. A fintech auditor reading SECURITY_CONTROLS.md should be able to tell which controls are Live (testable with evidence) vs. Planned (design intent only). Tagging is the cheapest way to give both of them that clarity.