Cross-Cutting: When the Answer Isn't a Subtree

Here is a question that sounds easy and usually isn’t:

Show me everything in the safety-critical set.

If your model is a well-organized decomposition — system, subsystem, assembly, component — you can answer any question whose answer is a branch. Everything in Propulsion. Everything under the flight computer. Those are one click.

But the safety-critical set isn’t a branch. It is a handful of components scattered across several branches that otherwise have nothing to do with each other. There is no node you can point at whose contents are the answer.

That is what cross-cutting means, and it is worth being precise about it.

The definition

A concern is cross-cutting when the set of elements it applies to is not a subtree of the primary decomposition.

That is the whole idea. Not “applies to lots of things” — plenty of concerns apply broadly and still nest neatly. The test is structural: can you name one container whose contents are exactly the set? If yes, your hierarchy already answers it. If no, the concern cuts across, and you need something other than containment to express it.

Why every model has this

A model has exactly one containment hierarchy. Elements nest inside other elements, and that nesting is single — a part is in one place.

You choose that hierarchy, usually for good reasons. A physical breakdown matches how the thing is built, how it is procured, and how work is assigned. A functional breakdown matches how it behaves. Either is defensible.

And whichever you choose is arbitrary with respect to every other question anyone will ask. The decomposition was organized around one axis. Safety wasn’t consulted. Neither was thermal, or the certification boundary, or the list of components that touch the outside world.

This is not a sign that the breakdown is wrong. It is a consequence of the fact that a system has properties which are not localized in any one component. Latency belongs to a chain. Attack surface belongs to a boundary. Thermal behavior belongs to a volume. None of those is a box, so none of them lines up with a tree of boxes.

Examples worth recognizing

Safety criticality. The flight computer, the data bus that carries its commands, and the engine controller that acts on them. Three components, two subsystems, one obligation.

Attack surface. Everything that touches an external interface — a nav receiver, a maintenance port, a display unit with a USB socket. They have nothing structural in common. What they share is a relationship to the outside.

Thermal. Whatever sits in the hot bay, regardless of what it does. Here the set is defined by physical proximity, which cuts across a functional decomposition particularly badly.

A timing budget. “Sensor to actuator within 40 ms” is a property of a path. The path runs through four components in three subsystems, and no single one of them owns the number.

Certification scope. The set of items a standard applies to, including the ones that are in scope because something else is. This one has a sharp edge: the set has to be complete, and somebody will ask you to prove it.

Instrumentation. Which steps the running system has to expose so a requirement can be checked at all. That set is determined by what you decided to constrain, not by where anything sits.

Six concerns, six different shapes, and not one of them is a branch.

Why this matters more in a model than in a document

A specification tree made of documents has the same problem, but it sets lower expectations. Nobody believes a Word document can answer arbitrary questions.

A model implies something stronger. The reason to build one — the reason to pay for the tooling and the discipline — is that it should answer questions its author did not anticipate. That promise is what separates a model from a drawing.

And almost every question worth asking cuts across the tree:

• Allocate this safety requirement. Lands on a scattered set.
• What does this change touch? The blast radius follows data and control flow, not containment.
• What needs re-verification after this modification? Also scattered.
• Which components are in the certification boundary? Scattered, and it must be defensible.

If cross-cutting sets can only be maintained by hand, the model answers the easy questions and a spreadsheet answers the hard ones. That is a common outcome, and it is worth naming, because it is usually invisible from inside.

The failure mode is silence

This is the part that makes cross-cutting worth understanding rather than just working around.

A hand-maintained list of safety-critical components looks correct. It has the right names on it. It was reviewed. What it is missing is the component someone added last month, in a subsystem nobody associated with safety, which inherits the obligation for a reason that was obvious to its author and to nobody else.

Nothing errors. No tool complains. The list is simply, quietly incomplete, and stays that way until a review catches it — or doesn’t.

Compare that with a set the model computes. A new component that specializes a safety-critical type is in the set the moment it exists, whether or not anyone remembered. The difference is not convenience. It is whether the answer degrades when you stop paying attention.

Why the usual approaches struggle

Each of these is reasonable, and each fails the same way.

A label — a stereotype, a tagged value, a keyword in the name — puts a mark on an element. It carries no type relationship, so nothing inherits it and nothing traverses it. A specialization of a marked element is not marked.

A naming convention — SAF_FlightComputer — is a label with worse ergonomics. It also silently couples your classification to your naming, so a rename changes the answer.

A second hierarchy — a parallel tree that groups by safety — works, and then you maintain two trees. When they disagree, and they will, there is no way to tell which is right.

A spreadsheet works beautifully on the day it is written.

The common thread: the classification lives outside the model, so it cannot be inherited, traversed, or checked. The model does not know about it, which means the model cannot maintain it.

What actually holds

Two things, and they do different jobs.

Membership that inherits. The classification has to be a real relationship in the model rather than a mark on it, so that a new element joining a family joins the set without anyone acting. In SysML v2 the construct built for this is semantic metadata — a keyword that requires the annotated element to specialize a base type, so what you get is an ordinary specialization that inherits like any other. I wrote about the mechanism in detail in Semantic Metadata.

A way to see the cross-section. Once membership is a relationship, the view is a query rather than a drawing. SysML v2 views can expose a scope and filter it, with productions in the grammar for both — filter on a membership, and expose with an inline filter on what it pulls in. The cross-cutting picture gets rendered from the model instead of maintained beside it.

Those two together are what turn “show me everything safety-critical” from a research task into a question.

A construct worth knowing about

There is a third piece I want to mention carefully, because I have not used it in a tool and I would rather say so than imply otherwise.

SysML v2 defines a first-class construct for a concern itself. Requirements.sysml in the Systems Library declares:

concern def ConcernCheck :> RequirementCheck;

with a stakeholders feature — “the Parts that represent stakeholders interested in the concern being checked” — and requirements can declare which concerns they address. So “safety” need not remain an adjective scattered through prose; the language provides for it being an element that requirements point at.

That is what the standard says. What I cannot tell you is how well any particular tool supports it, and that gap is worth checking before building anything on it. I am noting it because it exists and it is aimed squarely at this problem, not because I have exercised it.

The short version

The decomposition you chose is a real engineering artifact and it is worth getting right. It is also, unavoidably, one view of a system that has many.

Cross-cutting is not a problem introduced by modeling tools. It is a fact about systems: the properties that matter most are the ones that do not live in any single box. Understanding that is what stops you from expecting the hierarchy to answer questions it structurally cannot — and starts you asking how the model will answer them instead.

One tree. Many concerns. Never a subtree.