{"schema":"https://ver.cy/schemas/card/1.0.0","id":"vr.tr.defensive-programming","code":"thing-q1182643","url":"https://ver.cy/models/thing/q1182643/","name":"defensive programming","alternateNames":[],"kind":"thing","status":"published","version":"0.1.0-research.1","language":"en","classifiers":{"family":"Thing Registry","category":"Information and virtual systems","entryKind":"thing","plane":"INF","domain":["INF.KNW"],"industry":[],"navPath":"","tags":[],"facets":{}},"whatItIs":"Defensive programming is a software development approach that explicitly anticipates invalid inputs, violated assumptions and component failures and implements checks and controlled responses to preserve correctness or limit harm.","purpose":"Enable an AI agent to recognise defensive programming practices, assess whether they protect stated assumptions and invariants, and select proportionate responses to unexpected conditions.","scope":{"in":["Assumptions, contracts and invariants that require defensive treatment","Validation of inputs and dependency outputs at identified boundaries","Defensive handling of invalid states, unavailable resources and unexpected failures","Containment, recovery and diagnostic behaviour of defensive controls","Evidence that defenses work and remain proportionate to their costs"],"out":["Software engineering as the encompassing discipline","Complete cybersecurity threat models and security governance","Testing methods independent of the defensive behaviours they evaluate","Programming language specifications and general type-system design","System-wide fault-tolerance architectures beyond the code-level defenses they require"],"boundaries":[]},"distinguishingFeatures":["A defensive practice identifies an assumption that can fail and specifies the resulting behaviour; adding checks without an identified assumption is insufficient.","Unlike testing alone, a defense constrains construction or execution of the software when an unexpected condition occurs.","Unlike ordinary feature logic, a defense addresses violations of expected conditions or prevents invalid states from being represented.","Defensive programming addresses accidental misuse and operational failures as well as potentially hostile inputs; security-specific protection is an overlapping concern.","A defensive response must preserve an explicit correctness or safety requirement; silently substituting a value or catching every exception does not by itself qualify."],"structure":{"bundles":[{"id":"assumptions-and-contracts","name":"Assumptions and contracts","description":"The expectations a program relies on and the guarantees it must preserve when those expectations fail.","layers":[{"id":"caller-obligations","name":"Caller obligations","description":"Preconditions at interfaces and responsibility for checking them.","findings":[{"id":"explicit-preconditions","name":"Explicit preconditions","description":"Record accepted inputs, required execution context and the party responsible for enforcing each precondition.","questions":[{"text":"Which values, object states or calling sequences violate this interface's preconditions?","id":"explicit-preconditions-q01","kind":"definition"},{"text":"Which preconditions must the callee check, and which may it rely on callers or construction rules to guarantee?","id":"explicit-preconditions-q02","kind":"boundary"}]}]},{"id":"state-invariants","name":"State invariants","description":"Conditions that must hold before, during or after operations.","findings":[{"id":"invariant-enforcement","name":"Invariant enforcement","description":"Record invariants, permitted temporary violations and whether enforcement prevents or detects invalid states.","questions":[{"text":"Which invariants must remain true at observable points, including exceptional exits?","id":"invariant-enforcement-q01","kind":"definition"},{"text":"Can restricted types or validated constructors prevent the invalid state, or is an execution-time check required?","id":"invariant-enforcement-q02","kind":"action"}]}]}]},{"id":"boundary-validation","name":"Boundary validation","description":"How data becomes acceptable for use after crossing an interface or trust boundary.","layers":[{"id":"acceptance-rules","name":"Acceptance rules","description":"Structural and semantic conditions for accepting incoming data.","findings":[{"id":"input-acceptance","name":"Input acceptance","description":"Record checks for representation, ranges, sizes and relationships among values before consequential use.","questions":[{"text":"Which checks establish structural validity, and which establish validity for this operation's meaning?","id":"input-acceptance-q01","kind":"definition"},{"text":"At what point are malformed, oversized or inconsistent inputs rejected before allocation, indexing or state mutation?","id":"input-acceptance-q02","kind":"action"}]}]},{"id":"validation-lifetime","name":"Validation lifetime","description":"The conditions under which an earlier validation remains applicable.","findings":[{"id":"validated-value-continuity","name":"Validated value continuity","description":"Record whether transformation, mutation or concurrent access can invalidate a check before the value is used.","questions":[{"text":"Can decoding, normalisation, shared mutation or elapsed time change the checked value or its relevant context?","id":"validated-value-continuity-q01","kind":"boundary"},{"text":"Should use be coupled atomically to the check, operate on an immutable snapshot or require revalidation?","id":"validated-value-continuity-q02","kind":"action"}]}]}]},{"id":"failure-and-state-integrity","name":"Failure and state integrity","description":"How detected violations become explicit outcomes while preserving valid program state.","layers":[{"id":"failure-signalling","name":"Failure signalling","description":"How unexpected conditions are classified and communicated.","findings":[{"id":"guard-and-assertion-policy","name":"Guard and assertion policy","description":"Record distinctions among rejected inputs, operational failures and programmer defects, including the deployment behaviour of their checks.","questions":[{"text":"Does this condition represent invalid caller input, an expected operational failure or a broken internal assumption?","id":"guard-and-assertion-policy-q01","kind":"definition"},{"text":"If assertions are disabled, which required checks still execute and how are their failures reported?","id":"guard-and-assertion-policy-q02","kind":"boundary"}]}]},{"id":"exceptional-exit-integrity","name":"Exceptional exit integrity","description":"State and resource guarantees when an operation cannot complete.","findings":[{"id":"partial-operation-containment","name":"Partial operation containment","description":"Record commit points, cleanup responsibilities and guarantees about partially completed operations.","questions":[{"text":"Which mutations or external effects may already have occurred when each failure path is taken?","id":"partial-operation-containment-q01","kind":"boundary"},{"text":"How are owned resources released and valid state restored or explicitly marked as degraded?","id":"partial-operation-containment-q02","kind":"action"}]}]}]},{"id":"dependencies-and-bounded-recovery","name":"Dependencies and bounded recovery","description":"Defenses against dependency misbehaviour, unavailable resources and recovery attempts that could amplify failure.","layers":[{"id":"dependency-assumptions","name":"Dependency assumptions","description":"Expectations about responses, completion and resource use at dependency interfaces.","findings":[{"id":"dependency-result-checks","name":"Dependency result checks","description":"Record handling of missing, malformed, partial, late or otherwise unusable dependency results.","questions":[{"text":"Which dependency outcomes violate the caller's assumptions even when the dependency reports success?","id":"dependency-result-checks-q01","kind":"definition"},{"text":"What deadlines, cancellation handling and size limits bound the caller's exposure to this dependency?","id":"dependency-result-checks-q02","kind":"action"}]}]},{"id":"recovery-constraints","name":"Recovery constraints","description":"Conditions under which retrying or falling back preserves correctness.","findings":[{"id":"retry-and-fallback-validity","name":"Retry and fallback validity","description":"Record retry eligibility, stopping rules and the semantics of any substitute result.","questions":[{"text":"Can a retry duplicate an effect when the previous attempt's outcome is unknown?","id":"retry-and-fallback-validity-q01","kind":"boundary"},{"text":"What bounds recovery attempts, and what contract makes a fallback result acceptable and distinguishable from normal success?","id":"retry-and-fallback-validity-q02","kind":"action"}]}]}]},{"id":"defense-evidence-and-proportionality","name":"Defense evidence and proportionality","description":"Evidence of defensive effectiveness and the costs of maintaining and executing checks.","layers":[{"id":"violation-path-evidence","name":"Violation path evidence","description":"Verification and observations tied to specific failed assumptions.","findings":[{"id":"defensive-outcome-verification","name":"Defensive outcome verification","description":"Record evidence that a triggered defense produces the intended outcome and preserves required invariants.","questions":[{"text":"Which tests or fault-injection results exercise rejection, cleanup and recovery exhaustion in the deployed configuration?","id":"defensive-outcome-verification-q01","kind":"provenance"},{"text":"Which observable signals confirm that the defense fired without exposing sensitive input or overwhelming diagnostics?","id":"defensive-outcome-verification-q02","kind":"measurement"}]}]},{"id":"defense-maintenance","name":"Defense maintenance","description":"Review of defense cost, duplication and continued relevance as contracts change.","findings":[{"id":"proportionate-check-placement","name":"Proportionate check placement","description":"Record the justification for check placement and evidence needed before consolidating or removing checks.","questions":[{"text":"What execution overhead and maintenance burden does this defense introduce under representative use?","id":"proportionate-check-placement-q01","kind":"measurement"},{"text":"Which verified upstream guarantees would justify removing a repeated check, and could another entry path bypass them?","id":"proportionate-check-placement-q02","kind":"action"}]}]}]},{"id":"evidence-and-external-alignment","name":"Evidence and external alignment","description":"What the world already says about this thing, gathered so the model can be checked against it.","layers":[{"id":"reported-evidence","name":"Reported evidence","description":"Findings from the breadth pass, kept separate from the structural claims.","findings":[{"id":"evidence-confidence-notes","name":"Check these first","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these check these first hold for the sense of defensive programming this model covers, and on what evidence?","id":"evidence-confidence-notes-q01","kind":"provenance"}]},{"id":"evidence-kinds","name":"Kinds and varieties","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these kinds and varieties hold for the sense of defensive programming this model covers, and on what evidence?","id":"evidence-kinds-q01","kind":"provenance"}]},{"id":"evidence-standards-and-regulation","name":"Standards and regulation","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these standards and regulation hold for the sense of defensive programming this model covers, and on what evidence?","id":"evidence-standards-and-regulation-q01","kind":"provenance"}]},{"id":"evidence-real-world-use","name":"Real-world use","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these real-world use hold for the sense of defensive programming this model covers, and on what evidence?","id":"evidence-real-world-use-q01","kind":"provenance"}]},{"id":"evidence-failure-modes-and-hazards","name":"Failure modes and hazards","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these failure modes and hazards hold for the sense of defensive programming this model covers, and on what evidence?","id":"evidence-failure-modes-and-hazards-q01","kind":"provenance"}]},{"id":"evidence-neighbours","name":"Neighbouring kinds and how to tell them apart","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"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?","id":"evidence-neighbours-q01","kind":"provenance"}]}]}]}]},"agentConduct":{"may":["Apply input validation, assertions and error handling in code it is authorized to write.","Review code for unchecked inputs and unsafe assumptions and report them."],"mustNot":["Swallow errors silently so that failures go unnoticed.","Present code as robust or secure when its checks are missing or untested.","Disable safety checks in production to save effort or time."],"requiresHuman":["Changing error-handling behaviour in safety-critical or financial systems."]},"ethics":{"considerations":["Unchecked failures in software can harm people who rely on it, from patients to account holders."],"affectedParties":["Users of the software","Developers","People affected by system failures"]},"owners":{"steward":"Nobody owns it; it is a software development practice.","roles":[],"masterSystems":[]},"relations":[{"target":"Q2734875","type":"parent","note":"registry parent class"},{"target":"Q39487140","type":"parent","note":"registry parent class"}],"interaction":{"identity":{"applicability":"required","items":["Vercy registry: vr.tr.defensive-programming","Wikidata: Q1182643 (https://www.wikidata.org/wiki/Q1182643)"]},"properties":{"applicability":"not-applicable","items":["Assumption being defended: input validity | caller contract | internal invariant | dependency behaviour | resource availability | execution ordering","Boundary location: relationship to an external input, public interface, internal module boundary or dependency interface","Enforcement mechanism: type restriction | validated construction | runtime guard | assertion | structured failure handling","Violation response: reject | propagate failure | terminate operation | roll back | retry within limits | use specified fallback","Deployment activation: always enforced | configuration-dependent | development-only | disabled | unknown","Residual state after failure: unchanged | restored | valid but degraded | partially modified | invalid | unknown","Defense overhead: latency in milliseconds, memory in bytes, or operation count under a specified workload","Verification evidence: links to review records, static analysis, tests, fault-injection results or operational observations"]},"recognition":{"applicability":"not-applicable","items":[]},"capabilities":{"applicability":"required","items":["Identify implicit assumptions and propose enforceable contracts or invariants.","Locate missing, duplicated or misplaced checks at software boundaries.","Choose a violation response consistent with state integrity and caller expectations.","Generate targeted cases that exercise invalid inputs, dependency failures and recovery limits.","Review whether assertions, fallbacks and exception handlers remain effective in deployment.","Recommend simplifying a defense when another verified guarantee makes it redundant."]},"hazards":{"applicability":"required","items":["Excessive checks can hide real errors behind default values.","Missing checks let invalid input corrupt data or open security holes."]},"interfaces":{"applicability":"required","items":["SEI CERT C Coding Standard, Software Engineering Institute, Carnegie Mellon University."]},"context":{"applicability":"required","items":["Defensive programming is used when software must respond predictably to invalid inputs, unexpected states or failures in other components.","It is encountered in input validation, interface boundaries and error handling, where checks and controlled responses protect explicitly stated assumptions."]}},"sources":[{"title":"Wikidata item Q1182643: defensive programming","url":"https://www.wikidata.org/wiki/Q1182643","note":"identity and sense of the item"},{"title":"Wikipedia: Defensive programming","url":"https://en.wikipedia.org/wiki/Defensive_programming","note":"general description of the item"}],"openQuestions":["Which authoritative sources should anchor this registry entry's definition and its boundary with design by contract, secure coding and fault-tolerant programming?","Should the registry classify defensive programming primarily as a practice, a technique family or a field of knowledge, and which classification convention supports that choice?","How broadly should compile-time prevention through types and validated construction count as defensive programming rather than general correctness-oriented design?","Which language- and runtime-specific profiles are needed to represent assertion activation, exception guarantees and resource cleanup accurately?","What evidence threshold should justify relying on upstream validation or removing a defense in systems with different consequences of failure?"],"resources":{"spec":"/models/things/publications/thing-q1182643/spec.json"},"provenance":{"origin":"thing registry research (pass 2)","builtFrom":["models/things/publications/thing-q1182643/spec.json"],"providers":["Codex"],"researchStatus":"unreviewed","generatedAt":"2026-09-12T09:02:48Z","builder":"tools/build_cards.py@1.0.0"},"completeness":{"sections":{"classifiers":"filled","whatItIs":"filled","purpose":"filled","distinguishingFeatures":"filled","structure":"filled","agentConduct":"filled","ethics":"filled","owners":"filled","relations":"filled","interaction.identity":"filled","interaction.properties":"not-applicable","interaction.recognition":"not-applicable","interaction.capabilities":"filled","interaction.hazards":"filled","interaction.interfaces":"filled","interaction.context":"filled","sources":"filled"},"notes":{"_gate":"Published through the thing publication gate 1.0 on 2026-10-07T10:10:25+00:00: completeness 1.00; sense: Wikidata description; 2 live sources; review by codex: pass","interaction.properties":"Plane INF: no invented physical properties.","interaction.recognition":"Defensive programming is a development approach that must be assessed through behavior and reasoning rather than visual appearance."},"score":1.0}}