For a SaaS dashboard, a false negative costs a support ticket. Someone notices, files a complaint, and the on-call engineer fixes it before lunch. For a system watching four nuclear facilities on behalf of armasuisse, Switzerland's national defense procurement agency, a false negative is a different category of event. Nobody files a ticket. The cost shows up somewhere else entirely, and by the time it does, the model is not the thing anyone is talking about anymore.
DAD built that system. It's called SkyPulse, a satellite intelligence platform developed with the Max Planck Institute for Software Systems (MPI-SWS) that fuses Sentinel satellite imagery with social media, weather, and infrastructure data for government analysts. The case study headline is "4 nuclear facilities monitored, 50k+ satellite images processed, 24/7 operations." That headline is a metric. It's not the interesting part.
The interesting part is which production decisions change shape once the cost of being wrong stops being measured in dollars. This post is not a technical postmortem of SkyPulse's internals, most of which are, correctly, not public. It's the standard DAD applies to any build in this stakes class, illustrated with what's publicly true about SkyPulse: a defense client, nuclear facility monitoring, government-grade access controls, and a fully logged and versioned research environment. Four things change. None of them are about the model getting smarter.
Sovereignty isn't a compliance checkbox, it's an architecture decision
The default for most commercial AI builds is a hosted model API. A request goes out over the internet to a third party, a response comes back, and nobody thinks twice about where the weights live or who else's infrastructure the payload transited. That default is convenient, and for a marketing copy generator or a support chatbot, it's fine.
It's the first thing that has to be re-examined for a system processing satellite imagery of nuclear facilities on behalf of a national defense agency. SkyPulse runs on cloud-native Kubernetes inside what the case study describes as "secure government environments," with government-grade access controls at every layer. That deployment shape is deliberate: infrastructure a government client controls end to end, not infrastructure borrowed from a vendor whose terms of service you didn't negotiate.
This is DAD's standing position for any build in this class, not a SkyPulse-specific disclosure: for classified or sensitive imagery, sovereign or self-hosted inference is the default assumption, and a third-party model API in the imagery path is the thing you have to justify, not the thing you default to. The question a commercial build never has to ask out loud is the first question a defense-grade build has to answer in writing: where does the model actually run, and who else's traffic touches that hardware?
The audit trail answers a different question than "did the model behave"
Every AI vendor will tell you they log requests. Almost none of them can tell you, six months later, who made a specific decision, on what evidence, with what downstream effect. That gap doesn't matter for a chatbot. It matters enormously for a system an analyst used to decide whether an image of a facility perimeter warranted escalation.
SkyPulse's system details, confirmed in the case study, include all queries logged, data access tracked, and research contexts versioned. Those are real, named controls, not a generic "we take security seriously" line. What they add up to is an evidentiary trail: not just what the model output, but who asked, what they were looking at, and whether that particular line of inquiry was later revisited.
That's the same discipline DAD documents generally in /blog/audit-logs-ai: actor and subject identity, model and version hash, a structured decision (not free text), and downstream effect, all tied together by a stable inference ID. Applied to a defense build, the questions the log has to answer don't change in kind, only in weight. "Which analyst queried which research context, using which model version, and what did they conclude" is the exact same schema shape as "which underwriter's model denied which loan." The stakes are different. The contract isn't.
That contract also happens to be the bar the EU AI Act sets for high-risk systems generally, not a Switzerland-specific requirement. Article 12 requires logs "over the lifetime of the system," and Article 19 sets a six-month retention floor. Neither article is Swiss law, and this post isn't claiming SkyPulse was built against them specifically. The point is narrower and more useful: the evidentiary bar European regulators wrote down for high-risk AI is the same bar DAD already applies by default to defense-grade systems, because "can you reconstruct the decision six months later" turns out to be the right question regardless of which jurisdiction is asking it.
The calibration target is "what happens if we're wrong," not a percentage
A vendor selling a 95% accuracy figure has told you almost nothing. Accuracy against what test set, measured how, and, most importantly, which 5% failed and what happens when it does? A recommendation engine that's wrong 5% of the time annoys a user into scrolling past a bad suggestion. A facility-monitoring system that's wrong 5% of the time in the false-negative direction has missed something, and there's no scroll-past for that.
This is DAD's stated philosophy for any consequence-sensitive build, not a documented fact about SkyPulse's internal calibration methodology, which isn't public: the calibration target has to be set by the cost of the two failure modes, not by a benchmark score. False negatives and false positives are not symmetric costs in facility monitoring the way they're roughly symmetric in a spam filter. A missed signal is the failure that matters most. A false alarm costs analyst attention and, at high enough volume, produces alarm fatigue that erodes trust in every future alert, including the real ones. Those two costs don't trade off at the same rate, so the threshold that minimizes one is rarely the threshold that's actually correct.
| Failure mode | Cost in a retail recommender | Cost in facility monitoring |
|---|---|---|
| False negative | User doesn't see a relevant item | A real signal goes unflagged |
| False positive | User scrolls past an irrelevant suggestion | Analyst investigates a non-event; repeated, it erodes trust in the alert system itself |
| Threshold logic | Optimize for engagement metrics | Optimize for the named worst-case outcome, accepting a higher false-positive rate as the price |
The practical consequence: DAD sets thresholds for high-stakes monitoring systems by naming the worst case first, then working backward to the tolerance for false positives that's acceptable to buy down that risk, rather than starting from an accuracy target and hoping the failure distribution lands somewhere tolerable. None of what follows is a disclosed SkyPulse parameter; it's an illustration of what a real answer sounds like versus a decorative one. A vendor who says "95% accurate" has given you a number for a slide. A vendor who says something like "we tuned the false-negative threshold assuming a missed breach is catastrophic and a false alarm costs an analyst ten minutes of review" has told you the actual tradeoff they made and why. Neither sentence is a SkyPulse quote. The second is the shape a defensible answer takes, not a specific number this or any named system was tuned to.
The threat model includes someone trying to fool the sensor, not just noisy data
Commercial computer vision has to handle noise: bad lighting, motion blur, a dirty camera lens. None of that noise has intent behind it. A defense-grade imagery system has to assume the opposite: that some fraction of the traffic it sees was constructed specifically to make the model wrong.
That's not a hypothetical DAD is inventing to sound serious. Lanier et al. (2023), publishing at IEEE's Applications of Computer Vision workshop, ran a large-scale evaluation of adversarial attacks against deep-learning classifiers on the SpaceNet aerial-imagery dataset, including attacks designed to be "physically feasible" rather than purely theoretical perturbations.
— Lanier et al., 'Eroding Trust In Aerial Imagery,' IEEE AIRP 2023In critical operations where aerial imagery plays an essential role, the integrity and trustworthiness of data are paramount.
The paper's finding is about the field, not about any specific deployed system, SkyPulse included: aerial and satellite imagery classifiers are a demonstrated, published target for adversarial manipulation, using techniques designed to survive real-world physical conditions rather than just fool a model in a lab. That's the threat model a defense-grade monitoring system has to design against as a baseline assumption, independent of which specific countermeasures any given build ships, and whether or not those countermeasures are public.
The distinction that matters for enterprise buyers evaluating vendors: a commercial CV threat model asks "how do we handle noisy input." A defense-grade threat model asks "how do we handle input someone had a motive and a budget to manipulate." Those are different engineering problems. A model tuned to tolerate blur and glare is not automatically resistant to a crafted patch designed to exploit its specific decision boundary. If a vendor's answer to "how do you handle adversarial input" is the same answer they'd give for "how do you handle bad weather," that's a signal the threat model hasn't been separated from the noise model.
What to ask before you sign
Enterprise buyers evaluating AI vendors for regulated or high-stakes environments rarely get a straight answer to the questions that matter, because the sales deck is optimized to answer the questions that don't. Ask these three instead, and expect specific answers, not reassurance:
- Where does inference actually run? Not "we're SOC 2 compliant." The physical or logical boundary of the infrastructure, and who else's workloads share it.
- What does the audit log capture, and what will it still contain six months from now? Not "we log everything." The specific fields, the retention tier they live in, and whether the log can answer "who decided what, based on what" without a forensic recovery effort.
- What is the calibration target tied to: a benchmark, or a named worst-case outcome? If the answer is a percentage with no worst-case behind it, the accuracy number is decoration. If the vendor can name the specific failure they tuned against and the tradeoff they accepted to buy it down, that's the sign the calibration work actually happened.
If a vendor can't answer the third question specifically, don't take the first two on faith either.
References
- DAD — SkyPulse: Satellite Intelligence Platform
- DAD — Audit logs for AI: the contract that survives a compliance review
- European Commission — AI Act Article 12: Record-keeping
- European Commission — AI Act Article 19: Automatically generated logs
- Lanier et al. — Eroding Trust In Aerial Imagery: Comprehensive Analysis and Evaluation Of Adversarial Attacks In Geospatial Systems (IEEE AIRP, 2023)