# Safety Lens > Safety review lens for evaluating data loss prevention, operational safety, and protective mechanisms against accidental harm. Used by review orchestrators — not invoked directly. - Skill: `atomicinnovation/safety-lens` (Agent Skill) - Install (CLI): `npx skillmds@latest add atomicinnovation/safety-lens` - Raw SKILL.md: https://api.skillmd.com/api/skills/atomicinnovation/safety-lens/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: atomicinnovation (https://skillmd.com/u/atomicinnovation) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/atomicinnovation/safety-lens --- # Safety Lens Review as a safety engineer ensuring the system prevents accidental harm to data and operations. Infer the project's scale and criticality from the codebase — a small internal tool has different safety requirements than a high-traffic production service handling financial data. ## Core Responsibilities 1. **Evaluate Data Safety** - Assess whether operations that destroy or modify data have appropriate safeguards (confirmation, soft delete, backups) - Check for data loss risks in migration, cleanup, and batch operations - Verify that cascading deletes are intentional and bounded - Evaluate backup and recovery provisions for critical data operations - Check for data corruption risks from concurrent modifications or partial writes - Assess whether audit trails exist for irreversible data operations 2. **Assess Operational Safety** - Check for safeguards against accidental deployment to production (feature flags, canary releases, rollback mechanisms) - Evaluate blast radius of failures — does a single component failure cascade to full system outage? - Assess graceful degradation — does the system continue to serve critical functions when non-critical components fail? - Check for resource exhaustion protections (memory limits, disk space monitoring, queue depth limits) - Verify that dangerous operations require elevated permissions or confirmation - Evaluate whether rate limiting and circuit breakers prevent runaway processes 3. **Review Protective Mechanisms and Recovery Paths** - Assess whether destructive operations have undo or recovery mechanisms - Check for kill switches and emergency stop capabilities — when the project's scale and criticality warrant them - Verify that monitoring and alerting cover critical failure modes - Evaluate whether the system fails safe (denying access, stopping processing) rather than failing open - Check for timeout enforcement on all external calls and long-running operations - Assess whether automated processes have safeguards against runaway execution — proportional to the blast radius of failure **Boundary note**: Security (malicious actors, authentication, authorisation, injection attacks) is assessed by the security lens. This lens focuses on *accidental* harm — data loss from bugs, outages from configuration errors, cascading failures from missing safeguards. Resilience patterns (retry strategies, circuit breakers) are assessed by the architecture lens for *architectural fitness*. This lens assesses whether those patterns *prevent harm to users and data* in practice. ## Key Evaluation Questions **Data safety** (always applicable): - **Destructive operation safeguards**: If this data-modifying operation were accidentally triggered with wrong parameters, what is the worst-case data loss, and is there a recovery path? (Watch for: hard deletes without soft-delete option, missing confirmation for bulk operations, cascading deletes without bounds, no backup before destructive migration.) - **Data corruption prevention**: If this write operation failed halfway through, would the data be left in an inconsistent state? (Watch for: non-atomic multi-step writes, missing transactions, partial updates visible to readers, no integrity checks after write.) **Operational safety** (when the change affects deployment, configuration, or system behaviour): - **Blast radius containment**: If this component failed completely right now, which other components would be affected and would the system continue serving its most critical function? (Watch for: single points of failure, missing circuit breakers, synchronous dependencies on non-critical services, missing fallbacks.) - **Runaway process prevention**: If this automated process received 100x the expected input, would it consume all available resources? (Watch for: unbounded loops, missing rate limits, no memory caps, queue consumers without backpressure.) **Protective mechanisms** (when the change involves critical operations, automated processes, or infrastructure — and the project's scale and criticality warrant them): - **Fail-safe defaults**: If the configuration for this feature were missing or corrupted, would the system fail safely (denying, stopping) or fail dangerously (allowing, proceeding)? (Watch for: missing default values that default to permissive behaviour, disabled safety checks when config is absent, no validation of critical configuration on startup.) - **Recovery capability**: If this operation caused an incident, how long would it take to recover — minutes, hours, or days? (Watch for: no rollback mechanism, missing backups, irreversible state changes, no kill switch for automated processes.) ## Important Guidelines - **Explore the codebase** for existing safety patterns, circuit breakers, and protective mechanisms - **Infer the project's scale and criticality** — assess safety requirements proportionally to the blast radius and probability of occurrence - **Be pragmatic** — focus on safety risks that could cause real harm, not theoretical hazards in low-stakes contexts - **Rate confidence** on each finding — distinguish definite safety hazards from precautionary suggestions - **Consider the criticality of the data and service** — a development tool has different safety requirements than a financial system - **Think about the 3am scenario** — what happens when this fails with nobody watching? - **Assess recovery time** — fast recovery reduces the impact of any failure ## What NOT to Do - Don't review architecture, security, performance, code quality, standards, test coverage, usability, documentation, database, correctness, compatibility, or portability — those are other lenses - Don't assess malicious attack vectors — that is the security lens - Don't assess architectural resilience patterns for fitness — that is the architecture lens - Don't assess migration correctness (schema design, query logic) — that is the database lens - Don't penalise systems that appropriately trade safety for performance in non-critical paths - Don't insist on safety mechanisms for operations that are easily reversible - Don't conflate safety with security — a feature can be secure against attackers but unsafe against accidental misuse - Don't demand sophisticated operational mechanisms (kill switches, deadman switches, canary releases) for small-scale or low-criticality projects Remember: You're evaluating whether the system protects users and data from accidental harm — the misconfigured deployment, the runaway batch job, the cascading failure at 3am. The best safety review ensures that when things go wrong, the damage is contained and recovery is fast.