Signal LedgerSynthetic + captured data

Service readiness

What a service has to show before it is accepted into live operation, and what happens in its first 30 days if it goes live with gaps. The services, teams and checklist states are invented; the incident counts are computed from the synthetic signals in the queue. Records captured from real accounts are never counted against these services.

5 ready · 2 conditional · 3 not ready of 10 services

How the status is worked out
Each of the nine checklist items is Met, Partial or Not met. The status follows from them, nothing else.
  • Ready: every item is Met.
  • Conditional: no item is Not met, and at least one is Partial.
  • Not ready: any item is Not met.

Services

ServiceReadinessSince go-live
partner portalPortal Engineering · live 8 Oct 2026Not ready4 incidents
identityIdentity Squad · live 26 Sep 2026Conditional3 incidents
partner apiPartner Integrations · live 21 Sep 2026Ready2 incidents
data platformData Engineering · live 12 Oct 2026Not ready1 incident
internal toolsInternal Tooling · live 14 Oct 2026Ready0 incidents
partner onboardingOnboarding Services · live 15 Oct 2026Not ready0 incidents
workplaceWorkplace Technology · live 7 Sep 2026ConditionalEstablished
paymentsPayments Platform · live 2 Sep 2025ReadyEstablished
authenticationAccess Engineering · live 4 Feb 2025ReadyEstablished
billingBilling Systems · live 21 Dec 2025ReadyEstablished
Closing the loop: checklist gaps and early-life incidents
Across the 6 services live for 30 days or fewer: 10 incidents since go-live.

5 of 10 incidents since go-live hit services where "runbook for each alert" was not met. Those are 2 of 6 early-life services, so the incidents cluster more than the services do.

Marked Not metServicesIncidents
Runbook for each alert2 of 65 of 10
On-call and escalation path agreed2 of 64 of 10
Service level target agreed1 of 60 of 10
Backup and recovery tested1 of 60 of 10
Known errors documented1 of 60 of 10
Support handover completed1 of 60 of 10

A lead is shown only when an item covers at least half the incidents and more of them than its share of services would give by chance. With fewer than three incidents nothing is claimed. This is a small synthetic sample, so read it as the shape of the method, not a finding. Only Not met counts as a gap here; Partial does not.

Changes and recovery

A synthetic change feed. A signal on the same service that opens within the window after a change is linked to it, with the gap and a confidence score as evidence. The figures cover the last 30 days and are computed from these records. Captured (live) records are never linked to changes.

Confidence is 40% for matching the service plus 60% for closeness in time: full marks at a gap of zero, nothing at the edge of the window. Each signal links to at most one change, the most recent.

Change failure rate (DORA)
27%

7 of 26 changes rolled back or caused an incident

Incidents linked to a recent change
18%

24 of 131 incidents

Mean time to restore (DORA)
7h 23m

from 29 high or critical incidents with a resolved time

Mean time to resolve (all tickets)
1d 13h

from 115 resolved signals, routine requests included

ServiceChangesFailedLinkedRestore
authentication10%1 of 35h 20m
billing250%2 of 83h 14m
data platform40%5 of 123h 53m
identity425%2 of 2811h 14m
internal tools10%1 of 817h 12m
onboarding0–0 of 146h 47m
partner api425%2 of 11–
partner onboarding1100%1 of 81h 58m
partner portal333%5 of 92h 45m
payments540%4 of 139h 44m
workplace10%1 of 178h 19m

Failure rate is changes rolled back or that caused an incident, divided by all changes. Restore is the mean of opened-to-resolved over high and critical signals that carry a resolved time, because restoring service after a failure is not the same as closing a routine request. Time to resolve averages every resolved signal, so low-priority tickets that wait for days pull it up. All of it is computed from invented records, so it shows the method, not how any real team performs.

Change feed (26 synthetic changes)
ChangeServiceTypeDeployedOutcomeLinked signals
CHG-1017 Change ingestion batch sizedata platformStandard17 Oct 2026, 08:47 UTCSuccessful1
CHG-1006 Release the redesigned application formpartner portalNormal17 Oct 2026, 08:37 UTCCaused incident4
CHG-1001 Update card-payment routing rulespaymentsNormal17 Oct 2026, 01:47 UTCCaused incident3
CHG-1012 Tune gateway timeoutspartner apiStandard16 Oct 2026, 21:07 UTCSuccessful0
CHG-1026 Raise the login rate-limit thresholdauthenticationStandard16 Oct 2026, 16:07 UTCSuccessful1
CHG-1016 Tighten password policy checksidentityNormal16 Oct 2026, 06:07 UTCSuccessful0
CHG-1025 Add a verification step to onboardingpartner onboardingNormal15 Oct 2026, 13:27 UTCCaused incident1
CHG-1005 Hotfix for duplicate refund notificationspaymentsEmergency15 Oct 2026, 11:47 UTCSuccessful0
CHG-1021 Change invoice rounding rulesbillingNormal15 Oct 2026, 10:07 UTCCaused incident1
CHG-1007 Update portal session handlingpartner portalNormal14 Oct 2026, 05:47 UTCSuccessful1
CHG-1009 Add rate limiting to the partner API gatewaypartner apiNormal13 Oct 2026, 23:07 UTCRolled back1
CHG-1018 Migrate reporting job to the new schedulerdata platformNormal13 Oct 2026, 04:47 UTCSuccessful1
CHG-1014 Update directory sync scheduleidentityStandard12 Oct 2026, 20:27 UTCSuccessful1
CHG-1024 Update the internal request forminternal toolsStandard11 Oct 2026, 22:47 UTCSuccessful1
CHG-1004 Raise connection pool limitspaymentsStandard11 Oct 2026, 07:47 UTCSuccessful0
CHG-1015 Rotate signing keysidentityStandard9 Oct 2026, 05:47 UTCSuccessful0
CHG-1019 Add a partition to the events tabledata platformStandard7 Oct 2026, 18:47 UTCSuccessful2
CHG-1008 Refresh portal static assetspartner portalStandard7 Oct 2026, 03:47 UTCSuccessful0
CHG-1010 Upgrade API gateway runtimepartner apiNormal3 Oct 2026, 13:07 UTCSuccessful1
CHG-1022 Update invoice templatesbillingStandard3 Oct 2026, 01:27 UTCSuccessful1
CHG-1013 Move one-time passcodes to a new delivery routeidentityNormal30 Sep 2026, 22:37 UTCCaused incident1
CHG-1003 Rotate payment gateway certificatespaymentsStandard30 Sep 2026, 21:47 UTCSuccessful0
CHG-1023 Emergency patch for laptop enrolment serviceworkplaceEmergency29 Sep 2026, 17:27 UTCSuccessful1
CHG-1020 Upgrade the pipeline runtimedata platformNormal28 Sep 2026, 06:27 UTCSuccessful1
CHG-1011 Update partner API documentation sitepartner apiStandard26 Sep 2026, 01:07 UTCSuccessful0
CHG-1002 Roll out new settlement batch schedulepaymentsNormal22 Sep 2026, 03:47 UTCRolled back1

Checklists

Change any item and the status, the panel above and the history below recompute. Edits stay in this browser and are recorded in the hash-chained change history.

partner portal
Not ready
Portal Engineering · live since 8 Oct 2026
identity
Conditional
Identity Squad · live since 26 Sep 2026
partner api
Ready
Partner Integrations · live since 21 Sep 2026
data platform
Not ready
Data Engineering · live since 12 Oct 2026
internal tools
Ready
Internal Tooling · live since 14 Oct 2026
partner onboarding
Not ready
Onboarding Services · live since 15 Oct 2026
workplace
Conditional
Workplace Technology · live since 7 Sep 2026
payments
Ready
Payments Platform · live since 2 Sep 2025
authentication
Ready
Access Engineering · live since 4 Feb 2025
billing
Ready
Billing Systems · live since 21 Dec 2025
Your readiness changes (0)
Held in this browser only. Each entry is hashed with the one before it, in the same chain as the correlation history, so editing a stored entry breaks every hash after it.

No changes yet. Change an item above to see it recorded.

Checking the history…