Public demo scenario, no account needed
From change request to decision ready impact analysis
This is a read only executive walkthrough of what ImpactOS produces for a proposed software change. Every organisation, project, document and object below is synthetic: Northstar Labs and Project Atlas are fictional and the domain is a generic SaaS billing platform. No customer data is shown here.
Choose a scenario
Three synthetic changes of different kinds, to show the analysis is not tied to one shape of change.
Proposed change
API contract change
The Billing API invoice payload gains a required tax breakdown field and drops a legacy total field in the same release train.
A change that looks local to one service turns out to reach the payment path, the downstream event consumers and the customer facing invoice record.
- Intent
- Expose an itemised tax breakdown on every invoice
- Change type
- API contract
- Compatibility
- Breaking
- Scope
- Billing
- Target release
- Phase 2
- Risk tolerance
- Low
Before ImpactOS
The change looks local. A single field on the invoice payload, owned by one team, with no visible dependants and no record of who must approve it.
After ImpactOS
Twelve impacted objects, three critical risks, two unknowns with conflicting or missing evidence, four required approvals and a Change Decision Pack ready to share.
Decision Readiness Score
How ready this change is for a human decision, and exactly what is holding it back.
0 / 100
Deterministic score from the current analysis run
Too much is unresolved for a safe decision. Close the factors below, then rescore.
- Impacted objects
- 12
- Critical
- 3
- Unknown
- 2
- Approvals outstanding
- 3
Why this score?
- Critical impacts: 3 critical impacts on the change pathminus 36
- Approvals outstanding: 3 required approvals not grantedminus 21
- Unknown impacts: 2 impacts could not be scored from the available evidenceminus 16
- High impacts: 2 high impacts on the change pathminus 12
- Conflicting evidence: 2 conflicting sources touching this changeminus 12
- Knowledge readiness: Project knowledge readiness stands at 62 out of 100minus 10
- Open reviews: 3 impacts are still waiting on a reviewerminus 9
- Missing source evidence: 1 impact has no source document behind themminus 5
- Blast radius breadth: 12 impacted objects in scopeminus 2
Decision support score. It reflects only the evidence recorded in this project and is not a probability, a prediction or a guarantee. Critical impacts must still be validated by the responsible team.
Why this score, and how to improve it
The score is deterministic. Every point removed is attributed to a named factor with a fixed limit.
100 of 100 points were removed by the factors below. Each factor is capped, so no single factor can drive the score alone.
Factors and limits
- Critical impactsminus 36 of a possible 36
3 critical impacts on the change path
- Approvals outstandingminus 21 of a possible 21
3 required approvals not granted
- Unknown impactsminus 16 of a possible 24
2 impacts could not be scored from the available evidence
- High impactsminus 12 of a possible 24
2 high impacts on the change path
- Conflicting evidenceminus 12 of a possible 18
2 conflicting sources touching this change
- Knowledge readinessminus 10 of a possible 25
Project knowledge readiness stands at 62 out of 100
- Open reviewsminus 9 of a possible 15
3 impacts are still waiting on a reviewer
- Missing source evidenceminus 5 of a possible 15
1 impact has no source document behind them
- Blast radius breadthminus 2 of a possible 10
12 impacted objects in scope
How to improve this score
- plus 36Review and close the critical impacts, or record why they are accepted.
- plus 21Obtain the outstanding required approvals.
- plus 16Add a source for the unscored objects so they can leave the unknown state.
- plus 12Work through the high impacts and record a determination on each.
- plus 12Resolve the conflicting sources with the owning team.
- plus 10Improve project knowledge coverage by ingesting the missing sources and resolving duplicates.
- plus 9Assign the remaining impacts and record a reviewer determination.
- plus 5Attach the source document behind each impact that has none.
- plus 2Reduce the scope of the change, or split it across releases.
What blocks the decision
- 2 impacts are unknown, so the blast radius is incomplete.
- 2 conflicting sources remain unresolved.
- 1 impact has no source document.
- 3 impacts are still waiting on a reviewer.
- 3 required approvals are not granted.
Decision support only. The score reflects the evidence recorded in this project. It is not a probability, a prediction or a guarantee, and critical impacts must still be validated by the responsible team.
Impacted objects
Each object states why it is reached, the relationship path behind it and how confident the evidence is.
| Object | Type | Severity | Why it is reached | Relationship path | Confidence |
|---|---|---|---|---|---|
| Billing API | API | critical | The invoice response contract changes shape for every consumer of the endpoint. | Change, Billing API | high |
| Payment Processor | Component | critical | The component still reads the legacy total field on the settlement path. | Billing API, consumed by, Payment Processor | medium |
| Invoice Record | Data object | critical | The stored record must carry the breakdown for historical invoices to stay readable. | Billing API, writes, Invoice Record | high |
| Customer Profile Service | Component | high | Tax treatment depends on the profile country, which is owned elsewhere. | Invoice Record, enriched by, Customer Profile Service | medium |
| Invoice regression suite | Test | high | Contract assertions on the invoice payload fail once the field set changes. | Billing API, covered by, Invoice regression suite | high |
| Release Train | Release | medium | Two coupled changes ship together, so the rollback unit is the whole train. | Billing API, delivered in, Release Train | medium |
| Invoice accuracy KPI | KPI | medium | The measure is computed from the legacy total field. | Invoice Record, measured by, Invoice accuracy KPI | medium |
| Invoice display story | User story | low | Acceptance criteria mention the legacy total wording. | Invoice Record, described by, Invoice display story | high |
| Tax breakdown requirement | Requirement | low | The requirement is the origin of the change and stays in scope. | Change, derived from, Tax breakdown requirement | high |
| Invoice versioning decision | Decision | low | An earlier decision set the versioning approach for billing endpoints. | Billing API, governed by, Invoice versioning decision | medium |
| Event Queue | Component | unknown | No source describes who consumes invoice events downstream. | Billing API, publishes to, Event Queue | unknown |
| Legacy total field consumers | Data object | unknown | One source says the legacy total is still consumed, a newer source says it was retired. | Invoice Record, references, Legacy total field consumers | unknown |
12 impacted objects in this synthetic run. Confidence is qualitative on purpose: no probability is claimed.
Unknowns
What the evidence does not support is shown as unknown rather than guessed.
- No source names the downstream consumers of invoice events on the Event Queue.
- Two sources disagree on whether the legacy total field is still read by the Payment Processor.
Evidence chain
Each impact traces back to a source, an excerpt, a location, its freshness and who validated it.
Atlas billing service specification
"The invoice response returns a single total amount. Consumers must not assume a breakdown is present."
Section 4.2, page 11. Last updated two releases ago. Reviewed by the billing architect.
The specification is the reason the removal is treated as breaking rather than additive.
Payment settlement notes
"Settlement reconciles against the invoice total returned by the Billing API."
Paragraph 3. Current release. Not yet validated by a human reviewer.
This is the only source connecting the Payment Processor to the removed field.
Invoice retirement note
"The legacy total field was retired for internal consumers in the previous phase."
Paragraph 1. Current release. Not yet validated by a human reviewer.
This source contradicts the settlement notes, which is why the impact stays unknown instead of being guessed.
Approval readiness
1 of 4 required gates granted.
- Approved
Product
Product lead, Northstar Labs
The itemised breakdown is required for the Phase 2 outcome.
- Pending
Architecture
Architecture review, Project Atlas
Waiting on the Event Queue consumer list.
- Pending
Data
Data steward, Project Atlas
Backfill plan for historical invoices is not agreed.
- Pending
Delivery
Release manager, Project Atlas
Requests the removal moves to a later train.
Change Decision Pack preview
The shareable record a decision maker reads: summary, score, risks, unknowns, evidence and approvals.
Executive summary
A breaking invoice payload change reaches the settlement path, the stored invoice record and the downstream event consumers. Two impacts cannot be scored from the evidence available, and three of four required approvals are outstanding, so the change is not ready for a decision.
- Decision Readiness
- 0 of 100
- Level
- Blocked
- Impacted objects
- 12
- Approvals outstanding
- 3
Decision support only. ImpactOS surfaces what the available evidence supports and what remains unknown. It does not guarantee an exhaustive list of impacts, so critical impacts must still be validated by the responsible team.
Give feedback or request private beta access
Two minutes. It shapes what gets built next, and nothing you send here is used as demo content.