defensive programming

Explicit preconditions

Record accepted inputs, required execution context and the party responsible for enforcing each precondition.

1. Which values, object states or calling sequences violate this interface's preconditions? definition
2. Which preconditions must the callee check, and which may it rely on callers or construction rules to guarantee? boundary

Invariant enforcement

Record invariants, permitted temporary violations and whether enforcement prevents or detects invalid states.

1. Which invariants must remain true at observable points, including exceptional exits? definition
2. Can restricted types or validated constructors prevent the invalid state, or is an execution-time check required? action

Input acceptance

Record checks for representation, ranges, sizes and relationships among values before consequential use.

1. Which checks establish structural validity, and which establish validity for this operation's meaning? definition
2. At what point are malformed, oversized or inconsistent inputs rejected before allocation, indexing or state mutation? action

Validated value continuity

Record whether transformation, mutation or concurrent access can invalidate a check before the value is used.

1. Can decoding, normalisation, shared mutation or elapsed time change the checked value or its relevant context? boundary
2. Should use be coupled atomically to the check, operate on an immutable snapshot or require revalidation? action

Guard and assertion policy

Record distinctions among rejected inputs, operational failures and programmer defects, including the deployment behaviour of their checks.

1. Does this condition represent invalid caller input, an expected operational failure or a broken internal assumption? definition
2. If assertions are disabled, which required checks still execute and how are their failures reported? boundary

Partial operation containment

Record commit points, cleanup responsibilities and guarantees about partially completed operations.

1. Which mutations or external effects may already have occurred when each failure path is taken? boundary
2. How are owned resources released and valid state restored or explicitly marked as degraded? action

Dependency result checks

Record handling of missing, malformed, partial, late or otherwise unusable dependency results.

1. Which dependency outcomes violate the caller's assumptions even when the dependency reports success? definition
2. What deadlines, cancellation handling and size limits bound the caller's exposure to this dependency? action

Retry and fallback validity

Record retry eligibility, stopping rules and the semantics of any substitute result.

1. Can a retry duplicate an effect when the previous attempt's outcome is unknown? boundary
2. What bounds recovery attempts, and what contract makes a fallback result acceptable and distinguishable from normal success? action

Defensive outcome verification

Record evidence that a triggered defense produces the intended outcome and preserves required invariants.

1. Which tests or fault-injection results exercise rejection, cleanup and recovery exhaustion in the deployed configuration? provenance
2. Which observable signals confirm that the defense fired without exposing sensitive input or overwhelming diagnostics? measurement

Proportionate check placement

Record the justification for check placement and evidence needed before consolidating or removing checks.

1. What execution overhead and maintenance burden does this defense introduce under representative use? measurement
2. Which verified upstream guarantees would justify removing a repeated check, and could another entry path bypass them? action

Check these first

Recalled without web access and unsourced; every item is a lead to verify.

1. Which of these check these first hold for the sense of defensive programming this model covers, and on what evidence? provenance

Kinds and varieties

Recalled without web access and unsourced; every item is a lead to verify.

1. Which of these kinds and varieties hold for the sense of defensive programming this model covers, and on what evidence? provenance

Standards and regulation

Recalled without web access and unsourced; every item is a lead to verify.

1. Which of these standards and regulation hold for the sense of defensive programming this model covers, and on what evidence? provenance

Real-world use

Recalled without web access and unsourced; every item is a lead to verify.

1. Which of these real-world use hold for the sense of defensive programming this model covers, and on what evidence? provenance

Failure modes and hazards

Recalled without web access and unsourced; every item is a lead to verify.

1. Which of these failure modes and hazards hold for the sense of defensive programming this model covers, and on what evidence? provenance

Neighbouring kinds and how to tell them apart

Recalled without web access and unsourced; every item is a lead to verify.

1. Which of these neighbouring kinds and how to tell them apart hold for the sense of defensive programming this model covers, and on what evidence? provenance