I’ve spent 25 years doing failure analysis. Cloud infrastructure at hyperscale. Manufacturing lines. NASA-grade criticality analysis. Fraud detection systems processing millions of transactions. In every domain, the methodology is the same: identify what can go wrong, score it, and make sure the highest-risk failures get addressed first.
FMEA. Failure Mode and Effects Analysis. You decompose a system into components, identify how each component can fail, and score every failure mode on severity, probability, and detectability. Multiply the scores together. The highest numbers get fixed first. It works for rocket engines. It works for cloud data centers. It works for catching financial fraud patterns before they propagate.
Recently, I applied it to a domain nobody else had connected it to: physical safety as a constraint on strategic decision systems.
The Gap Nobody Talks About
Here’s what I discovered. Every tool designed to help people assess safety treats it as a separate activity from the decisions that create risk in the first place.
Safety plans are static documents. Fill them out once. Review them occasionally. They don’t update when circumstances change. They don’t score the relative severity of different threats. They don’t detect when multiple threat vectors activate simultaneously.
Meanwhile, decision systems, whether they’re legal strategy platforms, financial optimizers, or operational planning tools, optimize for outcomes without any awareness of physical safety implications. A legal strategy tool might recommend filing a complaint that maximizes settlement value. What it can’t tell you is whether that filing increases your physical risk, by how much, or what protective measures would offset it.
The gap is structural. Safety lives in one silo. Strategy lives in another. Nobody connected them.
What Engineering Failure Analysis Teaches Us
In every engineering domain I’ve worked in, safety is not a separate consideration. It’s a constraint on the system itself.
When you design cloud infrastructure for a service handling billions of requests, you don’t have a separate “reliability checklist” that someone reviews after the architecture is designed. Reliability is built into the architecture. Every design decision is evaluated against failure modes. The system won’t let you deploy a configuration that violates safety constraints.
When NASA evaluates a mission, FMECA (the criticality-enhanced version of FMEA) doesn’t sit in a separate binder from mission planning. Criticality analysis IS mission planning. A component with a Category I failure mode (catastrophic, mission-ending) constrains every decision downstream.
The principle: safety as a constraint function, not an afterthought.
S-ARPN: Scoring Safety Like an Engineer
Standard risk scoring works well for systems and processes. But physical safety has dimensions that hardware failure modes don’t.
I built a safety-adapted scoring system called S-ARPN. Five dimensions:
Threat Severity (TS): The worst-case physical outcome. Scale of 1 to 10, where 1 is annoyance, 7 is injury, and 10 is lethal. This is the “S” in traditional FMEA, adapted for human safety instead of system failure.
Probability (P): How likely, given current conditions. Not baseline probability. Conditioned on the current state. The same threat actor at escalation level 2 has a different probability than at level 6.
Vulnerability (V): How exposed is the person at risk. This dimension doesn’t exist in traditional FMEA because machines don’t have variable exposure. People do. Living alone with a predictable routine is high vulnerability. Security cameras, varied schedule, and a check-in protocol reduce it. Protective measures directly lower this score.
Behavioral Impairment (BI): This comes from my fraud analytics background. A rational, sober actor making calculated decisions is a fundamentally different risk profile than someone with substance issues and impulse control problems. Traditional threat assessment uses qualitative categories. S-ARPN uses a continuous variable from 1.0 to 3.0 because the difference matters quantitatively, not just categorically.
Escalation Coupling (EC): How many other threat vectors activate when this one fires. This is the dimension that makes coordinated campaigns dangerous. A single threatening message is one thing. A threatening message, a false police report, a financial action, and professional targeting all happening on the same day is something fundamentally different. EC captures that difference. Scale of 1 to 5.
The formula: S-ARPN = TS x P x V x BI x EC
The maximum possible score is 15,000. The tier thresholds map to response urgency:
- IMMEDIATE (above 3,000): Get out. Call 911. This is not a planning moment.
- CRITICAL (1,500 to 3,000): File a law enforcement report within 24 hours. Activate protective measures.
- HIGH (500 to 1,500): Review protective measures. Update documentation. Adjust routine.
- MODERATE (100 to 500): Maintain awareness. Monitor for escalation.
- LOW (below 100): Monitor and log.
The power of quantified scoring is that it turns “I feel unsafe” (valid, but not actionable for a system) into “your V score is 6 because cameras aren’t installed and your routine is predictable. Installing cameras and varying your schedule drops V to 3, which moves you from CRITICAL to HIGH tier. Those two changes cost $200 and zero dollars respectively.”
Safety becomes measurable and reducible through specific actions.
Cross-Domain Coordination Detection
The dimension that surprised me most was Escalation Coupling. In fraud analytics, we call related patterns “coordinated campaigns.” Multiple accounts moving money on the same day through different channels. The individual transactions look normal. The pattern is the signal.
The same principle applies to threat escalation. Individual events in isolation look manageable. A rude message from someone you don’t know. A financial transaction. A government agency contact. Each one has an explanation. But when they cluster in a compressed timeframe across multiple domains, you’re looking at coordination, not coincidence.
No consumer safety tool detects this. Law enforcement sees isolated incidents reported to different departments. A financial crime goes to one unit. A harassment report goes to another. A false filing goes to a third. Nobody connects them because the systems aren’t connected.
An engineering approach connects them. The same way fraud detection systems correlate transactions across accounts and channels and timeframes, a safety system can correlate threat events across domains and detect the pattern.
The Escalation Ladder
Threats escalate in predictable patterns. This isn’t speculation. It’s documented across security research, law enforcement data, and threat assessment literature. I structured it as a state machine with ten levels:
- Verbal threats via proxy
- Professional targeting
- Institutional weaponization (false reports, licensing complaints)
- Property interference
- Digital surveillance or monitoring
- Evidence fabrication
- Property damage
- Stalking or following
- Physical intimidation
- Physical harm
The value of the ladder isn’t just knowing where you are. It’s knowing the trajectory. Moving through six levels in three weeks is a different risk profile than sitting at level 2 for six months. Velocity matters as much as position.
Safety as a Constraint on Decision Systems
Here’s where it comes together. If you’re building any system that recommends actions, whether that’s a legal strategy platform, an autonomous vehicle, a military operations planner, or a corporate security tool, the system needs to understand that some recommendations increase physical risk.
The implementation is straightforward. Add a safety penalty to the objective function:
Outcome = benefit - cost - risk - safety_penaltyThe safety_penalty is computed from S-ARPN scores. The weight on the penalty (I default to 2.0) means safety concerns carry double the weight of equivalent financial risks. The system literally cannot recommend an action that looks financially optimal but physically dangerous without that danger being visible in the score.
This is how engineering systems work. The autopilot doesn’t optimize fuel efficiency in a way that exceeds structural load limits. The cloud orchestrator doesn’t optimize for latency in a way that violates redundancy requirements. Safety is a hard constraint, not a soft preference.
Compartmentalization: Protecting the Assessment Itself
One thing I learned from building this: the safety assessment is itself sensitive data. If someone accesses your risk scores, they know exactly how afraid you are, which protective measures you haven’t implemented, and where your gaps are.
The architecture handles this through compartmentalization. The decision system sees the safety penalty as a number. It doesn’t see the underlying scores, the threat actor details, or the protective measures register. Even if the decision system’s output is disclosed, the safety assessment stays protected. The penalty is visible. The vulnerability is not.
This is the same principle as zero-knowledge proofs. You prove a constraint is binding without revealing why. Applied to physical safety in a decision system, this pattern appears to be novel.
Who Needs This
The applications extend well beyond any single domain:
Legal technology. Attorneys representing clients in cases with a safety dimension need tools that integrate threat assessment into case strategy. Filing a motion might be legally optimal but physically risky. The system should surface that tradeoff.
Whistleblower protection. Someone considering a regulatory filing needs to understand how that filing changes their risk profile and what protective measures offset the increase.
Autonomous systems. Any system that makes decisions affecting human safety needs a constraint layer that can’t be optimized around. This is the alignment problem expressed as engineering practice.
Institutional threat assessment. Law enforcement, advocacy organizations, and corporate security all use threat assessment tools. None of them integrate that assessment into the decision systems that create and manage risk.
Open Source Intent
The methodology, the S-ARPN scoring specification, the escalation ladder framework, and the protective measures register format, these should be public goods. A DV advocate in a rural county with no budget should be able to run this scoring on paper and give a judge something quantified instead of something qualitative. An attorney should be able to document threat escalation with a framework that a court finds credible.
I’m releasing the scoring methodology openly. The commercial implementation is part of Acquit.ai, where Safety Shield runs as a constraint layer on the litigation intelligence platform. But the math belongs to everyone.
The Provenance
I didn’t design this in a conference room. The dimensions exist because I needed them. The behavioral impairment variable exists because I watched it matter. The escalation coupling dimension exists because I saw four domains activate on the same day and nobody in any institution connected them.
You don’t build something like this from theory. You build it because the alternative is unacceptable.
25 years of failure analysis across hyperscale cloud, manufacturing, fraud detection, and engineering. The methodology is proven in every domain it’s been applied to. Applying it to human safety is the most important thing I’ve done with it.
Safety should be a constraint, not a checklist.
Read the Full Technical Architecture
Safety Shield: Physical Safety as a Constraint Layer on Acquit.ai Insights. The complete S-ARPN scoring system, escalation ladder framework, optimizer integration architecture, and protective measures register.
Schedule a consultation to see Safety Shield applied to your case data.
The S-ARPN scoring methodology is available as an open source package: safety-shield on PyPI and GitHub. Install with pip install safety-shield.
Colin McNamara is the founder of Self-Improving Code and the creator of Acquit.ai, a litigation intelligence platform. His engineering background spans hyperscale cloud infrastructure (iCloud, Oracle Cloud), fraud analytics (ID Analytics), and manufacturing FMEA. He studied Lean Six Sigma at Purdue College of Engineering.