SERVICE_READINESS — lock-integration-service
Bundle: SERVICE_OVERVIEW · SECURITY_MODEL · OBSERVABILITY · TESTING_STRATEGY · FAILURE_MODES · DEPLOYMENT_TOPOLOGY
Cross-cutting: docs/standards/DEFINITION_OF_DONE, docs/standards/SERVICE_TEMPLATE — SERVICE_READINESS.
A go/no-go scorecard for shipping any version of lock-integration-service to production. Reviewed at the release readiness review chaired by the platform lead.
1. Tier definitions
| Tier | Meaning |
|---|---|
| MVP-Internal | Beta with internal hotel pilot (≤ 1 property), full feature set behind a feature flag, vendor sandboxes only |
| MVP-GA | First paying tenant in production, single region, single vendor (TTLock or Salto) |
| GA-Multi-Vendor | Two or more vendor adapters in production for the same tenant |
| GA-Offline | Electron offline-issuance path enabled in production |
| GA-Multi-Region | EU-residency tenants live |
2. Readiness checklist
| Domain | Item | MVP-Internal | MVP-GA | GA-Multi-Vendor | GA-Offline | GA-Multi-Region |
|---|---|---|---|---|---|---|
| Functional | LockPort implemented, all canonical operations | ✅ | ✅ | ✅ | ✅ | ✅ |
| At least one vendor adapter passing contract suite | ✅ | ✅ | ≥ 2 ✅ | ≥ 2 ✅ | ≥ 2 ✅ | |
| Issue saga (reservation.confirmed → key) end-to-end | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Revoke saga (checkout/cancel) end-to-end | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Update saga (date change) end-to-end | — | ✅ | ✅ | ✅ | ✅ | |
| Master-key shift saga | — | ✅ | ✅ | ✅ | ✅ | |
| Vendor webhook ingress (signed) | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Offline issuance via Electron + reconciliation | — | — | — | ✅ | ✅ | |
| Quality | Coverage ≥ targets (TESTING_STRATEGY §10) | partial | ✅ | ✅ | ✅ | ✅ |
| Mutation score ≥ targets on domain + sagas | — | ✅ | ✅ | ✅ | ✅ | |
| Vendor sandbox conformance green ≥ 3 nightly | ✅ | ✅ | ✅ | ✅ | ✅ | |
| k6 load baseline within 10% | — | ✅ | ✅ | ✅ | ✅ | |
| HIL Generic Wiegand checklist within 14d | — | (if used) | (if used) | ✅ | ✅ | |
| Security | Vendor secrets in Secret Manager, per-tenant CMEK | ✅ | ✅ | ✅ | ✅ | ✅ |
| RLS enforced on all tables, audited | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Webhook signature verification per vendor | ✅ | ✅ | ✅ | ✅ | ✅ | |
lock_audit immutability + Merkle anchoring | partial | ✅ | ✅ | ✅ | ✅ | |
| Logging redaction tests pass; secret-scan CI clean | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Penetration test report — no Highs unaddressed | — | ✅ | ✅ | ✅ | ✅ | |
| Offline issuance signing key in KMS, rotation policy active | — | — | — | ✅ | ✅ | |
| Device binding + CRL operational | — | — | — | ✅ | ✅ | |
| Reliability | All saga retries + circuit breakers configured | ✅ | ✅ | ✅ | ✅ | ✅ |
| All failure modes from FAILURE_MODES covered by tests | partial | ✅ | ✅ | ✅ | ✅ | |
| Disaster-recovery drill executed (Cloud SQL restore from PITR) | — | ✅ | ✅ | ✅ | ✅ | |
| Observability | All SLO recording rules deployed | ✅ | ✅ | ✅ | ✅ | ✅ |
| Page-the-on-call alerts wired with runbook links | ✅ | ✅ | ✅ | ✅ | ✅ | |
| SRE dashboards + per-tenant + per-property dashboards live | partial | ✅ | ✅ | ✅ | ✅ | |
| Synthetic vendor checks running per region | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Operability | Runbooks (FAILURE_MODES §1) merged in runbooks/lock-integration/ | partial | ✅ | ✅ | ✅ | ✅ |
| On-call rotation defined, primary + secondary | — | ✅ | ✅ | ✅ | ✅ | |
| Customer-facing status page integration | — | ✅ | ✅ | ✅ | ✅ | |
| Vendor escalation contacts documented per vendor | — | ✅ | ✅ | ✅ | ✅ | |
| Compliance | Data classification mapping reviewed by privacy | ✅ | ✅ | ✅ | ✅ | ✅ |
| Subject-deletion path implemented (pseudonymization) | — | ✅ | ✅ | ✅ | ✅ | |
| Data residency routing implemented and tested | — | — | — | — | ✅ | |
| Documentation | All 17 service docs current (SERVICE_TEMPLATE) | ✅ | ✅ | ✅ | ✅ | ✅ |
| OpenAPI spec published, lint clean | ✅ | ✅ | ✅ | ✅ | ✅ | |
| Event schemas in registry; consumer compatibility checked | ✅ | ✅ | ✅ | ✅ | ✅ | |
| ADR-0004 still reflects implementation | ✅ | ✅ | ✅ | ✅ | ✅ |
3. Sign-off
Each tier requires written sign-off in the release ticket from:
- Service owner (lock domain lead)
- Platform SRE (alerts + dashboards + DR drill)
- Security lead (secret handling, audit, pen-test)
- Product (feature scope, customer comms)
- Tenant operations (for tenant-scoped tier promotions)
4. Exit criteria for each tier
The promotion path is sequential. Skipping a tier requires a written exception approved by the platform lead.
| Promote from → to | Trigger condition |
|---|---|
| MVP-Internal → MVP-GA | 30 days in pilot with no P1 incidents; all checklist items ✅ |
| MVP-GA → GA-Multi-Vendor | Second vendor in production with > 100 issuances and stable health for 14d |
| GA-Multi-Vendor → GA-Offline | Offline reconciliation tested with > 50 real provisional credentials over 30d |
| → GA-Multi-Region | Residency routing tested with at least one EU-tagged tenant in staging for 14d |