Skip to main content
ArcSight

← Homepage

Impact analysis example

What breaks when you change KafkaJS?

Real arc impact output on KafkaJS — same structure as the homepage demo. Know blast radius before you merge.

Project: KafkaJS · Score: 92.8/100 (Excellent architecture) · 383 modules · 897 edges

Engineering decision simulation

Validation procedure 01 · merge vs. hold before output

Before arc impact

You plan a change to a high fan-in module in KafkaJS. Would you merge without knowing blast radius?

Typical answer: hold — need dependency context.

After arc impact

Structured output below: score, hotspots, corridors, and high-risk modules — same field schema as the homepage proof.

Decision: confirm hold, narrow change, or inspect paths first.

Published as part of the validation record. Run locally: arc impact <file-you-are-changing>

Architectural Risk Map

Where risk accumulates by control surface — drill down Surface → Substrate → Mechanism → Evidence.

See control surfaces →

Dependency evidence

Architecture visualization

Diagrams are generated from ArcSight analysis data. Dependency graph and risk map show key modules; subsystem view shows high-level structure.

Dependency graph
Dependency graph for this codebase
Subsystem architecture
Subsystem architecture for this codebase
Risk map
Risk map for this codebase

Architecture score & metrics

Score: 92.8/100 · Stability: 33/100 · Status: healthy · Confidence: 100%

    Modules to inspect

    One row per module. Fan-in is direct dependents. Blast radius is downstream modules reachable from that file.

    Fan-in, direct dependents
    • src/protocol/encoder75 dependents
    • src/protocol/decoder75 dependents
    • src/protocol/requests/apiKeys65 dependents
    • src/protocol/error49 dependents
    • src/errors41 dependents
    • src/utils/long14 dependents
    • src/protocol/message/compression9 dependents
    • src/utils/websiteUrl3 dependents
    Blast radius, downstream modules
    • src/utils/long309 modules
    • src/errors205 modules
    • src/protocol/encoder192 modules
    • src/protocol/decoder167 modules
    • src/utils/websiteUrl159 modules
    • src/protocol/error156 modules
    • src/protocol/requests/apiKeys152 modules
    • src/protocol/message/compression39 modules
    ModuleFan-inBlastRisk
    src/utils/long14309CRITICAL
    src/errors41205CRITICAL
    src/protocol/encoder75192CRITICAL
    src/protocol/decoder75167CRITICAL
    src/utils/websiteUrl3159CRITICAL
    src/protocol/error49156CRITICAL
    src/protocol/requests/apiKeys65152CRITICAL
    src/protocol/message/compression939HIGH

    Architectural gravity centers

    • src/utils/long— concentrates too many responsibilities
    • src/utils/long— shared utility hub
    • src/errors— concentrates too many responsibilities
    • src/errors— shared utility hub
    • src/protocol/encoder— concentrates too many responsibilities

    CLI workflow

    Scan → Fix → Finish → Watch. Nothing else required.

    • arc scanFind issues
    • arc fixApply fixes
    • arc finishResolve remaining
    • arc watchKeep clean

    More commands (explain, impact, guard…) →

    Key takeaways

    • •Architecture score 92.8/100 indicates a healthy structure with room to reduce cycles and violations.
    • •High fan-in modules are change-risk zones; run arc explain <path> before refactoring.
    • •Run the full workflow (analyze, hotspots, explain, impact, snapshot, drift) in your repo for deterministic architecture insights.

    Run ArcSight on your repo

    Install the CLI and run analyze, then hotspots and explain for the same workflow.

    npm install -g arcsight
    arc analyze
    Install ArcSight →

    This case study is generated from ArcSight analysis data. View short analysis. View all analyses