{ "model": "WM-XCT-008", "version": "0.3.0-research.1", "sha256": "b315e808411d0a4f4009f057707454164ccbe5ac8bf99b5ad2864b9d1e334dde", "scope": "Exact extracted selected source clauses, not a new implementation or compatibility claim. Reading checkpoint only.", "findings": [ { "bundle": "quantity-semantics", "layer": "kind-and-dimension", "finding": { "id": "quantity-kind-identity", "name": "Quantity kind identity and disambiguation", "description": "Which kind of quantity the value expresses, resolved to a governed identifier, and how kinds that share a dimension are kept apart. VIM 1.2 defines kind of quantity as the aspect common to mutually comparable quantities; VIM 1.9 Note 2 records that units with the same dimension may name different kinds (joule per kelvin for both heat capacity and entropy; hertz for frequency but becquerel for activity, both 1/s). QUDT carries this as qudt:QuantityKind linked by qudt:hasQuantityKind with qudt:applicableUnit constraining admissible units.", "source_refs": [ "SRC-002", "SRC-008", "SRC-010" ], "questions": [ { "id": "qki-q1", "text": "Which quantity kind does this value express, and through which governed identifier is that kind resolved?", "kind": "identity", "answer_data": [ "quantity kind identifier (IRI or registry code)", "quantity kind label", "issuing vocabulary and pinned version" ] }, { "id": "qki-q2", "text": "When two candidate units share a dimension but denote different kinds, what evidence disambiguates the intended kind?", "kind": "classification", "answer_data": [ "disambiguating kind assertion", "dimension vector shared by the candidates", "rule or note cited for the distinction" ] }, { "id": "qki-q3", "text": "Which quantity kinds are admissible in this property slot, and who has authority to add one?", "kind": "authority", "answer_data": [ "admissible quantity kind list", "binding strength (required, extensible, example)", "authority reference for extension" ] }, { "id": "qki-q4", "text": "Is the property in fact a nominal property with no magnitude, and therefore outside this mixin?", "kind": "validation", "answer_data": [ "magnitude-bearing flag", "redirect target model when not magnitude-bearing" ] } ], "data_elements": [ { "id": "quantity-kind-id", "name": "Quantity kind identifier", "description": "Governed identifier for the kind of quantity, preferring an authoritative registry IRI over a locally minted code.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-002" ] }, { "id": "quantity-kind-vocabulary-version", "name": "Quantity kind vocabulary version", "description": "Pinned release of the vocabulary that supplied the kind identifier, so the identifier resolves deterministically.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "admissible-kind-set", "name": "Admissible quantity kind set", "description": "The kinds permitted for the host property slot, with binding strength.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "The quantity kind is an inline reference to an external vocabulary term; the mixin holds only the identifier and pinned version. The vocabulary release itself is an artifact governed by the unit-registry finding, not duplicated here." } }, { "bundle": "quantity-semantics", "layer": "kind-and-dimension", "finding": { "id": "dimension-and-consistency", "name": "Quantity dimension and dimensional consistency", "description": "The dimension of the quantity expressed as integer exponents over the ISQ base quantities (length, mass, time, electric current, thermodynamic temperature, amount of substance, luminous intensity), and the arithmetic checks it authorises. VIM 1.7 defines quantity dimension; VIM 1.8 defines quantity of dimension one. QUDT materialises this as a QuantityKindDimensionVector. Dimension equality is a necessary but not sufficient condition for comparability.", "source_refs": [ "SRC-002", "SRC-003", "SRC-008", "SRC-010" ], "questions": [ { "id": "dim-q1", "text": "What are the dimensional exponents of this quantity over the seven ISQ base quantities?", "kind": "measurement", "answer_data": [ "dimension exponent vector", "base quantity ordering convention", "source vocabulary for the vector" ] }, { "id": "dim-q2", "text": "Which dimensional consistency checks must pass before an addition, comparison or assignment involving this value is accepted?", "kind": "constraint", "answer_data": [ "required check list", "failure action", "operations exempted from the check" ] }, { "id": "dim-q3", "text": "Does dimension equality alone authorise treating two values as interchangeable in this context?", "kind": "relationship", "answer_data": [ "dimension-equality outcome", "kind-equality outcome", "decision on interchangeability" ] } ], "data_elements": [ { "id": "dimension-vector", "name": "Dimension exponent vector", "description": "Ordered integer or rational exponents of the ISQ base quantities characterising the quantity dimension.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "dimension-one-flag", "name": "Dimension-one indicator", "description": "Whether all dimensional exponents are zero, in which case the quantity is of dimension one.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "A dimension vector is derived, deterministic data computed from the quantity kind or the unit expression; materialising it as a standalone artifact would create a second source of truth that can drift from the registry." } }, { "bundle": "quantity-semantics", "layer": "scale-and-measurability", "finding": { "id": "scale-type-classification", "name": "Scale type and permitted operations", "description": "Whether the value sits on a ratio, interval, ordinal or nominal scale, and which arithmetic is therefore legal. VIM 1.26 defines ordinal quantity, 1.27 quantity-value scale, 1.28 ordinal quantity-value scale and 1.29 conventional reference scale. UCUM separates proper units, which form an Abelian group under multiplication, from special units on non-ratio scales such as degree Celsius that convert by function rather than scalar multiplication. Ratios and multiplicative scaling are invalid on interval scales.", "source_refs": [ "SRC-002", "SRC-005", "SRC-010" ], "questions": [ { "id": "stc-q1", "text": "Is the underlying scale ratio, interval, ordinal or nominal?", "kind": "classification", "answer_data": [ "scale type code", "justification or source clause", "special-unit indicator" ] }, { "id": "stc-q2", "text": "Which arithmetic operations must be refused on this scale type, and what is returned instead?", "kind": "constraint", "answer_data": [ "prohibited operation list", "permitted operation list", "refusal or error behaviour" ] }, { "id": "stc-q3", "text": "If a conventional reference scale is used, which scale definition and edition applies?", "kind": "provenance", "answer_data": [ "reference scale identifier", "edition or year", "issuing authority" ] }, { "id": "stc-q4", "text": "How are ordinal codes that look numeric prevented from entering arithmetic pipelines?", "kind": "validation", "answer_data": [ "ordinal marker on the value", "storage type used", "guard rule and enforcement point" ] } ], "data_elements": [ { "id": "scale-type", "name": "Scale type", "description": "Ratio, interval, ordinal or nominal classification of the underlying quantity-value scale.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-005" ] }, { "id": "reference-scale-id", "name": "Conventional reference scale identifier", "description": "Identifier and edition of a conventional reference scale, where the value derives its meaning from a scale rather than a unit alone.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "prohibited-operations", "name": "Prohibited operation set", "description": "Operations that must be refused for this scale type, such as ratio or multiplicative scaling on interval scales.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-010" ] } ], "artifacts": [ { "id": "scale-definition-record", "name": "Conventional reference scale definition record", "description": "The pinned definition of a conventional reference scale (for example a hardness or pH scale) that the value references, held so historical values remain interpretable after the scale is revised.", "media_or_form": [ "structured record", "normative document reference", "registry entry" ], "serial": false, "identity_strategy": "Authoritative scale identifier issued by the defining standards body; where none exists, a governed IRI minted by the adopting Dimension plus the edition designation.", "source_refs": [ "SRC-002", "SRC-010" ] } ], "inline_only_rationale": null } }, { "bundle": "value-expression", "layer": "value-composition", "finding": { "id": "value-reference-binding", "name": "Numeric value and reference binding", "description": "VIM 1.19 defines a quantity value as a number and reference together, where the reference may be a measurement unit (5.34 m), a measurement procedure (43.5 HRC) or a reference material (5.0 IU/l). VIM 1.20 defines the numerical quantity value as the number in that expression. The number may be complex, and vector or tensor quantities have a value per component. The operational consequence is that value and reference form an atomic pair: neither may be written, updated, defaulted or indexed independently, and D-SI carries them as one payload with uncertainty.", "source_refs": [ "SRC-002", "SRC-013", "SRC-009" ], "questions": [ { "id": "vrb-q1", "text": "What is the numerical value, and which reference type does it bind to — unit, measurement procedure or reference material?", "kind": "composition", "answer_data": [ "numerical value", "reference type code", "reference identifier" ] }, { "id": "vrb-q2", "text": "Is the numerical value real, complex, vector or tensor, and how are components carried and ordered?", "kind": "definition", "answer_data": [ "value arity and type", "component ordering convention", "per-component unit if components differ" ] }, { "id": "vrb-q3", "text": "Is the value/reference pair enforced as atomic, so that no write path can set one without the other?", "kind": "constraint", "answer_data": [ "atomicity constraint statement", "enforcement point", "behaviour on partial write" ] } ], "data_elements": [ { "id": "numeric-value", "name": "Numerical quantity value", "description": "The number component of the quantity value, carried in a representation that preserves the source precision.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-009" ] }, { "id": "reference-type", "name": "Reference type", "description": "Whether the reference is a measurement unit, a measurement procedure or a reference material.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "value-components", "name": "Vector or tensor components", "description": "Ordered component values for a vector or tensor quantity, each a number sharing or overriding the parent reference.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "This is the irreducible inline payload of the mixin. Externalising the number or reference into a separate artifact would break the atomicity the finding exists to enforce." } }, { "bundle": "value-expression", "layer": "numeric-representation", "finding": { "id": "precision-rounding-exactness", "name": "Precision, rounding and exactness", "description": "FHIR states that a Quantity value 'includes an implicit precision in the presentation of the value' and that 0.010 is regarded as different from 0.01, so trailing zeros are semantically significant and must be preserved. ISO 80000-1:2022 specifies rules for rounding of numbers, and NIST SP 811 gives rules for expressing values of quantities. Binary floating-point representation destroys both trailing-zero precision and exact decimal round-trips, so the representation choice is a semantic decision, not an implementation detail. Some values are exact by definition (the SI defining constants, and defined conversions such as 1 in = 25.4 mm) and must never be rounded.", "source_refs": [ "SRC-009", "SRC-010", "SRC-011", "SRC-003" ], "questions": [ { "id": "pre-q1", "text": "How many significant digits are meaningful, and are trailing zeros preserved through storage and serialisation?", "kind": "measurement", "answer_data": [ "significant digit count", "trailing-zero preservation flag", "serialisation form that preserves it" ] }, { "id": "pre-q2", "text": "Is this value exact by definition or an approximation subject to rounding?", "kind": "quality", "answer_data": [ "exactness flag", "defining authority for an exact value", "rounding permitted or prohibited" ] }, { "id": "pre-q3", "text": "Which numeric representation is mandated to guarantee lossless round-trip, and what is the behaviour if a consumer cannot honour it?", "kind": "interoperability", "answer_data": [ "mandated representation (decimal string, arbitrary precision decimal, rational)", "prohibited representations", "degradation behaviour and required warning" ] }, { "id": "pre-q4", "text": "Which rounding rule applies when the value is scaled, converted or aggregated, and is the rounding recorded?", "kind": "constraint", "answer_data": [ "rounding rule identifier", "rounding recorded as provenance", "pre-rounding value retained or discarded" ] } ], "data_elements": [ { "id": "significant-digits", "name": "Significant digits", "description": "Number of digits in the value that carry measurement meaning, distinct from the digits used in storage.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "exactness-flag", "name": "Exactness indicator", "description": "Whether the value is exact by definition and must not be rounded, or is an approximation.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-011" ] }, { "id": "numeric-representation-form", "name": "Numeric representation form", "description": "Declared representation used to carry the number without loss, for example arbitrary-precision decimal string or exact rational.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Precision and exactness are properties of the inline number itself. The only durable artifact in this area is the deployment's numeric-representation policy, which is governed under the service layers rather than duplicated as a finding artifact." } }, { "bundle": "comparability-and-conversion", "layer": "comparability", "finding": { "id": "commensurability-and-equality", "name": "Commensurability, equality and comparison rules", "description": "UCUM treats two units as commensurable when they share the same dimension, while stressing that commensurable units need not be equal, and that equality forms a narrower equivalence class than commensurability. Arbitrary units form no equivalence classes at all and are incomparable even to other arbitrary units. QUDT v3.4.0 introduced explicit relations such as qudt:specializationOf and qudt:unitForQuantityKind precisely because dimensional matching alone produced wrong equivalences. Comparison of values carrying uncertainty is a further distinct decision that must not default to bare numeric comparison.", "source_refs": [ "SRC-005", "SRC-007", "SRC-002", "SRC-012" ], "questions": [ { "id": "com-q1", "text": "Are the two units commensurable, and by which test — equal dimension, equal quantity kind, or both?", "kind": "relationship", "answer_data": [ "commensurability test applied", "test outcome", "dimension and kind of each operand" ] }, { "id": "com-q2", "text": "Does commensurability alone authorise comparison here, or is agreement on quantity kind also required?", "kind": "constraint", "answer_data": [ "comparison precondition set", "kind-agreement requirement flag", "documented exceptions" ] }, { "id": "com-q3", "text": "How are equality and ordering defined when one or both values carry uncertainty or a comparator?", "kind": "decision", "answer_data": [ "comparison semantics for uncertain values", "treatment of comparators in ordering", "tie or overlap resolution rule" ] }, { "id": "com-q4", "text": "Which comparisons must be refused outright rather than approximated?", "kind": "exception", "answer_data": [ "prohibited comparison classes such as arbitrary-unit pairs", "refusal response", "escalation path" ] } ], "data_elements": [ { "id": "commensurability-result", "name": "Commensurability determination", "description": "Recorded outcome of a commensurability test between two units, with the test kind and the vocabulary version used.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-007" ] }, { "id": "comparison-semantics", "name": "Comparison semantics identifier", "description": "Named rule set governing equality and ordering for values of this kind, including uncertainty handling.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "A commensurability determination is a derived computation over pinned registry data; persisting it as an artifact would create a cache that silently ages when the registry version changes." } }, { "bundle": "comparability-and-conversion", "layer": "conversion-mechanics", "finding": { "id": "conversion-functions", "name": "Linear and non-linear conversion", "description": "QUDT expresses conversion as qudt:conversionMultiplier with an optional qudt:conversionOffset relative to the coherent SI unit of the kind. UCUM distinguishes proper units, where conversion factors derive from dimensional analysis over its base set (meter, second, gram, radian, kelvin, coulomb, candela), from special units on non-ratio scales such as degree Celsius, which require mathematical functions rather than scalar multiplication. The critical trap is that converting a point on an interval scale and converting a difference on the same scale use different rules: a temperature difference of 5 °C is 5 K, but a temperature of 5 °C is 278.15 K.", "source_refs": [ "SRC-008", "SRC-005", "SRC-011", "SRC-001" ], "questions": [ { "id": "cnv-q1", "text": "What multiplier and offset convert this unit to the coherent SI unit of its quantity kind?", "kind": "measurement", "answer_data": [ "conversion multiplier", "conversion offset", "target coherent SI unit" ] }, { "id": "cnv-q2", "text": "Does the unit require a non-linear conversion function rather than multiplier and offset?", "kind": "constraint", "answer_data": [ "special-unit flag", "conversion function identifier and parameters", "function domain restrictions" ] }, { "id": "cnv-q3", "text": "Is this value a point on the scale or a difference, and which conversion rule therefore applies?", "kind": "decision", "answer_data": [ "point-or-difference designation", "conversion rule selected", "offset applied or suppressed" ] }, { "id": "cnv-q4", "text": "Which authority publishes the conversion factor, at what version, and is the factor exact or rounded?", "kind": "authority", "answer_data": [ "publishing authority and document", "version or edition", "exact or rounded designation with digits" ] } ], "data_elements": [ { "id": "conversion-multiplier", "name": "Conversion multiplier", "description": "Factor converting a value in this unit to the coherent SI unit of the same quantity kind.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-011" ] }, { "id": "conversion-offset", "name": "Conversion offset", "description": "Additive offset applied after the multiplier for units on non-zero-origin scales.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "conversion-function-ref", "name": "Conversion function reference", "description": "Identifier and parameters of a non-linear conversion function required by a special unit.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "point-or-difference", "name": "Point or difference designation", "description": "Whether the value denotes a point on the scale or a difference, selecting whether the offset applies.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-001" ] } ], "artifacts": [ { "id": "conversion-factor-table", "name": "Pinned conversion factor table", "description": "The set of conversion multipliers, offsets and function references in force for a deployment, pinned to named authority editions so that a historical conversion can be reproduced exactly.", "media_or_form": [ "tabular data", "RDF graph", "versioned reference dataset" ], "serial": true, "identity_strategy": "Governed IRI plus monotonically increasing release number in the adopting Dimension namespace; each row cites its upstream authority document and edition.", "source_refs": [ "SRC-008", "SRC-011", "SRC-001" ] } ], "inline_only_rationale": null } }, { "bundle": "comparability-and-conversion", "layer": "conversion-mechanics", "finding": { "id": "conversion-provenance-and-loss", "name": "Conversion provenance and information loss", "description": "Every conversion is a derivation that can lose information. A converted value that overwrites the original destroys the ability to audit or reverse the transformation, and rounding after conversion silently changes the implied precision. D-SI carries value, unit and uncertainty as a single payload precisely so that a transformed result remains metrologically interpretable. Round-trip conversion through binary floating point is frequently not idempotent.", "source_refs": [ "SRC-013", "SRC-009", "SRC-012", "SRC-011" ], "questions": [ { "id": "cpl-q1", "text": "Is the stored value the value as originally reported, or a derivative produced by conversion?", "kind": "provenance", "answer_data": [ "original or derived designation", "source value and source unit", "conversion agent and timestamp" ] }, { "id": "cpl-q2", "text": "What precision or uncertainty was lost in the conversion, and is the pre-conversion value retained?", "kind": "quality", "answer_data": [ "pre-conversion significant digits", "post-conversion significant digits", "retention decision for the original" ] }, { "id": "cpl-q3", "text": "Is the conversion reversible without drift, and is a round-trip check required before the result is accepted?", "kind": "validation", "answer_data": [ "round-trip test outcome", "tolerance for round-trip deviation", "action on failure" ] } ], "data_elements": [ { "id": "source-quantity-ref", "name": "Source quantity value", "description": "The originally reported value and unit from which a converted value was derived.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-009" ] }, { "id": "conversion-event-time", "name": "Conversion timestamp", "description": "RFC 3339 timestamp with explicit offset or Z recording when the conversion was performed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "conversion-loss-note", "name": "Conversion loss note", "description": "Recorded statement of precision, uncertainty or scale information lost or approximated during conversion.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-011" ] } ], "artifacts": [], "inline_only_rationale": "Conversion provenance is inline metadata attached to the derived value so it travels with it; separating it into an artifact would let a converted value circulate without its own derivation record." } }, { "bundle": "context-provenance-and-lifecycle", "layer": "versioning-and-correction", "finding": { "id": "registry-version-and-value-correction", "name": "Registry versioning, deprecation and value correction", "description": "Unit vocabularies change in ways that alter meaning: QUDT v3.4.0 replaced ambiguous broader-than relations with an explicit commensurability framework and v3.5.0 redefined BIT, BYTE and OCTET as counting units; CGPM 2022 extended the prefix set; UN/CEFACT Rec 20 has reached Revision 17; the SI itself was redefined in 2019 in terms of exact defining constants. Values must therefore record the registry release in force when they were created, and the model must state whether historical values are reinterpreted under new definitions or frozen. Separately, a corrected value needs an explicit disposition — in-place amendment, superseding version, or retraction — because silent overwrite destroys auditability.", "source_refs": [ "SRC-007", "SRC-004", "SRC-006", "SRC-001", "SRC-003" ], "questions": [ { "id": "rvc-q1", "text": "Which registry release supplied the unit definition in force when this value was created?", "kind": "provenance", "answer_data": [ "registry identifier and release tag", "release date", "pinning mechanism" ] }, { "id": "rvc-q2", "text": "Has the unit code since been deprecated, redefined or reclassified, and what is the successor and migration rule?", "kind": "lifecycle", "answer_data": [ "deprecation status and date", "successor code", "migration rule and whether it is value-affecting" ] }, { "id": "rvc-q3", "text": "Are historical values reinterpreted under a new unit definition, or frozen at the version of record?", "kind": "decision", "answer_data": [ "reinterpretation policy", "affected value population", "notification obligation to consumers" ] }, { "id": "rvc-q4", "text": "When a value is corrected, is it amended in place, superseded by a new version, or retracted — and what remains visible?", "kind": "state", "answer_data": [ "correction disposition", "supersession or retraction link", "visibility of the prior value and its reason" ] } ], "data_elements": [ { "id": "registry-release-pin", "name": "Registry release pin", "description": "Identifier and release tag of each unit or quantity-kind registry release the value was resolved against.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-006" ] }, { "id": "unit-lifecycle-status", "name": "Unit lifecycle status", "description": "Status of the unit code in its registry: active, deprecated, redefined, withdrawn, or replaced.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-006" ] }, { "id": "correction-disposition", "name": "Correction disposition", "description": "How a change to a recorded value was applied: amended, superseded or retracted, with a reason code.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "registry-release-manifest", "name": "Pinned registry release manifest", "description": "Manifest listing every external unit, quantity-kind and value-set release the deployment has pinned, with release tags, retrieval timestamps, content digests and the breaking changes noted between releases.", "media_or_form": [ "manifest record", "lock file", "versioned reference dataset" ], "serial": true, "identity_strategy": "Governed IRI plus monotonically increasing manifest sequence number; each entry keyed by upstream registry URI, release tag and content digest.", "source_refs": [ "SRC-007", "SRC-006", "SRC-005" ] }, { "id": "deprecation-and-migration-notice", "name": "Unit deprecation and migration notice", "description": "Notice issued when a pinned unit code is deprecated or redefined upstream, stating the successor code, whether the change is value-affecting, the affected value population and the remediation deadline.", "media_or_form": [ "notice record", "change log entry", "machine-readable migration rule" ], "serial": true, "identity_strategy": "Governed IRI with a sequential notice number, carrying an RFC 3339 issue timestamp and references to the affected registry release manifest entries.", "source_refs": [ "SRC-007", "SRC-004", "SRC-006" ] } ], "inline_only_rationale": null } }, { "bundle": "interoperability-and-embedding", "layer": "embedding-and-disclosure", "finding": { "id": "mixin-embedding-contract", "name": "Mixin embedding contract", "description": "The registry marks this model as an EMBED value object. Embedding rather than referencing means the quantity has no independent identity or lifecycle: it is created, versioned, secured and deleted with its host. FHIR's Quantity is a datatype, not a resource, for the same reason, and SOSA delegates result encoding to whatever vocabulary the host adopts. The contract must state the minimum field set every embedding carries, which host responsibilities are inherited rather than restated, and the narrow conditions under which a quantity may instead be referenced by identifier — for example a shared reference condition or a defining constant reused across many records.", "source_refs": [ "SRC-009", "SRC-015", "SRC-013", "SRC-008" ], "questions": [ { "id": "mec-q1", "text": "Is the quantity embedded as a value object in the host record, or referenced by identifier, and what justifies the choice?", "kind": "composition", "answer_data": [ "embed or reference decision", "justification", "referenced object identifier if referenced" ] }, { "id": "mec-q2", "text": "Which fields are mandatory in every embedding, and which are conditionally required by scale type or origin?", "kind": "requirement", "answer_data": [ "mandatory field set", "conditional requirement rules", "minimum viable embedding example" ] }, { "id": "mec-q3", "text": "Does the embedded quantity inherit the host record's identity, versioning and audit trail, or does it carry its own?", "kind": "identity", "answer_data": [ "identity inheritance statement", "versioning inheritance statement", "audit trail location" ] }, { "id": "mec-q4", "text": "Which host-model responsibilities are explicitly delegated so this mixin does not restate them?", "kind": "ownership", "answer_data": [ "delegated responsibility list", "host model reference", "non-duplication assertion" ] } ], "data_elements": [ { "id": "embedding-mode", "name": "Embedding mode", "description": "Whether the quantity is embedded in the host record or referenced by identifier.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-008" ] }, { "id": "mandatory-field-set", "name": "Mandatory field set", "description": "The minimum fields that must be present in any embedding for the value to be interpretable.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-009", "SRC-013" ] }, { "id": "host-record-ref", "name": "Host record reference", "description": "Identifier of the record that owns the embedded quantity and from which it inherits identity and lifecycle.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-015" ] } ], "artifacts": [ { "id": "embedding-conformance-profile", "name": "Embedding conformance profile", "description": "Declaration of the mandatory and conditional field set for embeddings of this mixin in a given host model, with the inherited-responsibility list and worked minimal examples in at least one concrete projection.", "media_or_form": [ "profile declaration", "schema fragment", "conformance example set" ], "serial": false, "identity_strategy": "Governed IRI plus version in the adopting Dimension namespace, keyed by host model identifier and mixin version.", "source_refs": [ "SRC-009", "SRC-013" ] } ], "inline_only_rationale": null } } ] }