# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-09-03T03:38:41Z", "synthesisSha256": "5a5f9e1ad4cc848b678c42f77b96221b55e9ee6d8313a57bfc8250c4ecb86656", "providerMode": "single-provider-waiver", "providers": [ "Claude" ], "waivedProviders": [ "Grok" ] }, "metaModel": { "id": "WM-SFT-014", "registryId": "vr.wm-sft-014", "name": "Defect / Bug", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "entity", "family": "World Models", "category": "Information and virtual systems", "industry": [ "Cross-industry" ], "domain": [ "INF.SFT.BUG" ], "tags": [ "defect", "bug", "inf.sft.bug" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-sft-014-defect-bug/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-sft-014", "model": { "registry_id": "vr.wm-sft-014", "model_id": "WM-SFT-014", "name": "Defect / Bug", "entry_kind": "entity", "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_statement": "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.", "in_scope": [ "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_of_scope": [ "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" ], "boundary_notes": [ { "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.", "source_refs": [ "SRC-002", "SRC-003" ] }, { "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.", "source_refs": [ "SRC-003" ] }, { "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.", "source_refs": [ "SRC-012", "SRC-003" ] }, { "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.", "source_refs": [ "SRC-016", "SRC-009" ] }, { "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.", "source_refs": [ "SRC-004", "SRC-006", "SRC-011" ] }, { "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.", "source_refs": [ "SRC-009", "SRC-014" ] }, { "neighbor": "Enhancement / change request", "distinction": "OSLC separates Defect from Enhancement; records asserting new capability rather than deviation are out of scope.", "source_refs": [ "SRC-003" ] }, { "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.", "source_refs": [ "SRC-009", "SRC-006" ] } ] }, "sources": [ { "id": "SRC-001", "title": "IEEE 1044-2009 - IEEE Standard Classification for Software Anomalies", "organization": "IEEE Standards Association", "url": "https://standards.ieee.org/ieee/1044/4607/", "version_or_date": "Approved 2009-11-09, published 2010-01-07; status Inactive-Reserved since 2020-03-05", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:05:00Z", "relevance": "Uniform classification of software anomalies regardless of origin or lifecycle point; classification data supports causal analysis and process improvement." }, { "id": "SRC-002", "title": "OSLC Change Management Version 3.0 - Part 1: Specification (OASIS Standard)", "organization": "OASIS Open Projects", "url": "https://docs.oasis-open-projects.org/oslc-op/cm/v3.0/os/change-mgt-spec.html", "version_or_date": "OASIS Standard, 26 May 2021", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:06:00Z", "relevance": "Normative change-request resource with status, state, severity, priority and read-only state predicates closed, inProgress, fixed, approved, reviewed, verified." }, { "id": "SRC-003", "title": "OSLC Change Management Version 3.0 - Part 2: Vocabulary (OASIS Standard)", "organization": "OASIS Open Projects", "url": "https://docs.oasis-open-projects.org/oslc-op/cm/v3.0/os/change-mgt-vocab.html", "version_or_date": "OASIS Standard, 26 May 2021", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:07:00Z", "relevance": "Defines Defect, Enhancement, Task, State, Priority, Severity classes and properties closeDate, affectedByDefect, relatedChangeRequest, tracksChangeSet, testedByTestCase, parent." }, { "id": "SRC-004", "title": "CVE Record Format JSON Schema Documentation", "organization": "CVE Program (MITRE)", "url": "https://cveproject.github.io/cve-schema/schema/docs/", "version_or_date": "Record Format v5.1.0", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:08:00Z", "relevance": "Container model, cveMetadata state PUBLISHED/REJECTED, dateReserved/datePublished/dateUpdated, affected products and versions, problemTypes, metrics, timeline, solutions and workarounds." }, { "id": "SRC-005", "title": "Common Vulnerability Scoring System version 4.0: Specification Document", "organization": "FIRST.Org, Inc.", "url": "https://www.first.org/cvss/v4-0/specification-document", "version_or_date": "CVSS v4.0, document version 1.2, 2023-11-01 (revised 2024-06-18)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:09:00Z", "relevance": "Base, Threat, Environmental and Supplemental metric groups, vector-string form and the requirement to publish score together with the vector." }, { "id": "SRC-006", "title": "Common Security Advisory Framework Version 2.0 (OASIS Standard)", "organization": "OASIS", "url": "https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html", "version_or_date": "OASIS Standard, 18 November 2022", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:10:00Z", "relevance": "Tracking status draft/interim/final, revision history and versioning; product_status values known_affected, known_not_affected, fixed, first_fixed, under_investigation; remediation categories and VEX justifications." }, { "id": "SRC-007", "title": "BF Vulnerability State Model - Bugs Framework", "organization": "National Institute of Standards and Technology", "url": "https://pages.nist.gov/BF/info/bf-vulnerability-models/bf-vulnerability-state-model", "version_or_date": "Bugs Framework project pages, citing NIST SP 800-231 (2024)", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:11:00Z", "relevance": "Formal separation of bug, fault, error, weakness and failure and the propagating causal chain from an improper operation to an exploitable final error." }, { "id": "SRC-008", "title": "NIST SP 800-231, Bugs Framework (BF): Formalizing Cybersecurity Weaknesses and Vulnerabilities", "organization": "National Institute of Standards and Technology", "url": "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-231.pdf", "version_or_date": "NIST Special Publication 800-231, 2024", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:12:00Z", "relevance": "Cause-operation-consequence triple as the structured unit of weakness description, with attribute lists per BF class." }, { "id": "SRC-009", "title": "Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act)", "organization": "European Parliament and Council of the European Union", "url": "https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng", "version_or_date": "Regulation of 23 October 2024, OJ L, 20 November 2024", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:13:00Z", "relevance": "Annex I Part II duties to identify, document and remediate vulnerabilities without delay across a support period, and Article 14 phased reporting of actively exploited vulnerabilities and severe incidents." }, { "id": "SRC-010", "title": "GitHub REST API - Issues", "organization": "GitHub, Inc.", "url": "https://docs.github.com/en/rest/issues/issues", "version_or_date": "REST API version 2026-03-10", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:14:00Z", "relevance": "Widely deployed issue resource with state, state_reason (completed, reopened, not_planned, duplicate), labels, assignees, milestone, created_at/updated_at/closed_at and sub-issues." }, { "id": "SRC-011", "title": "About CWE - Common Weakness Enumeration", "organization": "MITRE Corporation", "url": "https://cwe.mitre.org/about/index.html", "version_or_date": "CWE List, updated three to four times per year; accessed 2026-09-03", "source_type": "classifier", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:15:00Z", "relevance": "Catalogue of software and hardware weakness types with organising views, used as the weakness classification for security-relevant defects." }, { "id": "SRC-012", "title": "IEEE/ISO/IEC 29119-3-2021 - Software and systems engineering - Software testing - Part 3: Test documentation", "organization": "IEEE Standards Association", "url": "https://standards.ieee.org/ieee/29119-3/7499/", "version_or_date": "Published 2021-10-28, active", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:16:00Z", "relevance": "Templates and content outlines for test documentation, including the incident report also known as anomaly, bug or defect report." }, { "id": "SRC-013", "title": "ISO/IEC/IEEE 24765-2017 - Systems and software engineering - Vocabulary", "organization": "IEEE Standards Association / ISO / IEC", "url": "https://standards.ieee.org/ieee/24765/6800/", "version_or_date": "Published 2017-08-28, active", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:17:00Z", "relevance": "Common systems and software engineering vocabulary used as the terminology authority for defect, fault, failure, error and anomaly." }, { "id": "SRC-014", "title": "IEC 62304:2006+AMD1:2015 CSV - Medical device software - Software life cycle processes", "organization": "International Electrotechnical Commission", "url": "https://webstore.iec.ch/en/publication/22794", "version_or_date": "Edition 1.1, 2015-06-26", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:18:00Z", "relevance": "Regulated life-cycle framework requiring documented problem reports, retained resolution records, verification of resolutions and trend analysis of problem reports." }, { "id": "SRC-015", "title": "Bugzilla Documentation - Understanding a Bug", "organization": "Bugzilla Project (Mozilla Foundation)", "url": "https://bugzilla.readthedocs.io/en/latest/using/understanding.html", "version_or_date": "Bugzilla documentation, latest build; accessed 2026-09-03", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:19:00Z", "relevance": "Product/component hierarchy, version, platform/OS, severity, P1-P5 priority, assignee, QA contact, target milestone, Depends On/Blocks, See Also; status and resolution values are explicitly installation-defined." }, { "id": "SRC-016", "title": "Using the Four Keys to measure your DevOps performance", "organization": "Google Cloud (DORA)", "url": "https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance", "version_or_date": "Published 2020-09-23", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:20:00Z", "relevance": "Change failure rate and time to restore service are computed from deployment and incident data, marking the boundary between defect-corpus measures and delivery-performance measures." } ], "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.", "rationale": "Classification, resolution and exchange are all undefined until the record's term of art, identifier and affected scope are fixed, and duplicate records otherwise corrupt every downstream measure.", "source_refs": [ "SRC-001", "SRC-004", "SRC-006", "SRC-013" ], "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.", "source_refs": [ "SRC-004", "SRC-006", "SRC-013", "SRC-015" ], "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.", "source_refs": [ "SRC-001", "SRC-007", "SRC-013" ], "questions": [ { "id": "q-term-1", "text": "Which term of art does this record instantiate: reported problem, confirmed defect, underlying fault, or observed failure?", "kind": "definition", "answer_data": [ "Term-of-record code", "Confirmation state", "Vocabulary reference and version" ] }, { "id": "q-term-2", "text": "Is the recorded item a product anomaly, a work-product or documentation anomaly, or an environment and configuration issue?", "kind": "classification", "answer_data": [ "Anomaly subject class", "Affected work-product reference" ] }, { "id": "q-term-3", "text": "Does the record assert deviation from a stated requirement, or from an unstated expectation that requires adjudication?", "kind": "decision", "answer_data": [ "Deviation basis code", "Referenced requirement or specification", "Adjudication note" ] }, { "id": "q-term-4", "text": "Which external vocabulary supplies the definition in force, and at which edition?", "kind": "interoperability", "answer_data": [ "Terminology authority identifier", "Edition or publication date" ] } ], "data_elements": [ { "id": "de-term-of-record", "name": "Term of record", "description": "Coded term the record instantiates within the bound vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-013" ] }, { "id": "de-deviation-basis", "name": "Deviation basis", "description": "Stated requirement, specification or expectation the observed behaviour departs from.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-terminology-authority-ref", "name": "Terminology authority reference", "description": "Reference to the vocabulary edition governing the term of record.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Terminology binding is a coded assertion over the record itself, resolvable against external vocabularies; it yields no separable deliverable and duplicating it as an artifact would create a second, divergent statement of the same fact." }, { "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.", "source_refs": [ "SRC-004", "SRC-010", "SRC-015", "SRC-003" ], "questions": [ { "id": "q-ident-1", "text": "Which system of record assigns the authoritative identifier for this defect?", "kind": "identity", "answer_data": [ "System-of-record reference", "Master identifier", "Identifier namespace" ] }, { "id": "q-ident-2", "text": "Which governed global identifier, such as a CVE ID or an OSLC resource IRI, additionally names this defect?", "kind": "identity", "answer_data": [ "Global identifier value", "Issuing scheme and authority" ] }, { "id": "q-ident-3", "text": "On what evidence is one record declared a duplicate of another, and which record survives as canonical?", "kind": "decision", "answer_data": [ "Duplicate-of reference", "Canonical record flag", "Merge rationale" ] }, { "id": "q-ident-4", "text": "Which identifiers were carried across from a migrated or upstream tracker, and how are they preserved?", "kind": "provenance", "answer_data": [ "Legacy identifier values", "Origin system reference", "Migration note" ] } ], "data_elements": [ { "id": "de-master-record-id", "name": "Master record identifier", "description": "Authoritative identifier assigned by the designated defect system of record.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-015" ] }, { "id": "de-global-identifier", "name": "Governed global identifier", "description": "CVE ID, IRI or other externally governed identifier for the same defect.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-003" ] }, { "id": "de-canonical-record-flag", "name": "Canonical record flag", "description": "Whether this record is the surviving canonical record after duplicate resolution.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-duplicate-of-ref", "name": "Duplicate-of reference", "description": "Reference to the canonical record this one duplicates.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-015" ] } ], "artifacts": [], "inline_only_rationale": "Identifiers and duplicate links are reference data that must remain resolvable in place; materialising them as artifacts would introduce copies that can drift from the system of record." }, { "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.", "source_refs": [ "SRC-006", "SRC-004", "SRC-015" ], "questions": [ { "id": "q-scope-1", "text": "Which products, components and version ranges are known affected, known not affected, fixed or under investigation?", "kind": "composition", "answer_data": [ "Affected product entries", "Product status codes", "Version range expressions" ] }, { "id": "q-scope-2", "text": "As of which observation time is each affected-status assertion held to be valid?", "kind": "temporal", "answer_data": [ "Status assertion time", "Superseded assertion reference" ] }, { "id": "q-scope-3", "text": "What evidence supports a known-not-affected assertion instead of leaving the product under investigation?", "kind": "evidence", "answer_data": [ "Justification code", "Supporting analysis reference" ] }, { "id": "q-scope-4", "text": "Which platform, runtime, locale and configuration values are material to whether the deviation appears?", "kind": "spatial", "answer_data": [ "Environment descriptor", "Deployment locus", "Configuration snapshot reference" ] } ], "data_elements": [ { "id": "de-affected-product-entry", "name": "Affected product entry", "description": "Product, component and version-range tuple with its affected-status code.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "de-product-status-code", "name": "Product status code", "description": "Known affected, known not affected, fixed, first fixed or under investigation.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "de-environment-descriptor", "name": "Environment descriptor", "description": "Platform, operating system, runtime, locale and configuration under which the deviation is observed.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-status-assertion-time", "name": "Status assertion time", "description": "Time at which the affected-status assertion was made.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Affected-scope statements are structured record fields; their publishable form as a VEX or advisory document is produced by the disclosure neighbour and is declared under the interchange finding rather than owned here." } ] } ] }, { "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.", "rationale": "A defect assertion is only actionable and falsifiable if the observed deviation, its reproduction conditions and its evidence are recorded with integrity and detection context.", "source_refs": [ "SRC-012", "SRC-001", "SRC-004" ], "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.", "source_refs": [ "SRC-012", "SRC-001", "SRC-010" ], "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.", "source_refs": [ "SRC-012", "SRC-001", "SRC-010", "SRC-007" ], "questions": [ { "id": "q-obs-1", "text": "What were the expected result, the actual result and the exact steps that produced the deviation?", "kind": "evidence", "answer_data": [ "Summary title", "Expected result", "Actual result", "Ordered reproduction steps" ] }, { "id": "q-obs-2", "text": "How often does the failure occur per attempt, and is it deterministic, intermittent or not reproducible?", "kind": "measurement", "answer_data": [ "Reproducibility code", "Observed occurrence ratio" ] }, { "id": "q-obs-3", "text": "During which lifecycle activity was the anomaly encountered, and what trigger surfaced the latent fault?", "kind": "process", "answer_data": [ "Detection activity code", "Trigger code", "Detection channel" ] }, { "id": "q-obs-4", "text": "When did the failure occur, when was it first observed, and when was it reported?", "kind": "temporal", "answer_data": [ "Occurrence time", "Observation time", "Report time" ] }, { "id": "q-obs-5", "text": "Did the anomaly escape to production or to an external party before detection?", "kind": "event", "answer_data": [ "Escape flag", "External reporter reference" ] } ], "data_elements": [ { "id": "de-summary-title", "name": "Summary title", "description": "Single-line statement of the deviation.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-012" ] }, { "id": "de-reproduction-steps", "name": "Reproduction steps", "description": "Ordered actions and inputs that produce the deviation.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-reproducibility-code", "name": "Reproducibility code", "description": "Deterministic, intermittent, environment-specific or not reproducible.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-012" ] }, { "id": "de-occurrence-time", "name": "Occurrence time", "description": "Time the failure occurred, distinct from the time it was observed or reported.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "de-detection-activity-code", "name": "Detection activity code", "description": "Review, unit test, system test, operation, monitoring or external report.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "af-defect-report-document", "name": "Defect report document", "description": "The documented information item stating the deviation, its reproduction and its context, as an incident or defect report.", "media_or_form": [ "Structured tracker record", "Markdown or HTML report", "Portable document rendering" ], "serial": false, "identity_strategy": "Identified by the master record identifier of the defect plus the record revision number; the rendering format is never part of identity.", "source_refs": [ "SRC-012", "SRC-010" ] } ], "inline_only_rationale": null } ] }, { "id": "evidence-corpus-layer", "name": "Evidence Corpus", "description": "Diagnostic artifacts substantiating the report, their integrity fixing, sufficiency and redaction.", "source_refs": [ "SRC-004", "SRC-012", "SRC-009" ], "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.", "source_refs": [ "SRC-004", "SRC-012", "SRC-009" ], "questions": [ { "id": "q-evid-1", "text": "Which artifacts substantiate the report: logs, stack traces, core dumps, captures or a minimal reproduction?", "kind": "evidence", "answer_data": [ "Evidence item list", "Evidence kind codes", "Capture times" ] }, { "id": "q-evid-2", "text": "How is each evidence artifact's integrity fixed at the moment of attachment?", "kind": "validation", "answer_data": [ "Content hash and algorithm", "Attachment time", "Attaching actor" ] }, { "id": "q-evid-3", "text": "Is the evidence sufficient to reproduce, or must further material be requested from the reporter?", "kind": "quality", "answer_data": [ "Sufficiency verdict", "Outstanding evidence request" ] }, { "id": "q-evid-4", "text": "Which personal data, credentials or customer content must be masked before evidence is retained?", "kind": "privacy", "answer_data": [ "Sensitivity label", "Redaction action record", "Residual-risk note" ] } ], "data_elements": [ { "id": "de-evidence-item", "name": "Evidence item", "description": "Attached diagnostic artifact with kind, capture time and provenance.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-content-hash", "name": "Content hash", "description": "Digest fixing the artifact content at attachment time.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-sensitivity-label", "name": "Sensitivity label", "description": "Confidentiality or personal-data classification of an evidence item.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-evidence-sufficiency-verdict", "name": "Evidence sufficiency verdict", "description": "Whether the corpus supports reproduction, analysis or neither.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "af-diagnostic-log-bundle", "name": "Diagnostic log bundle", "description": "Collected log, trace and telemetry excerpts covering the failure window.", "media_or_form": [ "Plain-text log", "Line-delimited structured records", "Compressed archive" ], "serial": false, "identity_strategy": "Identified by content hash bound to the parent defect record identifier; capture window is an attribute, never part of the identifier.", "source_refs": [ "SRC-004", "SRC-012" ] }, { "id": "af-crash-dump", "name": "Crash or memory dump", "description": "Process core, minidump or heap snapshot captured at failure.", "media_or_form": [ "Binary core image", "Vendor minidump format" ], "serial": false, "identity_strategy": "Content hash plus originating host and process identifiers, bound to the parent defect record identifier.", "source_refs": [ "SRC-004", "SRC-007" ] }, { "id": "af-minimal-reproduction-case", "name": "Minimal reproduction case", "description": "Smallest executable input, script or environment manifest that reproduces the deviation.", "media_or_form": [ "Source file or patch", "Executable script", "Container or environment manifest" ], "serial": false, "identity_strategy": "Content hash of the case bundle, bound to the parent defect record identifier and the environment descriptor it targets.", "source_refs": [ "SRC-012", "SRC-015" ] } ], "inline_only_rationale": null } ] } ] }, { "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.", "rationale": "Classification data drives causal analysis and process improvement, while severity, priority and reportability determine the response the organisation owes.", "source_refs": [ "SRC-001", "SRC-007", "SRC-011", "SRC-005", "SRC-009" ], "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.", "source_refs": [ "SRC-001", "SRC-007", "SRC-011" ], "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.", "source_refs": [ "SRC-001", "SRC-007", "SRC-008" ], "questions": [ { "id": "q-class-1", "text": "Which anomaly type best describes the correction required, such as function, interface, checking, assignment, timing or documentation?", "kind": "classification", "answer_data": [ "Anomaly type code", "Type qualifier of missing, incorrect or extraneous", "Scheme version" ] }, { "id": "q-class-2", "text": "Which quality characteristic is degraded: functional correctness, performance, security, usability or compatibility?", "kind": "quality", "answer_data": [ "Affected quality characteristic codes", "Degradation description" ] }, { "id": "q-class-3", "text": "What improper operation or improper operand caused the first weakness, and how did the error propagate to the observed failure?", "kind": "composition", "answer_data": [ "Cause, operation and consequence steps", "Propagation chain ordering" ] }, { "id": "q-class-4", "text": "In which artifact and lifecycle phase was the defect inserted, and by which preceding change?", "kind": "provenance", "answer_data": [ "Insertion phase code", "Insertion artifact reference", "Suspected originating change reference" ] }, { "id": "q-class-5", "text": "Is the recorded root cause a verified conclusion or a working hypothesis?", "kind": "decision", "answer_data": [ "Root-cause confidence code", "Analysing actor", "Analysis completion time" ] } ], "data_elements": [ { "id": "de-anomaly-type-code", "name": "Anomaly type code", "description": "Coded classification of the correction the defect requires.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-type-qualifier-code", "name": "Type qualifier code", "description": "Whether the implementation was missing, incorrect or extraneous.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-causal-step", "name": "Causal step", "description": "One cause, operation and consequence triple in the propagation chain.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] }, { "id": "de-insertion-phase-code", "name": "Insertion phase code", "description": "Lifecycle phase in which the defect was introduced.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-root-cause-confidence", "name": "Root cause confidence", "description": "Confidence that the recorded cause is verified rather than hypothesised.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Classification and causal chains are coded field values on the record whose value depends on remaining queryable in aggregate; any narrative analysis document belongs to the process-improvement neighbour, not to this record." }, { "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.", "source_refs": [ "SRC-011", "SRC-004", "SRC-005", "SRC-006" ], "questions": [ { "id": "q-sec-1", "text": "Is this defect security-relevant, and which weakness type in the catalogue applies?", "kind": "security", "answer_data": [ "Security relevance flag", "Weakness identifiers", "Catalogue version" ] }, { "id": "q-sec-2", "text": "Which severity vector and score have been assigned, on which metric version, and by which assessing party?", "kind": "measurement", "answer_data": [ "Scoring vector string", "Numeric score", "Assessor reference" ] }, { "id": "q-sec-3", "text": "Which authority owns vulnerability identifier assignment for the affected product?", "kind": "authority", "answer_data": [ "Assigning authority reference", "Assigned identifier", "Assignment state" ] }, { "id": "q-sec-4", "text": "What is asserted when a bundled component is vulnerable but this product is not exploitable?", "kind": "exception", "answer_data": [ "Not-affected justification code", "Supporting rationale" ] } ], "data_elements": [ { "id": "de-security-relevant-flag", "name": "Security relevance flag", "description": "Whether the defect has security consequences.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-009" ] }, { "id": "de-weakness-id", "name": "Weakness identifier", "description": "Catalogue identifier of the weakness type embodied by the defect.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-vulnerability-id", "name": "Vulnerability identifier", "description": "Externally governed vulnerability identifier assigned to the defect.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-severity-vector", "name": "Severity vector string", "description": "Complete metric vector accompanying any published numeric severity score.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "These are alignment values referencing externally governed catalogues; advisory documents that carry them are produced and published by the disclosure neighbour, so reproducing them here would claim ownership this model does not hold." } ] }, { "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.", "source_refs": [ "SRC-003", "SRC-015", "SRC-009", "SRC-014" ], "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.", "source_refs": [ "SRC-003", "SRC-001", "SRC-005" ], "questions": [ { "id": "q-sev-1", "text": "What severity value is assigned, on which governed scale, and against which impact definition?", "kind": "measurement", "answer_data": [ "Severity code", "Severity scale reference", "Impact definition text" ] }, { "id": "q-sev-2", "text": "What is the worst credible consequence for users, data or safety if the defect remains unresolved?", "kind": "evidence", "answer_data": [ "Impact statement", "Safety impact flag", "Affected population estimate" ] }, { "id": "q-sev-3", "text": "Who may raise or lower severity, and what justification must accompany the change?", "kind": "authority", "answer_data": [ "Authorised role", "Change justification", "Assessor reference" ] }, { "id": "q-sev-4", "text": "Is the history of severity revisions preserved as new information arrives?", "kind": "temporal", "answer_data": [ "Severity assessment time", "Prior severity values" ] } ], "data_elements": [ { "id": "de-severity-code", "name": "Severity code", "description": "Severity or potential impact value of the defect on the governed scale.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-015" ] }, { "id": "de-impact-statement", "name": "Impact statement", "description": "Narrative worst credible consequence supporting the severity value.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-safety-impact-flag", "name": "Safety impact flag", "description": "Whether the defect can contribute to harm in a safety-related context.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "de-severity-assessment-time", "name": "Severity assessment time", "description": "Time the current severity value was assigned.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Severity is a single governed code with a justification and timestamp held on the record; it is consumed by queries and dashboards rather than delivered as a standalone product." }, { "id": "priority-and-response-targets", "name": "Priority and response targets", "description": "Relative work ordering and response or resolution targets, kept distinct from severity.", "source_refs": [ "SRC-003", "SRC-015", "SRC-009" ], "questions": [ { "id": "q-prio-1", "text": "What priority is assigned, and how is it kept methodologically distinct from severity?", "kind": "decision", "answer_data": [ "Priority code", "Priority scale reference", "Distinction rule" ] }, { "id": "q-prio-2", "text": "Which response and resolution targets apply to this priority band?", "kind": "requirement", "answer_data": [ "Target response duration", "Target resolution duration", "Target basis reference" ] }, { "id": "q-prio-3", "text": "Which factors, such as exposure, workaround availability or contractual duty, may override the default priority?", "kind": "constraint", "answer_data": [ "Override factor codes", "Priority rationale", "Approving role" ] }, { "id": "q-prio-4", "text": "At which points in the record's life is priority re-evaluated?", "kind": "process", "answer_data": [ "Re-evaluation trigger list", "Last re-evaluation time" ] } ], "data_elements": [ { "id": "de-priority-code", "name": "Priority code", "description": "Relative importance of resolving this defect against others.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-015" ] }, { "id": "de-target-response-duration", "name": "Target response duration", "description": "Committed elapsed time to first substantive response for the priority band.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-target-resolution-duration", "name": "Target resolution duration", "description": "Committed elapsed time to resolution for the priority band.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-priority-rationale", "name": "Priority rationale", "description": "Recorded justification when priority departs from the severity-implied default.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Priority and its targets are scheduling attributes evaluated continuously against the live record; freezing them into an artifact would misrepresent a value that legitimately changes on every re-evaluation." }, { "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.", "source_refs": [ "SRC-009", "SRC-014" ], "questions": [ { "id": "q-reg-1", "text": "Does this defect meet a regulatory reporting threshold, and which regime governs that threshold?", "kind": "authority", "answer_data": [ "Reportability determination code", "Applicable regime references" ] }, { "id": "q-reg-2", "text": "Who made and recorded the reportability determination, and at what time?", "kind": "ownership", "answer_data": [ "Determining role reference", "Determination time" ] }, { "id": "q-reg-3", "text": "Which facts and timestamps must be preserved to defend the determination if it is later challenged?", "kind": "evidence", "answer_data": [ "Preserved fact set", "Awareness time", "Supporting evidence references" ] }, { "id": "q-reg-4", "text": "Which downstream process receives the determination and its payload for notification?", "kind": "interoperability", "answer_data": [ "Hand-off target reference", "Hand-off time", "Payload field set" ] } ], "data_elements": [ { "id": "de-reportability-determination", "name": "Reportability determination", "description": "Coded conclusion on whether an external reporting duty is triggered.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-applicable-regime-ref", "name": "Applicable regime reference", "description": "Reference to the regulation or standard imposing the duty.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-014" ] }, { "id": "de-awareness-time", "name": "Awareness time", "description": "Time the responsible organisation became aware of the qualifying facts.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-handoff-reference", "name": "Hand-off reference", "description": "Reference to the reporting or disclosure process instance that received the determination.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Only the determination, its timing and the hand-off reference are held here; notification documents, deadline tracking and regulator submissions are produced and owned by the regulatory reporting neighbour." } ] } ] }, { "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.", "rationale": "The defect record's operational value is its disciplined progression from report to a justified, verified terminal state with traceability to the resolving change.", "source_refs": [ "SRC-002", "SRC-003", "SRC-010", "SRC-014", "SRC-015" ], "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.", "source_refs": [ "SRC-002", "SRC-010", "SRC-015" ], "findings": [ { "id": "defect-state-model", "name": "Defect state model", "description": "States the record may occupy, permitted transitions, transition preconditions and reopening semantics.", "source_refs": [ "SRC-002", "SRC-003", "SRC-010", "SRC-015" ], "questions": [ { "id": "q-state-1", "text": "Which states may this record occupy, and which of them are terminal?", "kind": "state", "answer_data": [ "State scheme reference", "Current state code", "Terminal state flags" ] }, { "id": "q-state-2", "text": "Which transitions are permitted, and which of them demand a recorded reason or an approval?", "kind": "lifecycle", "answer_data": [ "Transition matrix", "Reason requirement flags", "Approving role" ] }, { "id": "q-state-3", "text": "Which fields must be populated before a transition into a resolved or closed state is allowed?", "kind": "constraint", "answer_data": [ "Per-state mandatory field sets", "Blocking validation rules" ] }, { "id": "q-state-4", "text": "How do local states map onto the interoperable predicates for closed, in progress, fixed, approved, reviewed and verified?", "kind": "interoperability", "answer_data": [ "State-to-predicate mapping", "Unmapped local states" ] }, { "id": "q-state-5", "text": "How is reopening after closure represented without erasing the earlier closure facts?", "kind": "exception", "answer_data": [ "Reopen count", "Reopen reason", "Prior closure retained values" ] } ], "data_elements": [ { "id": "de-current-state-code", "name": "Current state code", "description": "State the record currently occupies within the governed state scheme.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-010" ] }, { "id": "de-state-entry-time", "name": "State entry time", "description": "Time the record entered its current state.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-transition-event", "name": "Transition event", "description": "Recorded state change with actor, reason and time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-reopen-count", "name": "Reopen count", "description": "Number of times the record returned to an open state after closure.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "The state and its transition history are live record attributes; the governed state scheme itself is a Dimension code list held in the code-list registry rather than inside an individual defect record." }, { "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.", "source_refs": [ "SRC-010", "SRC-015", "SRC-003" ], "questions": [ { "id": "q-tri-1", "text": "Was the report accepted as a defect, rejected, deferred, or routed to another queue or model?", "kind": "decision", "answer_data": [ "Triage outcome code", "Routing target", "Deferral reason" ] }, { "id": "q-tri-2", "text": "Which component owner or queue takes accountability once triage completes?", "kind": "ownership", "answer_data": [ "Assigned owner reference", "Assigned queue reference", "Assignment time" ] }, { "id": "q-tri-3", "text": "Which checks constitute completed triage, such as duplicate search, reproduction attempt and scope confirmation?", "kind": "process", "answer_data": [ "Completed check list", "Triage actor", "Triage completion time" ] }, { "id": "q-tri-4", "text": "How long may a record remain untriaged before escalation is required?", "kind": "temporal", "answer_data": [ "Untriaged age threshold", "Escalation target", "Escalation state" ] } ], "data_elements": [ { "id": "de-triage-outcome-code", "name": "Triage outcome code", "description": "Accepted, rejected, deferred or routed outcome of triage.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-015" ] }, { "id": "de-assigned-owner-ref", "name": "Assigned owner reference", "description": "Party accountable for progressing the defect after triage.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-015" ] }, { "id": "de-triage-time", "name": "Triage completion time", "description": "Time the triage decision was recorded.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "de-deferral-review-date", "name": "Deferral review date", "description": "Date on which a deferred defect must be reconsidered.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] } ], "artifacts": [], "inline_only_rationale": "Triage produces a decision plus assignment attributes on the existing record; scheduling and queue mechanics belong to the parent activity model, so no separate triage deliverable is defined here." } ] }, { "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.", "source_refs": [ "SRC-003", "SRC-006", "SRC-010", "SRC-014" ], "findings": [ { "id": "resolution-classification", "name": "Resolution classification", "description": "The coded outcome terminating the record and the justification required for non-fix outcomes.", "source_refs": [ "SRC-010", "SRC-015", "SRC-003" ], "questions": [ { "id": "q-res-1", "text": "Which resolution classification terminates this record: fixed, duplicate, not reproducible, works as designed, will not fix, or superseded?", "kind": "classification", "answer_data": [ "Resolution code", "Resolution time", "Resolving actor" ] }, { "id": "q-res-2", "text": "What justification is mandatory when the outcome is anything other than a fix?", "kind": "requirement", "answer_data": [ "Justification text", "Approving role", "Supporting references" ] }, { "id": "q-res-3", "text": "How is a substantive resolution distinguished from mere administrative closure of the tracking record?", "kind": "quality", "answer_data": [ "Resolution versus closure flag", "Closure basis code" ] }, { "id": "q-res-4", "text": "How does the local resolution value map to the exchange partner's closure reason vocabulary?", "kind": "interoperability", "answer_data": [ "Resolution mapping table", "Unmappable value handling" ] } ], "data_elements": [ { "id": "de-resolution-code", "name": "Resolution code", "description": "Coded outcome that terminates active work on the defect.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-015" ] }, { "id": "de-resolution-justification", "name": "Resolution justification", "description": "Recorded reasoning for the chosen resolution, mandatory for non-fix outcomes.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-resolution-time", "name": "Resolution time", "description": "Time the resolution was recorded.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-superseded-by-ref", "name": "Superseded-by reference", "description": "Record that replaces this one when the outcome is supersession.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Resolution is a coded terminal attribute with justification text; release notes and customer-facing resolution communications are produced by the change and advisory neighbours." }, { "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.", "source_refs": [ "SRC-003", "SRC-006", "SRC-004" ], "questions": [ { "id": "q-fix-1", "text": "Which software change records are claimed to resolve this defect?", "kind": "relationship", "answer_data": [ "Resolving change references", "Link predicate used" ] }, { "id": "q-fix-2", "text": "Which product versions or builds first contain the fix?", "kind": "composition", "answer_data": [ "Fixed-in versions", "First-fixed version", "Build reference" ] }, { "id": "q-fix-3", "text": "Which binding metadata may this record hold about the change without duplicating the change's own lifecycle?", "kind": "constraint", "answer_data": [ "Permitted binding field list", "Prohibited field list" ] }, { "id": "q-fix-4", "text": "How was the defect-to-change link established: author declaration, commit-message parsing, or verified confirmation?", "kind": "provenance", "answer_data": [ "Link assertion method", "Link confidence", "Asserting actor" ] } ], "data_elements": [ { "id": "de-resolving-change-ref", "name": "Resolving change reference", "description": "Typed reference to a software change record claimed to resolve the defect.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-fixed-in-version", "name": "Fixed-in version", "description": "Product version in which the corrected behaviour is available.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-link-assertion-method", "name": "Link assertion method", "description": "How the defect-to-change association was established.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "The relation to the software change model is REFERENCE only: this finding holds the pointer, the fixed-in binding and link provenance, while the change's own content, review and release lifecycle remain entirely in the target model." }, { "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.", "source_refs": [ "SRC-014", "SRC-002", "SRC-012" ], "questions": [ { "id": "q-ver-1", "text": "What criteria must be satisfied before a resolution is accepted as verified?", "kind": "validation", "answer_data": [ "Closure criteria set", "Criteria source reference" ] }, { "id": "q-ver-2", "text": "Which party performs verification, in which environment, and against which build?", "kind": "process", "answer_data": [ "Verifier reference", "Verification environment", "Verification build reference" ] }, { "id": "q-ver-3", "text": "Where does the underlying verification evidence live, and what is stored here as a reference?", "kind": "evidence", "answer_data": [ "External verification record references", "Retained outcome summary" ] }, { "id": "q-ver-4", "text": "What must happen when verification fails or the defect recurs after closure?", "kind": "exception", "answer_data": [ "Failed verification action", "Recurrence handling rule", "Reopen linkage" ] } ], "data_elements": [ { "id": "de-verification-outcome-code", "name": "Verification outcome code", "description": "Result of verifying the resolution against the closure criteria.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014", "SRC-002" ] }, { "id": "de-verification-time", "name": "Verification time", "description": "Time the verification conclusion was reached.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "de-verification-evidence-ref", "name": "Verification evidence reference", "description": "Reference to the externally owned test execution or review record supporting the outcome.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-003" ] }, { "id": "de-closure-time", "name": "Closure time", "description": "Time after which no further activity is intended on the record.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Verification evidence is generated and retained by the testing neighbour as test execution records; this model holds only the outcome, its timing, the verifier and resolvable references, so producing a local verification artifact would duplicate another model's records." }, { "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.", "source_refs": [ "SRC-006", "SRC-004", "SRC-009" ], "questions": [ { "id": "q-work-1", "text": "What temporary workaround or containment measure is available to affected users?", "kind": "requirement", "answer_data": [ "Workaround description", "Remediation category code", "Applicable product scope" ] }, { "id": "q-work-2", "text": "Which conditions or side effects limit the workaround's applicability?", "kind": "constraint", "answer_data": [ "Applicability conditions", "Known side effects" ] }, { "id": "q-work-3", "text": "From when is the workaround valid, and what supersedes it?", "kind": "temporal", "answer_data": [ "Valid-from time", "Superseding remediation reference" ] }, { "id": "q-work-4", "text": "Who may receive and redistribute the workaround while the defect is under embargo?", "kind": "access", "answer_data": [ "Distribution audience", "Embargo constraint reference" ] } ], "data_elements": [ { "id": "de-workaround-description", "name": "Workaround description", "description": "Actionable interim mitigation for affected users.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "de-remediation-category-code", "name": "Remediation category code", "description": "Category of the interim measure, such as mitigation, workaround, vendor fix or no fix planned.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-workaround-valid-from", "name": "Workaround valid-from time", "description": "Time from which the workaround is considered applicable.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Workaround text is inline advisory content bound to the defect; its publishable packaging into a security advisory or customer bulletin is produced and released by the advisory neighbour." } ] } ] }, { "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.", "rationale": "Defect records rarely live in one system; typed relations and lossless-as-possible projections are what make traceability and federation defensible.", "source_refs": [ "SRC-003", "SRC-004", "SRC-006", "SRC-010", "SRC-015" ], "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.", "source_refs": [ "SRC-003", "SRC-015", "SRC-010" ], "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.", "source_refs": [ "SRC-003", "SRC-015", "SRC-010", "SRC-016" ], "questions": [ { "id": "q-rel-1", "text": "Which typed links connect this defect to other defects: duplicate-of, blocks, depends-on, parent-of, or regression-of?", "kind": "relationship", "answer_data": [ "Relation entries", "Relation type codes", "Direction" ] }, { "id": "q-rel-2", "text": "Which support cases, service incidents, requirements or test cases are linked, and which model owns each of them?", "kind": "composition", "answer_data": [ "External reference entries", "Owning model identifier", "Locally permitted fields" ] }, { "id": "q-rel-3", "text": "Which link types are exclusive, and where are cycles forbidden?", "kind": "constraint", "answer_data": [ "Exclusivity rules", "Cycle prohibition rules", "Validation outcome" ] }, { "id": "q-rel-4", "text": "How does closing a blocking defect affect the records that depend on it?", "kind": "lifecycle", "answer_data": [ "Propagation rule", "Dependent record notification reference" ] }, { "id": "q-rel-5", "text": "How many distinct customer reports or incidents are attributed to this defect?", "kind": "measurement", "answer_data": [ "Attributed report count", "Counting window", "Attribution method" ] } ], "data_elements": [ { "id": "de-relation-entry", "name": "Relation entry", "description": "One typed, directed link with target reference and assertion time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-015" ] }, { "id": "de-relation-type-code", "name": "Relation type code", "description": "Governed link predicate used for the relation.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-external-context-ref", "name": "External context reference", "description": "Reference to a case, incident, requirement or test record owned by another model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-016" ] }, { "id": "de-attributed-report-count", "name": "Attributed report count", "description": "Number of distinct external reports attributed to this defect.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] } ], "artifacts": [], "inline_only_rationale": "Relations are resolvable pointers whose authority lies with the linked records; snapshotting them into an artifact would create stale copies of records this model does not own." } ] }, { "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.", "source_refs": [ "SRC-002", "SRC-004", "SRC-006", "SRC-010" ], "findings": [ { "id": "interchange-representations", "name": "Interchange representations", "description": "Target representations the record must be projectable into, their schema versions, mapping tables and lossy fields.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-006" ], "questions": [ { "id": "q-exch-1", "text": "Into which external representations must this record be projectable, and at which schema versions?", "kind": "interoperability", "answer_data": [ "Projection target codes", "Target schema versions", "Mapping table reference" ] }, { "id": "q-exch-2", "text": "Which local fields have no counterpart in a target schema and are therefore lost on export?", "kind": "constraint", "answer_data": [ "Lossy field list", "Loss mitigation note" ] }, { "id": "q-exch-3", "text": "How is a projection validated against the target schema before it is released?", "kind": "validation", "answer_data": [ "Validation result", "Validator reference", "Validation time" ] }, { "id": "q-exch-4", "text": "How is the source record version recorded inside an exported representation?", "kind": "provenance", "answer_data": [ "Source record identifier", "Source record version", "Projection time" ] } ], "data_elements": [ { "id": "de-projection-target-code", "name": "Projection target code", "description": "External representation the record is projected into.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "de-projection-schema-version", "name": "Projection schema version", "description": "Version of the target schema used for a projection.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-lossy-field-list", "name": "Lossy field list", "description": "Local fields with no target counterpart in a given projection.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-projection-time", "name": "Projection time", "description": "Time a projection was generated from the source record.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "af-change-request-projection", "name": "Change-management resource projection", "description": "Projection of the defect as an interoperable change-management defect resource with state predicates and links.", "media_or_form": [ "RDF graph serialisation", "JSON-LD document", "XML representation" ], "serial": false, "identity_strategy": "Identified by the resource IRI assigned by the serving system, carrying the master record identifier and source record version as properties.", "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "af-vulnerability-record-projection", "name": "Vulnerability record projection", "description": "Projection of a security-relevant defect into the governed vulnerability record format for submission to the assigning authority.", "media_or_form": [ "JSON document conforming to the vulnerability record schema" ], "serial": false, "identity_strategy": "Identified by the assigned vulnerability identifier plus the record's own update timestamp property; never by the defect tracker number alone.", "source_refs": [ "SRC-004" ] }, { "id": "af-exploitability-statement", "name": "Exploitability status statement", "description": "Machine-readable statement of affected, not affected, fixed or under-investigation status for downstream consumers.", "media_or_form": [ "JSON advisory document with product status and justifications" ], "serial": false, "identity_strategy": "Identified by the issuing party's document tracking identifier with an explicit document version; the defect record identifier is carried as a reference.", "source_refs": [ "SRC-006" ] } ], "inline_only_rationale": null }, { "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.", "source_refs": [ "SRC-004", "SRC-010", "SRC-015", "SRC-006" ], "questions": [ { "id": "q-corr-1", "text": "How are records for the same defect in different systems correlated to a single subject?", "kind": "identity", "answer_data": [ "Correlation key set", "Correlation confidence", "Correlated record references" ] }, { "id": "q-corr-2", "text": "Which system is authoritative when field values conflict between mirrored records?", "kind": "decision", "answer_data": [ "Field-level precedence rules", "Authoritative system reference" ] }, { "id": "q-corr-3", "text": "How are out-of-order or replayed updates from mirrored systems reconciled?", "kind": "temporal", "answer_data": [ "Update ordering key", "Ingestion time", "Reconciliation action" ] }, { "id": "q-corr-4", "text": "What is done when the authoritative system rejects or withdraws a record that others still reference?", "kind": "exception", "answer_data": [ "Withdrawal state code", "Tombstone reference", "Notified consumers" ] } ], "data_elements": [ { "id": "de-correlation-key", "name": "Correlation key", "description": "Key or key set used to match records for the same defect across systems.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-authoritative-system-ref", "name": "Authoritative system reference", "description": "System whose value prevails for a given field on conflict.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-ingested-time", "name": "Ingestion time", "description": "Time a mirrored update was received, distinct from the time the change occurred upstream.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Correlation keys, precedence rules and reconciliation outcomes are configuration and control fields evaluated at synchronisation time; they describe how references behave rather than producing any separable deliverable." } ] } ] }, { "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.", "rationale": "Defect records carry sensitive detail and regulated retention duties, and their classification data is only useful for improvement if record quality and measurement rules are explicit.", "source_refs": [ "SRC-001", "SRC-006", "SRC-009", "SRC-014", "SRC-016" ], "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.", "source_refs": [ "SRC-006", "SRC-004", "SRC-010" ], "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.", "source_refs": [ "SRC-015", "SRC-010", "SRC-014" ], "questions": [ { "id": "q-own-1", "text": "Who owns the defect record's content, as distinct from who owns the corrective work?", "kind": "ownership", "answer_data": [ "Record steward reference", "Content owner role", "Delegation note" ] }, { "id": "q-own-2", "text": "Who is authorised to change classification, severity, state and confidentiality level?", "kind": "authority", "answer_data": [ "Authorised role per field group", "Authorisation source" ] }, { "id": "q-own-3", "text": "What becomes of stewardship when a component is transferred or an owning team is dissolved?", "kind": "process", "answer_data": [ "Succession rule", "Reassignment time", "Interim owner" ] }, { "id": "q-own-4", "text": "Which stewardship roles must exist in an adopting Dimension for the record to be operable?", "kind": "requirement", "answer_data": [ "Required role list", "Role-to-responsibility mapping" ] } ], "data_elements": [ { "id": "de-record-steward-ref", "name": "Record steward reference", "description": "Party accountable for the accuracy and completeness of the record's content.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-014" ] }, { "id": "de-reporter-ref", "name": "Reporter reference", "description": "Party that submitted the original observation.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "de-field-authority-map", "name": "Field authority map", "description": "Mapping of controlled field groups to the roles permitted to change them.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] } ], "artifacts": [], "inline_only_rationale": "Stewardship is expressed as party references and a role-authority mapping resolved against the adopting Dimension's directory; the directory itself is external, so no local artifact is warranted." }, { "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.", "source_refs": [ "SRC-006", "SRC-004", "SRC-010" ], "questions": [ { "id": "q-prov-1", "text": "Which actor or system supplied each field value, and through which channel did it arrive?", "kind": "provenance", "answer_data": [ "Contributor references", "Supply channel", "Field-level attribution" ] }, { "id": "q-prov-2", "text": "How are event time, observation time and record ingestion time distinguished on this record?", "kind": "temporal", "answer_data": [ "Event time", "Observation time", "Ingestion time" ] }, { "id": "q-prov-3", "text": "How is the record's own version incremented, and what does its revision history retain?", "kind": "state", "answer_data": [ "Record version", "Revision entries", "Change summary per revision" ] }, { "id": "q-prov-4", "text": "How can a consumer detect that the record changed since it was last read?", "kind": "validation", "answer_data": [ "Last updated time", "Content entity tag", "Change detection method" ] } ], "data_elements": [ { "id": "de-record-version", "name": "Record version", "description": "Version of the defect record itself, advanced on each substantive revision.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "de-revision-entry", "name": "Revision entry", "description": "Historical revision with version, time and summary of the change.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-created-time", "name": "Record creation time", "description": "Time the record was created in the system of record.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-004" ] }, { "id": "de-last-updated-time", "name": "Record last updated time", "description": "Time the record was last modified in the system of record.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "This covers only the defect record's own version metadata and contributor attribution; tamper-evident logging, evidentiary audit trails and their retention are services of the adopting Dimension and are referenced rather than modelled." } ] }, { "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.", "source_refs": [ "SRC-009", "SRC-014", "SRC-004" ], "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.", "source_refs": [ "SRC-009", "SRC-004", "SRC-006" ], "questions": [ { "id": "q-conf-1", "text": "What confidentiality level applies to this record, and who is inside the need-to-know scope?", "kind": "access", "answer_data": [ "Confidentiality label", "Need-to-know party list", "Labelling authority" ] }, { "id": "q-conf-2", "text": "Under what embargo conditions is the record restricted, and which event lifts the embargo?", "kind": "security", "answer_data": [ "Embargo flag", "Embargo lift condition", "Planned lift time" ] }, { "id": "q-conf-3", "text": "Which fields may carry personal or customer-identifying data, and how are they treated on disclosure?", "kind": "privacy", "answer_data": [ "Personal-data field list", "Disclosure treatment rule" ] }, { "id": "q-conf-4", "text": "How is partial disclosure represented, where metadata is visible but detail is withheld?", "kind": "exception", "answer_data": [ "Disclosure profile code", "Withheld field list", "Public summary text" ] } ], "data_elements": [ { "id": "de-confidentiality-label", "name": "Confidentiality label", "description": "Declared sensitivity classification of the record.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "de-embargo-flag", "name": "Embargo flag", "description": "Whether disclosure of the record is currently withheld pending a condition.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-withheld-field-list", "name": "Withheld field list", "description": "Fields suppressed under a partial disclosure profile.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "These are declarative labels and conditions attached to the record; evaluation of an access request and enforcement of the decision are performed by the adopting Dimension's access-control service, which this model references but does not own." }, { "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.", "source_refs": [ "SRC-009", "SRC-014", "SRC-004" ], "questions": [ { "id": "q-ret-1", "text": "How long must the defect record and its evidence be retained after closure?", "kind": "retention", "answer_data": [ "Retention period", "Retention clock start event", "Applicable schedule reference" ] }, { "id": "q-ret-2", "text": "Which regulatory or contractual duty sets the minimum retention period for this record?", "kind": "requirement", "answer_data": [ "Duty reference", "Minimum period", "Jurisdiction" ] }, { "id": "q-ret-3", "text": "What tombstone or rejection representation remains when a record is withdrawn?", "kind": "lifecycle", "answer_data": [ "Withdrawal state code", "Retained identifier", "Retained minimal fields" ] }, { "id": "q-ret-4", "text": "Who authorises early deletion, anonymisation or legal hold, and what is recorded about it?", "kind": "decision", "answer_data": [ "Authorising role", "Disposition action code", "Decision time and rationale" ] } ], "data_elements": [ { "id": "de-retention-period", "name": "Retention period", "description": "Minimum period the record must be preserved after the retention clock starts.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-014" ] }, { "id": "de-disposition-action-code", "name": "Disposition action code", "description": "Retain, anonymise, tombstone, withdraw or destroy.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-legal-hold-flag", "name": "Legal hold flag", "description": "Whether disposition is suspended by an active hold.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Retention duties and disposition decisions are attributes and decision records on the defect record; execution of destruction, archival and hold enforcement is performed under the adopting Dimension's records policy, which owns the operation." } ] }, { "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.", "source_refs": [ "SRC-001", "SRC-014", "SRC-016" ], "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.", "source_refs": [ "SRC-012", "SRC-014", "SRC-004" ], "questions": [ { "id": "q-val-1", "text": "Which fields are mandatory at submission, and which only at triage, resolution or closure?", "kind": "validation", "answer_data": [ "Per-state mandatory field sets", "Rule set version" ] }, { "id": "q-val-2", "text": "Which cross-field rules must hold, such as a fixed-in version requiring a resolving change reference?", "kind": "constraint", "answer_data": [ "Cross-field rule list", "Violation severity", "Violation records" ] }, { "id": "q-val-3", "text": "How is submitted report quality scored and fed back to the reporting party?", "kind": "quality", "answer_data": [ "Quality score", "Deficiency codes", "Feedback action" ] }, { "id": "q-val-4", "text": "How are migrated or legacy records that cannot satisfy current rules represented?", "kind": "exception", "answer_data": [ "Legacy exemption flag", "Exemption rationale", "Remediation plan reference" ] } ], "data_elements": [ { "id": "de-validation-rule-set-version", "name": "Validation rule set version", "description": "Version of the rule set the record was validated against.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-validation-finding", "name": "Validation finding", "description": "One rule violation with rule identifier, severity and detection time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-legacy-exemption-flag", "name": "Legacy exemption flag", "description": "Whether the record is exempt from current rules because it predates them.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [], "inline_only_rationale": "Validation state is a computed annotation over the live record and its rule set; persisting it as an artifact would create a snapshot that silently diverges from the record it describes." }, { "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.", "source_refs": [ "SRC-001", "SRC-014", "SRC-016" ], "questions": [ { "id": "q-meas-1", "text": "Which measures are computed over the defect population, such as open counts, age distribution, reopen rate and escape rate?", "kind": "measurement", "answer_data": [ "Measure definitions", "Computed values", "Cohort filter" ] }, { "id": "q-meas-2", "text": "Over which period and cohort is each measure computed, and against which record snapshot?", "kind": "temporal", "answer_data": [ "Period start and end", "Cohort key", "Snapshot time" ] }, { "id": "q-meas-3", "text": "Is periodic trend analysis of problem reports a standing obligation in this context?", "kind": "requirement", "answer_data": [ "Obligation reference", "Required cadence", "Responsible role" ] }, { "id": "q-meas-4", "text": "Which measures depend on data owned by other models and therefore cannot be computed from defect records alone?", "kind": "interoperability", "answer_data": [ "Dependent measure list", "Required external inputs", "Owning model references" ] } ], "data_elements": [ { "id": "de-measure-definition", "name": "Measure definition", "description": "Named measure with its formula, unit and inclusion criteria.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-measure-value", "name": "Measure value", "description": "Computed value of a measure for a period and cohort.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "de-measurement-snapshot-time", "name": "Measurement snapshot time", "description": "Time of the record snapshot from which measures were computed.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] } ], "artifacts": [ { "id": "af-defect-trend-report", "name": "Defect trend report", "description": "Periodic analysis of problem-report trends over a defined cohort, supporting process improvement and regulated trend review.", "media_or_form": [ "Tabular dataset", "Rendered analytical report" ], "serial": true, "identity_strategy": "Sequence number within a named cohort and measure scope; the reporting period and snapshot time are attributes, never components of the identifier.", "source_refs": [ "SRC-014", "SRC-001" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "fn-capture-defect-report", "name": "Capture defect report", "description": "Create a defect record from an observation, binding subject, environment, evidence and report timing.", "inputs": [ "Observation narrative and reproduction steps", "Affected product and environment descriptor", "Evidence items", "Reporter reference" ], "outputs": [ "Defect record in initial state", "Assigned master record identifier", "Defect report document" ], "preconditions": [ "Reporter is identified", "Minimum submission fields are present", "Target product and system of record are known" ], "effects": [ "Record created and timestamped with occurrence, observation and report times", "Evidence attached with integrity fixed" ], "source_refs": [ "SRC-012", "SRC-010", "SRC-015" ] }, { "id": "fn-detect-and-resolve-duplicates", "name": "Detect and resolve duplicates", "description": "Search for existing records describing the same defect and establish the canonical record.", "inputs": [ "Candidate record", "Search keys and correlation keys" ], "outputs": [ "Duplicate-of link or negative result", "Canonical record flag" ], "preconditions": [ "Candidate record exists", "Search scope and matching rules are configured" ], "effects": [ "Non-canonical record marked duplicate without deletion", "Inbound references redirected to canonical record" ], "source_refs": [ "SRC-010", "SRC-015" ] }, { "id": "fn-triage-and-classify-defect", "name": "Triage and classify defect", "description": "Decide acceptance, assign accountability and record anomaly type, qualifier and causal hypothesis.", "inputs": [ "Defect record", "Reproduction outcome", "Classification code lists" ], "outputs": [ "Triage outcome", "Owner or queue assignment", "Anomaly type and qualifier values" ], "preconditions": [ "Record has passed submission validation", "Duplicate check has been performed" ], "effects": [ "State advanced per the governed state scheme", "Classification fields populated with scheme version" ], "source_refs": [ "SRC-001", "SRC-010", "SRC-015" ] }, { "id": "fn-assert-affected-scope", "name": "Assert affected scope", "description": "Record which products and version ranges are affected, not affected, fixed or under investigation, with justification.", "inputs": [ "Product and version catalogue references", "Analysis results", "Assertion time" ], "outputs": [ "Affected product entries with status codes", "Not-affected justifications" ], "preconditions": [ "Product and version identifiers resolve in the catalogue", "Analysis basis is recorded" ], "effects": [ "Scope assertions timestamped and superseded assertions retained" ], "source_refs": [ "SRC-006", "SRC-004" ] }, { "id": "fn-rank-severity-and-priority", "name": "Rank severity and priority", "description": "Assign severity on the governed scale and a separate priority with response targets and rationale.", "inputs": [ "Impact assessment", "Exposure and workaround status", "Governed severity and priority scales" ], "outputs": [ "Severity value with assessor and time", "Priority value with targets and rationale" ], "preconditions": [ "Severity and priority scales are published and versioned", "Assessor holds the required authority" ], "effects": [ "Prior severity and priority values retained in revision history" ], "source_refs": [ "SRC-003", "SRC-005", "SRC-015" ] }, { "id": "fn-bind-resolving-change-reference", "name": "Bind resolving change reference", "description": "Attach a typed reference to the software change claimed to resolve the defect together with fixed-in versions.", "inputs": [ "Change record reference", "Fixed-in version values", "Link assertion method" ], "outputs": [ "Resolving change reference", "Fixed-in version binding", "Link provenance" ], "preconditions": [ "Change reference resolves in the change model", "Asserting actor is recorded" ], "effects": [ "Binding stored on the defect record only; no change-model state is created, altered or executed" ], "source_refs": [ "SRC-003", "SRC-006" ] }, { "id": "fn-record-verification-outcome", "name": "Record verification outcome", "description": "Record the conclusion, verifier, build and references of an externally executed verification of the resolution.", "inputs": [ "Closure criteria", "External verification record references", "Verification build reference" ], "outputs": [ "Verification outcome code", "Verification time and verifier" ], "preconditions": [ "A resolution has been recorded", "Referenced verification records exist and resolve" ], "effects": [ "Record eligible for closure on a passing outcome; returned to an open state on failure" ], "source_refs": [ "SRC-014", "SRC-002", "SRC-012" ] }, { "id": "fn-close-or-withdraw-record", "name": "Close or withdraw record", "description": "Terminate the record with a resolution classification or withdraw it, preserving prior facts.", "inputs": [ "Resolution code and justification", "Verification outcome", "Authorising role" ], "outputs": [ "Terminal state with closure time", "Withdrawal tombstone where applicable" ], "preconditions": [ "Per-state mandatory fields are complete", "Non-fix outcomes carry a justification" ], "effects": [ "Closure facts retained across any later reopening", "Reopen count incremented on return to an open state" ], "source_refs": [ "SRC-003", "SRC-010", "SRC-004" ] }, { "id": "fn-project-defect-to-interchange-format", "name": "Project defect to interchange format", "description": "Generate a validated projection of the record into a target external representation and record the loss profile.", "inputs": [ "Defect record and version", "Target schema and version", "Field mapping table" ], "outputs": [ "Validated projection artifact", "Lossy field list", "Projection provenance" ], "preconditions": [ "Mapping table exists for the target schema version", "Confidentiality constraints permit the projection audience" ], "effects": [ "Projection carries source record identifier and version", "Validation failures block release of the projection" ], "source_refs": [ "SRC-002", "SRC-004", "SRC-006" ] }, { "id": "fn-compute-defect-population-measures", "name": "Compute defect population measures", "description": "Compute cohort measures over defect records for trend analysis, declaring externally owned inputs.", "inputs": [ "Record snapshot", "Cohort filter", "Measure definitions" ], "outputs": [ "Measure values with period and cohort", "Defect trend report" ], "preconditions": [ "Snapshot time is recorded", "Measure definitions are versioned" ], "effects": [ "Measures reproducible from the snapshot", "Measures requiring external inputs are flagged as not computable here" ], "source_refs": [ "SRC-001", "SRC-014", "SRC-016" ] }, { "id": "fn-apply-retention-disposition", "name": "Apply retention disposition", "description": "Evaluate the retention schedule for a closed record and mark the disposition decision for execution by the records owner.", "inputs": [ "Closure or withdrawal time", "Applicable retention schedule", "Legal hold status" ], "outputs": [ "Disposition action code with due time", "Tombstone specification" ], "preconditions": [ "Record is in a terminal state", "Retention schedule and jurisdiction are resolved" ], "effects": [ "Disposition marked and authorised; physical destruction, archival or anonymisation is executed under the adopting Dimension's records policy" ], "source_refs": [ "SRC-009", "SRC-014", "SRC-004" ] } ], "composition": [ { "target": "WM-ACT-021", "relation": "CHILD", "purpose": "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.", "required": true, "source_refs": [ "SRC-003", "SRC-010" ] }, { "target": "WM-SFT-013", "relation": "REFERENCE", "purpose": "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.", "required": false, "source_refs": [ "SRC-003", "SRC-006" ] }, { "target": "OSLC Change Management Version 3.0 (OASIS Standard)", "relation": "ALIGN", "purpose": "Align defect resource semantics, state predicates, severity and priority properties and link predicates for cross-tool interchange.", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "target": "IEEE 1044-2009 Classification for Software Anomalies", "relation": "ALIGN", "purpose": "Align anomaly classification attributes; the standard is Inactive-Reserved, so alignment is asserted as a mapping and not as conformance.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "ISO/IEC/IEEE 24765 Systems and software engineering vocabulary", "relation": "ALIGN", "purpose": "Bind terminology for defect, fault, failure, error and anomaly to a governed vocabulary edition.", "required": false, "source_refs": [ "SRC-013" ] }, { "target": "Common Weakness Enumeration (CWE)", "relation": "ALIGN", "purpose": "Classify security-relevant defects by weakness type using an externally governed catalogue version.", "required": false, "source_refs": [ "SRC-011" ] }, { "target": "CVE Record Format v5.1.0", "relation": "ALIGN", "purpose": "Enable projection of security-relevant defects into the governed vulnerability record format; identifier assignment and publication remain with the assigning authority.", "required": false, "source_refs": [ "SRC-004" ] }, { "target": "CVSS v4.0 Specification", "relation": "ALIGN", "purpose": "Carry severity vector strings and scores for security-relevant defects, always publishing vector together with score.", "required": false, "source_refs": [ "SRC-005" ] }, { "target": "CSAF 2.0 and its VEX profile", "relation": "ALIGN", "purpose": "Express affected, not affected, fixed and under-investigation product status and remediation categories for downstream consumers.", "required": false, "source_refs": [ "SRC-006" ] }, { "target": "ISO/IEC/IEEE 29119-3:2021 test documentation", "relation": "ALIGN", "purpose": "Align the defect report document with the standard incident report information item used in test documentation.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "IEC 62304 medical device software life cycle processes", "relation": "ALIGN", "purpose": "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.", "required": false, "source_refs": [ "SRC-014" ] }, { "target": "Regulation (EU) 2024/2847 (Cyber Resilience Act)", "relation": "ALIGN", "purpose": "Support vulnerability identification, documentation and remediation duties and supply the determination inputs for reporting obligations executed by the reporting neighbour.", "required": false, "source_refs": [ "SRC-009" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "Name the system of record for defect identifiers per product line and publish its identifier namespace.", "Publish the state scheme, severity scale, priority scale, resolution codes and anomaly type list as versioned code lists with change history.", "Appoint a defect record steward and a security coordinator role able to apply confidentiality labels and embargoes.", "Declare the retention schedule, jurisdiction and legal-hold procedure that govern defect records and their evidence." ], "namespace_guidance": "Identify records as {dimension-namespace}/defect/{product-key}/{master-record-id}; qualify every tracker-local sequential number with its system namespace before external use, keep code lists in a separate {dimension-namespace}/codelist/{scheme}/{version} namespace, and never reuse a retired identifier.", "registry_links": [ "Adopting-Dimension code-list registry for state, severity, priority, resolution and anomaly type schemes", "Product and version catalogue registry supplying affected-scope identifiers", "External weakness catalogue (CWE) and vulnerability identifier authority (CVE Program) for security alignment", "Change-management vocabulary registry (OSLC CM 3.0) for link predicates and state predicates" ] }, "canon_and_patch": { "canonicalization_rules": [ "Serialise all time values as RFC 3339 with seconds and an explicit offset; normalise to UTC only for comparison, never by discarding the original offset.", "Normalise external identifiers to their issuing authority's canonical case and form before comparison.", "Represent coded values as a scheme reference, scheme version and code, never as free text.", "Order relation and evidence collections deterministically by target identifier and assertion time before hashing or diffing." ], "patch_rules": [ "Apply changes additively: supersede a value by adding a new assertion with its own time rather than overwriting history.", "Record every state change as a transition event with actor, reason and time; silent state edits are invalid.", "Increment the record version and append a revision entry for each substantive change.", "Require a recorded justification for severity or priority downgrades and for any non-fix resolution.", "Treat redaction as a patch that retains the field with a redaction marker, not as a deletion of the field." ], "compatibility_rules": [ "Code lists may be extended by adding values; removing or re-meaning an existing value is a breaking change requiring a scheme major version.", "Adding an optional field is compatible; adding a required field or narrowing cardinality is breaking.", "Mapping tables to external schemas are versioned independently and pinned per projection.", "Consumers must ignore unknown fields and must not infer meaning from field order." ] }, "artifact_rules": { "identity_priority": [ "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." ], "timestamp_rule": "All time values are RFC 3339 date-times with explicit seconds and an explicit numeric UTC offset or the literal Z; local wall-clock times without an offset are invalid. Event time (failure occurrence, state transition, resolution, closure) is recorded separately from observation time (when a party detected or reported it) and from ingestion time (when this model's store received the assertion), and all three are retained when they differ.", "serial_naming_rule": "Serial artifacts are named {model-id}-{artifact-family}-{cohort-key}-{zero-padded sequence}, with the sequence monotonic within cohort and family; reporting period, snapshot time and version are attributes of the artifact and must never be embedded in the identifier.", "integrity_rule": "Every attached evidence artifact records a content digest, digest algorithm, byte size and attachment time fixed at attachment; artifacts are immutable thereafter, and any correction is a new artifact superseding the previous one with a supersession link." }, "policies": [ "Severity and priority are distinct governed attributes; a priority value is never derived automatically from a severity value without a recorded rationale.", "A defect record may reference but must never restate the lifecycle, content or operational state of a software change, test execution, service incident or published advisory.", "Security-relevant defects carry a confidentiality label and, where applicable, an embargo flag from creation; default-open publication is not permitted for unassessed security defects.", "No record may enter a terminal state without a resolution classification and, for non-fix outcomes, a recorded justification.", "Classification code lists are versioned; every classified record stores the scheme version in force at classification time." ], "crud": { "read": [ "Reads are scoped by confidentiality label and embargo state; restricted records are invisible rather than partially rendered unless a disclosure profile is defined.", "Every read response carries the record version and last updated time so consumers can detect change.", "Aggregate reads for measurement operate on a timestamped snapshot and must state the snapshot time." ], "create": [ "Creation requires a reporter reference, summary, affected product and detection activity; the system of record assigns the master identifier.", "Creation records occurrence, observation and report times separately when they are known and differ.", "Creation of a record duplicating an existing subject is permitted but must be resolvable to a canonical record by duplicate handling." ], "update": [ "Updates append transition and revision entries; prior values remain retrievable through revision history.", "Changes to controlled fields require the role authorised for that field group and a recorded reason where the policy demands one.", "Concurrent updates are rejected unless the caller supplies the record version it read." ], "delete": [ "Hard deletion of a defect record is not permitted while a retention duty or legal hold applies; the default disposition is retention to the end of the applicable schedule.", "Withdrawal is represented as a tombstone retaining the identifier, withdrawal state, withdrawal time and reason so that inbound references continue to resolve; the substantive content is suppressed rather than erased.", "Personal data within a record or its evidence may be anonymised or redacted ahead of record disposition when a data-protection duty requires it, leaving the redaction recorded as a patch.", "This model defines disposition marking only. Execution of destruction, archival, anonymisation and hold release is owned by the adopting Dimension's records-management policy; where the record is subject to regulated retention, the referenced regulatory regime (for example the medical-device software life-cycle standard or the applicable product-security regulation) sets the minimum period and this model must not shorten it.", "Evidence artifacts inherit the parent record's disposition unless a stricter artifact-level rule applies, in which case the stricter rule governs." ] }, "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" ] } ], "access": { "default_rule": "Deny by default for security-relevant or embargoed records and for evidence artifacts; permit read to the owning product organisation for ordinary defect records, with write restricted to the roles authorised for the specific field group.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Embargoed security defects are visible only to the security coordinator, the assigned owner and named need-to-know parties until the embargo lift condition occurs.", "Partial disclosure profiles may expose identifier, state and public summary while withholding reproduction steps and evidence.", "Evidence artifacts containing personal data or credentials may carry a stricter label than the parent record and are then withheld independently.", "External reporters may read only the records they submitted, and only the fields marked reporter-visible." ], "audit_requirements": [ "Each disclosure, embargo change and confidentiality relabelling is recorded on the record as a transition event with actor, reason and time.", "Every projection released externally records its target schema, audience and projection time.", "Access decisions themselves are evaluated, logged and retained by the adopting Dimension's access-control and logging services; this model records only the resulting labels and disclosure events." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID", "Owner or maintainer" ], "read_order": [ "Read AGENTS.md and resolve Name, Type and Model ID before touching any record", "Read the Specification URL to load scope, boundaries and the known-relation ledger", "Read the Storage type URL to learn the projection in use, whether document store, graph, repository files or an API-backed service", "Read the Interface URL for the access and query surface and its authentication requirements", "Read the Processes URL for the create, triage, resolve, verify, close and disposition procedures before invoking any function" ] } }, "coverage": { "claim": "Audited coverage is limited to what the sixteen cited sources support for the defect record treated as a record-plane entity: terminology binding, identity and duplicate resolution, affected scope, observation and evidence, anomaly and weakness classification, severity/priority/regulatory ranking, state and triage, resolution, fix reference and verification, typed relations, interchange projections, stewardship, provenance, confidentiality, retention and population measures. Two dimensions remain declared gaps (no normative measure catalogue; no canonical state value set), two normative texts (SRC-012, SRC-014) are unverified at clause level, the parent-model inheritance the boundary notes rely on is not in the frozen relationship contract, and no independent second-provider review exists. This is not a claim of universal or complete coverage of software problem management.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Master-system identifier first, then governed global identifier, then Dimension-minted UUID or ULID; duplicate and merge handling and cross-system correlation keys are explicit." }, { "dimension": "lifecycle", "status": "covered", "notes": "State scheme, transitions with preconditions, triage, resolution classification, verification and reopening are modelled; the concrete state values remain a Dimension code list." }, { "dimension": "relationships", "status": "covered", "notes": "Typed defect-to-defect links and outward references to change, incident, case, requirement and test records, with exclusivity and cycle rules." }, { "dimension": "temporal", "status": "covered", "notes": "Occurrence, observation, report, triage, resolution, verification, closure, projection and ingestion times are distinct RFC 3339 values with explicit offsets." }, { "dimension": "provenance", "status": "covered", "notes": "Field-level contributor attribution, supply channel, record version and revision history; organisational audit trails are explicitly external." }, { "dimension": "ownership", "status": "covered", "notes": "Record steward distinguished from fix owner, field-level change authority, succession on team change, and required Dimension roles." }, { "dimension": "validation", "status": "covered", "notes": "Per-state mandatory fields, cross-field consistency rules, report quality scoring, projection schema validation and legacy exemptions." }, { "dimension": "access", "status": "covered", "notes": "Confidentiality labels, embargo, need-to-know and partial disclosure are declared here; evaluation and enforcement are owned by the adopting Dimension." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention period and clock start, tombstone on withdrawal, redaction as patch, legal hold, and explicit delegation of execution to the records-management policy and referenced regulatory regimes." }, { "dimension": "interoperability", "status": "covered", "notes": "Projections to change-management, vulnerability record and exploitability-statement formats with versioned mappings, lossy-field declaration and provenance stamping." }, { "dimension": "classification", "status": "covered", "notes": "Anomaly type and qualifier, affected quality characteristic, causal chain, insertion point and weakness alignment." }, { "dimension": "evidence", "status": "covered", "notes": "Evidence corpus with integrity digests, sufficiency verdict, redaction handling and references to externally owned verification records." }, { "dimension": "measurement", "status": "gap", "notes": "No retrieved primary source defines a normative catalogue of defect-population measures; IEEE 1044 only states that classification data supports analysis and IEC 62304 only requires trend analysis, so measure definitions remain Dimension-specific." }, { "dimension": "state model canonicity", "status": "gap", "notes": "Bugzilla documents that status and resolution values are installation-defined, and OSLC exposes only read-only predicates, so no primary source supports a single canonical defect state set; the model therefore governs the scheme rather than the values." }, { "dimension": "spatial", "status": "not-applicable", "notes": "Geographic location is not intrinsic to a defect; deployment locus, region and tenant are captured only as environment attributes where they affect reproduction or jurisdiction." } ], "known_omissions": [ "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." ], "conflicts": [ "Terminology diverges across sources: IEEE 1044 classifies anomalies broadly, ISO/IEC/IEEE 24765 separates defect, fault and failure, and the NIST Bugs Framework defines bug as an improper operation and fault as an improper operand. The model requires an explicit terminology binding rather than asserting one definition.", "IEEE 1044-2009 has been Inactive-Reserved since 2020-03-05, so alignment to it is a mapping and cannot be presented as conformance to a current standard.", "Severity and priority are separate properties in OSLC and in Bugzilla, but many deployments conflate them; the model keeps them distinct and requires a rationale when they diverge.", "CVSS is a severity metric and is explicitly not a priority or risk decision; using a CVSS score as a work-ordering priority is a common but unsupported practice.", "GitHub represents closure reasons as state_reason values including duplicate and not_planned, while Bugzilla treats resolution as an installation-defined field; a lossless mapping between them is not always possible.", "ISO/IEC/IEEE 29119-3 names the artifact an incident report while service management reserves incident for service disruption; this model uses defect report and references service incidents separately." ], "regional_assumptions": [ "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." ], "adversarial_checks": [ "Boundary sweep against the known-relation ledger: every bundle, layer, finding and function was compared with the REFERENCE rationale to WM-SFT-013; the fix-reference finding carries only pointer, fixed-in version and link provenance, and no node models change authoring, review, build, release or deployment.", "Ownership sweep for runtime semantics: no node claims evaluation, enforcement, execution or audit-trail retention. Access constraints are declarative, verification records the outcome of externally executed verification, disposition marks a decision executed under Dimension policy, and regulatory reporting stops at the determination and hand-off.", "Counterexample search for a canonical state model: Bugzilla's installation-defined statuses and resolutions and OSLC's read-only predicates falsify any claim of a universal defect state machine, so the model governs the scheme and its mapping instead of prescribing values.", "Counterexample search for defect equals vulnerability: CSAF's known_not_affected and under_investigation statuses show that a weakness in a bundled component need not be a defect of the product, so security alignment is optional and scope assertions carry justifications.", "Identity stress test: date-like and title-like candidates were rejected as identifiers; reporting period and snapshot time are attributes of the trend report, and tracker-local sequence numbers are only valid when namespace-qualified.", "Evidence-availability check: IEC 62304 clause content and ISO/IEC/IEEE 29119-3 information items were verified only through catalogue records and secondary summaries because the normative texts are paywalled, so claims resting on them are limited to the existence of documented problem reports, retained records, verification and trend analysis.", "Duplication check against the parent activity model: generic assignment, queueing, scheduling and effort tracking were left to WM-ACT-021 and appear here only as references from triage." ] }, "researchAdjudication": { "providerMode": "single-provider-waiver", "activeProviders": [ "claude" ], "waivedProviders": [ "grok" ], "providerPolicy": { "contract_version": "1.0.0", "mode": "single-provider-waiver", "effective_at": "2026-08-29T09:06:27Z", "scope": "Queued subject-model research from WM-XCT-013 onward", "active_providers": [ "claude" ], "waived_providers": [ { "provider": "grok", "authorized_by": "repository owner", "authorized_at": "2026-08-29T09:06:27Z", "reason": "The repository owner explicitly instructed the research queue to continue without Grok after repeated structured-output failures." } ], "review_rule": "Claude-only results require a separate no-tools adversarial audit and remain reviewable drafts with a visible single-provider hold." }, "boundaryDecision": { "entry_kind": "entity", "status": "accepted", "rationale": "Two axes must not be conflated. On the record plane the frozen registry value standalone-mm states only that WM-SFT-014 occupies its own registry record rather than being a contained sub-model; it is not a member of the subject-kind enum and must never be published as one. On the subject plane the modelled thing is a single identified, versioned, state-bearing defect record with a master-system identifier, append-only revision history and terminal states, so entity is the most defensible schema kind. Aggregate was explicitly tested and rejected: the contained evidence artifacts are content-addressed, immutable and corrected by supersession rather than mutation, i.e. value objects held inside one entity, and the only cluster-like signals (record-version optimistic concurrency, disposition cascading to evidence) are entity-internal composition rather than a transactional cluster of independently lifecycled entities. Event was rejected because the record persists across and outlives its transitions; relationship was rejected because it is a subject in its own right rather than a link between two other subjects, with defect-to-defect links carried as typed edges on it; classifier and registry were rejected because the governed code lists live in the adopting Dimension registry, not in this record; mixin and pattern were rejected because the model is instantiated per defect rather than reused as a fragment. The one genuine root violation found, the cohort-scoped defect trend report artifact whose identity is a cohort sequence and not bound to any defect record, is recorded as a deferred split candidate rather than as grounds to reclassify the whole model." }, "decisions": [ { "concept": "Subject-model entry kind versus frozen registry record-plane value", "disposition": "accepted as entity; standalone-mm retained strictly as a record-plane classifier", "rationale": "The registry value classifies how the record sits in the registry, not what the model models. Publishing standalone-mm as an entry kind would put a non-enum value into the subject plane, so the two axes are recorded separately and entity is fixed as the subject kind." }, { "concept": "Aggregate-root test for the defect record and its evidence corpus", "disposition": "aggregate rejected; entity root over immutable value-artifacts accepted", "rationale": "Evidence artifacts are content-addressed, immutable after attachment and corrected only by supersession, which makes them value objects rather than independently lifecycled sub-entities. Version-scoped concurrency and cascading disposition are entity-internal composition and do not by themselves establish an aggregate kind." }, { "concept": "Population-plane leak: defect-population-measures and af-defect-trend-report", "disposition": "deferred as an out-of-root artifact pending owner decision", "rationale": "Every other node is bound to a single defect record, but the trend report is identified by cohort key and sequence with no parent record binding, so it sits on the corpus plane. Coverage already marks measurement as a gap with no normative source, so relocation should be decided before the artifact hardens." }, { "concept": "Unregistered inheritance dependency on WM-ACT-021", "disposition": "rejected as currently asserted; register the relation or drop the inheritance claims", "rationale": "Boundary notes, out-of-scope entries and known omissions all delegate assignment, scheduling, effort and cost to a parent activity model, yet the frozen relationship contract contains only REFERENCE to WM-SFT-013. The ownership boundary therefore rests on an edge that does not exist in the contract, and the adversarial boundary sweep was run against a one-entry ledger." }, { "concept": "Timestamp used as an identity component in af-vulnerability-record-projection", "disposition": "rejected; replace the update timestamp with an explicit document or record version", "rationale": "This directly contradicts the model's own identity_priority rule that a date is never an identifier and the serial_naming_rule that snapshot time and version must never be embedded in an identifier. It is an internal inconsistency the synthesizer can resolve editorially without new facts." }, { "concept": "Host and process identifiers inside af-crash-dump identity strategy", "disposition": "rejected as identity components; demote both to attributes", "rationale": "Identifier components cannot be redacted without breaking reference resolution, which collides with the redaction-as-patch rule and the privacy question requiring masking of personal or infrastructure data before retention. Content digest plus parent record identifier is sufficient and stable." }, { "concept": "af-defect-report-document as an owned record-plane deliverable", "disposition": "deferred; re-evaluate as a rendering or projection rather than an owned artifact", "rationale": "Its identity is wholly derived from the master record identifier plus revision number, so every substantive change mints a new artifact identity, and the model elsewhere refuses artifacts precisely because they would restate record content and diverge from the system of record." }, { "concept": "af-exploitability-statement against the out-of-scope advisory-authoring boundary", "disposition": "accepted with an explicit projection-only constraint", "rationale": "Identity is assigned by the issuing party and the affected-scope finding already declares the publishable form external, so no ownership is claimed. The published draft must nonetheless state that issuance, disclosure timing and publication remain with the disclosure neighbour, because an exploitability statement reads as advisory-class content." }, { "concept": "Access scopes enumerate model structure while access rules govern record instances and field groups", "disposition": "accepted structurally with a required reconciliation note", "rationale": "The declared scopes are bundle, layer, finding and artifact, but the default rule, update rules and reporter-visible exception all grant authority per record field group, which is not an available scope. Readers must not infer that document-structure scopes govern instance-level field disclosure." }, { "concept": "Retention minima attributed to SRC-009 and SRC-014", "disposition": "accepted only as delegation; no stated period may be published", "rationale": "Neither citation was verified at clause level for record-retention duties, and the product-security regulation governs vulnerability handling rather than defect-record schedules. The model already delegates the schedule and legal hold to the adopting Dimension, and that delegation is the only defensible published claim." }, { "concept": "IEEE 1044-2009 as the anchor vocabulary for anomaly typing", "disposition": "accepted as a declared mapping, never as conformance", "rationale": "The source has been Inactive-Reserved since 2020-03-05 and the model already records this as a conflict and phrases the anomaly-type question as a best-fit choice. Publication must carry the inactive-status note beside every code list derived from it." }, { "concept": "Absence of a canonical defect state value set", "disposition": "accepted; the model governs the scheme and its mapping rather than the values", "rationale": "Installation-defined statuses and resolutions in the tracker documentation and read-only predicates in the change-management vocabulary falsify any universal state machine, so pushing concrete values into the model would assert support no cited source provides." }, { "concept": "Function coverage for evidence attachment, redaction, confidentiality labelling, embargo and reportability hand-off", "disposition": "deferred to a follow-up pass; no functions added under the waiver", "rationale": "The integrity rule, three evidence artifact families and the security-coordinator role have no owning function, and cross-system correlation is only partially covered by duplicate resolution. The single-provider rules forbid adding functions in this plan, so the gap is recorded rather than filled." }, { "concept": "Layer identifier impact-and-response-ranking breaking the -layer suffix convention", "disposition": "deferred editorial normalization for the synthesizer", "rationale": "Eleven of twelve layer identifiers carry the suffix, so the outlier is a real naming defect, but renaming identifiers is a deterministic normalization step and should not be performed by a no-tools auditor who cannot update downstream references." }, { "concept": "Registry provenance string implying multi-pass independent review", "disposition": "rejected as written; must record the single-provider waiver alongside it", "rationale": "Provenance lists Claude review, gap audit and Claude adversarial audit, which a reader can mistake for independent verification. The waived-provider fact and its owner authorization must appear wherever provenance is rendered." } ], "publicationHolds": [ "Live source verification hold: all sixteen source URLs and their version pins must be re-resolved immediately before publication. SRC-001 must be published with its Inactive-Reserved status since 2020-03-05, SRC-011 and SRC-015 are undated moving targets carrying only an accessed-on date of 2026-09-03, and SRC-010 is pinned to a dated REST API version that must be confirmed still served.", "Clause-level evidence hold: SRC-012 and SRC-014 were verified only through catalogue records and secondary summaries because the normative texts are paywalled. Every verification, retention and trend-analysis claim resting on them must be published as existence-level support, not as clause-level conformance, until the normative text is obtained.", "Single-provider hold: publish only as a reviewable draft carrying a visible notice that independent second-provider review does not exist, that Grok was waived by the repository owner on 2026-08-29T09:06:27Z after repeated structured-output failures, and that the sole adversarial check is a same-provider no-tools audit.", "Boundary hold: registry status remains candidate and review_state remains boundary-review-required until the WM-ACT-021 parent relation is registered in the relations ledger or all inheritance and delegation claims to a parent activity model are removed from the boundary notes, out-of-scope list and known omissions.", "Registry completeness hold: namespace_uri and source_url are empty in the frozen record while the model publishes namespace guidance and an identifier priority ladder; populate them or mark them explicitly as Dimension-supplied before any external publication.", "Identity hold: the vulnerability-record projection identity strategy and the crash-dump identity strategy must be corrected before publication, since both contradict the model's own rule that dates and attribute values are never identifier components.", "Independent second-provider review was explicitly waived by the repository owner; this Claude-only result remains a reviewable draft." ], "deferredResearch": [ "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." ] }, "statistics": { "sources": 16, "bundles": 6, "layers": 12, "findings": 25, "questions": 104, "artifacts": 8, "functions": 11 } }