Safety by Design, Rewritten: When Data Defines the Boundary

Boundaries are usually drawn before deployment. A product team defines where a system is allowed to operate, safety engineers translate that into requirements, regulators ask whether the evidence matches the claim, and everyone pretends the world politely fits inside the diagram. Charming. Occasionally even useful.

Safety-critical AI makes that ritual harder. The system does not operate in a neat spreadsheet of conditions. It sees continuous states, correlated variables, rare combinations, sensor noise, and operational edge cases that were never invited to the design meeting. For autonomous vehicles, aircraft collision-avoidance systems, industrial robots, or AI-assisted control systems, the question is not simply whether the model performs well. The question is: under what conditions is the system actually allowed to claim that performance?

That is the Operational Design Domain, or ODD. In plain terms, it is the operating envelope: the set of conditions under which the system is intended to function safely. The paper Defining Operational Conditions for Safety-Critical AI-Based Systems from Data proposes a way to derive that envelope from data, using a deterministic kernel-based representation rather than relying only on expert-defined rules or brittle geometric boundaries.¹

The important part is not that the method uses kernels. Many things use kernels. The important part is the chain:

data points become anchors; anchors become local affinity fields; local fields become a global soft boundary; that boundary becomes evidence for monitoring and certification.

That mechanism is the paper’s business relevance. It does not promise that logs magically reveal the “true” safe world. It builds a conservative, data-supported under-approximation of where the system has enough operational evidence to make a safety claim. That distinction matters. A lot of AI safety theater begins exactly where that distinction is ignored.

The ODD problem is not a missing checklist; it is a missing shape

Traditional ODD work often begins with a taxonomy: define the relevant parameters, then specify acceptable ranges. For an automated driving system, that may include road type, weather, lighting, speed, lane markings, and traffic conditions. For an aviation AI system, it may include altitude, relative motion, time to closest point of approach, previous advisory state, and related operational variables.

That is already useful. But range lists are only the easy part. The expensive part is ontology: the relationships among parameters.

A condition can be safe in one combination and unsafe in another. A speed may be acceptable under one visibility regime and unacceptable under another. An aircraft state may be valid only when multiple physical and procedural variables line up. A table of independent parameter intervals cannot express those dependencies cleanly unless humans already know them and write them down precisely.

This is where the paper’s framing becomes interesting. Instead of treating the ODD as a manually specified box, the authors formalize it as a structure consisting of a domain, predicates describing membership, an interpretation function, and noise. They then define similarity between ODDs in a data-centric way: two ODDs are similar if they generate the same dataset of observable outputs. That is a practical move. It accepts that, from data alone, we may not recover the same semantic explanation experts would write, but we may recover an operationally equivalent boundary for the system’s behavior.

For business readers, that is the first useful translation:

The last row is the one managers will feel. Conservatism is not free. It may reject conditions that are actually safe. But in safety-critical deployment, that is often preferable to treating unknown regions as safe because a convex hull happened to include them. The hull has no ethics. It just connects dots.

The mechanism: every safe sample gets a small vote

The proposed method starts with two kinds of data: in-distribution samples, which are considered part of the ODD, and out-of-distribution samples, which are explicitly outside it. In the default setup, every in-distribution sample becomes an anchor point.

Around each anchor, the method places a local affinity function. The paper uses a radial basis function kernel:

The intuition is simple. If a new operating condition $x$ is close to a known safe anchor $x_i$, that anchor gives it a high affinity score. If it is far away, the score decays.

The local scores are then combined into a global affinity function:

This formula is doing more than decoration. It keeps the global affinity bounded between 0 and 1, even when many local kernels overlap. It also lets clusters of evidence reinforce one another. Dense regions of observed safe operation become stronger regions of membership. Sparse regions remain weak unless enough nearby anchors support them.

The final ODD membership rule is threshold-based:

Here, $\zeta$ is the chosen affinity threshold. A higher threshold gives a stricter, more conservative boundary. A lower threshold admits more conditions but risks letting in regions where evidence is thinner.

This is the heart of the paper. It turns the ODD from a hand-drawn perimeter into a continuous evidence surface.

A conventional ODD says: “inside” or “outside.” This representation says: “close to known safe conditions,” “near the edge,” or “far enough away that you should stop pretending.”

That soft boundary is operationally useful. It supports runtime monitoring. A system can trigger warnings, fallback behavior, or graceful degradation before it crosses a hard boundary. In a certified system, that matters because the safety argument is not only about the model’s average performance. It is about how the system behaves when the world drifts toward the edge of the claim.

OOD samples are not thrown away; they squeeze the boundary

The paper’s second mechanism is the treatment of out-of-distribution samples. Since RBF kernels never become exactly zero, an OOD point may still receive some affinity from nearby in-distribution anchors. The authors introduce an OOD consistency constraint: every known OOD sample must have global affinity at or below a maximum threshold $\xi$.

If an OOD sample violates that constraint, the algorithm identifies the most violated OOD point, finds the local kernel contributing most to that violation, and shrinks that kernel’s covariance matrix by a scaling factor. Then it repeats until all OOD samples satisfy the constraint.

This is a useful design choice because it is deterministic and order-independent. The result does not depend on whether the data happened to be fed in row 17 before row 4,983. For certification-facing systems, this sounds boring only until one remembers that “the model changed because the input order changed” is not a sentence anyone wants to say in front of an aviation safety assessor.

The paper also proves finite termination for this OOD adjustment procedure. The practical interpretation is not that the method is magically optimal. It is that the adjustment process is bounded and predictable enough to support a safety argument.

The algorithm can be summarized as:

ID samples -> anchor points
anchor distances -> kernel widths
local kernels -> global affinity surface
OOD samples -> boundary adjustment
affinity threshold -> operational membership

This is why the accepted article structure should be mechanism-first. The empirical section matters, but the paper’s value is unlocked only after the reader understands how the boundary is constructed.

The evidence: simulation first, aviation second

The paper validates the method in two layers. The first is a Monte Carlo setup, where the underlying ODD is known. The second is a VCAS aviation collision-avoidance use case, where the method is tested at a more realistic scale.

The distinction matters because these experiments answer different questions.

The Monte Carlo test uses a simple 2D ODD: $X=[-5,5]\times[-5,5]$ with a linear relation $x_2\geq x_1-3$. The number of anchor points varies from 3 to 10,000, and each configuration is tested against 100,000 validation samples. The authors then compute precision and recall across different affinity thresholds.

The qualitative pattern is important. As anchor density increases, recall improves because the data-driven ODD covers more of the true domain. Precision can decrease because the boundary expands. That may sound bad if one reads precision mechanically. But in the paper’s interpretation, it is part of convergence from the inside: the conservative boundary grows toward the true ODD as more anchor evidence becomes available.

The authors also compare the data-driven ODD’s threshold behavior against a convex hull of the anchor points. In the 2D case, the coefficient of determination between the original-ODD curves and convex-hull curves is $R^2=0.9855$ for precision and $R^2=0.9987$ for recall. Across tests up to 10 dimensions and more complex relationship functions, all reported coefficients of determination are above 0.973.

That result should be read carefully. It does not say: “Use convex hulls as the ODD.” The paper says almost the opposite in the discussion. Convex hulls can enclose holes, concavities, and physically invalid regions. They are useful as a validation proxy for threshold tuning when the true ODD is unknown. They are not the final safety boundary. The distinction is small enough to miss and large enough to break the whole interpretation.

The VCAS case shows scale, not omniscience

The aviation use case focuses on a vertical collision-avoidance system, VCAS. The decision depends on variables such as relative altitude, ownship vertical rate, time to closest point of approach, and the previous advisory. The paper uses 622,110 observed state vectors as anchor points and creates $10^7$ validation samples around the defined parameter ranges.

The reported VCAS curves follow a similar pattern to the Monte Carlo experiments, but with lower and steeper recall. The authors explain this through lower anchor density in the higher-dimensional space. More validation samples lie inside the underlying ODD but are not classified inside the data-driven ODD, creating more false negatives.

This is not a failure of the method. It is the method behaving like a conservative safety tool. Sparse data means the boundary has gaps. Those gaps may include regions that are valid in the real world, but the method refuses to claim them without sufficient evidence.

For the VCAS use case, the coefficient of determination between the underlying ODD comparison and the convex-hull comparison is $R^2=0.99105$ for precision and $R^2=0.99979$ for recall. That supports the paper’s claim that convex-hull-based validation can help tune thresholds when the true ODD is not directly available.

The appendix adds a small but telling implementation detail. The nominal VCAS parameter space includes five variables, but the intruder vertical rate is constant at $0,m/s$ in the dataset. Since a zero-variance dimension contributes no discriminative information and would create a degenerate covariance entry, the effective kernel computation reduces the space from nominal 5D to 4D. That is not a side curiosity. It is a reminder that data-driven ODD construction is not “press button, receive safety.” Someone still has to understand what the variables mean and when a dimension is mathematically present but operationally useless.

The business value is not automation; it is auditability

The obvious business reading is that the paper automates ODD construction. That is true, but incomplete. Automation alone is not impressive. One can automate bad boundaries very quickly. Many organizations have already mastered that dark art.

The more important business value is auditability. A safety-critical AI project needs to show where its operational claim comes from. The proposed representation gives teams a data-linked artifact:

For aviation, autonomous vehicles, robotics, industrial automation, and similar domains, this kind of artifact can support three workflows.

First, it can support development-time ODD analysis. Teams can inspect where their data actually cover the claimed operating domain and where the safety case is thin. This is less glamorous than a new model architecture, but generally more useful to the person who has to sign the deployment document.

Second, it can support runtime monitoring. Instead of asking only whether the current state is inside or outside a manually coded rule set, the system can compute an affinity score and react before it fully exits the domain. A falling affinity score can become a trigger for degraded operation, fallback logic, human alerting, or data collection.

Third, it can support certification evidence. The paper explicitly connects the representation to safety-by-design and future certification workflows. The useful inference for business is narrower: this method could become one component in a larger assurance case. It is not a certificate. It is evidence that the operational boundary is deterministic, explainable, bounded, and connected to actual data.

That is valuable because many AI systems fail certification conversations not because they are useless, but because their evidence is badly shaped. A benchmark score says the model works “on average.” A data-driven ODD says where the claim applies.

What the paper directly shows, and what Cognaptus infers

The paper directly shows that a kernel-based ODD can be built from ID and OOD data; that the representation is deterministic, order-independent, bounded, and conservative; that the OOD adjustment terminates; and that the method performs plausibly in both Monte Carlo tests and a VCAS aviation use case. It also defines a data-centric notion of ODD similarity and uses precision-recall threshold curves to evaluate the derived boundary against both known underlying ODDs and convex-hull proxies.

Cognaptus infers that this kind of representation is especially useful for organizations moving from AI prototypes to governed AI systems. The method gives safety, engineering, and compliance teams a shared object to discuss: not a vague “model confidence” score, but an operational affinity surface tied to observed conditions.

The remaining uncertainty is equally important. The paper does not prove that every safety-critical AI system can derive a sufficient ODD from available logs. It does not solve temporal ODDs. It does not fully model tightly coupled cross-dimensional dependencies because the current method uses diagonal kernel parameter matrices for robustness and interpretability. It does not eliminate the need for expert-defined ODD work. The authors explicitly position it as support for current ODD development, especially where expert knowledge is incomplete.

That is the right posture. Data can define a boundary only around what the data actually cover. Beyond that, one needs either more data, stronger assumptions, expert constraints, or a lower tolerance for pretending.

The limitation is not conservatism; it is unmanaged conservatism

The paper’s most important limitation is not that the method is conservative. Conservatism is the point. The real operational issue is how that conservatism is managed.

Kernel parameters matter. For the RBF setup, $\kappa$ and $\eta$ affect the affinity surface. The authors provide recommendations, but they also state that users should perform systematic ablation studies. In business language: parameter settings become part of the safety argument. They cannot be treated as incidental configuration.

Sparse data also changes interpretation. With few anchors, the derived ODD under-approximates safe regions. This may create operational gaps: the system may reject valid conditions because it lacks evidence. In a safety-critical setting, that may be acceptable. In a commercial setting, it may affect availability, user experience, and operating cost. A conservative monitor that constantly triggers fallback is safe in the narrow sense and annoying in the expensive sense.

Temporal dynamics remain future work. Many real operating domains are not static point clouds. Air traffic, road traffic, industrial processes, weather systems, and human-machine interactions evolve over time. A static affinity score over current state variables may miss patterns that only become meaningful as trajectories. The paper acknowledges time-dependent kernels as a future extension.

Computational scalability is another boundary. The naïve query cost is $O(Nn)$, and VCAS uses 622,110 anchor points. The appendix argues that RBF locality and approximate nearest-neighbor tools such as Faiss can reduce practical cost by evaluating only nearby anchors, with query complexity moving toward $O(Kn+n\log N)$. That is promising, but the paper leaves formal approximation-error analysis and hardware-specific optimization for future work.

None of these limitations weakens the paper’s central contribution. They define where the method must be engineered before it becomes a production-grade assurance component.

A practical adoption frame for safety-critical teams

For a company building safety-critical AI, the immediate question is not “Should we replace our ODD process with kernels?” The answer should be no, unless the company enjoys regulatory pain as a lifestyle choice.

A more sensible adoption frame is layered:

1. Expert ODD first. Define the initial taxonomy, known constraints, and unacceptable conditions using standards and domain expertise.
2. Data-driven ODD reconstruction second. Use operational or simulation data to derive a kernel-based affinity boundary.
3. Mismatch analysis third. Compare the expert-defined ODD and data-driven ODD. Gaps become questions: missing data, incorrect assumptions, rare conditions, or genuine unsafe regions?
4. Runtime monitor fourth. Use affinity scores to trigger warning zones and fallback behavior.
5. Controlled updates fifth. As new data arrive, update the representation under configuration control, with documented parameter choices and validation thresholds.

This is where the paper’s mechanism can enter real engineering practice. It does not replace safety engineers. It gives them a sharper instrument. Some will still use it to produce PowerPoint fog, naturally. But the instrument itself is useful.

The strategic point: AI safety needs evidence surfaces, not slogans

The broader significance of this paper is that it moves safety-by-design from a declaration to a representation. That may sound subtle. It is not.

Most organizations already know they need boundaries for AI systems. The problem is that those boundaries are often textual, manual, stale, or disconnected from the data actually used to train and test the system. The proposed method creates a bridge between operational evidence and operational permission.

That bridge is especially important as AI systems move into regulated domains. In consumer software, an edge case becomes a support ticket. In aviation, mobility, healthcare devices, or industrial control, an edge case becomes a safety case. The vocabulary changes because the consequences do.

The paper’s kernel-based ODD is not the final answer to safety-critical AI certification. It is a strong piece of infrastructure: deterministic, auditable, conservative, and mathematically structured. It gives teams a way to say, with evidence, “This is where our claim applies.”

And sometimes, in safety-critical AI, the most valuable system is not the one that says yes more often. It is the one that knows exactly when to stop saying yes.

Cognaptus: Automate the Present, Incubate the Future.