Instability and abstractness
Also known as: distance from the main sequence (D) · stable abstractions principle · zone of pain · zone of uselessness
What it is
Instability is the share of package coupling that points outward: Ce divided by Ca plus Ce. Near 0, incoming coupling dominates. Near 1, outgoing coupling dominates. It does not measure change frequency or safety. Abstractness is the share of public types that are interfaces or abstract classes. Robert Martin's stable-abstractions principle reads the two together: incoming-dominated packages face pressure toward public abstraction, while outgoing-dominated packages can sit farther toward concreteness. Distance shows how far a package sits from that balance.
Why it matters
Picture a package that half your codebase imports and whose public types are concrete all the way down. Maybe that is a deliberately boring foundation. Maybe callers know more about the implementation than they need. The lower-left Zone of Pain gives that question a visible home. The upper-right Zone of Uselessness asks the opposite question about highly abstract, outgoing-dominated packages. In both cases, AtlasArc gives you the position and evidence; the package's job decides what it means.
What a high value usually means
High Instability means outgoing coupling dominates incoming coupling. High Abstractness means most public types are abstract. High Distance means the package sits far from the main sequence, but Distance alone does not identify the zone. Read the X/Y position and the raw Fan-in/Fan-out counts before deciding what deserves attention.
What a low value usually means
Low Instability means incoming coupling dominates outgoing coupling. Low Abstractness means the public types are mostly concrete. Together they place a package in Zone of Pain territory. Low Distance means the package is close to the main sequence by this metric, not that the design is automatically healthy.
When not to overinterpret it
The main sequence is design-pressure evidence, not a law. Small value objects, DTOs, generated contracts, adapters, and deliberately stable concrete APIs can sit far from it for good reasons. Low Abstractness does not mean implementation details are publicly exposed; Relative Visibility answers that question. Do not add interfaces just to move a bubble. Add a boundary when callers genuinely benefit from a smaller, steadier contract.
Where AtlasArc shows it
Instability is available from Java/Kotlin package and TypeScript source-folder dependency graphs. It appears in the selection sidebar, colour overlays in Topology, Matrix, and Composition, package or source-folder metrics exports, and supported subsystem rollups. With JVM abstraction evidence, Hotspots adds the Zone Map preset: Instability on X, Abstractness on Y, and Distance as bubble size and colour.
How AtlasArc computes it
Instability I = Ce / (Ca + Ce), where Ca and Ce count distinct in-scope architecture units with direct incoming and outgoing dependencies. Multiple references along one relationship remain separate edge evidence and do not increase either count. When Ca + Ce is zero, Instability is unavailable rather than 0 or 1. Abstractness A = Nₐ / Nₜ where Nₐ is the number of public abstract types and Nₜ is the total public type count. Distance D = |A + I − 1| and is unavailable whenever A or I is unavailable. Abstractness and Distance require JVM public-type evidence and are unavailable for TypeScript artifact analysis; Instability remains available from TypeScript source-folder coupling.