StackScopes
Problem
A dependency graph can look authoritative even when its relationships come from very different sources. One edge may be an explicit target-group attachment. Another may be inferred from an environment variable. A third may reflect a trace observed once during a short telemetry window. If the interface renders all three as identical lines, operators cannot judge what the model actually knows.
The same problem affects blast-radius results, incident hypotheses, and recovery recommendations. A result without provenance forces users either to trust the system blindly or ignore it. Neither response supports safe operations.
Cloud evidence is also temporal and incomplete. Configuration can be stale. Runtime telemetry can be sampled. Policies show possible access rather than successful use. Human knowledge can be valuable but outdated. Several sources can contradict one another.
Operational software therefore needs more than an answer. It needs a consistent way to explain why the answer exists, when its evidence was observed, what assumptions were applied, and which facts remain uncertain.
What We Built
StackScopes Explainability and Evidence Layer is a shared data model and interaction pattern used across discovery, dependency intelligence, simulation, change preflight, incident investigation, and recovery planning.
It attaches provenance to resources, relationships, events, findings, and recommendations. Evidence can point to:
- AWS configuration fields
- Infrastructure-as-code definitions
- Deployment state and outputs
- IAM or resource-policy statements
- Network and routing configuration
- CloudTrail events
- Approved telemetry observations
- Ownership catalogs or tags
- Human validation
- Prior simulation or recovery records
Each evidence item can carry source type, source identifier, account, Region, observation time, validity interval, collection status, sensitivity classification, and relevant excerpt or normalized value.
Relationships remain typed. Configuration evidence, policy reachability, runtime observation, and human assertion are not collapsed into one category. Confidence summarizes the strength of a conclusion while the supporting reasons remain inspectable.
The evidence layer does not claim that a high-confidence relationship guarantees application behavior. It provides a disciplined basis for review.
How It Works
Capture source-aware observations
Service adapters and approved evidence collectors emit normalized observations rather than directly declaring universal truth. An ECS task definition can state that a secret ARN is referenced. A security-group rule can state that a network flow may be allowed. A trace can state that an endpoint was called during a time window.
Every observation retains its source. Raw sensitive payloads are minimized; only fields necessary for evidence and explanation are stored.
Resolve entities and relationships
Observations are resolved to canonical graph nodes using account, Region, ARN, provider identifier, deployment binding, and context. Ambiguous references remain unresolved or linked to candidates rather than silently assigned.
Inference rules produce typed edges and attach the evidence used. A relationship can have several independent evidence items. Conflicting evidence is preserved for review.
Represent time
Resources and relationships have observation timestamps and, where supportable, validity intervals. Snapshot comparison can show that a relationship changed between two observations; event evidence may provide a more precise change time.
Deleted resources remain available in historical views under retention policy. This allows incident analysis to inspect the topology that existed before a resource vanished.
Explain confidence
Confidence is not a mysterious percentage. The interface describes the basis: explicit configuration reference, matching runtime observation, policy-only path, stale source, ambiguous target, or human validation.
Severity and confidence remain separate. A weakly evidenced path to a critical resource may deserve investigation even though the model is uncertain.
Propagate evidence into analysis
Simulation results include the dependency paths and assumptions used for propagation. Change findings include the planned field, resolved live resource, traversed edges, and topology freshness. Incident hypotheses cite relevant changes and telemetry. Recovery steps cite prerequisites and validation evidence.
AI-assisted summaries receive bounded, relevant evidence and return references that users can inspect. Unsupported model language should not be promoted into graph truth.
Support correction and review
Authorized users can confirm, reject, or annotate an inferred relationship. Review activity becomes new evidence with author, time, scope, and rationale; it does not erase the original source. If later configuration contradicts the validation, StackScopes can flag the relationship for renewed review.
Evidence rules are versioned. When a resolver changes—for example, when a new AWS field improves the mapping between an event source and consumer—the system can state which rule produced the conclusion. Historical data is not silently rewritten into false certainty. Reprocessing occurs only where retained source material and governance permit it.
This correction loop matters because cloud models are never complete. Explainability makes imperfection manageable: teams can see where a conclusion came from, improve it, and understand which downstream simulations or findings may need reevaluation.
Output and Evidence
The user-facing output is an evidence panel available wherever StackScopes makes an operational claim. It can answer:
- What is the conclusion?
- Which resources and relationships support it?
- Which source produced each observation?
- When was it collected?
- Is the relationship explicit, inferred, observed, or validated?
- What confidence and limitations apply?
- Are sources stale, missing, or contradictory?
- Which accounts or Regions were inaccessible?
- Which assumptions drive a simulation?
- Who reviewed or approved the finding?
For example, a dependency from an application service to a database can show an endpoint reference in task-definition revision 42, a DNS record resolving to a proxy, and an approved trace observation during a defined window. If the infrastructure template points elsewhere, the conflict remains visible as possible drift.
Evidence views are scoped by authorization. IAM paths, tags, telemetry excerpts, and customer or tenant mappings can be sensitive. A user should see only the evidence permitted for their role and tenant.
Exports retain source references and timestamps so a finding does not become an unexplained screenshot detached from context.
Why It Matters
Explainability changes how teams use operational intelligence. Platform engineers can correct wrong resource resolution. SREs can distinguish a configured fallback from one observed under load. Security reviewers can inspect the policy statements behind a path. Incident commanders can separate facts, hypotheses, and missing coverage. Approvers can understand why a production change or recovery step needs additional controls.
Evidence also improves the product over time. Confirmed, rejected, and conflicting relationships reveal where inference rules or collection coverage need work.
The goal is not to make every decision easy. It is to make the basis of the decision visible enough to evaluate.
Operational Guardrails
- Evidence collection is minimized to approved fields.
- Secret values and unnecessary payloads are excluded.
- Source, time, and scope remain attached to findings.
- Missing telemetry is never treated as proof of absence.
- Policy permission is not represented as confirmed use.
- Human assertions include author and review time.
- Conflicts remain visible until resolved.
- AI output cannot create hidden evidence.
- Sensitive evidence follows tenant and role authorization.
- Production actions require separate approval and audit.
FAQ
What is the difference between evidence and confidence?
Evidence is the inspectable source supporting a conclusion. Confidence summarizes how strongly the available evidence supports it. A reviewer should always be able to inspect the reasons behind the confidence.
Does runtime telemetry prove every dependency?
No. It shows selected observed behavior during a defined window and may be sampled or incomplete. Low-frequency, recovery, and failover paths can remain unobserved.
What happens when two sources disagree?
StackScopes preserves the conflict, shows provenance and time, and allows review. Contradiction may reveal drift, stale configuration, a proxy, or incomplete coverage.
Can evidence include sensitive information?
Some metadata and telemetry can be sensitive. Collection is minimized, values can be masked, and access is constrained by tenant and role. Secret values are not required for dependency explanation.
Related StackScopes links
StackScopes keeps operational evidence, timestamps, assumptions, and confidence visible. Production-impacting recovery remains subject to policy and human approval.