{ "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-12T08:53:16Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 23.9, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a094d1-071c-7340-9c35-cb3700e8b325\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: CPUID\nSense to describe: (none recorded)\nDomain code: INF.MED\nAlso known as: (none)\n\n\nContext for this batch of 1001 things:\n# Batch 043: 1001 registere", "usd": 0.0, "recall": true }, "codex": { "seconds": 74.9, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a094d1-0723-7fb2-b9e7-d011380c264c\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: CPUID\nRegistry id: vr.tr.cpuid\nPlane / domain: INF / INF.MED\nRegistry definition: (none recorded)\nNames folded into this entry: (none)\n\n\nContext for " } }, "enrichment": { "pass": 3, "engine": "claude", "producedAt": "2026-10-06T12:00:00Z", "ingestedAt": "2026-10-06T08:45:54+00:00", "fields": [ "agent_conduct", "ethics", "failure_modes_and_hazards", "owners", "visual_identification" ] }, "gate": { "passed": true, "version": "1.0", "at": "2026-10-07T10:10:25+00:00", "evidence": [ "completeness 1.00", "sense: Wikidata description", "2 live sources", "review by codex: pass" ] } }, "metaModel": { "id": "THING-Q1024235", "registryId": "vr.tr.cpuid", "name": "CPUID", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "INF.MED" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q1024235/", "model": { "registry_id": "vr.tr.cpuid", "name": "CPUID", "purpose": "Enable an agent to recognize CPUID, interpret processor capability reports in context, and decide which additional checks are needed before using those capabilities.", "definition": "CPUID is an x86 processor instruction that returns processor identification, capability and configuration information through registers selected by an input function number and, for some functions, a subfunction number.", "scope_statement": "This model owns CPUID as the x86 processor identification and feature enumeration instruction, including its query contract, reported information, interpretation rules, and evidence limits; this referent remains provisional because vr.tr.cpuid has no recorded definition.", "in_scope": [ "The CPUID instruction and its leaf and subleaf query interface", "Raw register responses and their documented interpretation", "Reported processor identity, features, topology, and cache information", "Vendor-specific enumeration rules and unsupported queries", "Execution context, virtualization, and capability decision prerequisites" ], "out_of_scope": [ "Processor hardware design, manufacture, and lifecycle", "The CPUID software company and its products", "Complete operating system processor initialization and scheduling", "Benchmark results and measured application performance", "General instruction set semantics beyond CPUID and its interpretation dependencies", "Hardware identity attestation and asset ownership records" ], "distinguishing_features": [ "Denotes an executable x86 instruction with selector-dependent register results, rather than a single permanent CPU identifier.", "Uses EAX to select a leaf and, for applicable leaves, ECX to select a subleaf; responses occupy EAX, EBX, ECX, and EDX.", "Reports processor identity and capability information rather than measuring instruction throughput or application speed.", "Its mnemonic names an architectural interface; a diagnostic utility that invokes it is a separate software artifact.", "A reported feature and a feature usable by the current process require separate judgments." ], "characteristics": [ { "name": "Referent interpretation", "kind": "category", "unit_or_values": "x86 instruction; unresolved alternative referent", "why_it_matters": "The registry name alone does not conclusively distinguish the instruction from namesakes." }, { "name": "Query selector", "kind": "category", "unit_or_values": "32-bit EAX leaf and applicable 32-bit ECX subleaf, represented in hexadecimal", "why_it_matters": "A response has meaning only under its exact selector and enumeration rules." }, { "name": "Raw response", "kind": "measurement", "unit_or_values": "Four unsigned 32-bit register values: EAX, EBX, ECX, EDX", "why_it_matters": "Preserving raw evidence permits later decoding and correction." }, { "name": "Enumeration coverage", "kind": "state", "unit_or_values": "complete for declared scope; partial; unavailable; unknown", "why_it_matters": "An omitted query must not become evidence that a feature is absent." }, { "name": "Reported processor identity", "kind": "category", "unit_or_values": "Vendor string, applicable family/model/stepping fields, optional brand string", "why_it_matters": "These fields guide interpretation without establishing a unique physical device identity." }, { "name": "Feature evidence state", "kind": "state", "unit_or_values": "reported present; reported absent; unqueried; reserved; undecoded", "why_it_matters": "Separates an observed bit value from missing evidence or undefined meaning." }, { "name": "Execution context", "kind": "relation", "unit_or_values": "Observation linked to logical processor or vCPU, process environment, and collection time", "why_it_matters": "A response must remain attached to the context that produced it." }, { "name": "Decode authority", "kind": "relation", "unit_or_values": "Vendor manual, revision, section, and applicable processor or interface scope", "why_it_matters": "Bit meanings and validity conditions require an explicit interpretation authority." }, { "name": "Capability usability", "kind": "state", "unit_or_values": "usable after checks; prerequisite missing; unsupported; undetermined", "why_it_matters": "Software dispatch may require operating system state and other checks beyond CPUID." } ], "affordances": [ "Collect a bounded CPUID report while retaining query selectors and raw registers.", "Decode identity and capability fields against an applicable vendor specification.", "Determine which leaves and subleaves require further enumeration.", "Compare reports across logical processors or execution environments.", "Evaluate a software feature's prerequisites before selecting an implementation.", "Flag incomplete, contradictory, or context-dependent reports for investigation." ], "agent_conduct": { "may": [ "Query processor capabilities on systems it is authorized to run on and report them.", "Explain the instruction and its common leaves for developers." ], "must_not": [ "Use processor identification to fingerprint and track users without consent.", "Spoof processor information to evade licensing or security controls.", "Assume features are present without checking, risking crashes on other processors." ], "requires_human": [ "Collecting hardware identifiers from users' machines." ] }, "ethics": { "considerations": [ "Hardware identifiers can be used to track people across services." ], "affected_parties": [ "Users of the computers", "Software developers", "Owners of the machines" ] }, "owners": { "steward": "Nobody owns it; processor vendors document its behaviour.", "master_systems": [] }, "visual_identification": [ "Appears in assembly code as the cpuid mnemonic, with a leaf number placed in the EAX register." ], "failure_modes_and_hazards": [ "Misread feature flags lead programs to crash on unsupported processors.", "Virtual machines may report misleading values." ], "what_it_is_for": [ "CPUID is used by operating systems, hypervisors, diagnostic programs and application libraries on x86 processors.", "Its reported information supports processor identification, capability discovery and selection of compatible software execution paths.", "Reported hardware capabilities may require additional operating system support checks before software can use them." ], "facets_not_applicable": { "interfaces": "The instruction interface is defined by processor architecture specifications rather than an independently issued standard, law or official classification." } }, "sources": [ { "id": "wikidata", "title": "Wikidata item Q1024235: CPUID", "url": "https://www.wikidata.org/wiki/Q1024235", "url_status": "live", "what_it_supports": "identity and sense of the item", "checked_by": "wikidata-api" }, { "id": "wikipedia-en", "title": "Wikipedia: CPUID", "url": "https://en.wikipedia.org/wiki/CPUID", "url_status": "live", "what_it_supports": "general description of the item", "checked_by": "wikidata-api sitelink" } ], "structure": { "bundles": [ { "id": "instruction-and-query-contract", "name": "Instruction and query contract", "description": "Identify the intended instruction and preserve the inputs needed to interpret each response.", "rationale": "CPUID is a query interface whose results cannot be understood as an undifferentiated processor ID.", "layers": [ { "id": "referent-and-interface", "name": "Referent and interface", "description": "Resolve what CPUID denotes and establish its register-based interface.", "findings": [ { "id": "selector-dependent-register-interface", "name": "Selector-dependent register interface", "description": "CPUID returns identification and feature information in EAX, EBX, ECX, and EDX. Model the instruction separately from each observation. Reference: [Intel architecture programming reference](https://www.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference-737410.pdf).", "questions": [ { "text": "Does the registry's originating record identify the x86 instruction rather than the CPUID company or a utility?", "kind": "definition", "id": "selector-dependent-register-interface-q01" }, { "text": "Which EAX leaf and applicable ECX subleaf produced this response?", "kind": "measurement", "id": "selector-dependent-register-interface-q02" } ] } ] }, { "id": "enumeration-boundaries", "name": "Enumeration boundaries", "description": "Determine which queries are meaningful and how enumeration terminates.", "findings": [ { "id": "range-and-subleaf-validity", "name": "Range and subleaf validity", "description": "Standard and extended function ranges require explicit handling; retain range discovery and leaf-specific enumeration rules. Reference: [AMD CPUID specification](https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/design-guides/25481.pdf).", "questions": [ { "text": "What supported ranges and maximum selectors were observed?", "kind": "measurement", "id": "range-and-subleaf-validity-q01" }, { "text": "Which documented validity and termination rules apply to this leaf's subleaves?", "kind": "boundary", "id": "range-and-subleaf-validity-q02" } ] } ] } ] }, { "id": "identity-and-decoding", "name": "Identity and decoding", "description": "Interpret reported identity and register fields under the correct architectural authority.", "rationale": "Vendor strings, signatures, and feature bits serve different purposes and must not collapse into one identity claim.", "layers": [ { "id": "processor-signature", "name": "Processor signature", "description": "Relate identification fields to documented processor classifications.", "findings": [ { "id": "family-model-stepping-interpretation", "name": "Family, model, and stepping interpretation", "description": "Processor signature interpretation requires documented family and model decoding rules. Reference: [Intel CPUID enumeration guidance](https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/cpuid-enumeration-and-architectural-msrs.html).", "questions": [ { "text": "Which raw signature fields and vendor-specific rules support the decoded family, model, and stepping?", "kind": "provenance", "id": "family-model-stepping-interpretation-q01" }, { "text": "What evidence would be needed before associating this report with one physical asset?", "kind": "boundary", "id": "family-model-stepping-interpretation-q02" } ] } ] }, { "id": "field-meaning-and-authority", "name": "Field meaning and authority", "description": "Keep raw values distinct from named capabilities and interpretation revisions.", "findings": [ { "id": "traceable-bit-decoding", "name": "Traceable bit decoding", "description": "Each decoded claim should identify its leaf, subleaf, register, bit or field, and supporting specification; retain unrecognized fields without assigning invented meanings.", "questions": [ { "text": "Which document revision and field definition justify this decoded claim?", "kind": "provenance", "id": "traceable-bit-decoding-q01" }, { "text": "Is this field defined, reserved, or outside the decoder's supported scope?", "kind": "boundary", "id": "traceable-bit-decoding-q02" } ] } ] } ] }, { "id": "reported-capabilities-and-use", "name": "Reported capabilities and use", "description": "Connect capability reports to software decisions and structural interpretations.", "rationale": "An agent needs actionable prerequisites and interpretation limits, not merely a list of feature names.", "layers": [ { "id": "feature-dispatch-prerequisites", "name": "Feature dispatch prerequisites", "description": "Distinguish a reported processor capability from permission and readiness to execute dependent code.", "findings": [ { "id": "usable-feature-decision", "name": "Usable feature decision", "description": "Record the complete prerequisite check for a proposed code path, including applicable operating system extended-state enablement, rather than treating one feature bit as sufficient.", "questions": [ { "text": "Which CPUID fields and non-CPUID state checks does this code path require?", "kind": "action", "id": "usable-feature-decision-q01" }, { "text": "What fallback should the agent select when a prerequisite is absent or unverified?", "kind": "action", "id": "usable-feature-decision-q02" } ] } ] }, { "id": "topology-and-cache-reports", "name": "Topology and cache reports", "description": "Interpret structural reports with explicit units, scope, and derivation rules.", "findings": [ { "id": "structural-report-interpretation", "name": "Structural report interpretation", "description": "For available topology and cache queries, retain raw fields and decoding formulas, and separate the reported structure from operating system availability and measured performance.", "questions": [ { "text": "Which queries and formulas support the reported cache dimensions or topology relationships?", "kind": "measurement", "id": "structural-report-interpretation-q01" }, { "text": "How does the reported structure relate to the processors available to this process?", "kind": "boundary", "id": "structural-report-interpretation-q02" } ] } ] } ] }, { "id": "observation-context-and-confidence", "name": "Observation context and confidence", "description": "Preserve where a report came from and determine how far its claims may be generalized.", "rationale": "A CPUID observation is evidence about an execution environment and requires context before it informs machine-wide decisions.", "layers": [ { "id": "physical-and-virtual-context", "name": "Physical and virtual context", "description": "Attach observations to their logical processor and any known virtualization boundary.", "findings": [ { "id": "report-origin-and-mediation", "name": "Report origin and mediation", "description": "Record whether the report was collected directly, supplied by another tool, or obtained inside a virtual environment, and leave host hardware conclusions unresolved where mediation is unknown.", "questions": [ { "text": "Which collector, logical processor or vCPU, and execution environment produced the report?", "kind": "provenance", "id": "report-origin-and-mediation-q01" }, { "text": "What evidence establishes whether the reported capabilities reflect a guest-visible configuration or physical hardware?", "kind": "boundary", "id": "report-origin-and-mediation-q02" } ] } ] }, { "id": "coverage-and-revalidation", "name": "Coverage and revalidation", "description": "Determine whether collected evidence supports the intended decision and when it needs refreshing.", "findings": [ { "id": "decision-specific-evidence-coverage", "name": "Decision-specific evidence coverage", "description": "Record missing queries, collection failures, and differences between processor observations; define revalidation conditions for decisions that depend on those reports.", "questions": [ { "text": "Does the report cover every selector and execution context required by the proposed decision?", "kind": "measurement", "id": "decision-specific-evidence-coverage-q01" }, { "text": "Which changes to processor placement, virtual machine configuration, or system state require recollection?", "kind": "action", "id": "decision-specific-evidence-coverage-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": [ "No sense is recorded; this description assumes the x86 instruction. The INF.MED classification warrants checking against the registry's original record.", "This is recalled knowledge, not source-verified research.", "Exact leaf layouts and capability checks should be verified against the applicable vendor manual and processor generation." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of CPUID 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": "x86 instruction mnemonic", "value_or_pattern": "CPUID", "note": "The instruction name in Intel and AMD assembly documentation." }, { "scheme": "x86 instruction opcode", "value_or_pattern": "0F A2", "note": "Two-byte hexadecimal opcode." }, { "scheme": "CPUID leaf and subleaf numbering", "value_or_pattern": "EAX selects a leaf; ECX selects a subleaf where defined", "note": "Results are returned in EAX, EBX, ECX and EDX; interpretation depends on the selected leaf and processor vendor." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of CPUID 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": [ "Intel 64 and IA-32 Architectures Software Developer's Manual - Intel.", "AMD64 Architecture Programmer's Manual - AMD." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of CPUID 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": [ "Selecting optimized software implementations according to supported processor instruction sets.", "Reporting processor vendor, family, model and stepping.", "Discovering supported cache and processor topology information.", "Configuring operating systems and hypervisors for processor capabilities.", "Diagnosing which processor capabilities a virtual machine exposes." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of CPUID 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": "Output register width", "typical_range": "32 per register across four output registers", "unit": "bit" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of CPUID 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": [ "Treating an advertised instruction-set capability as immediately usable without checking required operating-system support and enabled processor state.", "Querying unsupported leaves or subleaves and interpreting their results as valid capability information.", "Applying one vendor's leaf interpretation to another vendor's processor.", "Assuming a virtual machine exposes the physical processor's complete or unmodified capabilities.", "Treating identification fields as a universally unique or trustworthy hardware identity." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of CPUID 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": "CPU-Z", "difference": "CPU-Z is a diagnostic application that reports hardware information; CPUID is an instruction applications can use to obtain some of that information." }, { "name": "CPUID software publisher", "difference": "The publisher associated with CPU-Z is an organization using the same name, rather than the processor instruction." }, { "name": "Processor serial number", "difference": "A serial number identifies an individual processor where supported; CPUID generally reports processor characteristics and does not guarantee a unique device identity." }, { "name": "XGETBV", "difference": "XGETBV reads extended control-register state, including enabled state components; CPUID reports capabilities whose usability can depend on that state." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of CPUID this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does the originating registry record confirm the x86 instruction as the referent, and why was it assigned to INF.MED?", "Does an existing Vercy world model already own CPUID or its processor capability enumeration contract?", "Which processor vendors, architectural generations, and specification revisions should the first researched publication support?", "Which hypervisor interfaces and vendor-specific leaves need explicit coverage, and which should remain extensions?", "What minimum collection and operating system state evidence is required before an agent may approve a feature-dependent code path?" ], "statistics": { "bundles": 5, "layers": 9, "findings": 15, "questions": 23 } }