One authoritative service, not five

A customer panel, a CRM chat, a public in-person form, checkout and future loyalty all need to verify a mobile number. Left alone, each grows its own identity logic, and they drift.

The goal is one authoritative mobile-verification service that every surface calls. Adapters may use it; they may not implement competing identity logic beside it.

Fail closed, by default

Duplicate identities do not get merged automatically — they fail closed and wait for manual review. A system that guesses about who a customer is will eventually guess wrong in a way that costs money or trust.

The safe default is to stop and ask, not to proceed and hope.

Design before runtime

The first version registers no authentication endpoint and no hook, and performs no migration, database write, cookie or provider call. Its runtime is deliberately non-operational.

That is not incompleteness — it is sequence. The architecture decision, API contract, data model, security sequences and threat model exist and are approved before anything can execute.

Staged approval gates

Production stays read-only until explicit, staged approvals are supplied: design, staging, migration, shadow, internal acceptance, pilot, and finally a fresh go/no-go for production.

Each gate authorises only its own step. Nothing about the release is automatic, and no gate implies the next.

Why build identity this way

Secrets, OTP values and full mobile numbers never enter Git or logs. Schema changes are additive, versioned, InnoDB-only, and never run from a public request.

Identity is the one subsystem where moving fast is the same as being reckless. The discipline is the deliverable.

For implementation detail, see Customer Identity Core — showcase and Staging security showcase. You can also browse the project library and the case studies.