{ "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-12T09:22:02Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 22.7, "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: 01a094eb-414f-76e2-978d-327a37fd8558\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: dynamic frequency scaling\nSense to describe: (none recorded)\nDomain code: XCT.QTY\nAlso known as: (none)\n\n\nContext for this batch of 1001 things:\n# Batch", "usd": 0.0, "recall": true }, "codex": { "seconds": 81.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: 01a094eb-415c-7723-b807-70b9b1fbf1a4\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: dynamic frequency scaling\nRegistry id: vr.tr.dynamic-frequency-scaling\nPlane / domain: XCT / XCT.QTY\nRegistry definition: (none recorded)\nNames folde" } }, "enrichment": { "pass": 3, "engine": "claude", "producedAt": "2026-10-05T23:50:00Z", "ingestedAt": "2026-10-05T20:49:40+00:00", "fields": [ "agent_conduct", "ethics", "failure_modes_and_hazards", "owners", "standards_and_regulation", "visual_identification" ] }, "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-Q2027240", "registryId": "vr.tr.dynamic-frequency-scaling", "name": "dynamic frequency scaling", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "XCT.QTY" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q2027240/", "model": { "registry_id": "vr.tr.dynamic-frequency-scaling", "name": "dynamic frequency scaling", "purpose": "Enable an agent to recognise dynamic frequency scaling, assess whether clock-rate adaptation meets workload and operating constraints, and select justified control actions.", "definition": "Dynamic frequency scaling is the adjustment of a processor's or other synchronous digital circuit's clock frequency during operation to manage performance, power consumption, or temperature.", "scope_statement": "This model owns runtime adjustment of a computing component's operating clock frequency, including control domains, selection policies, transitions, constraints and observed effects; vr.tr.dynamic-frequency-scaling denotes a control technique rather than a quantity or unit.", "in_scope": [ "Clock domains and components subject to runtime frequency adjustment", "Supported frequency choices, policy bounds and effective restrictions", "Frequency selection by software, firmware or autonomous hardware", "Frequency transitions and their timing", "Requested versus observed frequency and workload outcomes", "Interfaces to coupled voltage control, thermal limits and power budgets" ], "out_of_scope": [ "The general definition and measurement standard for frequency", "Voltage regulation and voltage-selection algorithms beyond their coupling to frequency", "Clock gating, power gating and sleep-state management as independent mechanisms", "Static overclocking or underclocking configuration without runtime adaptation", "Complete processor architecture and workload scheduling models", "Radio carrier tuning and spread-spectrum clock modulation" ], "distinguishing_features": [ "The controlled variable is a component's operating clock rate during operation, rather than merely its fraction of time active.", "The mechanism permits runtime frequency changes; a fixed clock specification alone does not establish dynamic frequency scaling.", "Voltage changes are not required by this model; coordinated voltage and frequency adjustment additionally belongs to dynamic voltage and frequency scaling.", "Thermal throttling overlaps when it changes clock frequency, but a thermal trigger alone does not identify the mechanism used.", "A frequency request is distinguishable from the delivered operating rate; Linux CPUFreq documents this distinction in its interfaces: [CPU Performance Scaling](https://www.kernel.org/doc/html/latest/admin-guide/pm/cpufreq.html)." ], "characteristics": [ { "name": "Controlled clock domain", "kind": "relation", "unit_or_values": "Component and clock-domain identifiers, with all affected members", "why_it_matters": "Determines which resources a frequency change can affect." }, { "name": "Frequency selection space", "kind": "category", "unit_or_values": "Discrete supported rates in Hz, bounded range in Hz, or abstract performance requests with documented mapping", "why_it_matters": "Prevents an agent from assuming arbitrary frequencies are selectable." }, { "name": "Requested frequency", "kind": "measurement", "unit_or_values": "Hz, timestamped; unavailable when the interface exposes only a preference or performance level", "why_it_matters": "Records the target without confusing it with hardware delivery." }, { "name": "Observed operating frequency", "kind": "measurement", "unit_or_values": "Hz with measurement method, clock domain and observation interval", "why_it_matters": "Supports verification of actual scaling behaviour." }, { "name": "Effective frequency bounds", "kind": "measurement", "unit_or_values": "Minimum and maximum in Hz, each with origin and validity interval", "why_it_matters": "Separates current restrictions from nominal hardware capability." }, { "name": "Selection authority", "kind": "category", "unit_or_values": "Software, firmware, autonomous hardware, shared or unknown", "why_it_matters": "Identifies whether an agent can request a rate directly or only influence selection." }, { "name": "Scaling policy", "kind": "relation", "unit_or_values": "Policy identifier, implementation version, inputs and tunable parameters", "why_it_matters": "Explains how operating conditions become frequency decisions." }, { "name": "Transition latency", "kind": "measurement", "unit_or_values": "Seconds, with request and settling endpoints and measured or declared provenance", "why_it_matters": "Determines whether adaptation can respond within workload deadlines." }, { "name": "Voltage coupling", "kind": "category", "unit_or_values": "Fixed voltage, coupled operating points, autonomous coupling or unknown", "why_it_matters": "Constrains valid changes and interpretation of energy effects." }, { "name": "Limiting condition", "kind": "state", "unit_or_values": "No observed limit, policy cap, thermal limit, power limit, electrical limit, competing request or unknown; multiple values allowed", "why_it_matters": "Helps explain why delivered frequency differs from the requested target." }, { "name": "Workload result", "kind": "measurement", "unit_or_values": "Completion time in seconds, throughput in declared work units per second, and deadline misses over a stated interval", "why_it_matters": "Tests whether scaling delivers acceptable service." }, { "name": "Energy per completed work", "kind": "measurement", "unit_or_values": "J per declared work unit, with energy measurement boundary", "why_it_matters": "Tests efficiency without assuming lower frequency guarantees lower total energy." } ], "affordances": [ "Identify supported frequency controls and the resources sharing their effects.", "Inspect the active selection policy, effective bounds and limiting conditions.", "Request a supported target, bound or preference through the available authorised interface.", "Trace frequency response to workload changes and diagnose request-delivery discrepancies.", "Compare policies using completed work, energy and deadline outcomes.", "Restore a recorded configuration when a trial violates its acceptance criteria." ], "agent_conduct": { "may": [ "Adjust clock frequency within the limits set by the system's firmware and operator.", "Monitor and report frequency, temperature and power together." ], "must_not": [ "Run a processor above its rated limits without the owner's agreement.", "Disable thermal throttling on systems that depend on it to avoid overheating.", "Change frequency scaling on safety-critical or real-time systems without validation.", "Hide throttling that degrades performance users rely on." ], "requires_human": [ "Changing power policy on production or safety-critical systems." ] }, "ethics": { "considerations": [ "Hidden throttling can mislead users about the performance of devices they paid for.", "Overheating devices can damage hardware and cause burns." ], "affected_parties": [ "Device users", "System operators" ] }, "owners": { "steward": "The owner of the device; the manufacturer sets the rated limits.", "master_systems": [] }, "visual_identification": [ "Clock speed readings in system monitors that rise and fall with load.", "Power or performance mode settings in the operating system or firmware." ], "failure_modes_and_hazards": [ "Overheating and instability when limits are set too high.", "Missed deadlines in real-time systems from unexpected slowdowns.", "Hidden performance loss from aggressive throttling." ], "standards_and_regulation": [ "Advanced Configuration and Power Interface specification, UEFI Forum, which defines processor performance states." ], "what_it_is_for": [ "Dynamic frequency scaling is used in computers, mobile devices and embedded systems to adapt processing speed to workload and operating conditions.", "Operating systems and hardware controllers use it to balance performance, energy consumption and heat generation.", "Its behavior matters when evaluating response times, battery life and thermal limits." ] }, "sources": [ { "id": "wikidata", "title": "Wikidata item Q2027240: dynamic frequency scaling", "url": "https://www.wikidata.org/wiki/Q2027240", "url_status": "live", "what_it_supports": "identity and sense of the item", "checked_by": "wikidata-api" }, { "id": "wikipedia-en", "title": "Wikipedia: Dynamic frequency scaling", "url": "https://en.wikipedia.org/wiki/Dynamic_frequency_scaling", "url_status": "live", "what_it_supports": "general description of the item", "checked_by": "wikidata-api sitelink" } ], "structure": { "bundles": [ { "id": "clock-domain-and-capability", "name": "Clock domain and capability", "description": "Identify the operating clock being adapted and the changes the platform supports.", "rationale": "Frequency control is meaningful only for an identified domain with a known selection space.", "layers": [ { "id": "controlled-resources", "name": "Controlled resources", "description": "Establish the resources affected by one scaling decision.", "findings": [ { "id": "scaling-domain-membership", "name": "Scaling domain membership", "description": "Record clock-domain membership separately from software policy membership and shared power dependencies.", "questions": [ { "text": "Which processor cores, accelerators, memory interfaces or other components have their operating clock changed by this control?", "kind": "boundary", "id": "scaling-domain-membership-q01" }, { "text": "What platform documentation or runtime enumeration establishes which resources must scale together?", "kind": "provenance", "id": "scaling-domain-membership-q02" } ] } ] }, { "id": "selectable-operating-rates", "name": "Selectable operating rates", "description": "Describe frequency capability and how it is exposed.", "findings": [ { "id": "frequency-selection-space", "name": "Frequency selection space", "description": "Record supported rates or ranges, request encoding and any conditional availability of elevated rates.", "questions": [ { "text": "Does the interface accept a frequency in Hz, a discrete operating-point identifier, a range or a performance preference?", "kind": "definition", "id": "frequency-selection-space-q01" }, { "text": "Which selectable rates are documented, and which depend on additional operating conditions?", "kind": "boundary", "id": "frequency-selection-space-q02" }, { "text": "How are unsupported targets rejected, rounded or mapped to supported rates?", "kind": "action", "id": "frequency-selection-space-q03" } ] } ] } ] }, { "id": "frequency-selection-control", "name": "Frequency selection control", "description": "Describe who selects frequency and how workload signals influence that selection.", "rationale": "An agent must distinguish direct control from advisory inputs before predicting the effect of an action.", "layers": [ { "id": "decision-authority", "name": "Decision authority", "description": "Locate selection responsibility across software and hardware.", "findings": [ { "id": "request-and-selection-contract", "name": "Request and selection contract", "description": "Record whether a control supplies an exact target, limits or a preference, and which component makes the final selection.", "questions": [ { "text": "Which software, firmware or hardware component selects the operating frequency?", "kind": "provenance", "id": "request-and-selection-contract-q01" }, { "text": "Does an agent's request specify a required target, an allowed range or an advisory preference?", "kind": "action", "id": "request-and-selection-contract-q02" } ] } ] }, { "id": "adaptation-rule", "name": "Adaptation rule", "description": "Connect observed demand and policy objectives to rate changes.", "findings": [ { "id": "demand-to-frequency-policy", "name": "Demand-to-frequency policy", "description": "Record the policy's signals, update triggers and mechanisms for avoiding unnecessary oscillation.", "questions": [ { "text": "Which demand signals or events cause the policy to reconsider frequency?", "kind": "definition", "id": "demand-to-frequency-policy-q01" }, { "text": "What sampling interval, hysteresis or minimum residency controls repeated upshifts and downshifts?", "kind": "measurement", "id": "demand-to-frequency-policy-q02" }, { "text": "Which policy parameters may be adjusted to meet the workload's latency or efficiency objective?", "kind": "action", "id": "demand-to-frequency-policy-q03" } ] } ] } ] }, { "id": "operating-constraints-and-coupling", "name": "Operating constraints and coupling", "description": "Represent limits and coupled mechanisms that restrict frequency choices.", "rationale": "A supported rate may be temporarily unavailable or require coordinated action outside frequency control.", "layers": [ { "id": "effective-limits", "name": "Effective limits", "description": "Identify currently binding bounds and their sources.", "findings": [ { "id": "limit-arbitration", "name": "Limit arbitration", "description": "Distinguish configured frequency bounds from thermal, power, electrical and competing-client restrictions.", "questions": [ { "text": "Which limits currently constrain frequency, and which source imposed each limit?", "kind": "provenance", "id": "limit-arbitration-q01" }, { "text": "How are conflicting minimum requests and maximum caps resolved?", "kind": "definition", "id": "limit-arbitration-q02" }, { "text": "What evidence identifies the binding restriction when the requested rate is not delivered?", "kind": "measurement", "id": "limit-arbitration-q03" } ] } ] }, { "id": "voltage-and-domain-dependencies", "name": "Voltage and domain dependencies", "description": "Expose dependencies without absorbing their complete control models.", "findings": [ { "id": "valid-operating-point-dependencies", "name": "Valid operating-point dependencies", "description": "Record voltage prerequisites and cross-domain restrictions relevant to a frequency change.", "questions": [ { "text": "Is frequency adjustment independent of voltage selection, or mediated through coupled operating points?", "kind": "boundary", "id": "valid-operating-point-dependencies-q01" }, { "text": "Which shared supply rails, clock relationships or other domains constrain a valid transition?", "kind": "boundary", "id": "valid-operating-point-dependencies-q02" }, { "text": "Which controller guarantees required sequencing and rejects invalid combinations?", "kind": "provenance", "id": "valid-operating-point-dependencies-q03" } ] } ] } ] }, { "id": "transition-and-frequency-evidence", "name": "Transition and frequency evidence", "description": "Establish how requested changes become observable operating behaviour.", "rationale": "Configuration readback alone cannot establish transition timing or the rate actually delivered.", "layers": [ { "id": "transition-behaviour", "name": "Transition behaviour", "description": "Describe the interval between requesting and attaining a new operating rate.", "findings": [ { "id": "frequency-change-timing", "name": "Frequency change timing", "description": "Record transition completion criteria, latency, intermediate behaviour and failure indications.", "questions": [ { "text": "What event marks request acceptance, and what evidence marks arrival at the new operating rate?", "kind": "definition", "id": "frequency-change-timing-q01" }, { "text": "How long does the transition take under the relevant load, including any execution stall?", "kind": "measurement", "id": "frequency-change-timing-q02" }, { "text": "How does the interface report rejected, superseded or incomplete changes?", "kind": "action", "id": "frequency-change-timing-q03" } ] } ] }, { "id": "frequency-observation", "name": "Frequency observation", "description": "Qualify the meaning and resolution of frequency telemetry.", "findings": [ { "id": "telemetry-semantics", "name": "Telemetry semantics", "description": "Label readings as targets, hardware observations or interval estimates and document their treatment of idle time.", "questions": [ { "text": "Does each frequency reading represent a requested target, a hardware observation or an interval-derived estimate?", "kind": "definition", "id": "telemetry-semantics-q01" }, { "text": "What observation interval, resolution and idle-time treatment apply to the measurement?", "kind": "measurement", "id": "telemetry-semantics-q02" }, { "text": "Which clock or counter supplies timing, and does its rate change with the scaled domain?", "kind": "provenance", "id": "telemetry-semantics-q03" } ] } ] } ] }, { "id": "workload-outcomes-and-intervention", "name": "Workload outcomes and intervention", "description": "Judge scaling by useful work and support controlled policy changes.", "rationale": "Clock rate is an intermediate control variable; useful performance and energy outcomes determine whether adaptation succeeds.", "layers": [ { "id": "performance-and-energy-response", "name": "Performance and energy response", "description": "Assess how the workload responds to different frequency behaviour.", "findings": [ { "id": "frequency-sensitivity-and-efficiency", "name": "Frequency sensitivity and efficiency", "description": "Compare completed work, latency and energy under documented workload and operating conditions.", "questions": [ { "text": "How do throughput, completion time and deadline misses change across tested frequency settings or policies?", "kind": "measurement", "id": "frequency-sensitivity-and-efficiency-q01" }, { "text": "What energy per completed work unit is measured, and which components are included in the energy boundary?", "kind": "measurement", "id": "frequency-sensitivity-and-efficiency-q02" }, { "text": "Is workload progress limited by the scaled compute domain, memory access, I/O or another dependency?", "kind": "boundary", "id": "frequency-sensitivity-and-efficiency-q03" } ] } ] }, { "id": "controlled-policy-change", "name": "Controlled policy change", "description": "Make frequency-control interventions attributable and reversible.", "findings": [ { "id": "trial-and-restoration", "name": "Trial and restoration", "description": "Record the baseline, authorised intervention, acceptance criteria and restoration procedure for a scaling trial.", "questions": [ { "text": "Which target, bounds or policy parameters will change, and which shared-domain workloads will be affected?", "kind": "action", "id": "trial-and-restoration-q01" }, { "text": "What latency, deadline, energy or stability result requires stopping the trial and restoring the baseline?", "kind": "action", "id": "trial-and-restoration-q02" }, { "text": "How will the agent verify that restoration took effect despite autonomous selection or competing controllers?", "kind": "measurement", "id": "trial-and-restoration-q03" } ] } ] } ] }, { "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 supplied domain code XCT.QTY should be checked: this term denotes a control technique rather than a unit or measured quantity.", "Usage sometimes treats dynamic frequency scaling as shorthand for dynamic voltage and frequency scaling; the intended boundary should be confirmed.", "ACPI applicability, operating ranges, and transition behavior depend on the platform; these statements are recalled knowledge rather than source-verified findings." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of dynamic frequency scaling 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": [ "Workload-driven frequency scaling", "Thermally constrained frequency scaling", "Power-budget-constrained frequency scaling", "Software-controlled frequency scaling", "Hardware-controlled frequency scaling" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of dynamic frequency scaling 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": [ "The Advanced Configuration and Power Interface (ACPI) specification, maintained by the UEFI Forum, defines processor performance-control interfaces, including performance states and Collaborative Processor Performance Control." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of dynamic frequency scaling 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": [ "Reducing processor power consumption during light workloads.", "Managing CPU and GPU performance within thermal and power limits.", "Extending battery runtime in mobile and embedded devices.", "Managing server performance and power consumption.", "Matching embedded-system processing speed to changing workload requirements." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of dynamic frequency scaling 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": "Clock frequency", "typical_range": "Device-dependent; commonly MHz to GHz in processors", "unit": "Hz" }, { "quantity": "Frequency-transition latency", "typical_range": "Hardware- and control-interface-dependent; no universal range", "unit": "s" }, { "quantity": "Energy consumed per completed task", "typical_range": "Workload-dependent; reducing frequency does not necessarily reduce total task energy", "unit": "J" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of dynamic frequency scaling 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": [ "Reducing frequency can increase response times or cause real-time workloads to miss deadlines.", "Poorly tuned control policies can oscillate between frequencies, adding overhead and performance variability.", "Unsafe clock transitions or operating frequencies can violate circuit timing requirements and cause incorrect operation.", "With voltage scaling, incorrect sequencing of voltage and frequency changes can cause instability.", "Longer execution at lower frequency can offset power savings through accumulated leakage and other system energy consumption." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of dynamic frequency scaling 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": "Dynamic voltage and frequency scaling", "difference": "Coordinates supply-voltage changes with frequency changes; dynamic frequency scaling alone does not require voltage adjustment." }, { "name": "Clock gating", "difference": "Suppresses clock pulses to inactive circuitry rather than selecting a different operating clock frequency." }, { "name": "Power gating", "difference": "Disconnects power from circuitry rather than changing its clock frequency." }, { "name": "Thermal throttling", "difference": "Limits operation to control temperature and may use frequency scaling, but can also use other mechanisms." }, { "name": "Overclocking", "difference": "Operates circuitry beyond its specified operating frequency; dynamic frequency scaling can remain entirely within specified limits." }, { "name": "Clock frequency", "difference": "Is the measured rate of clock cycles; dynamic frequency scaling is a control technique that changes that quantity." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of dynamic frequency scaling this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does the registry intend processor-only scaling or also accelerator, memory and interconnect clock scaling, and why is this control technique assigned to XCT.QTY?", "Does an existing Vercy world model already own dynamic frequency scaling or its relationship to dynamic voltage and frequency scaling?", "Which platform-specific sources establish frequency capability, voltage coupling and control authority for the implementations this publication should cover?", "Which implementations expose sufficiently reliable frequency telemetry to distinguish clock-rate changes from idle residency or duty-cycle modulation?", "What representative workloads, energy boundaries and service constraints should establish whether a scaling policy is beneficial?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 17, "questions": 35 } }