{"schema":"https://ver.cy/schemas/card/1.0.0","id":"vr.wm-sft-014","code":"wm-sft-014-defect-bug","url":"https://ver.cy/models/wm-sft-014-defect-bug/","name":"Defect / Bug","alternateNames":[],"kind":"world-model","status":"published","version":"0.3.0-research.1","language":"en","classifiers":{"family":"World Models","category":"Information and virtual systems","entryKind":"entity","plane":"","domain":["INF.SFT.BUG"],"industry":["Cross-industry"],"navPath":"NAV.INF.SFT.BUG","tags":["defect","bug","inf.sft.bug"],"facets":{}},"whatItIs":"Covers the defect record as an entity: what deviation is asserted, in which product versions and environments, on what evidence, how it is classified and ranked, how its state advances to a recorded resolution, and how the record is owned, exchanged, protected and retained. It stops at the corrective change itself, test execution, service restoration and advisory publication, holding only typed references and subject-specific binding parameters for those neighbours.","purpose":"Give an agent the context needed to record, classify, assess, resolve and retire a software defect record, from first observation to verified closure and disposition.","scope":{"in":["Terminology binding fixing whether the record asserts a problem, defect, fault or observed failure","Identity, uniqueness and duplicate resolution of the defect record","Affected product, component, version-range and environment scope","Observation narrative, reproduction recipe, detection context and evidence artifacts","Anomaly type, causal chain and security-weakness classification","Severity, impact, priority and response-target assessment","State model, triage, resolution classification, verification outcome and closure","Typed relations to other defects and references to changes, incidents, cases, requirements and tests","Interchange projections, record provenance, access constraints, retention and defect-population measures"],"out":["Authoring, review, build, merge, release or deployment of the corrective software change","Test case design and test execution records that supply verification evidence","Service incident detection, escalation and restoration of production service","Customer support case intake and complaint handling","CVE publication, advisory authoring and coordinated-disclosure execution","Regulatory notification submission and deadline management","Enhancement and feature requests that assert no deviation from expected behaviour","Product and version catalogue mastering","Access-control enforcement, tamper-evident logging and organisational audit-trail services"],"boundaries":[{"neighbor":"WM-SFT-013 (software change)","distinction":"This model may carry the resolving-change reference, fixed-in version and link-assertion metadata only; change authoring, review, build, release and deployment lifecycle stay in the target model."},{"neighbor":"WM-ACT-021 (parent activity/work item)","distinction":"Generic work-item assignment, scheduling, effort and queue mechanics are inherited from the parent; this model specialises only defect-specific classification, resolution and evidence semantics."},{"neighbor":"Test case and test execution records","distinction":"Verification outcome, time and verifier are recorded here as closure facts; the executed test design and its results are owned by the testing model and referenced."},{"neighbor":"Service incident / outage management","distinction":"An incident is a service-availability event with restoration goals; a defect is a persisting product deviation. Incidents are referenced, never modelled here."},{"neighbor":"Vulnerability disclosure and advisory publication","distinction":"CWE, CVE and CVSS values are alignments carried on the record; advisory authoring, disclosure timing and publication are owned by the disclosure neighbour."},{"neighbor":"Regulatory reporting","distinction":"Only the reportability determination and its hand-off reference are held here; notification execution and deadline tracking belong to the reporting process."},{"neighbor":"Enhancement / change request","distinction":"OSLC separates Defect from Enhancement; records asserting new capability rather than deviation are out of scope."},{"neighbor":"Access-control and audit systems","distinction":"Confidentiality labels and embargo flags are declarative attributes; evaluation, enforcement and audit-trail retention are performed by adopting-Dimension services."}]},"distinguishingFeatures":["Records an asserted deviation from expected behaviour with evidence and affected versions, not the fix itself.","Differs from a service incident, which is about restoring service, and from an enhancement request.","Differs from a vulnerability advisory, which is a public disclosure about a security defect.","Keeps severity and priority as separate rankings."],"structure":{"bundles":[{"id":"subject-identity-and-scope","name":"Subject, Identity and Affected Scope","description":"What the record asserts, how it is identified and uniquely held, and which product versions and environments it applies to.","layers":[{"id":"defect-identity-layer","name":"Concept, Identity and Subject Binding","description":"Terminology binding, identifier assignment and uniqueness, and the affected product, version and environment scope of the assertion.","findings":[{"id":"defect-terminology-binding","name":"Defect terminology binding","description":"Fixes whether the record asserts a reported problem, a confirmed defect, an underlying fault or an observed failure, and against which vocabulary.","questions":[{"text":"Which term of art does this record instantiate: reported problem, confirmed defect, underlying fault, or observed failure?","id":"q-term-1","kind":"definition"},{"text":"Is the recorded item a product anomaly, a work-product or documentation anomaly, or an environment and configuration issue?","id":"q-term-2","kind":"classification"},{"text":"Does the record assert deviation from a stated requirement, or from an unstated expectation that requires adjudication?","id":"q-term-3","kind":"decision"},{"text":"Which external vocabulary supplies the definition in force, and at which edition?","id":"q-term-4","kind":"interoperability"}]},{"id":"defect-record-identity","name":"Record identity and uniqueness","description":"Identifier assignment across systems of record and governed global schemes, plus duplicate and merge resolution.","questions":[{"text":"Which system of record assigns the authoritative identifier for this defect?","id":"q-ident-1","kind":"identity"},{"text":"Which governed global identifier, such as a CVE ID or an OSLC resource IRI, additionally names this defect?","id":"q-ident-2","kind":"identity"},{"text":"On what evidence is one record declared a duplicate of another, and which record survives as canonical?","id":"q-ident-3","kind":"decision"},{"text":"Which identifiers were carried across from a migrated or upstream tracker, and how are they preserved?","id":"q-ident-4","kind":"provenance"}]},{"id":"affected-scope-and-environment","name":"Affected product, version and environment scope","description":"Which products, components, version ranges and runtime configurations are affected, not affected, fixed or still under investigation.","questions":[{"text":"Which products, components and version ranges are known affected, known not affected, fixed or under investigation?","id":"q-scope-1","kind":"composition"},{"text":"As of which observation time is each affected-status assertion held to be valid?","id":"q-scope-2","kind":"temporal"},{"text":"What evidence supports a known-not-affected assertion instead of leaving the product under investigation?","id":"q-scope-3","kind":"evidence"},{"text":"Which platform, runtime, locale and configuration values are material to whether the deviation appears?","id":"q-scope-4","kind":"spatial"}]}]}]},{"id":"observation-and-evidence","name":"Observation and Evidence","description":"What was observed, how it is reproduced, in which activity it was detected, and what evidence substantiates the claim.","layers":[{"id":"failure-observation-layer","name":"Observation, Reproduction and Detection Context","description":"The narrative deviation report, its reproduction recipe, and the activity, trigger and channel through which it was detected.","findings":[{"id":"symptom-reproduction-and-detection","name":"Symptom, reproduction and detection context","description":"Expected versus actual behaviour, reproduction steps and frequency, and the lifecycle activity, trigger and detector that surfaced it.","questions":[{"text":"What were the expected result, the actual result and the exact steps that produced the deviation?","id":"q-obs-1","kind":"evidence"},{"text":"How often does the failure occur per attempt, and is it deterministic, intermittent or not reproducible?","id":"q-obs-2","kind":"measurement"},{"text":"During which lifecycle activity was the anomaly encountered, and what trigger surfaced the latent fault?","id":"q-obs-3","kind":"process"},{"text":"When did the failure occur, when was it first observed, and when was it reported?","id":"q-obs-4","kind":"temporal"},{"text":"Did the anomaly escape to production or to an external party before detection?","id":"q-obs-5","kind":"event"}]}]},{"id":"evidence-corpus-layer","name":"Evidence Corpus","description":"Diagnostic artifacts substantiating the report, their integrity fixing, sufficiency and redaction.","findings":[{"id":"evidence-artifacts-and-integrity","name":"Evidence artifacts, integrity and redaction","description":"Logs, dumps, captures and minimal reproductions attached to the record, with integrity fixing, sufficiency judgement and sensitive-data handling.","questions":[{"text":"Which artifacts substantiate the report: logs, stack traces, core dumps, captures or a minimal reproduction?","id":"q-evid-1","kind":"evidence"},{"text":"How is each evidence artifact's integrity fixed at the moment of attachment?","id":"q-evid-2","kind":"validation"},{"text":"Is the evidence sufficient to reproduce, or must further material be requested from the reporter?","id":"q-evid-3","kind":"quality"},{"text":"Which personal data, credentials or customer content must be masked before evidence is retained?","id":"q-evid-4","kind":"privacy"}]}]}]},{"id":"classification-and-assessment","name":"Classification and Assessment","description":"The nature and cause of the anomaly, its security-weakness alignment, and the severity, priority and regulatory significance assigned to it.","layers":[{"id":"nature-and-cause-layer","name":"Nature and Cause Classification","description":"Anomaly type and qualifier, the causal chain from improper operation to observed failure, and alignment to security weakness catalogues.","findings":[{"id":"anomaly-type-and-causal-classification","name":"Anomaly type and causal classification","description":"Coded anomaly type, qualifier and affected quality characteristic, plus the causal chain and insertion point of the defect.","questions":[{"text":"Which anomaly type best describes the correction required, such as function, interface, checking, assignment, timing or documentation?","id":"q-class-1","kind":"classification"},{"text":"Which quality characteristic is degraded: functional correctness, performance, security, usability or compatibility?","id":"q-class-2","kind":"quality"},{"text":"What improper operation or improper operand caused the first weakness, and how did the error propagate to the observed failure?","id":"q-class-3","kind":"composition"},{"text":"In which artifact and lifecycle phase was the defect inserted, and by which preceding change?","id":"q-class-4","kind":"provenance"},{"text":"Is the recorded root cause a verified conclusion or a working hypothesis?","id":"q-class-5","kind":"decision"}]},{"id":"security-weakness-alignment","name":"Security weakness alignment","description":"Alignment of security-relevant defects to weakness catalogues, vulnerability identifiers and severity vectors without owning disclosure.","questions":[{"text":"Is this defect security-relevant, and which weakness type in the catalogue applies?","id":"q-sec-1","kind":"security"},{"text":"Which severity vector and score have been assigned, on which metric version, and by which assessing party?","id":"q-sec-2","kind":"measurement"},{"text":"Which authority owns vulnerability identifier assignment for the affected product?","id":"q-sec-3","kind":"authority"},{"text":"What is asserted when a bundled component is vulnerable but this product is not exploitable?","id":"q-sec-4","kind":"exception"}]}]},{"id":"impact-and-response-ranking","name":"Impact, Priority and Regulatory Significance","description":"Severity and impact assessment, priority and response targets, and whether a regulatory reporting threshold is met.","findings":[{"id":"severity-and-impact-assessment","name":"Severity and impact assessment","description":"Assigned severity on a governed scale, the worst credible consequence, and how severity changes are justified and dated.","questions":[{"text":"What severity value is assigned, on which governed scale, and against which impact definition?","id":"q-sev-1","kind":"measurement"},{"text":"What is the worst credible consequence for users, data or safety if the defect remains unresolved?","id":"q-sev-2","kind":"evidence"},{"text":"Who may raise or lower severity, and what justification must accompany the change?","id":"q-sev-3","kind":"authority"},{"text":"Is the history of severity revisions preserved as new information arrives?","id":"q-sev-4","kind":"temporal"}]},{"id":"priority-and-response-targets","name":"Priority and response targets","description":"Relative work ordering and response or resolution targets, kept distinct from severity.","questions":[{"text":"What priority is assigned, and how is it kept methodologically distinct from severity?","id":"q-prio-1","kind":"decision"},{"text":"Which response and resolution targets apply to this priority band?","id":"q-prio-2","kind":"requirement"},{"text":"Which factors, such as exposure, workaround availability or contractual duty, may override the default priority?","id":"q-prio-3","kind":"constraint"},{"text":"At which points in the record's life is priority re-evaluated?","id":"q-prio-4","kind":"process"}]},{"id":"regulatory-significance-determination","name":"Regulatory significance determination","description":"Whether the defect meets a reporting or regulated-records threshold, who determined it, and where the determination is handed off.","questions":[{"text":"Does this defect meet a regulatory reporting threshold, and which regime governs that threshold?","id":"q-reg-1","kind":"authority"},{"text":"Who made and recorded the reportability determination, and at what time?","id":"q-reg-2","kind":"ownership"},{"text":"Which facts and timestamps must be preserved to defend the determination if it is later challenged?","id":"q-reg-3","kind":"evidence"},{"text":"Which downstream process receives the determination and its payload for notification?","id":"q-reg-4","kind":"interoperability"}]}]}]},{"id":"lifecycle-and-resolution","name":"Lifecycle and Resolution","description":"The state model, triage decision, resolution classification, fix reference, verification and interim mitigation of the defect.","layers":[{"id":"state-and-triage-layer","name":"State Model and Triage","description":"Permitted states and transitions, and the triage decision that accepts, rejects, defers or routes the report.","findings":[{"id":"defect-state-model","name":"Defect state model","description":"States the record may occupy, permitted transitions, transition preconditions and reopening semantics.","questions":[{"text":"Which states may this record occupy, and which of them are terminal?","id":"q-state-1","kind":"state"},{"text":"Which transitions are permitted, and which of them demand a recorded reason or an approval?","id":"q-state-2","kind":"lifecycle"},{"text":"Which fields must be populated before a transition into a resolved or closed state is allowed?","id":"q-state-3","kind":"constraint"},{"text":"How do local states map onto the interoperable predicates for closed, in progress, fixed, approved, reviewed and verified?","id":"q-state-4","kind":"interoperability"},{"text":"How is reopening after closure represented without erasing the earlier closure facts?","id":"q-state-5","kind":"exception"}]},{"id":"triage-and-acceptance-decision","name":"Triage and acceptance decision","description":"Whether the report is accepted as a defect, rejected, deferred or routed elsewhere, and who becomes accountable.","questions":[{"text":"Was the report accepted as a defect, rejected, deferred, or routed to another queue or model?","id":"q-tri-1","kind":"decision"},{"text":"Which component owner or queue takes accountability once triage completes?","id":"q-tri-2","kind":"ownership"},{"text":"Which checks constitute completed triage, such as duplicate search, reproduction attempt and scope confirmation?","id":"q-tri-3","kind":"process"},{"text":"How long may a record remain untriaged before escalation is required?","id":"q-tri-4","kind":"temporal"}]}]},{"id":"resolution-and-closure-layer","name":"Resolution, Fix Reference and Verification","description":"How the record terminates, which change is claimed to resolve it, and how the resolution is verified before closure.","findings":[{"id":"resolution-classification","name":"Resolution classification","description":"The coded outcome terminating the record and the justification required for non-fix outcomes.","questions":[{"text":"Which resolution classification terminates this record: fixed, duplicate, not reproducible, works as designed, will not fix, or superseded?","id":"q-res-1","kind":"classification"},{"text":"What justification is mandatory when the outcome is anything other than a fix?","id":"q-res-2","kind":"requirement"},{"text":"How is a substantive resolution distinguished from mere administrative closure of the tracking record?","id":"q-res-3","kind":"quality"},{"text":"How does the local resolution value map to the exchange partner's closure reason vocabulary?","id":"q-res-4","kind":"interoperability"}]},{"id":"fix-reference-binding","name":"Resolving change reference binding","description":"Reference to the software change claimed to resolve the defect and the versions in which the fix first appears, without change lifecycle.","questions":[{"text":"Which software change records are claimed to resolve this defect?","id":"q-fix-1","kind":"relationship"},{"text":"Which product versions or builds first contain the fix?","id":"q-fix-2","kind":"composition"},{"text":"Which binding metadata may this record hold about the change without duplicating the change's own lifecycle?","id":"q-fix-3","kind":"constraint"},{"text":"How was the defect-to-change link established: author declaration, commit-message parsing, or verified confirmation?","id":"q-fix-4","kind":"provenance"}]},{"id":"verification-and-closure-criteria","name":"Verification and closure criteria","description":"Criteria, party, timing and outcome of verifying the resolution, and the conditions for closing the record.","questions":[{"text":"What criteria must be satisfied before a resolution is accepted as verified?","id":"q-ver-1","kind":"validation"},{"text":"Which party performs verification, in which environment, and against which build?","id":"q-ver-2","kind":"process"},{"text":"Where does the underlying verification evidence live, and what is stored here as a reference?","id":"q-ver-3","kind":"evidence"},{"text":"What must happen when verification fails or the defect recurs after closure?","id":"q-ver-4","kind":"exception"}]},{"id":"workaround-and-containment-advice","name":"Workaround and containment advice","description":"Interim mitigation available to affected users while the defect remains unresolved, with applicability limits and validity window.","questions":[{"text":"What temporary workaround or containment measure is available to affected users?","id":"q-work-1","kind":"requirement"},{"text":"Which conditions or side effects limit the workaround's applicability?","id":"q-work-2","kind":"constraint"},{"text":"From when is the workaround valid, and what supersedes it?","id":"q-work-3","kind":"temporal"},{"text":"Who may receive and redistribute the workaround while the defect is under embargo?","id":"q-work-4","kind":"access"}]}]}]},{"id":"relationships-and-interoperability","name":"Relationships and Interoperability","description":"Typed links to other defects and context records, interchange projections, and cross-system correlation and conflict handling.","layers":[{"id":"relationship-graph-layer","name":"Defect and Context Relationship Graph","description":"Typed links among defects and outward references to changes, incidents, cases, requirements and tests.","findings":[{"id":"defect-and-context-relations","name":"Defect and context relations","description":"Directional typed links between defects and to externally owned context records, with cardinality and propagation rules.","questions":[{"text":"Which typed links connect this defect to other defects: duplicate-of, blocks, depends-on, parent-of, or regression-of?","id":"q-rel-1","kind":"relationship"},{"text":"Which support cases, service incidents, requirements or test cases are linked, and which model owns each of them?","id":"q-rel-2","kind":"composition"},{"text":"Which link types are exclusive, and where are cycles forbidden?","id":"q-rel-3","kind":"constraint"},{"text":"How does closing a blocking defect affect the records that depend on it?","id":"q-rel-4","kind":"lifecycle"},{"text":"How many distinct customer reports or incidents are attributed to this defect?","id":"q-rel-5","kind":"measurement"}]}]},{"id":"exchange-and-correlation-layer","name":"Interchange and Cross-System Correlation","description":"Projections into external representations and reconciliation of the same defect across multiple systems.","findings":[{"id":"interchange-representations","name":"Interchange representations","description":"Target representations the record must be projectable into, their schema versions, mapping tables and lossy fields.","questions":[{"text":"Into which external representations must this record be projectable, and at which schema versions?","id":"q-exch-1","kind":"interoperability"},{"text":"Which local fields have no counterpart in a target schema and are therefore lost on export?","id":"q-exch-2","kind":"constraint"},{"text":"How is a projection validated against the target schema before it is released?","id":"q-exch-3","kind":"validation"},{"text":"How is the source record version recorded inside an exported representation?","id":"q-exch-4","kind":"provenance"}]},{"id":"cross-system-correlation-and-conflicts","name":"Cross-system correlation and conflicts","description":"Correlating the same defect across trackers and resolving field-level conflicts and out-of-order updates.","questions":[{"text":"How are records for the same defect in different systems correlated to a single subject?","id":"q-corr-1","kind":"identity"},{"text":"Which system is authoritative when field values conflict between mirrored records?","id":"q-corr-2","kind":"decision"},{"text":"How are out-of-order or replayed updates from mirrored systems reconciled?","id":"q-corr-3","kind":"temporal"},{"text":"What is done when the authoritative system rejects or withdraws a record that others still reference?","id":"q-corr-4","kind":"exception"}]}]}]},{"id":"governance-access-and-measurement","name":"Governance, Access and Measurement","description":"Stewardship, record provenance, confidentiality, retention and the quality and measurement of the defect corpus.","layers":[{"id":"stewardship-and-provenance-layer","name":"Stewardship and Record Provenance","description":"Who owns and may change the record's content, and how its own version history and time semantics are kept.","findings":[{"id":"ownership-and-stewardship","name":"Ownership and stewardship","description":"Accountability for the record's content, authority to change controlled fields, and continuity when ownership transfers.","questions":[{"text":"Who owns the defect record's content, as distinct from who owns the corrective work?","id":"q-own-1","kind":"ownership"},{"text":"Who is authorised to change classification, severity, state and confidentiality level?","id":"q-own-2","kind":"authority"},{"text":"What becomes of stewardship when a component is transferred or an owning team is dissolved?","id":"q-own-3","kind":"process"},{"text":"Which stewardship roles must exist in an adopting Dimension for the record to be operable?","id":"q-own-4","kind":"requirement"}]},{"id":"record-provenance-and-revisions","name":"Record provenance and revisions","description":"Which actor or system supplied each value, how the record's own version advances, and how event, observation and ingestion times are separated.","questions":[{"text":"Which actor or system supplied each field value, and through which channel did it arrive?","id":"q-prov-1","kind":"provenance"},{"text":"How are event time, observation time and record ingestion time distinguished on this record?","id":"q-prov-2","kind":"temporal"},{"text":"How is the record's own version incremented, and what does its revision history retain?","id":"q-prov-3","kind":"state"},{"text":"How can a consumer detect that the record changed since it was last read?","id":"q-prov-4","kind":"validation"}]}]},{"id":"confidentiality-and-retention-layer","name":"Confidentiality, Access Constraints and Retention","description":"Declared confidentiality and embargo constraints on the record, and its retention and disposition duties.","findings":[{"id":"confidentiality-and-access-constraints","name":"Confidentiality and access constraints","description":"Declarative confidentiality level, embargo conditions, need-to-know scope and partial-disclosure representation.","questions":[{"text":"What confidentiality level applies to this record, and who is inside the need-to-know scope?","id":"q-conf-1","kind":"access"},{"text":"Under what embargo conditions is the record restricted, and which event lifts the embargo?","id":"q-conf-2","kind":"security"},{"text":"Which fields may carry personal or customer-identifying data, and how are they treated on disclosure?","id":"q-conf-3","kind":"privacy"},{"text":"How is partial disclosure represented, where metadata is visible but detail is withheld?","id":"q-conf-4","kind":"exception"}]},{"id":"retention-and-disposition","name":"Retention and disposition","description":"How long the record and its evidence must be kept, what remains after withdrawal, and who authorises early disposal.","questions":[{"text":"How long must the defect record and its evidence be retained after closure?","id":"q-ret-1","kind":"retention"},{"text":"Which regulatory or contractual duty sets the minimum retention period for this record?","id":"q-ret-2","kind":"requirement"},{"text":"What tombstone or rejection representation remains when a record is withdrawn?","id":"q-ret-3","kind":"lifecycle"},{"text":"Who authorises early deletion, anonymisation or legal hold, and what is recorded about it?","id":"q-ret-4","kind":"decision"}]}]},{"id":"quality-and-measurement-layer","name":"Record Quality and Population Measurement","description":"Completeness and consistency rules for individual records, and measures computed over the defect population.","findings":[{"id":"record-completeness-validation","name":"Record completeness and consistency validation","description":"Field obligations by state, cross-field consistency rules and handling of legacy records that fail current rules.","questions":[{"text":"Which fields are mandatory at submission, and which only at triage, resolution or closure?","id":"q-val-1","kind":"validation"},{"text":"Which cross-field rules must hold, such as a fixed-in version requiring a resolving change reference?","id":"q-val-2","kind":"constraint"},{"text":"How is submitted report quality scored and fed back to the reporting party?","id":"q-val-3","kind":"quality"},{"text":"How are migrated or legacy records that cannot satisfy current rules represented?","id":"q-val-4","kind":"exception"}]},{"id":"defect-population-measures","name":"Defect population measures","description":"Measures derived from the defect corpus for trend analysis, with explicit limits where inputs are owned elsewhere.","questions":[{"text":"Which measures are computed over the defect population, such as open counts, age distribution, reopen rate and escape rate?","id":"q-meas-1","kind":"measurement"},{"text":"Over which period and cohort is each measure computed, and against which record snapshot?","id":"q-meas-2","kind":"temporal"},{"text":"Is periodic trend analysis of problem reports a standing obligation in this context?","id":"q-meas-3","kind":"requirement"},{"text":"Which measures depend on data owned by other models and therefore cannot be computed from defect records alone?","id":"q-meas-4","kind":"interoperability"}]}]}]}]},"agentConduct":{"may":["Capture a defect report with reproduction steps and evidence.","Detect likely duplicates and propose links.","Suggest classification, severity and affected versions for triage.","Link the resolving change and record verification results."],"mustNot":["Close a defect as fixed without verification evidence.","Downgrade severity to meet a release target.","Publish details of an undisclosed security defect.","Copy personal data from user reports into public trackers.","Merge reports as duplicates when the evidence differs."],"requiresHuman":["Deciding not to fix a defect with safety or security impact.","Approving disclosure of a security defect.","Reporting a defect to a regulator."]},"ethics":{"considerations":["Defects in safety, medical or financial software can harm people; severity must reflect that harm.","Reporters and users named in reports deserve privacy.","Defect counts should not be used to blame individuals without context."],"affectedParties":["Users affected by the defect","Reporters and testers","Developers responsible for the fix"]},"owners":{"steward":"Name the system of record for defect identifiers per product line and publish its identifier namespace.","roles":[{"name":"Defect record steward","responsibilities":["Maintain accuracy, completeness and classification of records in scope","Approve duplicate merges and canonical record selection","Own the local code-list bindings and their versions"]},{"name":"Reporter or submitting party","responsibilities":["Supply observation, reproduction steps and evidence","Respond to requests for additional evidence","Declare confidentiality expectations attaching to supplied material"]},{"name":"Triage owner","responsibilities":["Decide acceptance, rejection, deferral or routing","Assign accountability and initial severity and priority","Escalate records that exceed untriaged age thresholds"]},{"name":"Resolution verifier","responsibilities":["Confirm closure criteria are met against a named build","Record the verification outcome, time and referenced evidence","Return failed verifications to an open state with a reason"]},{"name":"Security coordinator","responsibilities":["Assess security relevance and apply weakness and severity alignments","Apply confidentiality labels and embargo conditions","Record the reportability determination and hand it to the reporting process"]},{"name":"Records and retention owner","responsibilities":["Publish the retention schedule and jurisdictional duties","Authorise early disposition and manage legal holds","Execute destruction, archival and anonymisation under Dimension policy"]}],"masterSystems":[]},"relations":[{"target":"WM-ACT-021","type":"child","note":"Inherit generic work-item identity, assignment, queueing and scheduling semantics from the parent activity model and specialise only defect-specific classification, evidence and resolution behaviour."},{"target":"WM-SFT-013","type":"references","note":"Carry the resolving-change reference, fixed-in version binding and link provenance for development traceability; the change's authoring, review, build, release and deployment lifecycle remains in the target model."},{"target":"OSLC Change Management Version 3.0 (OASIS Standard)","type":"aligned","note":"Align defect resource semantics, state predicates, severity and priority properties and link predicates for cross-tool interchange."},{"target":"IEEE 1044-2009 Classification for Software Anomalies","type":"aligned","note":"Align anomaly classification attributes; the standard is Inactive-Reserved, so alignment is asserted as a mapping and not as conformance."},{"target":"ISO/IEC/IEEE 24765 Systems and software engineering vocabulary","type":"aligned","note":"Bind terminology for defect, fault, failure, error and anomaly to a governed vocabulary edition."},{"target":"Common Weakness Enumeration (CWE)","type":"aligned","note":"Classify security-relevant defects by weakness type using an externally governed catalogue version."},{"target":"CVE Record Format v5.1.0","type":"aligned","note":"Enable projection of security-relevant defects into the governed vulnerability record format; identifier assignment and publication remain with the assigning authority."},{"target":"CVSS v4.0 Specification","type":"aligned","note":"Carry severity vector strings and scores for security-relevant defects, always publishing vector together with score."},{"target":"CSAF 2.0 and its VEX profile","type":"aligned","note":"Express affected, not affected, fixed and under-investigation product status and remediation categories for downstream consumers."},{"target":"ISO/IEC/IEEE 29119-3:2021 test documentation","type":"aligned","note":"Align the defect report document with the standard incident report information item used in test documentation."},{"target":"IEC 62304 medical device software life cycle processes","type":"aligned","note":"Satisfy regulated expectations for documented problem reports, retained resolution records, verification of resolutions and trend analysis where the adopting Dimension is in scope of the standard."},{"target":"Regulation (EU) 2024/2847 (Cyber Resilience Act)","type":"aligned","note":"Support vulnerability identification, documentation and remediation duties and supply the determination inputs for reporting obligations executed by the reporting neighbour."},{"target":"WM-SFT-013 (software change)","type":"neighbor","note":"This model may carry the resolving-change reference, fixed-in version and link-assertion metadata only; change authoring, review, build, release and deployment lifecycle stay in the target model."},{"target":"WM-ACT-021 (parent activity/work item)","type":"neighbor","note":"Generic work-item assignment, scheduling, effort and queue mechanics are inherited from the parent; this model specialises only defect-specific classification, resolution and evidence semantics."},{"target":"Test case and test execution records","type":"neighbor","note":"Verification outcome, time and verifier are recorded here as closure facts; the executed test design and its results are owned by the testing model and referenced."},{"target":"Service incident / outage management","type":"neighbor","note":"An incident is a service-availability event with restoration goals; a defect is a persisting product deviation. Incidents are referenced, never modelled here."},{"target":"Vulnerability disclosure and advisory publication","type":"neighbor","note":"CWE, CVE and CVSS values are alignments carried on the record; advisory authoring, disclosure timing and publication are owned by the disclosure neighbour."},{"target":"Regulatory reporting","type":"neighbor","note":"Only the reportability determination and its hand-off reference are held here; notification execution and deadline tracking belong to the reporting process."},{"target":"Enhancement / change request","type":"neighbor","note":"OSLC separates Defect from Enhancement; records asserting new capability rather than deviation are out of scope."},{"target":"Access-control and audit systems","type":"neighbor","note":"Confidentiality labels and embargo flags are declarative attributes; evaluation, enforcement and audit-trail retention are performed by adopting-Dimension services."}],"interaction":{"identity":{"applicability":"required","items":["Authoritative master-system identifier: the defect identifier assigned by the designated system of record for the product line, qualified by that system's namespace.","Governed global identifier or IRI: an externally governed identifier such as an assigned vulnerability identifier or a change-management resource IRI.","UUID or ULID minted by the adopting Dimension when neither a master-system identifier nor a governed global identifier is available.","A date, reporting period, title, summary text or affected version is never an identifier and may only be an attribute."]},"properties":{"applicability":"not-applicable","items":[]},"recognition":{"applicability":"optional","items":["A defect record states expected and actual behaviour, affected versions, evidence, severity and status.","Often confused with an incident, a feature request and a support ticket."]},"capabilities":{"applicability":"required","items":["Capture defect report: Create a defect record from an observation, binding subject, environment, evidence and report timing.","Detect and resolve duplicates: Search for existing records describing the same defect and establish the canonical record.","Triage and classify defect: Decide acceptance, assign accountability and record anomaly type, qualifier and causal hypothesis.","Assert affected scope: Record which products and version ranges are affected, not affected, fixed or under investigation, with justification.","Rank severity and priority: Assign severity on the governed scale and a separate priority with response targets and rationale.","Bind resolving change reference: Attach a typed reference to the software change claimed to resolve the defect together with fixed-in versions.","Record verification outcome: Record the conclusion, verifier, build and references of an externally executed verification of the resolution.","Close or withdraw record: Terminate the record with a resolution classification or withdraw it, preserving prior facts.","Project defect to interchange format: Generate a validated projection of the record into a target external representation and record the loss profile.","Compute defect population measures: Compute cohort measures over defect records for trend analysis, declaring externally owned inputs.","Apply retention disposition: Evaluate the retention schedule for a closed record and mark the disposition decision for execution by the records owner."]},"hazards":{"applicability":"required","items":["Underrated severity leaves harmful defects unfixed.","Premature closure lets regressions reach users.","Security details leak before a fix is available."]},"interfaces":{"applicability":"required","items":["IEEE 1044-2009 classification for software anomalies.","ISO/IEC/IEEE 29119-3 test documentation.","MITRE CWE weakness identifiers.","CVE identifiers for security defects."]},"context":{"applicability":"required","items":["Vulnerability handling and reporting duties are drawn from Regulation (EU) 2024/2847 and apply to products with digital elements placed on the EU market; other jurisdictions impose different thresholds and timelines.","Regulated retention and problem-resolution expectations reference IEC 62304 for medical device software; adopting Dimensions in other regulated sectors must substitute their own applicable regime.","Personal-data redaction assumes a data-protection regime with erasure and minimisation duties; the applicable law and its interaction with retention duties are Dimension-specific.","Vulnerability identifier assignment assumes participation in a CNA-style authority structure, which is not universal across products or regions."]}},"sources":[{"title":"IEEE 1044-2009 - IEEE Standard Classification for Software Anomalies","url":"https://standards.ieee.org/ieee/1044/4607/","note":"IEEE Standards Association"},{"title":"OSLC Change Management Version 3.0 - Part 1: Specification (OASIS Standard)","url":"https://docs.oasis-open-projects.org/oslc-op/cm/v3.0/os/change-mgt-spec.html","note":"OASIS Open Projects"},{"title":"OSLC Change Management Version 3.0 - Part 2: Vocabulary (OASIS Standard)","url":"https://docs.oasis-open-projects.org/oslc-op/cm/v3.0/os/change-mgt-vocab.html","note":"OASIS Open Projects"},{"title":"CVE Record Format JSON Schema Documentation","url":"https://cveproject.github.io/cve-schema/schema/docs/","note":"CVE Program (MITRE)"},{"title":"Common Vulnerability Scoring System version 4.0: Specification Document","url":"https://www.first.org/cvss/v4-0/specification-document","note":"FIRST.Org, Inc."},{"title":"Common Security Advisory Framework Version 2.0 (OASIS Standard)","url":"https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html","note":"OASIS"},{"title":"BF Vulnerability State Model - Bugs Framework","url":"https://pages.nist.gov/BF/info/bf-vulnerability-models/bf-vulnerability-state-model","note":"National Institute of Standards and Technology"},{"title":"NIST SP 800-231, Bugs Framework (BF): Formalizing Cybersecurity Weaknesses and Vulnerabilities","url":"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-231.pdf","note":"National Institute of Standards and Technology"},{"title":"Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act)","url":"https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng","note":"European Parliament and Council of the European Union"},{"title":"GitHub REST API - Issues","url":"https://docs.github.com/en/rest/issues/issues","note":"GitHub, Inc."},{"title":"About CWE - Common Weakness Enumeration","url":"https://cwe.mitre.org/about/index.html","note":"MITRE Corporation"},{"title":"IEEE/ISO/IEC 29119-3-2021 - Software and systems engineering - Software testing - Part 3: Test documentation","url":"https://standards.ieee.org/ieee/29119-3/7499/","note":"IEEE Standards Association"},{"title":"ISO/IEC/IEEE 24765-2017 - Systems and software engineering - Vocabulary","url":"https://standards.ieee.org/ieee/24765/6800/","note":"IEEE Standards Association / ISO / IEC"},{"title":"IEC 62304:2006+AMD1:2015 CSV - Medical device software - Software life cycle processes","url":"https://webstore.iec.ch/en/publication/22794","note":"International Electrotechnical Commission"},{"title":"Bugzilla Documentation - Understanding a Bug","url":"https://bugzilla.readthedocs.io/en/latest/using/understanding.html","note":"Bugzilla Project (Mozilla Foundation)"},{"title":"Using the Four Keys to measure your DevOps performance","url":"https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance","note":"Google Cloud (DORA)"}],"openQuestions":["Obtain clause-level access to ISO/IEC/IEEE 29119-3 and IEC 62304 Edition 1.1 so that verification, problem-report retention and trend-analysis obligations can be cited normatively instead of through catalogue records and secondary summaries.","Search for a primary source that defines a normative catalogue of defect-population measures; the measurement dimension is currently a declared gap resting on a classification-supports-analysis statement, a trend-analysis obligation and a DevOps metrics blog post.","Register or explicitly disclaim the WM-ACT-021 parent relation and assign model identifiers to the unnamed neighbours: test case and test execution, service incident management, support case intake, vulnerability disclosure and advisory publication, regulatory reporting, and enhancement request.","Decide whether the defect trend report artifact and the defect-population-measures finding belong to this record-plane model or to a separate corpus-plane measurement model, and record the decision before the artifact identity hardens.","Run a function-coverage pass for evidence attachment with integrity fixing, redaction as patch, confidentiality labelling and embargo lifting, reportability determination hand-off, and cross-system correlation conflict resolution, none of which currently has an owning function.","Verify Regulation (EU) 2024/2847 reporting thresholds and timelines at article level, and add at least one non-EU regime so the regional assumption about reporting duties is not the only jurisdictional anchor in the model.","Cost, effort and financial impact estimation for defect resolution is not modelled and is left to the parent activity model.","Defect prediction, clustering and machine-learning triage assistance are excluded as tooling rather than record semantics.","Sector-specific problem-report content beyond the generic set, such as aviation or automotive safety report fields, is not enumerated.","Human-language localisation of report content and multilingual field handling is only implied through interchange schemas.","Bug bounty and researcher-reward handling is out of scope even though external reporters are represented.","Component provenance and software bill of materials linkage is referenced only through affected-scope assertions, not modelled."],"resources":{"spec":"/models/wm-sft-014-defect-bug/spec.yaml","agents":"/models/wm-sft-014-defect-bug/AGENTS.md","source":"https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-sft-014"},"provenance":{"origin":"world-models research","builtFrom":["models/wm-sft-014-defect-bug/spec.yaml","ver-cy/world-models/card-supplements/wm-sft-014-defect-bug.json"],"providers":["Claude"],"researchStatus":"reviewable-draft","generatedAt":"2026-09-03T03:38:41Z","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":"filled","interaction.capabilities":"filled","interaction.hazards":"filled","interaction.interfaces":"filled","interaction.context":"filled","sources":"filled"},"notes":{"interaction.properties":"Institutional or informational subject: no invented physical properties.","_supplement":"Sections authored in card supplement 1.0.0 by Claude (Opus 5.5) (2026-10-05, unreviewed). Written from the published specification and established practice in the field; no new sources were read. Unreviewed."},"score":1.0}}