Demo — roadmap · all demos
FlowForge — Production Readiness Roadmap
Generated from the August Production Readiness Review: the recommended fixes the team committed to, phased by the §19.2 arc (stabilize, then see, then institutionalize) and ordered by the §17.9 priority bands.
Created 2026-08-25 · from the source assessment
30% complete — 3 of 10 applicable items done (1 marked not-applicable)
Phase 1 — Stabilize the foundations
The critical and high-priority gaps — stop the bleeding first (0–30 days).
- IN PROGRESSP0effort MMake rollback a tested pipeline stageowner: Priya (Platform)due 2026-09-12
Same pipeline path as deploy, expand/contract schema rules, quarterly rehearsal with the clock recorded.
How to validate it's done
A rollback executed in the last 90 days (rehearsal counts) with recorded duration; one pipeline action, not a document.Why this item exists — traced back to the assessment
From recommendation Make rollback a tested pipeline stage (/prr-test-rollbacks-on-schedule), which solves this finding of the source assessment:
CRITICAL — Critical control not implemented: If today's release broke the service, how would you get back? (rs_rollback_tested)question rs_rollback_tested · answered manual_steps · risk 92.16 CRITICAL
- DONEP1effort MSchedule monthly backup restore drillsowner: Marco (Data)due 2026-09-05
Restore the primary datastore into a scratch environment monthly; record observed RTO/RPO against business needs.
Marked done 2026-09-03 — self-reported; attaching evidence documents the work but never verifies it.
How to validate it's done
A restore drill ran within the last 30 days with recorded RTO/RPO and application-level checks against the restored data.Why this item exists — traced back to the assessment
From recommendation Verify backups by restoring them (/prr-verify-backups-by-restoring), which solves this finding of the source assessment:
HIGH — Control partially met: When did you last successfully restore this service's critical data from backup? (dr_restore_tested)question dr_restore_tested · answered verified_year · risk 41.47 HIGH
- DONEP1effort SRotate all credentials that ever touched a repoowner: Dana (Security)due 2026-08-29
Assume exposed; rotate, then move everything into the managed secret store with rotation enforced by the store.
Marked done 2026-08-28 — self-reported; attaching evidence documents the work but never verifies it.
How to validate it's done
No production credential resolves from a file in git; secret reads are audited and rotations scheduled by the store.Why this item exists — traced back to the assessment
From recommendation Move secrets out of code and config files (/prr-move-secrets-into-manager), which solves this finding of the source assessment:
MEDIUM — Control partially met: Where do this service's credentials (API keys, DB passwords, tokens) live? (sec_secrets_management)question sec_secrets_management · answered manager_no_rotation · risk 31.10 MODERATE
- PLANNEDP1effort MDefine SLOs and an error-budget policy for the APIowner: Priya (Platform)due 2026-09-26
Two user-felt SLIs (availability, p95 latency), objectives baselined from 90 days of real traffic, one-paragraph budget policy.
How to validate it's done
Every tier-1 service has a documented SLO with its SLI definition; the budget policy exists and burn rate is reviewed weekly.Why this item exists — traced back to the assessment
From recommendation Define SLOs and an error-budget policy (/prr-define-slos-and-error-budgets), which solves this finding of the source assessment:
MEDIUM — Control partially met: When the error budget is exhausted, does anything actually change (release freeze, reliability work prioritized)? (rel_error_budget)question rel_error_budget · answered informal · risk 13.82 LOW
- NOT STARTEDP2effort SMove backups of exports off plain-text storage
The primary datastore is encrypted; the nightly export bucket is not. Close the gap the assessment called out.
How to validate it's done
Backups/snapshots of sensitive stores are encrypted and access-logged.Why this item exists — traced back to the assessment
From recommendation Encrypt sensitive data at rest (/prr-encrypt-sensitive-data-at-rest), which solves this finding of the source assessment:
HIGH — Control partially met: Is sensitive data encrypted at rest (databases, buckets, disks — and their backups)? (dp_encryption_at_rest)question dp_encryption_at_rest · answered primary_only · risk 41.47 HIGH
Phase 2 — See what users see
Observability and alerting wired to the new SLOs (30–60 days).
- PLANNEDP2effort MRewire paging to SLO burn-rate alertsowner: Sam (SRE)due 2026-10-10
Multi-window burn alerts; causes become tickets; every page links a runbook.
How to validate it's done
Paging alerts key off SLOs or explicit user-visible symptoms; every paging alert links a runbook.Why this item exists — traced back to the assessment
From recommendation Page on symptoms, not causes (/prr-alert-on-symptoms), which solves this finding of the source assessment:
MEDIUM — Control partially met: When the paging alert fires, how often is it a real user-facing problem? (obs_alert_quality)question obs_alert_quality · answered mixed · risk 20.74 MODERATE
- IN PROGRESSP2effort MAdd distributed traces across the build pipeline boundaryowner: Sam (SRE)due 2026-10-17
Logs and metrics exist; traces stop at the queue. Propagate context end to end.
How to validate it's done
A trace opened from a user-visible symptom crosses service boundaries with consistent context. - NOT STARTEDP2effort SWrite runbooks for the top five failure modes
One page each: detection signal, first three actions, escalation path — owner and review date stamped.
How to validate it's done
Each top failure mode has a runbook with owner and review date; none past review by more than a cycle.Why this item exists — traced back to the assessment
From recommendation Keep runbooks alive for the top failure modes (/prr-keep-runbooks-alive), which solves this finding of the source assessment:
MEDIUM — Control partially met: For the service's top failure modes, what does the on-call engineer have? (ops_runbook_coverage)question ops_runbook_coverage · answered written_runbooks · risk 20.74 MODERATE
- BLOCKEDP2effort SFormalize the on-call rotationowner: Priya (Platform)due 2026-10-24
Blocked on hiring the second EU engineer — today out-of-hours is the author's phone.
Blocked — finish the blocking item first; nothing downstream is ever auto-completed.
How to validate it's done
A rotation with defined escalation and paging covers out-of-hours.
Phase 3 — Institutionalize
Cadences that keep the gains (60–90 days).
- DONEP1effort MQuarterly access reviews with last-used evidenceowner: Dana (Security)due 2026-09-19
Inventory every identity source; review by blast radius; revoke on evidence, not memory.
Marked done 2026-09-15 — self-reported; attaching evidence documents the work but never verifies it.
How to validate it's done
A dated access-review record exists per system within its cadence; unused credentials found were revoked.Why this item exists — traced back to the assessment
From recommendation Run a recurring access review (/prr-recurring-access-review), which solves this finding of the source assessment:
HIGH — Control partially met: Do all privileged (production) human paths require MFA or hardware keys? (sec_mfa_privileged)question sec_mfa_privileged · answered some_paths · risk 41.47 HIGH
- WONT DOP3effort LEvaluate a DR rehearsal game day (declined for now)
Single-region today; a full game day is disproportionate until the multi-AZ work lands. Revisit after Q4.
Progress = completed applicable items / total applicable × 100 (won't-do items excluded from the denominator). "Done" is an explicit human mark that acknowledges the validation criteria — nothing is verified or auto-completed by marking it. Within a phase, items order by prerequisites first, then priority band, then quick-win effort, then due date.