{ "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-12T10:10:59Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 22.8, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a09518-0e0f-7923-ba40-c3089d1a7971\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: half-precision floating-point format\nSense to describe: (none recorded)\nDomain code: XCT.QLT\nAlso known as: (none)\n\n\nContext for this batch of 1001 thin", "usd": 0.0, "recall": true }, "codex": { "seconds": 83.3, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a09518-0e09-7151-a6c9-9bba5e14a421\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: half-precision floating-point format\nRegistry id: vr.tr.half-precision-floating-point-format\nPlane / domain: XCT / XCT.QLT\nRegistry definition: (none" } }, "enrichment": { "pass": 3, "engine": "claude", "producedAt": "2026-10-06T12:00:00Z", "ingestedAt": "2026-10-06T08:42:05+00:00", "fields": [ "agent_conduct", "ethics", "failure_modes_and_hazards", "owners", "standards_and_regulation" ] }, "gate": { "passed": true, "version": "1.0", "at": "2026-10-07T10:10:28+00:00", "evidence": [ "completeness 1.00", "sense: Wikidata description", "2 live sources", "review by codex: pass" ] } }, "metaModel": { "id": "THING-Q1994657", "registryId": "vr.tr.half-precision-floating-point-format", "name": "half-precision floating-point format", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "XCT.QLT" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q1994657/", "model": { "registry_id": "vr.tr.half-precision-floating-point-format", "name": "half-precision floating-point format", "purpose": "Enable an agent to identify a half-precision floating-point format, interpret its encodings, and judge whether storing, converting, or computing with it meets a stated numerical requirement.", "definition": "A half-precision floating-point format represents numerical values in 16 bits, most commonly using IEEE 754 binary16 with one sign bit, five exponent bits and ten explicitly stored fraction bits.", "scope_statement": "This model owns vr.tr.half-precision-floating-point-format in XCT / XCT.QLT: the abstract representation contract for half-precision floating-point values, using IEEE binary16 as the reference profile and recording explicitly identified alternatives without assuming that every 16-bit numerical type is equivalent.", "in_scope": [ "Format identity, specification authority, and interpretation of names such as half and FP16", "Bit fields, decoding rules, representable values, and exceptional encodings", "Range, spacing, precision, and representability boundaries", "Conversion and arithmetic behavior required or selected by an implementation profile", "Evidence needed to assess interoperability and numerical suitability" ], "out_of_scope": [ "Full models of neighbouring formats such as binary32, bfloat16, fixed-point, and posits", "Processor architecture, instruction scheduling, and hardware design", "Complete programming-language type systems and compiler models", "Tensor layouts, image containers, and transport protocols beyond their format bindings", "Application algorithms and their domain-specific correctness criteria" ], "distinguishing_features": [ "Require a documented floating-point decoding rule; a 16-bit storage width alone does not distinguish half precision from integers or fixed-point values.", "For the binary16 reference profile, test for one sign bit, five exponent bits, and ten stored fraction bits, giving eleven bits of normal significand precision. [OpenEXR technical introduction](https://openexr.com/en/latest/TechnicalIntroduction.html#the-half-data-type)", "Inspect the treatment of the all-ones exponent: IEEE and Arm alternative half formats are incompatible despite sharing the half-precision label. [GCC half-precision documentation](https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html)", "Identify the representation separately from the language type and evaluation precision; a half storage type does not establish that expressions execute in half precision. [GCC half-precision documentation](https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html)" ], "characteristics": [ { "name": "Format profile", "kind": "category", "unit_or_values": "IEEE binary16 | documented alternative half format | unresolved", "why_it_matters": "Determines which interpretation rules apply before any bit pattern is decoded." }, { "name": "Specification authority", "kind": "relation", "unit_or_values": "Governing specification, edition, clause, and implementation binding", "why_it_matters": "Makes claims about compliance and naming traceable." }, { "name": "Field allocation", "kind": "measurement", "unit_or_values": "Bits per sign, exponent, and fraction field; binary16 reference: 1, 5, 10", "why_it_matters": "Distinguishes incompatible representations with the same total width." }, { "name": "Finite range", "kind": "measurement", "unit_or_values": "Binary16 reference: largest finite magnitude 65504; smallest positive normal 2^-14; smallest positive subnormal 2^-24", "why_it_matters": "Provides thresholds for checking overflow and loss of small values. [OpenEXR technical introduction](https://openexr.com/en/latest/TechnicalIntroduction.html#the-half-data-type)" }, { "name": "Local representable spacing", "kind": "measurement", "unit_or_values": "Difference between adjacent representable values at a specified magnitude and direction", "why_it_matters": "Supports error estimates without treating precision as a fixed number of decimal places." }, { "name": "Exceptional value class", "kind": "category", "unit_or_values": "Positive zero | negative zero | subnormal | normal | infinity | NaN, subject to profile", "why_it_matters": "Separates numerical values from exceptional encodings and preserves sign-sensitive distinctions." }, { "name": "Execution binding", "kind": "relation", "unit_or_values": "Language type, operation, operand format, intermediate precision, accumulator precision, and result format", "why_it_matters": "Prevents storage width from being used as evidence of arithmetic precision." }, { "name": "Conversion policy", "kind": "category", "unit_or_values": "Declared rounding direction, overflow response, subnormal handling, and NaN handling", "why_it_matters": "Determines whether conversion preserves the distinctions required by a consumer." }, { "name": "Implementation verification state", "kind": "state", "unit_or_values": "Unverified | documented | tested for named cases | conflicting evidence", "why_it_matters": "Keeps implementation observations distinct from the abstract format contract." } ], "affordances": [ "Resolve an ambiguous half or FP16 label to a documented format profile.", "Decode and classify raw encodings under the selected profile.", "Determine whether a value is exactly representable and quantify conversion error.", "Select a conversion policy or require wider storage when numerical tolerances are exceeded.", "Check whether two producers and consumers preserve required values and bit patterns.", "Construct boundary tests for rounding, subnormals, overflow, and exceptional values." ], "agent_conduct": { "may": [ "Convert values to and from half precision and report the precision lost.", "Explain its range, precision and use in graphics and machine learning." ], "must_not": [ "Store safety-critical, financial or medical values in half precision where its precision is not enough.", "Hide overflow, underflow or rounding errors from users of results.", "Present half-precision results as more precise than they are." ], "requires_human": [ "Changing number formats in a production system that others depend on." ] }, "ethics": { "considerations": [ "Precision shortcuts can produce wrong results in systems people trust." ], "affected_parties": [ "Users of computed results", "Engineers", "People affected by automated decisions" ] }, "owners": { "steward": "Nobody owns it; it is defined by a public standard.", "master_systems": [] }, "failure_modes_and_hazards": [ "Values above about 65,504 overflow to infinity.", "Small values lose precision or flush to zero, corrupting accumulated sums." ], "standards_and_regulation": [ "IEEE 754-2019, Standard for Floating-Point Arithmetic, Institute of Electrical and Electronics Engineers." ], "what_it_is_for": [ "Half precision formats are used in numerical computing, graphics and machine learning to reduce storage and data transfer requirements.", "They are suitable where their limited precision and numerical range meet the application's error tolerance.", "Interpreting stored values requires the exact encoding because different 16 bit floating point formats have different representations." ], "facets_not_applicable": { "recognition": "A floating point format is an abstract encoding whose identity cannot be established from visual appearance alone." } }, "sources": [ { "id": "wikidata", "title": "Wikidata item Q1994657: half-precision floating-point format", "url": "https://www.wikidata.org/wiki/Q1994657", "url_status": "live", "what_it_supports": "identity and sense of the item", "checked_by": "wikidata-api" }, { "id": "wikipedia-en", "title": "Wikipedia: Half-precision floating-point format", "url": "https://en.wikipedia.org/wiki/Half-precision_floating-point_format", "url_status": "live", "what_it_supports": "general description of the item", "checked_by": "wikidata-api sitelink" } ], "structure": { "bundles": [ { "id": "format-identity", "name": "Format identity", "description": "Establish what a half-precision claim denotes in its originating context.", "rationale": "Half precision is not a sufficient interoperability identifier.", "layers": [ { "id": "profile-resolution", "name": "Profile resolution", "description": "Resolve names to representation contracts.", "findings": [ { "id": "label-to-profile", "name": "Label to profile", "description": "Record the originating label and the evidence identifying its exact format; leave unresolved labels explicitly ambiguous.", "questions": [ { "text": "Which specification or producer declaration determines what half or FP16 means here?", "kind": "provenance", "id": "label-to-profile-q01" }, { "text": "Does the declared representation match binary16, a documented alternative half format, or a neighbouring numerical type?", "kind": "boundary", "id": "label-to-profile-q02" } ] } ] }, { "id": "specification-binding", "name": "Specification binding", "description": "Separate normative format definitions from implementation promises.", "findings": [ { "id": "authority-and-extent", "name": "Authority and extent", "description": "Attach each claimed behavior to the specification edition or implementation contract that supports it.", "questions": [ { "text": "Which edition and clauses define the encoding and associated numerical behavior?", "kind": "provenance", "id": "authority-and-extent-q01" }, { "text": "Does the implementation claim encoding compatibility, conversion support, arithmetic support, or some combination?", "kind": "definition", "id": "authority-and-extent-q02" } ] } ] } ] }, { "id": "encoding-and-value-classes", "name": "Encoding and value classes", "description": "Describe how a raw half-precision word acquires numerical meaning.", "rationale": "Agents must distinguish decoded values, exceptional classes, and preserved bit patterns.", "layers": [ { "id": "finite-decoding", "name": "Finite decoding", "description": "Capture the mapping from fields to finite values.", "findings": [ { "id": "field-interpretation", "name": "Field interpretation", "description": "Record radix, field positions, exponent bias, and separate decoding rules for normal and subnormal values.", "questions": [ { "text": "How are the sign, exponent, and fraction fields located and interpreted?", "kind": "definition", "id": "field-interpretation-q01" }, { "text": "Which exponent encodings change the leading-significand rule or select a non-normal class?", "kind": "boundary", "id": "field-interpretation-q02" } ] } ] }, { "id": "exceptional-encodings", "name": "Exceptional encodings", "description": "Identify zero, infinity, and NaN distinctions supported by the profile.", "findings": [ { "id": "special-value-distinction", "name": "Special value distinction", "description": "Track supported exceptional classes and any required preservation of zero signs, NaN payloads, or signaling distinctions.", "questions": [ { "text": "Which bit patterns represent signed zeros, infinities, and NaNs under this profile?", "kind": "definition", "id": "special-value-distinction-q01" }, { "text": "Which distinctions must an agent preserve when inspecting, copying, comparing, or converting these encodings?", "kind": "action", "id": "special-value-distinction-q02" } ] } ] } ] }, { "id": "range-and-resolution", "name": "Range and resolution", "description": "Expose the limits that determine whether a numerical requirement fits the format.", "rationale": "A small storage footprint is useful only when range and quantization remain acceptable.", "layers": [ { "id": "representability-boundaries", "name": "Representability boundaries", "description": "Locate finite limits and the transition into subnormal values.", "findings": [ { "id": "range-thresholds", "name": "Range thresholds", "description": "Record maximum finite magnitude, minimum positive normal, and minimum positive subnormal separately from operation-dependent overflow and underflow behavior.", "questions": [ { "text": "What are the exact finite and subnormal limits of the selected profile?", "kind": "measurement", "id": "range-thresholds-q01" }, { "text": "Which required input values fall outside those limits or inside the subnormal interval?", "kind": "measurement", "id": "range-thresholds-q02" } ] } ] }, { "id": "quantization-error", "name": "Quantization error", "description": "Assess resolution at the magnitudes an application actually uses.", "findings": [ { "id": "spacing-and-tolerance", "name": "Spacing and tolerance", "description": "Record adjacent-value spacing and conversion error against explicit absolute or relative tolerances, including behavior near zero.", "questions": [ { "text": "What are the nearest representable neighbours of each critical value, and is the value exactly representable?", "kind": "measurement", "id": "spacing-and-tolerance-q01" }, { "text": "Does the resulting error satisfy the required tolerance across the intended magnitude range?", "kind": "boundary", "id": "spacing-and-tolerance-q02" } ] } ] } ] }, { "id": "conversion-and-execution", "name": "Conversion and execution", "description": "Bind the representation to the operations that produce and consume it.", "rationale": "Numerical outcomes depend on rounding and evaluation rules as well as stored bits.", "layers": [ { "id": "conversion-contract", "name": "Conversion contract", "description": "Specify the treatment of values entering or leaving half precision.", "findings": [ { "id": "rounding-and-loss", "name": "Rounding and loss", "description": "Record source and destination formats, rounding decisions, and handling of out-of-range, tiny, and exceptional values.", "questions": [ { "text": "Which rounding rule applies, including halfway cases and negative values?", "kind": "definition", "id": "rounding-and-loss-q01" }, { "text": "When should conversion proceed, report loss, rescale values, or require a wider destination?", "kind": "action", "id": "rounding-and-loss-q02" } ] } ] }, { "id": "arithmetic-binding", "name": "Arithmetic binding", "description": "Identify where an execution path actually rounds.", "findings": [ { "id": "evaluation-and-accumulation", "name": "Evaluation and accumulation", "description": "Record operand, intermediate, accumulator, and output precision, together with fusion and subnormal settings.", "questions": [ { "text": "At which steps are results rounded to half precision, and which steps use wider intermediates or accumulators?", "kind": "definition", "id": "evaluation-and-accumulation-q01" }, { "text": "Which compiler, instruction, and runtime settings establish fusion and subnormal behavior?", "kind": "provenance", "id": "evaluation-and-accumulation-q02" } ] } ] } ] }, { "id": "interoperability-and-validation", "name": "Interoperability and validation", "description": "Determine whether a concrete use preserves its required numerical meaning.", "rationale": "Matching type names do not establish portable encodings or acceptable application error.", "layers": [ { "id": "representation-exchange", "name": "Representation exchange", "description": "Connect the abstract encoding to stored or transmitted bytes.", "findings": [ { "id": "exchange-contract", "name": "Exchange contract", "description": "Record the producer and consumer profiles, byte order, and any canonicalization or conversion during transfer.", "questions": [ { "text": "Do producer and consumer agree on the format profile and byte order?", "kind": "boundary", "id": "exchange-contract-q01" }, { "text": "Must transfer preserve numerical values, exceptional classes, or every original bit pattern?", "kind": "action", "id": "exchange-contract-q02" } ] } ] }, { "id": "numerical-acceptance", "name": "Numerical acceptance", "description": "Tie permission to use the format to explicit evidence.", "findings": [ { "id": "boundary-and-workload-evidence", "name": "Boundary and workload evidence", "description": "Combine targeted format tests with representative workload measurements before accepting a half-precision execution path.", "questions": [ { "text": "Which tests cover halfway rounding, normal-to-subnormal transitions, signed zeros, overflow, and supported NaN behavior?", "kind": "measurement", "id": "boundary-and-workload-evidence-q01" }, { "text": "What measured error, overflow frequency, and loss of small values would require wider precision or a revised computation?", "kind": "action", "id": "boundary-and-workload-evidence-q02" } ] } ] } ] }, { "id": "evidence-and-external-alignment", "name": "Evidence and external alignment", "description": "What the world already says about this thing, gathered so the model can be checked against it.", "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.", "layers": [ { "id": "reported-evidence", "name": "Reported evidence", "description": "Findings from the breadth pass, kept separate from the structural claims.", "findings": [ { "id": "evidence-confidence-notes", "name": "Check these first", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "The numerical limits given here apply to IEEE 754 binary16, not every format described as half precision.", "Storage format alone does not establish arithmetic precision, accumulation precision, rounding behavior or subnormal handling.", "This is a recall-based account; no standards or implementation documentation were consulted." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of half-precision floating-point format this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-kinds", "name": "Kinds and varieties", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "IEEE 754 binary16", "ARM alternative half-precision format, which uses the binary16 field widths but assigns finite values to the exponent encoding reserved for infinities and NaNs in binary16" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of half-precision floating-point format this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-identifiers", "name": "Identifiers and schemes", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "scheme": "IEEE 754 format designation", "value_or_pattern": "binary16", "note": "Names the standardized binary format commonly meant by half precision." }, { "scheme": "Computing shorthand", "value_or_pattern": "FP16", "note": "Common informal designation; the precise encoding and arithmetic behavior must be checked against the implementation." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of half-precision floating-point format this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-standards-and-regulation", "name": "Standards and regulation", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "IEEE Std 754-2008 and IEEE Std 754-2019, issued by IEEE, specify binary16 as a binary interchange format." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of half-precision floating-point format this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-real-world-use", "name": "Real-world use", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Storing and processing neural-network weights and activations.", "Mixed-precision numerical computation, often with accumulation in a wider format.", "Representing high-dynamic-range image channels and graphics data.", "Reducing numerical-array storage and memory-transfer requirements." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of half-precision floating-point format this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-measurements", "name": "Typical measurements", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "quantity": "Storage per encoded value", "typical_range": "16", "unit": "bit" }, { "quantity": "Binary16 significand precision for normal numbers", "typical_range": "11, including the implicit leading bit", "unit": "binary digit" }, { "quantity": "Positive finite normal binary16 values", "typical_range": "2^-14 through 65504", "unit": "dimensionless" }, { "quantity": "Positive subnormal binary16 values", "typical_range": "2^-24 through 2^-14 − 2^-24", "unit": "dimensionless" }, { "quantity": "Gap between 1 and the next larger binary16 value", "typical_range": "2^-10 = 0.0009765625", "unit": "dimensionless" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of half-precision floating-point format this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-failure-modes-and-hazards", "name": "Failure modes and hazards", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Limited precision causes rounding error and loss of small increments when added to much larger values.", "Overflow can produce infinity or a limiting finite value, depending on the rounding mode and implementation.", "Underflow reduces precision through subnormal values and can round small results to zero.", "Implementations that flush subnormal values to zero can change numerical results.", "Confusing binary16 with another 16-bit format or assuming wider accumulation can produce incorrect results." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of half-precision floating-point format this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-neighbours", "name": "Neighbouring kinds and how to tell them apart", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "name": "bfloat16", "difference": "Also uses 16 bits, but allocates eight exponent bits and seven fraction bits, providing greater exponent range and less significand precision than binary16." }, { "name": "Single-precision floating-point format", "difference": "IEEE 754 binary32 uses 32 bits and provides greater precision and exponent range than binary16." }, { "name": "16-bit fixed-point format", "difference": "Uses a fixed scaling factor rather than a per-value exponent, giving uniform spacing within its representable range." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of half-precision floating-point format this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does the registry intend half precision to mean IEEE binary16 exclusively, or should documented historical alternatives remain profiles within this entry?", "Which exact standard edition and clauses should anchor the published model's encoding, rounding, and exception claims?", "Which implementation bindings must be researched to establish promotion, accumulation, subnormal, and NaN behavior for intended users?", "Which neighbouring registry entries already own bfloat16 and other 16-bit formats, and what explicit cross-references prevent duplicate coverage?", "Which representative workloads and acceptance tolerances should govern decisions to retain half precision, rescale values, or widen precision?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 18, "questions": 28 } }