StackScopes
StackScopes models cloud infrastructure as a system that changes through time, not a collection of resources frozen at the moment of the latest scan. The Temporal Cloud Digital Twin Engine maintains the state, relationships, evidence, and operational context needed to understand what an AWS environment looked like at a selected point, how it evolved, and which changes may matter to a workload.
Problem
Current-state inventory answers what exists now. Incidents and risky changes usually require a different answer: what existed immediately before the problem, which relationship changed, and what did the system depend on at that moment?
A deployment can replace tasks, redirect a listener, remove a route, update a role, or rotate a secret reference. A rollback may restore the old configuration before an investigator opens the console. Autoscaling and managed services can replace affected resources. The current environment can therefore look healthy while the evidence behind the incident has disappeared.
Events alone are not a complete solution. An API event says an action occurred, but it may not provide the final normalized resource state or every relationship affected. A scheduled observation provides state but may only establish that a change occurred between two collection times. Treating either source as perfect creates false precision.
Static diagrams have another limitation: they preserve design intent, not continuous operational history. They rarely show when a shared dependency appeared, how blast radius grew, or whether a deleted resource was active during an incident.
What We Built
We built a temporal infrastructure model that preserves resource identity while versioning state and relationships. Instead of overwriting the last observation, StackScopes records when a configuration or edge was observed, when it became active according to available evidence, and when it was superseded.
The engine represents several related layers:
- Provider resource identity, such as an AWS ARN or service identifier
- Logical infrastructure identity, such as a declared stack or Terraform address
- Workload identity, such as an application service
- Operational capability, such as authentication or checkout
That separation matters when a deployment replaces a physical resource without changing the workload it serves. The historical record keeps both the old and new resources while showing their continuity at the application layer.
Nodes, relationships, evidence, and important attributes can all have temporal validity. A listener can forward to target group A during one interval and target group B during another. Both facts remain queryable, but only the appropriate relationship appears in a point-in-time view.
Deleted resources are retired from the current graph rather than erased. Their last known configuration, dependencies, ownership, and deletion evidence remain available according to retention policy.
How It Works
Normalize observations
Read-only collectors obtain supported resource and configuration data within approved AWS accounts and Regions. StackScopes normalizes identity, location, type, ownership context, and service-specific configuration without discarding the source evidence.
Every observation receives a collection timestamp and source. Coverage gaps—such as a denied permission, throttled request, or unsupported resource type—are recorded separately so absence is not mistaken for deletion.
Reconcile versions
The engine compares each normalized observation with the most recent known version. An unchanged resource refreshes freshness. A changed resource creates a new version and closes the prior validity interval. A missing resource does not immediately become deleted; reconciliation rules account for partial collection failures and resource-specific behavior.
Relationship extraction follows the same pattern. Explicit configuration references, declared infrastructure, runtime evidence where available, and reviewed context can open, update, or close edges. Each relationship retains provenance and confidence.
Connect events to state
CloudTrail, deployment, alert, and incident events can be attached to relevant resources and topology changes. StackScopes distinguishes event time from observation time. If a collector sees state A at 10:00 and state B at 10:10, an API event at 10:04 can provide likely transition context without pretending that every dependent effect was verified at exactly 10:04.
Build point-in-time views
When a user selects a time, the engine resolves the node and edge versions valid at that point. The result is a historical topology, not a current graph decorated with old events. Filters can scope the view to an account, Region, workload, change window, or incident.
Compare meaningful changes
Before-and-after analysis separates created resources, deleted resources, configuration changes, added dependencies, removed dependencies, and changes to dependency behavior. Routine autoscaling can be grouped at a service layer, while meaningful zonal or stateful replacement remains visible.
Output and Evidence
The engine supports outputs designed for investigation and review:
- A point-in-time infrastructure map
- A configuration and relationship timeline
- Before-and-after topology comparison
- Deleted-resource history
- Changes grouped by deployment or event window
- Historical dependency paths
- Drift between declared, actual, and observed state
- Simulation against a historical topology
Every significant item can show its supporting source, observation time, event context, previous value, current value, and confidence. An investigator can see whether a relationship came from direct AWS configuration, infrastructure-as-code, runtime evidence, or human validation.
Illustrative scenario: A security-group rule is changed at 14:04, new tasks begin failing at 14:10, and a rollback restores the rule at 14:18. A discovery run at 14:30 shows only the restored state. The temporal engine can still show the intermediate rule version, the endpoint path it affected, related events, and the workload dependencies valid during the incident window. This produces a strong investigation path without claiming that temporal proximity alone proves root cause.
Why It Matters
Operational teams need memory that survives rollback, replacement, and deletion. Temporal context reduces the time spent reconstructing infrastructure from unrelated console pages and gives change reviewers a way to understand how topology is evolving.
The model also reveals gradual risk. A shared security group, endpoint, key, or queue can accumulate dependents over months. A current graph shows the resulting fan-out; a temporal graph shows when it grew and which changes introduced it.
Historical simulation supports learning. Teams can ask whether a proposed architecture would change the modeled impact of a past failure, or whether a remediation actually removed the critical path it targeted. Results remain tied to the evidence and coverage available for the selected period.
The value is not unlimited retention for its own sake. It is the ability to connect state, change, dependency, and time around decisions that matter.
Operational Guardrails
The engine is designed around read-only collection. Discovery permissions are separate from any future production action path. Tenant, account, and Region boundaries remain part of resource identity and authorization.
Infrastructure history can reveal sensitive architecture and past access paths. StackScopes applies data minimization, encryption, tenant-aware access, auditability, and configurable retention principles. Secret values are not required to model a secret dependency.
Temporal results expose uncertainty. Observation time is not silently converted into exact change time. Missing collection coverage remains visible. Inferred relationships show provenance and confidence, and retrospective human validation remains distinguishable from evidence recorded at the historical time.
The system does not present a correlated change as automatically causal. It organizes the facts required for investigation and human judgment.
FAQ
Is the temporal twin a complete replay of every AWS action?
No. It combines observed state, supported events, declared changes, and available evidence. Exact replay depends on source completeness and ordering, so StackScopes presents observation bounds and uncertainty where appropriate.
What happens when a resource is deleted?
It leaves the current topology but remains in historical views according to retention policy. The record can preserve its last known state, relationships, and deletion context.
Can StackScopes compare historical and proposed architecture?
Yes. A historical or current topology can be compared with modeled changes from an infrastructure plan, allowing teams to review how dependency paths may change.
Does historical simulation guarantee what would have happened?
No. It evaluates a scenario against the known historical model and stated assumptions. Application behavior, external dependencies, missing telemetry, and managed-service internals can limit fidelity.
Related StackScopes links
StackScopes keeps operational evidence, timestamps, assumptions, and confidence visible. Production-impacting recovery remains subject to policy and human approval.