Fewer FPGA engine cycles
2,523 → 13 cycles
The same bounded witnessed-path task on the same FPGA: conventional scalar firmware versus source-generated native dataflow.
Hardware comparison & complete timing →SEED STATE OS · INTEGRATION PROGRAMME
Reconstruct what changed.
Keep the rest.
Seed State OS keeps compatible working state available so supported operations can update the changed part and check the result. That can remove repeated reconstruction from applications, graphics and embedded systems.
03 / STATE
Seed State OSRETAIN · RECONSTRUCT · VERIFYAnimated BBF product identity.UK patent application GB2624953.2 · Filed 22 October 2026 · Pending
WHAT THE WORK SHOWS
A result you can inspect.
In separate warm-state GPU studies, the measured update step was 22.41× faster in the primary run and 20.92× faster in the repeat than the full-update comparison. These timers excluded initial construction and the independent full-output check. A separate CPU validation repeat measured 1,259.6615 ms versus 0.4722 ms per replay block, using an existing atlas and receipts.
PUT IT TO WORK
Start with your application.
Start with a recurring state update in your own application. Compare the complete update time, output and operating cost on the same hardware, including the preparation needed for reuse.
Study details and comparisons ↓RETAINED HARDWARE & GPU ACHIEVEMENTS
Small state.
Substantial results.
Native execution and selective reconstruction tackle different sources of repeated work. These are retained measurements from their respective qualified workloads.
Less dispatched GPU work
One changed tile. 4,095 retained.
131,072 versus 536,870,912 logical GPU threads across 32 rounds of a deterministic structured update.
GPU workload & output contract →Shorter GPU execution
Same device. Same operator.
Measured primary-run GPU execution ratios. Wider operational update comparisons recorded approximately 21–27× across the primary and repeat studies.
Timing boundaries & repeat →These results come from separate studies. In one FPGA task, timing the engine together with communication and verification fell from 2.9465 to 2.3319 milliseconds: 20.9% less elapsed time (1.264×). That figure describes this FPGA experiment alone. The CPU validation and GPU results have their own workloads and timers. The GPU operational comparison used warm retained state and excluded initial construction and the independent full-output evaluator. Follow the evidence notes for each comparison.
QUALIFIED SOFTWARE ROUTES
2,668× shorter
CPU validation time.
A retained repeat study compared compact route validation with expanded validation across 96 compatible structured-state fixtures, using an existing local atlas and receipts. The original study recorded approximately 2,548×.
CPU workload, retained dependencies & repeat →MAKE RETAINED STRUCTURE WORK AGAIN
Reuse adds
another source of savings.
Later tests measured the value of retaining several structures, competing with an optimised conventional cache, and reusing a qualified transformation on recurring requests.
Fewer collection cycles
A 16-slot collection versus one slot of the same native algorithm, over repeated four- and sixteen-structure request streams.
Collection comparison →Fewer resident-active cycles
156,524 versus 188,610 cycles against an optimised conventional 16-slot cache with hardware multiplication and equivalent current assertions.
Optimised comparator →Fewer recurring producer cycles
Qualified retained-transform nomination enabled versus disabled. The complete mixed request corpus saved 20.42% of producer cycles.
Recurring and mixed results →Each percentage has its own comparator and workload. The 17.01% is a later, separate resident test; it is not an additional percentage applied to the 13-cycle engine result.
GLYX + SEED STATE
Retain exact structure.
Restore it for qualified reuse.
Exact archive restoration and current readmission have been checked in component studies. A newer 17 October versioned-data comparison retained 57.3% fewer logical bytes than trained Zstandard and 37.9% fewer than compacted Borg, with exact reconstruction checks.
The archive connection, with full accounting →REUSE ACROSS REQUESTS
Keep useful structure.
Use it again.
Qualified bases and successful transform nominations can help compatible future inputs, including new related inputs. A growing-stream comparison combined checked-history reuse with route nomination and used 14.73% less conservative total time than size-based selection with repeated history scans, including setup and diagnostics. All 7,680 fresh full/range checks passed.
This measures a particular combined archive/state workflow. Conventional dictionary processing was faster on that workload, and individual requests did not continually become faster. Gains depend on applicable structure and the cost of maintaining it.
The growing-stream comparison and conditions →ENERGY-SAVINGS MODEL · HISTORICAL SCENARIOS
Model the energy opportunity.
Measure it on your workload.
Three historical scenarios project an average 94.05% energy saving per equivalent completed job, with estimates from 89.72% to 97.71% under assumed workload shares. Device power and customer bill impact would be measured during a deployment evaluation.
The model uses work, timing and byte-avoidance proxies for energy reductions and assumes unchanged overhead shares of 10%, 5% and 2%. These assumed shares are not a calibrated workload survey. Average power in watts, battery life and electricity bills need their own deployment measurements.
See the three scenarios and assumptions →WATCH THE INTRODUCTION
Seed State OS.
A closer look.
Product chapter from the BBF portfolio introduction.
00:01:20–00:01:52 in the eight-technology introduction · Narrated by Aeternum. Read the portfolio transcript →
This scene preview stops at the end of the selected chapter. Open the video library to watch from a scene onwards.
THE OPPORTUNITY
Less reconstruction.
More useful work.
When much of a structured state remains applicable, a system can focus on the necessary changes and dependencies, then check the reconstructed result.
Restore selected state
Build the state a supported operation needs from retained information and exact changes.
Preserve useful structure
Keep applicable foundations across updates instead of repeating the same preparation.
Qualify before use
Make source, version and current applicability part of the release decision.
Begin inside your system
Evaluate a defined runtime or state engine within an existing application or device programme.
A PRACTICAL INTEGRATION PATH
Retain. Reconstruct.
Verify. Continue.
Identify the useful state
Agree the state boundaries, dependencies and output contract for one workload.
Reconstruct what is needed
Reuse applicable structure, apply exact changes and account for the complete reconstruction cost.
Verify the result
Compare exact outputs, latency, resource use and recovery with your existing implementation.
WHERE TO BEGIN
One state engine.
Several entry points.
Choose a bounded integration where retained state and repeated reconstruction already matter to your product.
Structured working state
Explore selected restoration of verified tool state and task dependencies. Pair with TokenHoloFold for supported local execution.
Focused scene updates
Connect complete observed changes to affected state and, with a compatible renderer, affected image regions.
Efficient device operations
Target repeated state work within a phone, controller or appliance. Measure device latency, memory and joules on the intended hardware.
Compact continuity
Restore exact records from GLYX, qualify them for current use and rebuild the required state.
Each application starts with a targeted integration and its own correctness, performance and resource checks.
TARGETED INTEGRATION
Start with one useful
state operation.
Describe the application, intended device and output requirements. We assess a defined operation and suitable comparison before proposing integration.
Availability, support and commercial terms are discussed privately for the intended deployment.
PRIVATE EMAIL CONSULTATION
Your workload.
A proposal made for it.
Tell us what you want to improve, the platform you use and the result you need. We discuss suitability, evaluation scope and commercial terms privately by email.
Any evaluation fee, licence, support arrangements and delivery commitments are agreed in writing before work begins. Start with a non-confidential outline.
PORTFOLIO INTRODUCTION
See how the
technologies fit together.
Discover how our eight technologies address AI workflows, data, graphics, interactive worlds and learning.
More to see.
Explore the product films, select a scene and browse 4 earlier public films and updates.