Purpose

Map all downstream consumers of a changed interface and assess the impact of the proposed change so that no consumer is surprised by breakages.

Context to Load

1. context-core/variable/integration-registry.md — Registered integrations and consumers
2. context-core/variable/dependency-map.md — System dependency graph

Workflow

Step 1: Identify Changed Interfaces

Accept a description of the proposed change: which API endpoints, event schemas, shared services, data contracts, or libraries are being modified. Classify each change as: addition, modification, deprecation, or removal.

Step 2: Map Downstream Consumers

For each changed interface, enumerate all known consumers from the integration registry and dependency map:

• Direct consumers: Systems that call the API or subscribe to the event
• Transitive consumers: Systems that depend on direct consumers and may be affected
• Internal consumers: Teams within the organisation
• External consumers: Third-party integrations, partner systems

Flag any interfaces not registered in the integration registry (shadow integrations).

Step 3: Classify Impact per Consumer

Step 4: Assess Migration Effort

For each consumer with Breaking or Behavioural impact, estimate:

• Code changes required (trivial/moderate/significant)
• Testing effort (smoke test/regression suite/full retest)
• Coordination needed (async notification/sync alignment/joint release)
• Timeline (same sprint/next sprint/multi-sprint)

Step 5: Generate Impact Matrix

Output a matrix: Consumer, Interface, Change Type, Impact Level, Migration Effort, Coordination, Owner. Include a summary: total consumers affected, breaking changes count, estimated total migration effort.

Step 6: Recommend Mitigation Strategy

Based on impact analysis, recommend:

• Versioning strategy (if breaking changes affect many consumers)
• Migration timeline and sequencing
• Feature flag approach (if gradual rollout is feasible)
• Communication plan for affected teams

Intent Alignment

• Every consumer must be accounted for — unknown consumers are the highest risk
• Breaking changes require explicit migration plans, not just notifications
• Additive changes are preferred over modifications — extend, do not modify
• Shadow integrations (unregistered consumers) must be flagged, not ignored

Escalation Triggers

• Breaking change affects more than 3 downstream consumers
• External consumer is affected by a breaking change
• Shadow integrations are discovered (unregistered consumers)
• Migration timeline exceeds the deployment window
• Changed interface touches payment, auth, or compliance systems

Input

$ARGUMENTS