Part I of this series argued that causal architectural metrics should not begin with whatever data happens to be convenient to count. They should begin with an architectural question and identify the causal relation that must be preserved in order to answer it.
The general pattern was:
![]()
Encountered complexity, Total Technical Debt, verification burden, and option entropy illustrated how this approach can diagnose burdens imposed on agents and on future action.
But architecture also depends on preservation.
- Intent must survive movement between layers
- Causal distinctions must survive projection into models and dashboards
- Decision rationale must remain recoverable after the people and circumstances that produced it are gone
- Apparent equivalence must survive changes in analytical resolution
- Local transitions must remain navigable even when average measures suggest that the architecture is healthy
In this Part II we now consider five additional metric families
- Representation fidelity
- Cross-layer transmission fidelity
- Decision-memory recoverability
- Overlap persistence
- Architectural roughness
These metrics are again illustrative rather than exhaustive. They show that the causal framework can generate measures of preservation, loss, recoverability, resolution, and structural condition without collapsing those concerns into a single score.
Fidelity is Always Fidelity to Something
The word fidelity is often used as though it described an intrinsic property of a representation. A model is called high fidelity. A simulation is called low fidelity. A dashboard is described as accurate. A requirements set is described as complete.
But fidelity is never absolute.
A representation can preserve the distinctions needed for one decision while erasing the distinctions needed for another. A model that is entirely adequate for estimating steady-state power consumption may be useless for understanding transient failure propagation. A dashboard that accurately summarizes schedule performance may conceal an architectural dependency that makes the schedule itself fragile.
The first causal question is therefore not
How detailed is the representation?
It is
Which causally relevant distinctions must this representation preserve for the decision being made?
This makes fidelity decision-relative.
Let
represent the architecture,
a representation of it, and
the decision for which the representation will be used. A schematic fidelity measure might be written as
![]()
This is not intended as a literal counting formula in every case. It identifies the relation that must be preserved. The representation must carry forward the distinctions upon which the decision depends.
The denominator is especially important. Fidelity cannot be evaluated without defining what the decision requires. A representation may omit enormous amounts of architectural detail while remaining highly faithful for a narrow decision. Another may contain thousands of precisely maintained elements while failing to preserve a single upstream distinction that determines whether the downstream conclusion is valid.
Detail is not fidelity.
This follows the broader systems engineering emphasis on traceability among needs, requirements, architecture, implementation, and verification. NASA defines bidirectional traceability as the ability to move from a requirement to its parent and allocated children, preserving relationships across decomposition [Nat16, Nat]. Traceability alone does not guarantee fidelity, but it supplies part of the causal structure needed to investigate whether meaning survived transformation.
Representation Fidelity: What Survived the Projection?
Every architectural representation is selective.
A model, diagram, requirement, review package, risk register, simulation, or dashboard includes some distinctions and excludes others. This is not a defect. A representation that preserved everything would cease to function as a useful representation.
The architectural problem is not loss by itself. The problem is the loss of distinctions that later become causally important.
A representation-fidelity metric should therefore ask
What decision-relevant architectural distinctions survived projection into this artifact and which were compressed, merged, or omitted?
Let
denote the set of causal distinctions in architecture
that matter to decision
.
Let
denote the projection that produces representation
. We can describe the preserved set schematically as
![]()
The central diagnostic is then not simply the size of the representation, but the relationship between the distinctions required by the decision and those that remain distinguishable after projection.
A useful representation-fidelity assessment might consider
- Whether relevant alternatives remain distinguishable
- Whether assumptions are visible
- Whether uncertainty is preserved or silently converted into certainty
- Whether dependencies remain traceable
- Whether exceptions and boundary conditions remain visible
- Whether the representation’s limitations accompany it into later decisions
- Whether omitted distinctions can be recovered when the decision context changes
The last two points are crucial.
Representations often travel farther than their original purpose. A model created for one analysis becomes evidence for another. A dashboard designed for operational awareness becomes a basis for investment decisions. A summary prepared for a review becomes the organization’s remembered account of why the architecture is acceptable.
As the representation moves, its original scope and limitations may be lost even when its content remains unchanged.
We can therefore distinguish between the fidelity of the artifact and the fidelity of its use
![]()
where
represents how well the artifact’s decision-use boundaries and known limitations are preserved.
The expression is schematic, but the implication is practical
A representation can remain internally accurate while becoming causally misleading in a new decision context.
This is the danger of second-order representations. The organization may no longer reason from the architecture itself, or even from a direct model of it. It may reason from an evaluation, status color, score, or executive summary derived from that model. Each projection can remove uncertainty and context while increasing institutional authority.
A representation-fidelity metric should therefore diagnose not only what the artifact says, but what it no longer allows the decision-maker to distinguish.
Cross-layer Transmission Fidelity: Did the Intent Survive?
Representation fidelity concerns projection into an artifact.
Cross-layer transmission fidelity concerns the movement of causal meaning through the vertical architecture.
A business objective may be translated into mission needs. Mission needs may be translated into operational concepts, functions, logical structures, physical components, software behavior, verification obligations, manufacturing constraints, service procedures, and governance controls.
Each layer may be internally detailed and locally coherent.
However, the architecture can still fail if the causal distinctions do not survive between layers.
Let the architecture contain layers
. We can represent transmission fidelity from layer
to layer
schematically as
![]()
Again, the expression describes a diagnostic relation rather than a universally computable ratio.
The important distinction is between within-layer resolution and cross-layer fidelity.
A downstream layer may have very high resolution
![]()
while the transmission fidelity remains poor
![]()
This creates a particularly dangerous condition. High downstream detail is built upon a coarse, mistaken, incomplete, or stale interpretation of upstream intent.
The result can look authoritative.
- Software may be thoroughly specified
- Interfaces may be modeled
- Verification cases may be complete
- Manufacturing plans may be detailed
Yet the system may precisely implement an architectural interpretation that no longer supports the business or mission need.
A cross-layer fidelity metric should then ask
Which upstream distinctions must remain causally active downstream, and where were they altered, collapsed, or lost?
Possible observations include
- Survival of mission and business rationale through decomposition
- Preservation of operational context in functional requirements
- Preservation of functional alternatives in physical allocation
- Preservation of architectural assumptions in software and interface specifications
- Consistency between design decisions and verification claims
- Survival of service, manufacturing, regulatory, and governance constraints
- The ability to trace downstream consequences back to the upstream distinction that created them
Cross-layer fidelity need not be symmetric, i.e.,
![]()
An upstream intent may be poorly transmitted downward, while a downstream constraint may be transmitted upward with great force. For example, a manufacturing limitation may reshape the system architecture even though the original business rationale was only weakly preserved in the manufacturing model.
This asymmetry can create architectural inversion as downstream constraints become authoritative while upstream purpose becomes progressively less visible.
A useful diagnostic must therefore consider both direction and locality.
Decision-memory Recoverability: Can the Architecture Explain Itself?
Architectures outlive many of the conditions that created them.
People leave. Teams reorganize. Tools change. Documents are moved or abandoned. Assumptions that were obvious at the time become invisible. Rejected options disappear from the record. A decision remains embedded in interfaces, allocations, standards, tests, and operational procedures even when its rationale can no longer be reconstructed.
Decision rationale has long been recognized as an important architectural asset. Parnas and Clements argued that design documentation should explain the reasoning behind decomposition and interfaces rather than merely record the resulting structure [PC86]. Architectural-decision approaches likewise treat decisions, alternatives, rationale, and consequences as first-class knowledge that should be captured and maintained [TA05, JB05].
The causal framework sharpens the question
Can the organization reconstruct enough of the causal past to safely act on the architecture in the present?
Let
represent the decision context required to reconsider or modify decision
, including
- The problem being addressed
- Alternatives considered
- Assumptions active at the time
- Constraints
- Evidence used
- Rejected paths
- Expected consequences
- Ownership and authority
- Dependencies on adjacent decisions.
Let
represent the portion of that context recoverable at time
. A schematic recoverability measure is
![]()
The denominator is not necessarily the full historical record. Recoverability is relative the required purpose. A minor maintenance action may require little of the original context. Reversing an architectural commitment, reusing the design in a new environment, or defending it in a certification review may require much more.
Decision-memory recoverability can decline even when documentation remains.
Documents may preserve conclusions without alternatives. Requirements may preserve obligations without rationale. Models may preserve structure without the assumptions under which such structure was judged acceptable. Meeting records may preserve discussion without identifying which statement became causally authoritative.
Thus
![]()
Recoverability also has a time dimension
![]()
A negative rate may indicate loss of expertise, tool obsolescence, broken references, organizational separation, or increasing distance between the current operating context and the one in which the decision was made.
Low recoverability also increases both CCC and TTD.
Future agents must rediscover constraints, repeat analysis, infer intent, or preserve questionable structure because changing it is too risky. The architecture becomes more difficult to inhabit and more expensive to alter.
Architecture reviews can therefore be understood as active probes of decision-memory recoverability. A review should not merely ask whether the current artifact is complete. It should test whether the organization can reconstruct the causal reasoning needed to trust, revise, or retire the decision.
Overlap Persistence: Equivalent at What Resolution?
Architectural alternatives often appear equivalent because they are viewed coarsely.
Two designs may satisfy the same summarized requirements. Two processes may produce the same dashboard status. Two implementation paths may have similar cost and schedule estimates.
At one level of resolution, their causal futures overlap strongly.
As resolution increases, however, previously hidden distinctions may appear. One alternative may create a much larger verification burden. Another may preserve business options. One may depend on tacit expertise. Another may export complexity into manufacturing or service. The alternatives were not truly equivalent. The representation was too coarse to distinguish them.
This gives rise to a resolution-dependent question
How long does apparent architectural equivalence persist as analytical resolution increases?
Let
represent the apparent overlap between alternatives
and
at resolution
. We can then examine an overlap-persistence function
![]()
The notation is deliberately simple. The important diagnostic is the shape of the function as resolution changes.
If
![]()
the alternatives remain similar as more distinctions are introduced.
If, however,
![]()
their apparent equivalence collapses rapidly under examination at a finer resolution.
This idea has a useful analogue in causal-set research, where continuum or spatial properties are recovered from discrete causal structure and where causal overlap can be used to characterize relationships across coarse-graining scales [Sur19, MRS07, BK24]. The use here in our causal architectural framework is an analogy rather than a direct transfer of the physical metric. The causal framework asks whether distinctions among architectural futures survive changes in representational or analytical resolution.
A practical overlap-persistence assessment might examine
- Whether alternatives remain equivalent after verification obligations are included
- Whether they remain equivalent across lifecycle phases
- Whether they remain equivalent when business and mission changes are considered
- Whether they remain equivalent from the perspective of different agents
- Whether they remain equivalent when cross-layer consequences are restored
- Whether apparent similarity depends on omitted decision history
Overlap persistence can also expose expertise-limited event collapse.
An inexperienced observer may represent several causally distinct events as one because the distinctions are not yet visible. The resulting coarse representation reduces encountered complexity, but it also reduces fidelity.
A rapidly collapsing overlap function warns that the equivalence is fragile.
A persistent overlap does not prove that two alternatives are identical. It indicates that their apparent equivalence survives the resolutions and causal distinctions examined so far.
Architectural Roughness: Where Does the Landscape Become Difficult?
Many architectural metrics are averages.
- Average complexity
- Average change effort
- Average defect rate
- Average verification cost
- Average cycle time
But agents do not act in averages. They act in particular regions of the architecture and the consequential difficulty may be concentrated in sharp local transitions.
The notion of architectural roughness concerns the uneven distribution of burden, constraint, and transition cost.
A system may have moderate average coupling while containing one interface that dominates integration risk. Average verification burden may be acceptable while one decision requires evidence distributed across several suppliers and regulatory authorities. Average encountered complexity may be low while a single cross-layer boundary overwhelms every team that reaches it.
The causal question we should be asking is
Where do small movements through the architecture produce large changes in burden, constraint, or future possibility?
Let
represent some burden field over architectural locality
. Depending on the analysis,
might represent CCC, TTD, verification burden, transition cost, coupling, or another causal quantity.
A local gradient
![]()
indicates how rapidly the burden changes across neighboring architectural regions. A roughness measure might then depend on the distribution of those gradients
![]()
This is schematic. Its purpose is to show that roughness is not simply the total amount of burden. It is the unevenness that shapes how agents can move.
The landscape metaphor has precedents in studies of complex adaptive systems and design spaces, where rugged landscapes contain many local optima and where local moves do not guarantee global improvement [Kau93, Sim96]. In architecture, the landscape is produced by decisions, dependencies, constraints, memory, evidence, and organizational capability rather than by an abstract fitness function alone.
Architectural roughness may appear as
- Abrupt changes in interface burden
- Local concentrations of TTD
- Sharp increases in verification obligations
- Transitions requiring scarce expertise
- Discontinuities between organizational responsibilities
- Regions where decision memory becomes unrecoverable
- Boundaries across which representation fidelity collapses
- Paths whose cost increases sharply after a commitment is made
Roughness helps explain why a globally reasonable architecture can still be locally uninhabitable.
It also helps explain path dependence.
Agents tend to follow paths that are visible, supported, and locally navigable. A rough region may divert decisions toward a nearby basin even when that basin produces greater long-term TTD. A smooth local path can therefore become a mechanism for global architectural lock-in.
However, roughness is not always undesirable. Some boundaries should be difficult to cross. Safety partitions, security controls, regulatory gates, and deliberate modular barriers may create useful architectural resistance.
The diagnostic question is not whether the landscape is smooth. It is whether the roughness occurs in the right places, for reasons the organization understands, and with consequences it can sustain.
Preservation Metrics are Coupled
The five metrics can be written schematically as
![]()
where
is representation fidelity, \tau is cross-layer transmission fidelity,
is decision-memory recoverability,
is overlap persistence, and
is architectural roughness.
As in Part I, this is a diagnostic vector, not a proposal for a weighted score. The metrics interact.
Low decision-memory recoverability can reduce representation fidelity because the assumptions and limitations of an artifact can no longer be reconstructed
![]()
Poor cross-layer transmission can create high downstream detail with low upstream fidelity
![]()
Low overlap persistence can reveal that a trade study depended on coarse representations
![]()
Increasing roughness can raise encountered complexity and TTD even when average structural measures remain stable
![]()
These relationships are not universal laws. They are diagnostic hypotheses that direct attention toward causal mechanisms. The same observed values may support different interpretations in different localities, layers, timescales, and resolutions.
The Metric Family Remains Open
Parts I and II have now discussed nine metric families
![]()
This list is not complete.
The causal framework can support metrics for governance latency, invariant survival, join burden, convergence rate, decision-order sensitivity, debt migration, frontier stability, causal reach, or other architectural concerns.
The generative method remains the same
- Identify the architectural question
- Identify the causal relation that gives the question meaning
- Determine which distinctions must be preserved
- Locate the condition in time, layer, agent, and resolution
- Identify observable evidence without confusing the evidence with the condition itself
- Examine rate, direction, interaction, and possible burden migration
- Preserve the metric’s limitations and decision-use boundaries
This approach does not promise effortless measurement.
Some causal quantities may be difficult to estimate. Some may require qualitative scales, structured judgment, active probes, or partial indicators. Some may resist precise scalar representation altogether.
That is not a failure of the method. The alternative is often precise measurement of the wrong condition.
A causal metric is valuable when it preserves enough of the architectural relation to improve diagnosis and decision-making. It should make visible what the architecture is doing, where it is doing it, to whom, across which layers, and with what consequences for the future.
The metrics in these two posts should therefore not be combined into one universal architecture score.
Their plurality is the point.
The next question is how we reason about a metric family whose members vary by locality, agent, layer, resolution, and time. And taking into consideration where the interactions between those members may matter more than any individual value.
The architecture does not have one number.
References
[BK24] Marián Boguñá. and Dmitri Krioukov. Measuring spatial distances in causal sets via causal overlaps. Physical Review D, 110:024008, 2024.
[JB05] Anton Jansen and Jan Bosch. Software architecture as a set of architectural design decisions. In Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture, pages 109–120. IEEE, 2005.
[Kau93] Stuart A. Kauffman. The Origins of Order: Self-Organization and Selection in Evolution. Oxford University Press, New York, 1993.
[MRS07] Seth Major, David Rideout, and Sumati Surya. On recovering continuum topology from a causal set. Journal of Mathematical Physics, 48(3):032501, 2007.
[Nat] National Aeronautics and Space Administration. System engineering handbook: Appendix. https://www.nasa.gov/reference/system-engineering-handbook-appendix. Accessed 2026-07-20.
[Nat16] National Aeronautics and Space Administration. Nasa systems engineering handbook. Technical Report NASA/SP-2016-6105 Rev2, NASA, Washington, DC, 2016.
[PC86] David L. Parnas and Paul C. Clements. A rational design process: How and why to fake it. IEEE Transactions on Software Engineering, SE-12(2):251–257, 1986.
[Sim96] Herbert A. Simon. The Sciences of the Artificial. MIT Press, Cambridge, Massachusetts, 3rd edition, 1996.
[Sur19] Sumati Surya. The causal set approach to quantum gravity. Living Reviews in Relativity, 22(5), 2019.
[TA05] Jeff Tyree and Art Akerman. Architecture decisions: Demystifying architecture. IEEE Software, 22(2):19–27, 2005.
Leave a Reply