The June 2026 dispatch Relevance Is Not Enforcement closed on an observation it did not name.
Reading the AIUC-1 × OWASP crosswalk, it noted that a single requirement — B006 — carried the mapping weight of five distinct enforcement functions, and that the crosswalk’s own implementation note acknowledged the arrangement in the act of mapping it. The dispatch left the point as a structural aside: aggregation is what standards do when threat surfaces evolve faster than requirement taxonomies.
That aside has a shape worth naming. This dispatch names it.
The Great Compression series named what happens when model providers absorb the harness layer — the infrastructure between the model and the application folded into the model tier under economic pressure. The same mechanism — aggregation under pressure — operates one architectural layer up. Not the substrate layer, where providers absorb harness functions, but the standards layer, where requirement taxonomies absorb enforcement surfaces. The byproduct of that absorption is compression debt.
Compression debt is corpus-grounded Luminity vocabulary, drawn from the Great Compression series and extended to the standards layer. The case studies that follow are sourced from the standards themselves — quoted, cited, and read along their own ground.
The shape of the debt
A standard accumulates compression debt when several architectural functions are represented by a single requirement. The requirement stays relevant to every threat it maps to. What drifts is the relationship between the requirement and the mechanism that would satisfy it. Read at face value, one requirement appears to describe one control. In practice, the requirement often functions as a container for several controls operating at different layers — each with its own enforcement surface, its own failure mode, its own verification path. The breadth of the requirement’s mapping and the work the requirement actually performs separate. The distance between them is the debt.
Stated as an architectural observation: a maturing standard increasingly describes containers of controls rather than the controls themselves. Compression debt is what that shift costs the implementer who reads the container as a control.
The word is chosen for its structural connotation. Debt accumulates quietly. It does not appear on the surface until something forces a reckoning. It eventually requires payment, and the longer it sits unaddressed, the more it costs to resolve. Technical debt is the familiar parallel — the shortcut that ships the release and bills the team later. Compression debt is the standards-layer equivalent: the aggregation that ships the coverage and bills the implementer later.
It is worth establishing early what this is not. Compression debt is not a defect, and naming it is not a charge against the bodies that carry it. A standard that aggregates is doing the rational thing under the pressure it operates within. The debt is not the failure of the choice. It is the honest accounting of the choice — the cost the aggregation incurs and defers rather than the mistake the aggregation makes.
Why standards compress
Consider the position a standards body occupies. Threat surfaces in agentic systems proliferate faster than any requirement taxonomy can track them. The OWASP Agentic Security Initiative’s State of Agentic AI Security and Governance (v2, June 2026) records the shift directly: in its retrospective on the Top 10 for Agentic Applications, nearly every threat category now carries at least one confirmed real-world incident, where a year earlier the catalog was largely anticipatory. New tool-call patterns, new inter-agent protocols, new memory and retrieval behaviors, new privilege paths — each arrives with its own way of going wrong. A requirement taxonomy that tried to name a distinct control for every emerging surface would double, then double again, and arrive at a count no implementer could read and no auditor could examine. The taxonomy that captured everything would be the taxonomy no one could use.
So the body aggregates. It writes a requirement broad enough to remain relevant as the surface beneath it shifts, and it maps that requirement against the family of threats it covers. The requirement holds its relevance precisely because it is general. A narrower requirement would be obsolete the moment a new variant appeared; the general one absorbs the variant without rewriting.
That is the rational move, and it is the right one. The cost is that the requirement now stands in for more enforcement work than its single line of text reveals. The mapping says the requirement is relevant to eight threats. It does not say the requirement resolves into five separate controls, each of which has to be built, operated, and verified on its own. Compression is the rational response to threat-surface velocity. Compression debt is the unbilled portion of that response — the enforcement decomposition the requirement defers rather than performs.
One requirement, five functions
The clearest worked example sits in the AIUC-1 × OWASP crosswalk, which maps the AIUC-1 control set against the OWASP Top 10 for Agentic Applications. One AIUC-1 requirement, B006, draws eight mappings across the Top 10 — six of them Primary — the broadest coverage footprint in the crosswalk. Read as a coverage statement, B006 is the strongest line in the document. Read as an enforcement statement, B006 is five controls wearing one requirement number.
The five enforcement functions B006 absorbs:
Permission-boundary control — what the agent is allowed to touch.
Execution-time authorization — whether a given action is permitted at the moment it is attempted.
Identity and credential control — what the agent is acting as.
Protocol-layer authentication and authorization — how agents establish trust and bound each other’s actions.
Architectural isolation — what holds when the prior four are bypassed.
These are not variations on one control. They sit at different layers, fail in different ways, and demand different verification. Whether an architect classifies them as five separate controls or as five implementations of a single control objective, the consequence is the same: each carries its own verification path, and satisfying one says nothing about the others. Scope enforcement is a policy question answered at configuration time. Runtime containment is an isolation property answered at the architecture. An implementation can satisfy any one of the five and leave the other four unaddressed while still, on paper, satisfying B006.
“Implementations should address each control function independently rather than treating B006 as a single checkbox. Coverage of one function does not imply coverage of others.”
That sentence is the debt made visible. The crosswalk acknowledges the aggregation in the same motion that performs it — the line item that says payment is due. The note does not split B006 into five requirements; it tells the reader the requirement contains more than one control, and that satisfying it means satisfying each function on its own ground.
The pattern is portable
B006 is the clearest case. It is not the only one. The same pattern appears wherever a governance framework has to cover a moving surface with a stable requirement set, which is to say nearly everywhere a serious standard operates.
The NIST AI Risk Management Framework organizes its work under four functions — Govern, Map, Measure, Manage — each resolving into categories and subcategories. A single subcategory routinely stands in for governance posture, operational practice, and technical control at once. The framework is built to be voluntary and broadly applicable across AI types; the decomposition into specific work lands in implementation — the use-case and sector profiles that translate a general subcategory into the controls a given deployment actually demands.
The Federal Reserve and OCC’s SR 11-7 guidance on model risk management (issued 2011, revised by the agencies in 2026) aggregates by design. A requirement to validate a model carries development testing, ongoing monitoring, and outcome analysis inside it — three distinct enforcement activities under one validation expectation. The guidance is built to be general across model types; the decomposition lands in independent validation practice and supervisory examination, where the single expectation resolves into the specific work a given model demands.
ISO/IEC 42001, the AI management system standard, folds governance, operational, and technical controls into single management-system clauses and Annex A control statements. A clause that reads as one control commitment often spans policy, process, and implementation. The decomposition arrives through the certification audit and the companion guidance an auditor brings to bear when testing conformance against the clause as written.
Three standards, three starting points, the same structural property. Each composes coverage through aggregation. Each carries the debt that aggregation defers. And each, notably, already has a mechanism through which the debt gets paid.
Where the debt gets paid
Compression debt resolves in three places.
The standard splits the requirement — replacing one general control with the several specific controls it contained. This is rare and slow. It expands the taxonomy the body was trying to keep bounded, and it happens only when a surface has stabilized enough to be named precisely.
Implementation guidance decomposes the requirement at the verification layer. The use-case profiles that instantiate a framework, the ISO companion guidance, the implementation notes attached to a control set — these unpack the general requirement into the specific work without changing the requirement itself. This is the common path, and it is slower than it sounds, because guidance trails the requirement and the surface keeps moving beneath both.
External mechanisms surface the decomposition — audits, certifications, third-party crosswalks — from outside the standard. This is immediate, but it asks something of the reader: the sophistication to recognize that a single requirement contains several controls and to demand each be satisfied on its own ground.
The OWASP × AIUC-1 crosswalk is the third kind. Its note on B006 is the payment notice — the document acknowledging the debt without yet splitting the requirement, and handing the reader the instruction to address each function independently. The reader who treats B006 as one checkbox has not read the notice. The reader who reads it understands the requirement is a container, not a control.
Standards compose coverage through aggregation because the alternative is unworkable. Compression debt accumulates as a structural property of that composition, not as a flaw in it.
The work that pays it down — verification decomposition at the audit layer, architectural enforcement at the runtime layer, contractual specificity at the procurement layer — is the work the field is building toward as enterprises move toward assurance. Compression Debt is where the series begins. The work that pays it down is what the dispatches that follow will read.
