{ "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-12T09:02:48Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 18.9, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a094d9-f7b2-7a13-a687-6c77ded7080c\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: defensive programming\nSense to describe: (none recorded)\nDomain code: INF.KNW\nAlso known as: (none)\n\n\nContext for this batch of 1001 things:\n# Batch 043", "usd": 0.0, "recall": true }, "codex": { "seconds": 61.4, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a094d9-f7bf-74d1-8b2d-00a849a19da8\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: defensive programming\nRegistry id: vr.tr.defensive-programming\nPlane / domain: INF / INF.KNW\nRegistry definition: (none recorded)\nNames folded into t" } }, "enrichment": { "pass": 3, "engine": "claude", "producedAt": "2026-10-06T12:00:00Z", "ingestedAt": "2026-10-06T08:45:54+00:00", "fields": [ "agent_conduct", "ethics", "failure_modes_and_hazards", "owners", "standards_and_regulation" ] }, "gate": { "passed": true, "version": "1.0", "at": "2026-10-07T10:10:25+00:00", "evidence": [ "completeness 1.00", "sense: Wikidata description", "2 live sources", "review by codex: pass" ] } }, "metaModel": { "id": "THING-Q1182643", "registryId": "vr.tr.defensive-programming", "name": "defensive programming", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "INF.KNW" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q1182643/", "model": { "registry_id": "vr.tr.defensive-programming", "name": "defensive programming", "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.", "definition": "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.", "scope_statement": "This model owns defensive programming as a software development practice: making assumptions explicit, checking them at appropriate boundaries, preserving valid state, and controlling failure when inputs, dependencies or execution conditions violate expectations.", "in_scope": [ "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_of_scope": [ "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" ], "distinguishing_features": [ "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." ], "characteristics": [ { "name": "Assumption being defended", "kind": "category", "unit_or_values": "input validity | caller contract | internal invariant | dependency behaviour | resource availability | execution ordering", "why_it_matters": "Connects each defense to a concrete condition whose violation could cause incorrect behaviour." }, { "name": "Boundary location", "kind": "relation", "unit_or_values": "relationship to an external input, public interface, internal module boundary or dependency interface", "why_it_matters": "Determines where checks belong and which guarantees downstream code may rely on." }, { "name": "Enforcement mechanism", "kind": "category", "unit_or_values": "type restriction | validated construction | runtime guard | assertion | structured failure handling", "why_it_matters": "Distinguishes prevention of invalid states from detection and response during execution." }, { "name": "Violation response", "kind": "category", "unit_or_values": "reject | propagate failure | terminate operation | roll back | retry within limits | use specified fallback", "why_it_matters": "Makes the consequences of a failed assumption reviewable." }, { "name": "Deployment activation", "kind": "state", "unit_or_values": "always enforced | configuration-dependent | development-only | disabled | unknown", "why_it_matters": "Prevents reliance on defenses that are absent in the deployed execution environment." }, { "name": "Residual state after failure", "kind": "state", "unit_or_values": "unchanged | restored | valid but degraded | partially modified | invalid | unknown", "why_it_matters": "Reveals whether detecting a problem actually prevents downstream corruption." }, { "name": "Defense overhead", "kind": "measurement", "unit_or_values": "latency in milliseconds, memory in bytes, or operation count under a specified workload", "why_it_matters": "Supports proportionate placement of checks, especially within frequently executed paths." }, { "name": "Verification evidence", "kind": "relation", "unit_or_values": "links to review records, static analysis, tests, fault-injection results or operational observations", "why_it_matters": "Separates intended defensive behaviour from behaviour supported by evidence." } ], "affordances": [ "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." ], "agent_conduct": { "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." ], "must_not": [ "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." ], "requires_human": [ "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." ], "affected_parties": [ "Users of the software", "Developers", "People affected by system failures" ] }, "owners": { "steward": "Nobody owns it; it is a software development practice.", "master_systems": [] }, "failure_modes_and_hazards": [ "Excessive checks can hide real errors behind default values.", "Missing checks let invalid input corrupt data or open security holes." ], "standards_and_regulation": [ "SEI CERT C Coding Standard, Software Engineering Institute, Carnegie Mellon University." ], "what_it_is_for": [ "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." ], "facets_not_applicable": { "recognition": "Defensive programming is a development approach that must be assessed through behavior and reasoning rather than visual appearance." } }, "sources": [ { "id": "wikidata", "title": "Wikidata item Q1182643: defensive programming", "url": "https://www.wikidata.org/wiki/Q1182643", "url_status": "live", "what_it_supports": "identity and sense of the item", "checked_by": "wikidata-api" }, { "id": "wikipedia-en", "title": "Wikipedia: Defensive programming", "url": "https://en.wikipedia.org/wiki/Defensive_programming", "url_status": "live", "what_it_supports": "general description of the item", "checked_by": "wikidata-api sitelink" } ], "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.", "rationale": "A defense cannot be judged without identifying the assumption it protects and the responsibility for enforcing it.", "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?", "kind": "definition", "id": "explicit-preconditions-q01" }, { "text": "Which preconditions must the callee check, and which may it rely on callers or construction rules to guarantee?", "kind": "boundary", "id": "explicit-preconditions-q02" } ] } ] }, { "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?", "kind": "definition", "id": "invariant-enforcement-q01" }, { "text": "Can restricted types or validated constructors prevent the invalid state, or is an execution-time check required?", "kind": "action", "id": "invariant-enforcement-q02" } ] } ] } ] }, { "id": "boundary-validation", "name": "Boundary validation", "description": "How data becomes acceptable for use after crossing an interface or trust boundary.", "rationale": "Defensive programming needs explicit acceptance criteria and a clear account of when validated data can safely be trusted.", "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?", "kind": "definition", "id": "input-acceptance-q01" }, { "text": "At what point are malformed, oversized or inconsistent inputs rejected before allocation, indexing or state mutation?", "kind": "action", "id": "input-acceptance-q02" } ] } ] }, { "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?", "kind": "boundary", "id": "validated-value-continuity-q01" }, { "text": "Should use be coupled atomically to the check, operate on an immutable snapshot or require revalidation?", "kind": "action", "id": "validated-value-continuity-q02" } ] } ] } ] }, { "id": "failure-and-state-integrity", "name": "Failure and state integrity", "description": "How detected violations become explicit outcomes while preserving valid program state.", "rationale": "Detecting a violation is insufficient if handling conceals the failure, leaks resources or leaves partial changes exposed.", "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?", "kind": "definition", "id": "guard-and-assertion-policy-q01" }, { "text": "If assertions are disabled, which required checks still execute and how are their failures reported?", "kind": "boundary", "id": "guard-and-assertion-policy-q02" } ] } ] }, { "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?", "kind": "boundary", "id": "partial-operation-containment-q01" }, { "text": "How are owned resources released and valid state restored or explicitly marked as degraded?", "kind": "action", "id": "partial-operation-containment-q02" } ] } ] } ] }, { "id": "dependencies-and-bounded-recovery", "name": "Dependencies and bounded recovery", "description": "Defenses against dependency misbehaviour, unavailable resources and recovery attempts that could amplify failure.", "rationale": "Code must account for failures outside its control without turning recovery into unbounded work or incorrect success.", "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?", "kind": "definition", "id": "dependency-result-checks-q01" }, { "text": "What deadlines, cancellation handling and size limits bound the caller's exposure to this dependency?", "kind": "action", "id": "dependency-result-checks-q02" } ] } ] }, { "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?", "kind": "boundary", "id": "retry-and-fallback-validity-q01" }, { "text": "What bounds recovery attempts, and what contract makes a fallback result acceptable and distinguishable from normal success?", "kind": "action", "id": "retry-and-fallback-validity-q02" } ] } ] } ] }, { "id": "defense-evidence-and-proportionality", "name": "Defense evidence and proportionality", "description": "Evidence of defensive effectiveness and the costs of maintaining and executing checks.", "rationale": "Defenses can be inactive, untested, redundant or counterproductive; their presence alone does not establish robustness.", "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?", "kind": "provenance", "id": "defensive-outcome-verification-q01" }, { "text": "Which observable signals confirm that the defense fired without exposing sensitive input or overwhelming diagnostics?", "kind": "measurement", "id": "defensive-outcome-verification-q02" } ] } ] }, { "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?", "kind": "measurement", "id": "proportionate-check-placement-q01" }, { "text": "Which verified upstream guarantees would justify removing a repeated check, and could another entry path bypass them?", "kind": "action", "id": "proportionate-check-placement-q02" } ] } ] } ] }, { "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.", "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.", "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.", "evidence": [ "Defensive programming is generally treated as an approach within software engineering rather than an independently institutionalized discipline.", "The listed kinds are recognizable groups of practices, not a standardized taxonomy.", "The named coding standards are relevant guidance, not universal requirements or dedicated standards for defensive programming; applicable editions and rules require verification." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of defensive programming this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-kinds", "name": "Kinds and varieties", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Input validation at system and component boundaries", "Runtime checking of invariants and preconditions", "Defensive handling of errors and resource failures" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of defensive programming this model covers, and on what evidence?", "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.", "evidence": [ "SEI CERT Coding Standards, maintained by the Software Engineering Institute, provide language-specific rules and recommendations relevant to defensive programming.", "MISRA C, issued by MISRA, provides guidelines for using C in critical systems, including restrictions relevant to preventing programming errors." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of defensive programming this model covers, and on what evidence?", "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.", "evidence": [ "Rejecting malformed or out-of-range data before processing it.", "Checking bounds and arithmetic limits before indexing arrays or calculating sizes.", "Handling failed allocations, unavailable services and unsuccessful file operations.", "Checking internal invariants to detect defects near their origin.", "Containing failures through controlled shutdown or explicitly designed degraded operation." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of defensive programming this model covers, and on what evidence?", "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.", "evidence": [ "Catching and suppressing errors can conceal defects and allow corrupted state to propagate.", "Excessive or duplicated checks can increase complexity, obscure intended behavior and introduce inconsistent validation.", "Assertions may be disabled in production and therefore cannot reliably replace required validation.", "Checking a resource before using it can still permit a time-of-check to time-of-use race.", "Fallbacks and retries can amplify failures or produce unsafe behavior when their consequences are not explicitly designed." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of defensive programming this model covers, and on what evidence?", "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.", "evidence": [ { "name": "Secure programming", "difference": "Secure programming specifically addresses security threats and adversarial behavior; defensive programming also addresses accidental misuse and ordinary operational failures." }, { "name": "Design by contract", "difference": "Design by contract specifies obligations through preconditions, postconditions and invariants; defensive programming chooses checks and responses for situations in which assumptions or obligations fail." }, { "name": "Fault tolerance", "difference": "Fault tolerance concerns continued acceptable service despite faults, often through redundancy or recovery; defensive programming can instead detect a fault and stop execution safely." }, { "name": "Software testing", "difference": "Testing executes software to evaluate behavior and expose defects; defensive programming places protective logic in the implementation." }, { "name": "Formal verification", "difference": "Formal verification establishes properties through mathematical reasoning; defensive programming introduces operational checks and handling without necessarily proving those properties." } ], "questions": [ { "id": "evidence-neighbours-q01", "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?", "kind": "provenance" } ] } ] } ] } ] }, "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?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 16, "questions": 26 } }