Modern software systems exhibit a persistent gap between their apparent structure and their actual governing behavior. Modules, APIs, configuration schemas, and documentation describe visible surfaces, while configuration resolution, authority delegation, execution routing, fallback behavior, and exception handling often remain distributed through implementation. The system has an operative constitution, but may be unable to represent or explain it. This paper introduces Semantic Fragmentation Analysis (SFA) as a source-bounded method for characterizing how a software system distributes, obscures, contradicts, or externalizes its governing structure. SFA does not primarily grade correctness or performance. It identifies decision classes, authority surfaces, admissibility rules, resolution cascades, fallbacks, projections, evidence, and revision paths; reconstructs representative decision events; and reports where declared structure and operative behavior diverge. The paper defines semantic fragmentation, operative and declared constitutions, structural legibility, resolution surfaces, authority scopes, and constitutional exposure. It formalizes a decision event, gives a non-compensatory fragmentation profile, states diagnostic invariants, expands the pattern taxonomy, and supplies a worked configuration-resolution example. It then locates SFA within the full Possibility--Specification--CM1--CM2--Instance Configuration--Implementation Realization--Evidence--Revision funnel and connects local structural legibility to constitutional compatibility across systems. SFA is a diagnostic architecture, not a certification result. Explicit models can be stale, incomplete, deceptive, excessively centralized, privacy-invasive, or more costly than the opacity they replace. The method therefore preserves uncertainty, hidden remainder, counterevidence, and refusal. Its intended contribution is a disciplined route from implicit constitutional behavior toward software whose authority, resolution, transformation, and failure semantics can be inspected and revised without claiming that legibility alone makes the software correct, secure, legitimate, or desirable.
No takes yet. Share an insight, caveat, or question.
Adam Ableman (2026) studied this question.
Synapse has enriched 5 closely related papers on similar clinical questions. Consider them for comparative context: