# Feature Risk Analysis > Naming what could go wrong with a specific feature in a form that can be acted on: the failure stated as an event rather than a worry, how anyone would find out it happened, what reduces its probability or its cost, and what is done if it happens anyway. Use before implementation on anything touching data, integrations, concurrency or a released contract, when a plan has a risk section containing only adjectives, when a HIGH risk has no detection signal, when a migration or a breaking change is about to ship, or when a review asks what happens if this fails and there is no answer. Does not catalogue distributed failure modes in general (distributed-failure-catalogue, failure-models), does not decide whether a deliberate shortcut is acceptable (technical-debt-decisions), and does not design the resilience mechanism (timeouts-and-deadlines, retries-and-backoff, circuit-breakers, concurrency-limiting-and-bulkheads). - Skill: `robsonkades/feature-risk-analysis` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add robsonkades/feature-risk-analysis` - Raw SKILL.md: https://api.skillmd.com/api/skills/robsonkades/feature-risk-analysis/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: robsonkades (https://skillmd.com/u/robsonkades) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/robsonkades/feature-risk-analysis --- # Feature Risk Analysis ## Purpose A risk section is worth writing only if something changes because of it. Most do not: they list "performance", "data integrity" and "scope", rate everything medium, and are read once. **Detection** explains how anyone discovers the event; **fallback** states what can be done afterward. Missing detection or recovery is itself important risk evidence. Keep the row and its unresolved controls visible instead of discarding it as a worry. ## Workflow 1. **Derive candidates from the artefacts, not from a list of adjectives.** Every boundary crossing in the impact map, every standing assumption in the ledger, every decision taken without an answer, and every resource touching data or an integration is a candidate. `references/risk-register.md` gives the derivation table, the precise definition of each field, and the revisit procedure for the completion review. 2. **State each as an event**: something that happens, at a time, with a consequence. "The migration is slow" is not one; "the migration holds a lock on `orders` long enough to time out requests" is. 3. **Rate impact and likelihood** against a stated deployment/operation window and exposure. Use HIGH, MEDIUM or LOW with evidence, or UNKNOWN when evidence is insufficient; distinguish inherent risk from residual risk after controls actually verified. 4. **Write the detection.** What signal, seen by whom, how long after. If the honest answer is "a customer tells us", write that — it is the finding. 5. **Write mitigation and fallback.** Mitigation reduces probability or cost before the fact; fallback is what is done after. They are different fields and a register that merges them usually has only mitigation. 6. **Convert what is actionable into work.** A mitigation that requires code is a resource in the plan, not a paragraph in a document. 7. **Revisit controls and residual exposure at completion.** Link relevant input revisions, `IMP-*`/`ED-*`, mitigating `RES-*` and observed `EV-*`; acceptance is reconsidered when premises, implementation, workload or controls change. ## What to sweep Correctness, data (loss, corruption, migration, retention), concurrency, performance, scalability, reliability and failure handling, security and access, compatibility with existing callers and stored data, deployment and ordering, migration and rollback, operations and diagnosis, maintainability. Use relevant concerns as a coverage check. Record "none identified in the inspected scope" or "not assessed" honestly; no need to create empty rows for every category. When no dossier exists, derive a bounded register from the request and repository evidence. ## Rating | Level | Impact means | Probability means | | ---------- | ----------------------------------------------------------- | -------------------------------------------------------------------------------- | | **HIGH** | Severe loss/exposure or outage over the affected population | Expected or repeatedly observed under the stated exposure and controls | | **MEDIUM** | Material degradation or bounded manual recovery | Credible failure path under the stated operating conditions | | **LOW** | Limited, bounded harm with demonstrated recovery | Evidence supports infrequency in the stated window; not merely missing incidents | Rate impact by consequence, not by embarrassment. Rate probability against **this** system's history and controls, not against the general frequency of the failure class. One incident or absent prevention alone does not establish high likelihood; no incidents does not establish low likelihood. Record confidence, detection gaps and correlated/common-cause failures rather than multiplying ordinal labels into a probability. ## Decision rules ```text IF a risk has no detection THEN record it as undetected unless customer discovery is supported; identify a detection task or state why detection is infeasible. Do not invent a signal or drop the risk. IF a risk is HIGH impact THEN identify the control/acceptance decision needed before the action that creates exposure. Implement mitigations and investigate safely within existing authorization; block only dependent exposure when required controls or authority remain unresolved. IF the mitigation is work THEN it is a RES-* with an identifier, and it appears in the execution order. IF a risk exists only because an assumption is unconfirmed THEN seek repository/runtime evidence or a discriminating experiment first; ask only for material information that remains unavailable. Confirmation does not remove other failure paths. IF a risk is accepted THEN link existing acceptance evidence, residual consequence, scope, owner and reopening trigger; use GAP-* when the feature workflow calls for a bounded accepted gap. IF the register is long and everything is MEDIUM THEN check specificity, duplication and rating evidence. Preserve material undetectable risks; register length and rating distribution alone do not prove poor analysis. IF a risk cannot be reduced, detected or recovered from THEN it is a constraint on the design, and it belongs back in the solution phase. ``` ## Constraints - **Record risks even when ownership is unresolved.** Separate the control implementer from the authority accepting residual exposure. Reuse existing user authorization/delegation and applicable policy; risk labels alone do not create a new approval gate. Material exposure outside that authority remains pending, even if its likelihood is LOW. - **Do not restate the general failure modes of a technology.** The register is about this feature's use of it, in this system. - **Do not use the register to relitigate the design.** If the risk kills the option, that is a solution-phase finding, not a row. ## Output ```text RISK-02 The dispatch consumer reprocesses an event after a redeploy Impact HIGH duplicate outbound charges Probability UNKNOWN rate per redeploy not measured; replay/lost-ack path exists Detection reconcile provider operation IDs and charge totals with intended effects; a local unique row can hide duplicate remote charges Mitigation PLANNED RES-07: local deduplication plus stable downstream operation key and recovery for charge-success/local-commit-failure; CT-02/EV-07 required Fallback reconcile unknown outcomes before retry/refund; assigned operator/runbook Status OPEN — planned mitigation is not verified protection Acceptance residual exposure/authority pending; preserve prior authorized work RISK-05 The V42 migration locks orders for longer than the deploy window Impact MEDIUM failed requests during deploy Probability UNKNOWN until target engine/version, lock contention and long transactions are checked; a no-rewrite operation can still wait for an exclusive lock Detection observe lock waits and application errors during the actual DDL; deploy timeout alone does not prove server-side cancellation Mitigation PLANNED: bounded lock acquisition, representative concurrent-load test, confirmed cancellation/transaction cleanup and compatible rollout Fallback abort before acquisition where possible; verify DB state after failure. Retain an additive column during app rollback; dropping it can lose new data Acceptance pending required evidence and applicable deployment authority ``` Close with the material open risks, control evidence and exact actions blocked by missing controls/authority. Counts may help navigation but are not a readiness score; continue independent authorized work and mitigation development.