MAESTRO registry sub-controls follow the superseded layer model

[emmanuelgjr]

Follow-up to the layer-name correction in this PR series.

data/frameworks/maestro.json carried seven layer titles that contradicted the CSA source and this repository's own three MAESTRO mapping files. The seven top-level titles are now corrected and guarded by validate.js.

The 21 sub-controls under them were not touched, and they should be. They were written against the same mistaken layer model, so several now sit under a layer whose name no longer describes them:

Sub-control	Currently under	Reads like
L4.1 Tool authorization and scoping L4.2 MCP server security L4.3 API integration security	L4 Deployment & Infrastructure	L3 Agent Frameworks — CSA puts "tool registries, MCP, plugin ecosystems" there
L5.1 Runtime isolation L5.3 Network segmentation	L5 Evaluation & Observability	L4 Deployment & Infrastructure
L5.2 Secrets and credential management	L5 Evaluation & Observability	L6 Security & Compliance
L6.1 Inter-agent authentication L6.2 Delegation controls L6.3 Cascading failure prevention	L6 Security & Compliance	L7 Agent Ecosystem
L7.1 Output validation and filtering L7.3 Trust calibration	L7 Agent Ecosystem	plausible under L7; L7.2 Human oversight less so

L1.*, L2.* and L3.* look correct as they stand.

Why this was not fixed alongside the titles

Re-homing a sub-control changes its control id, which is an identifier other people may already cite. Deciding where each belongs is taxonomy work, not transcription — it needs someone who will own the answer. Under C4 an agent should not author it.

Impact today is limited, not zero

• All 3,211 mappings reference only the top-level ids L1–L7, so no mapping row is affected.
• Nothing else in the repo cites a sub-control id: the three drafted control_failures[] on the AST10 incidents were retargeted to top-level ids in the same PR, precisely so they do not depend on this open question.
• So the sub-controls are currently unused, published, and wrong — which is a documentation defect rather than a data-integrity one.

Suggested resolution

Either re-home the 21 sub-controls against the CSA layer definitions and record the id changes in the registry's changelog, or drop them and keep the registry at the seven layers the framework actually defines and the mappings actually use. The second is smaller and loses nothing that is currently referenced.

/cc maintainer — needs a decision, not an implementation.

[emmanuelgjr]

The top-level layers have the same problem, not just the sub-controls. Found while working on #87.

#32 fixed the L4–L7 titles in data/frameworks/maestro.json, but their descriptions still describe the superseded model. Every layer now has a correct name and the wrong definition:

id	title (correct)	description today (superseded)	canonical definition, llm-top10/LLM_MAESTRO.md architecture table
L4	Deployment & Infrastructure	Tool access — covers MCP, API integrations, plugin security, and tool authorization.	Servers, containers, networks, CI/CD, runtime environments
L5	Evaluation & Observability	Infrastructure — covers containerization, networking, secrets management, and runtime isolation.	Monitoring, logging, telemetry, behavioural baselines
L6	Security & Compliance	Multi-agent coordination — covers inter-agent communication, delegation, consensus, and cascading failure prevention.	Identity, access control, audit, governance, credential management
L7	Agent Ecosystem	Human-agent interface — covers user authentication, output validation, human oversight, and trust management.	Multi-agent interaction, A2A communication, cascade dynamics

(L1–L3 descriptions agree with the table.)

Why it matters: these descriptions ship in the npm package's registries, in docs/frameworks-registry.js, and in the OSCAL catalog export. Anyone choosing a layer by its description, rather than its id or title, picks the wrong one. checkMaestroLayers() compares titles only, which is why this wasn't caught.

Proposed fix (transcription, no taxonomy change): replace the four descriptions with the canonical table text, and extend checkMaestroLayers() to catch this class of drift. Unlike the sub-control question above, this changes no control ids. It regenerates docs/frameworks-registry.js, so it needs C2 approval. Happy to open it as a PR once the current queue (#37, #38, #85, #87) has moved.

[emmanuelgjr]

Status update: half of this is done, and the other half just got more pressing.

Done: the L1–L7 layer descriptions were transcribed from the LLM_MAESTRO.md architecture table in #88 (4cf353d). checkMaestroLayers() now compares descriptions as well as titles, so that drift fails the build.

Changed since this was written: the issue says "Nothing else in the repo cites a sub-control id." That's no longer true. #182 (972048a) added INC-137, and three of its draft control_failures cite MAESTRO sub-controls:

Incident	Cites	Outcome	confirmed_by
INC-137	L5.1 Runtime isolation	present-but-bypassed	empty
INC-137	L5.1 Runtime isolation	absent	empty
INC-137	L5.3 Network segmentation	absent	empty

These are two of the sub-controls this issue flags as filed under the wrong layer: runtime isolation and network segmentation sit under L5 Evaluation & Observability but read like L4 Deployment & Infrastructure. So:

• "Drop the sub-controls" no longer loses nothing. It would leave INC-137's three failures pointing at ids that don't exist, and they'd have to be retargeted (probably to L4, the top-level layer), which is itself a mapping call.
• "Re-home them" changes L5.1/L5.3 to new ids, and INC-137 would follow.

Either way, INC-137 should be re-pointed in the same change. And until this is decided, new control_failures should cite the top-level L1–L7 ids, as the AST10 drafts were retargeted to do.

The decision stays with the maintainer (C4). No data changed.