EVIDENCE / CONTEXT MATTERS
A result is most useful when you know the workload, the comparator and what was included. Explore recorded work across all eight technologies, then read the detailed comparison studies below.
GLYX ARCHIVE · MATCHED RECORDED STUDIES
The 4.080 GB growing collection used 64.4% less complete-kit storage than ZIP Deflate 9. In the separate 11-file copy-heavy study, GLYX used 54.3% less than Deflate and 7.4% less than ZIP-LZMA, including recorded decoder costs.
Read the table as a storage bill: smaller numbers mean less space needed to keep and recover the same files. Archive + records counts the stored content and instructions needed to bring it back. Complete kit also counts the recovery software and helper files used in that study. Each row is its own experiment; repeated files and new files are identified so you can judge which resembles your collection.
How to read a ratio: 10:1 means ten bytes of original content for each stored byte. A whole-collection ratio counts the full archive. An added-batch ratio counts only the extra space needed when more files enter an archive that already holds reusable information. Exact recovery means the restored files matched their originals byte for byte.
| Study | GLYX archive + records | GLYX complete kit | Deflate 9 complete kit | ZIP-LZMA complete kit | What was checked |
|---|---|---|---|---|---|
| 14-file matched predecessor14 entries · 2.303 GB input | 377.157 MBArchive + recovery records | 478.845 MB | 675.393 MB | 346.847 MB | All 14 restored exactly in each arm. GLYX smaller than Deflate; ZIP-LZMA smaller than GLYX here. Common macOS excluded equally; additional reference Python-LZMA restoration is separate. |
| 11-file copy-heavy successive imports11 entries · 2.750 GB input | 292.700 MBArchive + recovery records | 394.388 MB | 863.231 MB | 425.875 MB | Declared copy-heavy workload. GLYX smaller than both matched ZIP arms after decoder costs. No compression-speed ranking: verified compressed ZIP payloads were reused. |
| 499-PDF matched stage499 entries · 1.496 GB input | 966.280 MBArchive + recovery records | 1,068.183 MB | 1,394.607 MB | 1,166.342 MB | 491 distinct file-content hashes. Original GLYX/Deflate results retained; the new ZIP-LZMA arm restored all 499 entries exactly. |
| 573-entry mixed continuation573 entries · 1.939 GB input | 1,110.356 MBArchive + recovery records | 1,212.222 MB | 1,774.654 MB | 1,496.426 MB | Includes eight labelled exact-copy controls; 555 distinct file-content hashes. The new ZIP-LZMA arm restored all 573 entries exactly. |
| 4.080 GB growing matched collection1,171 entries · 4.080 GB input | 1,231.460 MBArchive + recovery records | 1,333.450 MB | 3,749.489 MB | 3,182.329 MB | 1,171 entries / 569 distinct file-content hashes, including repeated inputs and three existing MP4 additions. GLYX, Deflate and the new ZIP-LZMA arm each restored every entry exactly. |
The three collections above were also archived with ZIP Zstandard and ZIP BZIP2. Every entry in every new ZIP archive was restored and checked against its original. The GLYX and Deflate results were reused from the accepted studies.
| Same collection | GLYX complete kit | ZIP Zstandard 3 complete kit | ZIP BZIP2 9 complete kit | Exact recovery in each new ZIP arm |
|---|---|---|---|---|
| 499 PDFs | 1,068.183 MB | 1,284.353 MB | 1,372.767 MB | 499 / 499 |
| 573 mixed entries | 1,212.222 MB | 1,626.821 MB | 1,748.146 MB | 573 / 573 |
| 1,171 growing-collection entries | 1,333.450 MB | 3,324.429 MB | 3,660.379 MB | 1,171 / 1,171 |
The new ZIP archives use Python 3.14’s ZIP implementation: LZMA with its default 8 MiB dictionary (lc3/lp0/pb2), Zstandard method 93 at level 3, and BZIP2 at level 9. Original file names, order and repetitions were preserved. Encoded prefixes were reused for the growing stages, so no compression-speed ranking is inferred.
The recorded complete kits include archive directories, manifests, restore helpers and the actual verified reader dependencies. Native bsdtar recovery passed the 499- and 573-entry LZMA sets and all BZIP2 sets. The 1,171-entry LZMA set and all Zstandard sets use the fully verified Python fallback; the installed native reader failed that LZMA run and did not support Zstandard method 93. Common macOS facilities are excluded consistently with the historical comparisons.
These are specific measured methods, settings and frozen collections. The earlier 14-file case where ZIP-LZMA was smaller remains visible. Extra 7-Zip encoder variants were inventoried, not benchmarked. The historical GLYX engine results are separate from qualification of the current encrypted desktop release.
Complete recorded kits include the restoration software and helper dependencies counted for each arm on the recorded macOS basis; the common operating system is excluded equally. These historical engine results are separate from the current encrypted desktop package. The 11-file comparison reused verified ZIP payloads and does not rank compression speed. The earlier 14-file workload favoured ZIP-LZMA on size, as shown above.
SEPARATE SCALE DEMONSTRATION
The original continuation retained 13.085 GB of archive and records, or 13.188 GB including the recorded macOS recovery kit. The corpus included existing and declared generated data, versions and controls. Every entry restored exactly; this continuation had no matched ZIP arm.
Follow-on cold-storage candidate: 12.930 GB retained, or 12.984 GB including its matched recovery kit. All 2,803 original files were restored exactly. This separate archival-storage study also has no matched ZIP arm; its candidate status is distinct from the desktop release.
KEEP ADDING TO THE SAME ARCHIVE
Byte avoidance in practice: information already retained can serve another addition without storing the whole content again. Explore the visual explanation across the technology family →
99.95% less extra storage than another uncompressed copy. Adding the same 584 files again meant 1,957,990,436 bytes of file content needed only 919,848 extra stored bytes, including recovery records. That avoided 1,957,070,588 bytes compared with another uncompressed copy. That is about 2,129 input bytes for each extra stored byte. Every file restored exactly; the earlier archive and recovery software remained required.
Watch the recorded progression →ALL EIGHT TECHNOLOGIES
Explore each technology’s recorded work and presentation. The dated studies below remain available with their original comparison details.
01 / EXECUTE
Complete supported structured operations locally and return a checked result to the wider AI workflow.
Explore named workload comparisons for time, memory and completed work, including their refusal or fallback boundaries.
UK application GB2623308.0 · Pending
02 / RETAIN
Compression that builds on what you’ve saved. More reusable structure can make later matching additions far smaller—giving you more room for files and versions, with exact recovery.
See the same-file ZIP comparisons and the 2,129:1 repeated-addition example. The free Mac trial lets you test your own files.
UK application GB2624952.4 · Pending
03 / UPDATE
Reuse applicable working state so supported operations can focus on the changes that matter.
The linked studies on conventional processors, graphics chips and programmable hardware show which operations were tested, what they saved and what still needed to run.
UK application GB2624953.2 · Pending
04 / EVOLVE
Create varied animated creatures and linked or nested environments from compact seed data, reconstructing the detail needed for play or inspection.
Explore playable visual prototypes and recorded world-checkpoint reconstruction. These are development demonstrations for future integrations.
UK application GB2625572.9 · Pending
05 / SHOW
Carry useful scene information forward and reconstruct the view or supported image regions needed after a change.
See visual demonstrations and measured reconstruction studies. The practical question is how much work and storage can be avoided while preserving the required output.
UK application GB2625573.7 · Pending
06 / REPRESENT
Carry reusable structured work across compatible language interfaces and explore smaller transfers with local reconstruction.
The linked work shows supported composition and checks that information applies in the intended situation, including when a stored relation can be reused and when it must be refused.
UK application GB2625574.5 · Pending
07 / CHECK
Catch missing work before it becomes rework: check each required part, supporting evidence and the actual combined answer in supported workflows.
Explore tests of multi-part completion, event ordering and continuity. The business value is being able to inspect why a result was accepted or refused.
UK application GB2625576.0 · Pending
08 / LEARN
Investigate source-backed learning and how learned relationships apply when the surrounding context changes.
Follow the recorded language and learning milestones. This is an active research programme; the linked evidence shows the abilities reached in each tested task.
UK application GB2625577.8 · Pending
LATEST / TOKENHOLOFOLD · 20 OCTOBER 2026
The frozen current customer package completed all 300 supported requests with exact interpreted parameters and complete numerical results. All 100 boundary controls were handled safely. Local workers ran with network access denied. A separate diagnostic pass also returned 30/30 exact restarted results and 60/60 exact warm repeats.
This preregistered study covers one synthetic structured patch/statistics operation family: six groups of 50 supported requests and 20 boundary classes of five controls. Requests varied wording, clause order, coordinates, state and query. The 300 state-bound requests contain 275 distinct raw strings. Repeated-state and changed-state pairs test contextual consistency; they are not 300 unrelated applications.
Swipe or scroll sideways to see all columns.
| Route | Exact answers | Safe controls | Median / p95 | Timing count |
|---|---|---|---|---|
| TokenHoloFold | 300 / 300 | 100 / 100 | 131.166 / 150.156 ms | 300 |
| Conventional local | 300 / 300 | 100 / 100 | 104.526 / 122.471 ms | 300 |
| One-call API + local tool | 237 / 300 | 92 / 100 | 1,386.661 / 1,671.974 ms | 237 |
The conventional local route also completed the work with zero API calls and was faster in this study. It shares the numerical receiver but uses lighter original release checks. Both local routes therefore remain visible in the comparison.
The API route used GPT-5.6 Luna with a frozen structured-output prompt and the same numerical receiver. It withheld 63 supported requests and released eight boundary requests that should have been refused. Those outcomes remain in the results; they were not retried or counted as successful work. This describes the tested configuration, not the provider's best possible performance.
On the 237 supported cases answered exactly by both TokenHoloFold and the API route, median complete-process times were 130.686 ms and 1,386.661 ms: a 10.61× ratio of medians. The median of individual paired ratios was 10.64×. The other 63 cases remain incomplete in the API arm and are excluded from this timing comparison.
The API arm made 355 calls: 300 supported requests and 55 semantic boundary controls, with zero retries. Ordinary application checks rejected the other 45 controls before inference. TokenHoloFold and the conventional local route made zero provider calls.
For the 237 supported tasks completed exactly by both routes, the API arm reported 89,528 input tokens and 8,295 output tokens. Using the rates frozen before testing gives an estimated US$0.02786–$0.03234 in provider charges. TokenHoloFold used zero provider calls for those tasks.
The entire comparison campaign made 355 calls, including controls and incomplete outcomes, with a frozen-rate estimate of US$0.04118–$0.04788. These are usage estimates, not invoices. The experiment ran both routes; it did not itself reduce a customer’s bill.
The conventional local route also incurred no provider charges. Net customer savings therefore need a matched evaluation against the best feasible existing route, counting local compute and other agreed incremental costs. Any savings-based licence is discussed against the agreed financial baseline and complete deployment costs. Count a saving once; token reduction and call avoidance can describe the same underlying benefit.
Native warm response time had a 26.834 ms median over 60 diagnostic repeats; the conventional local median was 19.842 ms. These repeats are separate from the 300 fresh requests and are not used to enlarge the primary speed ratio. Five missing-descriptor controls produced the expected validation exception. Source, learned state and the frozen test deck remained unchanged.
The results support this bounded operation on the tested Mac. Customer workload coverage, total application costs and deployment compatibility are established in a scoped evaluation. This test did not measure representation-token reduction or energy consumption.
The older 90.02× result used a different candidate, a two-call provider workflow and a different timer. It is displayed below as the original achievement; it is not the speedup measured by this larger trial. The separate 95.05% representation-token study also keeps its own denominator.
HISTORICAL / 24 SEPTEMBER 2026
The 24 September 2026 benchmark compared the native route with a selected-context GPT-5.6 Luna provider workflow across 32 tasks. Both paths returned 32/32 exact results. The paired-median latency ratio was 90.0223, rounded to 90.02×; 64 provider calls in the selected-context arm compared with zero on the native route.
The 25 September qualification recorded 24.31 ms median and 26.46 ms p95 complete-request time. All 112 fresh validation checks passed, including 32/32 exact end-to-end results, with zero model-provider calls in the qualified local route.
The provider comparison and fresh qualification concern separate recorded candidates. Their figures are presented independently. A customer evaluation measures complete equivalent work, output quality and eligible cost in the customer's deployment.
A separate 18-request study counted 59,064 tokens for the text-only exact-patch requests and 2,926 for their structured semantic-capsule representation using o200k_base. The reduction was 95.0461%, rounded to 95.05%.
This is a local count of those request representations. The compared answer-and-receipt projections were 4,034 tokens in both paths. Total provider invoice savings are measured separately in a customer evaluation; the request reduction and avoided calls are not added together as independent bill savings.
Watch Aeternum introduce TokenHoloFold →02 / GLYX ARCHIVE
The private candidate retained 793,564,456 bytes for 1,650,532,800 source bytes. The same-content ZIP used 1,490,471,935 bytes. All 742 selected files restored exactly.
Required reconstruction data was retained in the complete archive. A new runtime carrier of 68,152 bytes and an existing installation footprint of 51,749,173 bytes were recorded separately. Counting both conservatively gives approximately 845.4 MB, about 43.3% below the ZIP comparison. Backups, staging, the operating system and working memory are additional.
This is a private candidate test on a real-work library cohort, rather than a promise for every file or an installed-customer benchmark. Exact restoration and full retained-size accounting remain the basis for evaluation.
Explore GLYX Archive →Adding compatible structure can reduce the marginal storage needed for later content. File size alone does not guarantee that result. Encrypted, already-compressed and unique content can behave differently.
Business evaluations should compare the same content, count all retained dependencies and verify exact restoration.
Prepare an evaluation enquiry ↗03 / SEED STATE OS · NATIVE HARDWARE
The retained 3 October 2026 same-FPGA comparison used the same bounded selective-path function and preproduced witnesses. Median engine-cycle reduction was 99.4847% (99.5% to one decimal place), or 194.08× fewer engine cycles. There were 128 requests per arm: 256 total, 192 accepted and 64 correctly refused, with zero incorrect complete outputs.
For this FPGA experiment alone, completion-driven timing included the engine, communication and verification. It recorded conventional median elapsed time of 2.9465 ms and native time of 2.331896 ms: a 1.26356× ratio. Serial-loop throughput was 475.07 versus 366.31 requests per second, a 1.29693× ratio. These measurements include the transport around this operation; creation of the preproduced input witnesses is outside the comparison.
This supports the stated hardware operation and service. Whole-application reconstruction, operating-system performance, energy and battery life require their own measurements.
Return to the achievement overview →04 / SEED STATE OS · SELECTIVE GPU UPDATE
A retained matched Metal study used one deterministic tile-local structured workload on the same GPU with the same operator. One of 4,096 tiles changed; 4,095 retained tiles stayed applicable. Across 32 rounds, dispatched logical threads fell from 536,870,912 to 131,072. Logical work-accounting traffic fell from 12 GiB to 3 MiB. Here 1 GiB = 1,024 MiB, so 12 GiB is 12,288 MiB. Both are 4,096× reductions; logical traffic is distinct from physical bus traffic and electricity use.
Swipe or scroll sideways to see all columns.
| Output contract | Primary comparison | Separate repeat |
|---|---|---|
| Full-output materialisation | 22.4062× Mean times: 139.284 → 6.289 ms | 20.9190× Mean times: 124.365 → 6.023 ms |
| Compact output | 27.3896× Mean times: 142.448 → 5.316 ms | 24.6871× Mean times: 125.561 → 5.176 ms |
Primary GPU execution ratios of means were 353.4893× and 354.4632× for those two arms. All 120 trial results matched exactly across both studies. Twenty hostile controls were refused with exact fallback, with zero false accepts.
Operational timing covered event access, identity/path checks, updates, GPU dispatch and completion, output-path maintenance and work accounting. It used warm retained state: initial warm-state construction and the independent full-output evaluator (approximately 93–94 ms) were outside that timer. An integration requiring that evaluator on every request must include its cost. Compact-output consumers must support that contract or count later materialisation. The retained July 2026 study was reconciled into the current evidence record in October.
Explore graphics and structured-state applications →RETAINED CPU STUDY / COMPACT ROUTE VALIDATION
The retained July repeat of the matched structured-route study recorded a 2,667.6440× ratio in mean process CPU time and a 2,678.4904× ratio in mean wall time. The original study recorded 2,547.8000× and 2,563.8484× respectively. Both studies used 96 compatible deterministic fixtures and 2,880 validation checks per arm across ten replay blocks; warmups were excluded.
The comparator parsed, rebuilt and hash-checked expanded payloads. The compact route validated compatible retained structure using an existing local atlas and receipts. In the repeat, mean CPU time per replay block was 1,259.6615 ms for expanded validation and 0.4722 ms for compact route validation. Atlas construction and provisioning are retained input dependencies outside this per-block timer. This measures qualified route validation, rather than whole-machine CPU relief or arbitrary computation.
05 / RETAINED STRUCTURE COLLECTION
The 9 October 2026 capacity comparison used sixteen slots versus one slot of the same native algorithm on the same board. Twenty requests across four recurring structures used 211,272 → 78,528 cycles (62.8309% fewer). Eighty requests across sixteen structures used 845,112 → 314,112 cycles (62.8319% fewer).
The cycle boundary included lookup, miss qualification, exact computation and state commit. External transport, initial clearing, diagnostics and archive I/O were outside this timer. This measures the value of retaining multiple structures against a one-slot control. The optimised conventional comparison below is a separate test.
06 / OPTIMISED CONVENTIONAL COMPARISON
The 9 October comparison used an optimised RV32IM direct 16-slot retained-descriptor cache with hardware multiplication, equivalent current assertions and the same exact state/output contract. Aggregate reduction was 17.0118% over the 48-request task per arm. All 96 physical requests passed 290/290 correctness checks.
Resident-active timing included the first reset and frame clearing, resident input delivery, lookup, miss qualification, arithmetic, guards/state commit and full result capture. Diagnostic inter-request USB pauses, offline provisioning and archive I/O were excluded equally. This is a later workload-specific result, separate from the 13-cycle witnessed-path operation.
07 / RECURRING STRUCTURE & QUALIFIED REUSE
On 9 October, the same frozen hardware image executed 25 requests per arm with retained-transform nomination disabled and enabled. The twelve recurring requests used 222,070 → 152,088 producer-core cycles, a 31.5135% reduction. The complete mixed 25-request corpus used 504,567 → 401,550 cycles, a 20.4169% reduction.
Each new target was checked completely before exact reuse. These are physical producer-core measurements; output-consumer qualification and archival restoration were separate. Complete USB response was approximately 9.581 versus 9.547 seconds, so the producer result is kept distinct from end-to-end service performance. Benefits depend on recurring applicable structure; the cold subgroup did not share the recurring gain.
08 / GLYX & SEED STATE · EXACT PERSISTENCE
Exact restoration of retained numeric bases and current native software readmission were qualified separately. The later 138-request batch retained 16,167 archive-and-pin bytes versus 16,679 for identity-only encoding: 3.0697% less. The optimised conventional transform also retained 16,167 bytes, preserving parity. Runtime storage was a separate 10,787,643 bytes.
Unchanged verified native readmission evidence was reused for all 138 requests. Hardware producer work, software/RTL output consumption and archive restoration have separate evidence boundaries. A full TokenHoloFold/GLYX/Seed State customer integration measures their combined latency, quality and retained dependencies together; component percentages are not added or multiplied.
See how the products connect →LATEST / ARCHIVE + SEED STATE · 17 OCTOBER 2026
On one synthetic versioned-data workload, the accepted Seed State archive component retained 57.3% fewer logical bytes than trained Zstandard and 37.9% fewer than compacted Borg. Each arm retained 96 formation versions and 1,536 fresh versions; all 9,216 fresh full and selected-range checks passed.
Swipe or scroll sideways to see all columns.
| Implementation | Complete pipeline | Logical retained data | Allocated file space |
|---|---|---|---|
| Seed State archive component | 135.98 s | 32.51 MB | 246.02 MB |
| Zstandard + trained dictionary | 82.81 s | 76.09 MB | 289.41 MB |
| Borg + standard compaction | 918.48 s | 52.31 MB | 445.78 MB |
Seed State completed this workload 6.75× faster than Borg including its separately measured post-run standard compaction. Zstandard completed it faster than Seed State. Logical archive reduction does not equal the physical-disk or cloud-invoice reduction: both storage boundaries are shown above.
Complete time includes formation, setup, requests, durable storage, reconstruction, verification, restart and final checks. Retained counts include archive, pin, dictionary, cache and security files. Runtime installation and shared laboratory costs are reported separately. This used warm OS caches and process restart. Borg's fine-grained archive/restore workload is not a general backup-throughput benchmark; Zstandard used one fixed trained dictionary without an additional cross-version deduplication layer.
A separate fresh 17 October run reduced total time from 89.41 to 71.37 seconds (20.2%) while retaining the same 32.45 MB. Its 9,216 fresh reconstruction checks passed. Useful-request latency was essentially unchanged; the gain came from bookkeeping. Trained Zstandard took 50.57 seconds and retained 75.95 MB in that run. This isolated candidate has not been adopted into a customer product.
These software studies extend the archive/state evidence. They do not replace GLYX's 742-file desktop cohort, the FPGA results or a complete three-product customer evaluation. Ratios from different runs are kept separate.
Compare product and combined licences →LATEST / GLYX COMPLETE OPERATION · 19 OCTOBER 2026
A private macOS engine study compared the existing GLYX engine, an isolation control and a candidate across six authored workloads. The 108 fresh worker runs comprised six repetitions of each workload in each of three arms. The unchanged native decision programme executed in every arm.
Swipe or scroll sideways to see all columns.
| Workload | Existing engine | Candidate | Time change | Faster paired trials |
|---|---|---|---|---|
| Mixed content | 351.729 ms | 299.781 ms | 14.77% less | 6 / 6 |
| Repeated content | 1,155.853 ms | 894.071 ms | 22.65% less | 6 / 6 |
| Unique content | 338.421 ms | 288.503 ms | 14.75% less | 6 / 6 |
| Structured records | 577.064 ms | 582.620 ms | 0.96% more | 2 / 6 |
| Multiple sections | 1,070.307 ms | 1,034.495 ms | 3.35% less | 6 / 6 |
| Append operation | 435.288 ms | 357.410 ms | 17.89% less | 6 / 6 |
Four workloads met the preregistered improvement threshold of at least 5% lower median time and at least 80% faster paired trials. Structured records and multiple sections did not meet that threshold. These results describe the tested workloads, rather than a universal speed guarantee.
Archive input ingestion, native-worker preparation and teardown, full and selected-range restoration, exact checks, a fresh reader process and storage accounting. Parent-process startup, initial software-module loading and fixture construction are outside this operation timer and are included in the separately recorded complete-worker measurement. This engine comparison is separate from desktop interface and customer installation performance.
All 1,656 exact-output checks and 15 controls passed. Seventy-two matched archive and decision comparisons agreed. The candidate retained the same archive sizes and native decision results.
The largest measured child-process peak was about 129 MB. Several baseline workloads peaked at about 34 MB; the structured-record baseline already reached about 129 MB. Parent-process memory was recorded separately, so these figures are not a combined whole-application peak. Working memory is distinct from retained archive storage.
A bounded, selectively activated version is a proposed next optimisation. Its selection cost, memory cap and complete-operation benefit have not yet been demonstrated. These GLYX results do not add a new measured speedup to Seed State OS or to the combined product stack.
Return to GLYX Archive →GROWING-STREAM ARCHIVE / STATE COMPARISON
The 14 October comparison processed 768 fresh requests per arm in eight batches, including new bases, novel related variants, repeats and unrelated inputs. Combining checked-history reuse with route nomination used 53.1557 seconds versus 62.3384 seconds for size-based selection with repeated history scanning: 14.73% less conservative total time including setup and diagnostics. All 7,680 fresh full and selected-range output checks passed.
Qualified structure and applicable history could be reused, with fresh authority and validation for new transitions. Restarts or lost continuity required revalidation. Individual request latency did not continually decline; the conventional dictionary comparator remained faster on this workload. This is a software archive/state comparison, not an electrical-power result or a universal scaling guarantee.
HISTORICAL CONDITIONAL ENERGY PROJECTION · 25 JULY 2026
Three historical scenarios explore how reduced computing work could affect energy use. Their average projected saving is 94.05%, based on the assumed energy shares shown below. This is an illustrative model; the measured processor results are presented separately above.
Swipe or scroll sideways to see all columns.
| Scenario | GPU | CPU checks | Disk writes | Materialisation | Unchanged overhead | Projected saving |
|---|---|---|---|---|---|---|
| Conservative | 20% | 20% | 40% | 10% | 10% | 89.72% |
| Middle | 20% | 20% | 45% | 10% | 5% | 94.71% |
| Strong | 20% | 18% | 50% | 10% | 2% | 97.71% |
Projected saving = the sum of each assumed baseline energy share multiplied by its proxy reduction. The historical coefficients are GPU 99.7155%, CPU verification 99.7070%, disk writes 99.9263%, materialisation 98.6101% and unchanged overhead 0%. The unrounded scenario results are 89.716030%, 94.712345% and 97.714520%; their unweighted arithmetic mean is 94.047632%.
The mean describes these three assumed scenarios. It is not a statistical expectation or a confidence interval. Timing and avoided work do not directly measure electrical energy. The model assumes compatible retained state and a small change frontier. Setup, idle draw, transport and evaluator energy are not separately calibrated; the unchanged overhead share is an assumption. Stage speed ratios are not multiplied together.
These figures project energy for equivalent completed work. Average watts also depend on runtime and workload rate. Direct electrical measurement and complete deployment accounting remain necessary before claiming actual device-wide power, energy, bill or battery savings.
