StackScopes
Problem
Traditional recovery plans often become lists of isolated tasks: restore a database, redeploy an application, update DNS, and watch a dashboard. Those actions may be technically correct while the end-to-end service remains unavailable.
A database restore can depend on a KMS key, subnet group, parameter configuration, secret, proxy, application version, and queue reconciliation. A deployment can depend on an identity provider, artifact registry, pipeline, and network path affected by the same incident. A healthy resource does not prove that customers can complete a transaction.
Static runbooks also age. Resource identifiers change, teams reorganize, roles tighten, endpoints move, and failover architecture evolves. During an incident, operators must discover these differences while time is already scarce.
Recovery requires decisions that a document cannot make by itself: which recovery point is acceptable, whether data loss is within the approved objective, who can restore traffic, when evidence is sufficient to continue, and what to do when validation is inconclusive.
What We Built
StackScopes Evidence-Backed Recovery Planner creates a recovery sequence from the current cloud digital twin and a defined service objective. Instead of starting with “recover the account,” it begins with a bounded capability such as accepting orders, authenticating users, or processing queued events.
The planner maps the capability to its runtime, data, identity, network, encryption, deployment, ownership, and recovery dependencies. It categorizes components as required for minimum service, required for safe operation, degradable, deferred, or unknown.
From this model, StackScopes builds a prerequisite graph. Some steps form a strict order; others can proceed in parallel. Cycles are exposed so teams can document a controlled bootstrap or break-glass path before an incident.
Every material step can include:
- Objective and target
- Required prior state
- Execution role and permissions
- Evidence supporting the action
- Expected result
- Human approver and executor roles
- Validation checkpoint
- Failure branch
- Rollback or containment
- Confidence and unresolved assumptions
The planner supports recovery preparation and incident investigation. It does not independently accept data loss, switch customer traffic, broaden access, or execute unrestricted production action.
How It Works
Define the capability and scenario
The user selects a customer-facing or operational capability and a failure scope. “Restore order acceptance after primary database corruption” is more actionable than “disaster recovery.” The scope determines which topology, history, backups, owners, and policies matter.
Build the minimum-service graph
StackScopes traverses typed dependencies from the capability entry point. It identifies authoritative data, required network paths, identities, keys, secrets, queues, external services, observability, and deployment controls.
Redundancy is evaluated through shared dependencies. Two application replicas do not create independent recovery paths if both depend on one unavailable key or resolver.
Apply recovery objectives
Approved recovery time and recovery point objectives are attached to the capability and relevant data domains. The planner does not invent objectives. It presents available recovery-point evidence, backup timestamps, test records, and uncertainty for a human data owner to evaluate.
RTO is decomposed into detection, decision, access, restore, reconfiguration, validation, and traffic restoration. This reveals whether a fast infrastructure action is surrounded by undefined operational delay.
Order actions and approvals
The prerequisite graph establishes a partial order: restore operator access before invoking a deployment, restore encryption before secret retrieval, validate authoritative data before enabling writes, and reintroduce traffic only after capability checks pass.
Production-impacting actions carry explicit approval requirements. The approval context includes target, scope, evidence, predicted effect, rollback, and validation—not only a button.
Define checkpoints
The planner separates control-plane, data, application, capability, and customer-impact validation. Every checkpoint supports pass, fail, and inconclusive states. Absence of an alarm is not treated as success when monitoring is impaired.
Record execution
During controlled recovery, actions, approvers, timestamps, outcomes, and deviations can be recorded. Afterward, the result updates the evidence base for future reviews.
Output and Evidence
The output is an operator-readable plan backed by inspectable graph evidence. It includes:
- Capability and failure scenario
- Minimum acceptable service state
- A dependency-aware sequence
- Parallel and blocked branches
- Required resource identifiers
- Roles, accounts, and Regions
- RTO/RPO context
- Backup or recovery-point evidence
- Validation checkpoints
- Rollback and containment
- Ownership and approvals
- Open questions
Each prerequisite links to its source. A database restore step can show the selected snapshot, KMS key state, subnet group, parameter group, expected application consumers, and last restore-test record. A traffic step can show DNS or gateway paths, TTL assumptions, and synthetic checks.
Freshness remains visible. A topology collected before a migration or an old restore test is useful but weaker evidence. Conflicting sources are not hidden.
The planner can propose a sequence and highlight missing readiness, such as an untested role, unknown queue-reconciliation strategy, or recovery path that shares the failed control. Those findings are not claims that recovery will fail. They identify work that should be resolved or accepted.
Example recovery branch
Consider a hypothetical order service whose primary database must be restored. The database resource is only one branch. The plan verifies the KMS key and subnet group, selects a recovery point through human approval, restores into an isolated target, validates schema and integrity, updates the proxy or secret reference, starts one controlled application instance, and runs an approved synthetic transaction.
Before normal traffic resumes, the plan examines queued events created after the selected recovery point. Those messages may refer to data absent from the restored database. Queue age, retention, deduplication behavior, and business reconciliation determine whether they can be replayed safely. The recovery step therefore links data, messaging, application, and approval evidence rather than declaring success when the database reports “available.”
This example is illustrative. The exact sequence depends on the architecture, failure mode, objectives, and tested procedures.
Why It Matters
Recovery succeeds at the level of a capability, not a resource status page. The planner helps teams connect infrastructure tasks to data integrity, application compatibility, access, traffic, and customer behavior.
Platform teams gain a current view of shared foundations. SREs gain explicit checkpoints and stop conditions. Data owners see where RPO decisions enter the sequence. Security teams retain approval around permission and traffic changes. Incident commanders can coordinate parallel work without losing prerequisites.
Most importantly, the plan explains why an action is present. That makes it easier to challenge stale assumptions, review changes, and learn from exercises.
Operational Guardrails
- Discovery and plan generation use read-only evidence.
- Recovery objectives must be owner-approved.
- Sensitive data is minimized and masked.
- Backup presence is not presented as proven restorability.
- Every important step exposes evidence freshness.
- Data-loss acceptance remains a human decision.
- Inconclusive validation does not silently pass.
- Production remediation uses a separate role and approval.
- Actions and deviations are auditable.
- AI assistance cannot independently execute unrestricted operations.
FAQ
Does the planner replace a disaster-recovery exercise?
No. It strengthens preparation and can support model-based simulation, but restore tests and controlled exercises remain necessary to validate real behavior and timing.
Can it generate RTO and RPO values?
It can organize and test approved objectives, but the values require business and data-owner decisions. They should not be invented from infrastructure state.
Why model recovery as a graph?
Recovery contains prerequisites, parallel branches, shared controls, and cycles. A graph preserves those relationships more accurately than a flat checklist.
Can StackScopes execute the plan automatically?
Planning and execution are separated. Any production action requires a separately authorized, policy-bound workflow with human approval, target validation, and post-action verification.
Related StackScopes links
StackScopes keeps operational evidence, timestamps, assumptions, and confidence visible. Production-impacting recovery remains subject to policy and human approval.