Impact Analysis (DAG)
"This PR changes the
DataTablecomponent — what features across which repos are affected?"
That is the question impact analysis answers. SGD builds a directed acyclic graph (DAG) of your entire system — capabilities, specifications, components, API endpoints, and repositories — and traverses it to show exactly what is affected by any change.
The impact graph
When a developer modifies a shared component, SGD traces the dependency graph to identify every feature and repository that depends on it:
In this example, a change to the DataTable component puts four features across four repositories in amber — they may need review, testing, or version updates.
Node types in the graph
The DAG is built from five node types, each representing a different layer of your system:
| Node type | What it represents | Example |
|---|---|---|
| Capability | A business capability from your capability model | Payment Processing, Client Management |
| Specification | A feature spec within a capability | PAY-REFUND-001, AUTH-SSO-001 |
| Component | A shared UI component or library module | DataTable, AuthProvider, @acme/ui/Button |
| API Endpoint | A REST or GraphQL endpoint consumed by other services | POST /api/payments/refund, GET /api/clients/:id |
| Repository | A GitHub repository in the estate | banking-portal, payment-gateway |
Edges between nodes represent dependencies: a feature uses a component, a repository implements a specification, an API endpoint belongs to a capability.
How impact traversal works
When SGD needs to calculate impact (for a PR, a planned migration, or an ad-hoc query), it performs a forward traversal from the changed node:
- Identify the changed node — A PR modifies a component, an endpoint changes its contract, or a spec is updated
- Find direct dependents — All nodes that have a direct edge to the changed node (features that use the component, repos that call the endpoint)
- Traverse transitively — For each direct dependent, find its dependents (capabilities that contain the affected features, repositories that implement those capabilities)
- Collect affected repositories — The final output is a list of repositories that may need attention, each with a reason chain explaining why they are affected
Impact levels
Each affected node gets an impact level based on the traversal distance:
| Level | Meaning | Example |
|---|---|---|
| Direct | Immediately depends on the changed node | Feature that imports the modified component |
| Transitive | Depends on something that depends on the changed node | Repository that implements a feature using the component |
| Informational | Same capability, no direct dependency | Sibling repository in the same capability — might want to stay consistent |
Where impact analysis is used
PR checks
When a PR modifies a shared component or API contract, the governance check includes an impact summary:
"This PR modifies
DataTable. 4 features across 4 repositories depend on this component. View impact graph →"
This does not block the PR — it gives the author and reviewers context they would not otherwise have.
Release planning
Before releasing a new version of a shared library, the impact graph shows exactly which teams and repositories need to upgrade. No more "send an email to all-engineering and hope."
Onboarding
New developers (and AI agents) can query the impact graph to understand how their repository connects to the wider system. "What depends on the service I am about to change?" is answered instantly.
Migration planning
When planning an org-wide migration (e.g., upgrading a component library version), the impact graph feeds into the migration planner to prioritise repositories by impact and risk.
Building the graph
The DAG is assembled from multiple sources:
- Capability model — Defines the top-level structure (capabilities and their repositories)
- Feature specifications — Define which components, endpoints, and repos a feature touches
- Package dependencies —
package.json,requirements.txt,.csprojfiles reveal library dependencies - Import analysis — Static analysis of import statements to detect component usage
- API contracts — OpenAPI specs, GraphQL schemas, and proto files define endpoint relationships
SGD builds the graph incrementally. Each scan, each PR, and each spec update refines the edges. The graph is never "finished" — it evolves with your codebase.
You don't need a perfect graph
The impact graph is useful even when incomplete. If you only have a capability model and some specs, impact analysis still works for the nodes it knows about. Missing edges are reflected in the DAG completeness dimension of the coherence score — giving you a measurable reason to fill in the gaps.