Expensive research becomes more accessible when a smaller machine can keep making progress. We completed a large formal build by limiting concurrent work and preserving what had already finished. For a team with a fixed hardware budget, that is a useful alternative to treating the recommended machine size as the price of entry.
We asked that question while rebuilding a published Boussinesq formalization on a Windows workstation with roughly 62 GiB of installed memory available to the operating system. Its authors recommended a machine with around 150 GB for three dozen parallel jobs. Our recovered logs now show that the Boussinesq build completed after we reduced concurrency and resumed under a 28 GiB committed-memory limit for the build's process group. The recorded peak for that successful segment was 25.62 GiB.
The subsequent axiom audit also completed. A separate fresh-checker replay did not complete, so this is a successful build and axiom-audit result, rather than completion of every independent verification stage.
For research teams, the practical payoff is access: a large formal development may be workable on the machine you already have. The evidence needs to preserve the conditions that made it possible.
Read the hardware guidance with its workload attached
The pinned upstream README couples its memory guidance to high parallelism. It does not establish 150 GB as the minimum for every execution schedule.
Lake, Lean's build tool, retains completed compiled modules. A resumed attempt can therefore reuse earlier work while checking the remaining modules. Fewer active workers can reduce overlapping memory demands, at the cost of a different completion time. Individual modules still have to fit, and their demands vary.
Our launcher combined a requested Lean thread setting with a Windows Job Object limit. The former influenced scheduling; the latter limited committed virtual memory for the associated process group. Windows job limits are an operating-system mechanism, not a new 8DB compression technique.
Historical run · Separate completion boundaries
A completed build. A precise next checkpoint.
Resumed under a 28 GiB job commit limit.
25.62 GiBRecorded peak for that segment.
Both named targets list the three permitted standard axioms.
The separate checker did not complete in this pipeline.
What the retained run actually finished
The earlier attempt used a requested thread setting of eight and reached its 40 GiB job limit. Later attempts retained completed work. The successful resumed segment used a requested setting of two and ended on September 12, 2026, at 01:04 UTC.
| Checkpoint | Recorded outcome | What it establishes |
|---|---|---|
| Resumed Boussinesq build | Exit 0; final log reports 10,108 build jobs complete | The selected build finished, using earlier compiled work |
| Successful segment's resources | 28 GiB job limit; 25.62 GiB recorded peak; about 3 hours 52 minutes | Resource use and elapsed time for that segment |
| Target-specific axiom audit | Two named theorem outputs list only the three permitted standard axioms | The recorded audit completed for those targets |
| Separate fresh-checker replay | No completed check in the retained pipeline | This additional verification remains unestablished by these logs |
The elapsed time excludes earlier work, including dependency compilation and unsuccessful attempts. It is not a clean-build timing. Job commit is also different from physical RAM usage: these records do not prove a paging-free run or the smallest possible machine.
The comparison with the authors' guidance is contextual. It shows a useful alternative execution schedule; it does not establish a sixfold memory improvement against an otherwise matched run.
Keep the completed work and the unfinished checks together
For 8DB, the product opportunity is to make that hard-won progress reusable: keep the research question, completed steps, supporting evidence and remaining checks connected. A later worker should be able to continue the investigation without reconstructing it from scattered logs.
This is where the database becomes useful. A short handoff saying “replay in progress” can survive long after the build finishes. A later summary saying “verified” can make the opposite mistake and hide the checks still outstanding.
8DB's research twin has distinct event types for a build, an axiom audit, a kernel replay and a statement comparison. Those distinctions allow a research record to express progress without turning one successful step into every possible guarantee. The recovered logs provide evidence for updating the relevant build and audit history; a linked ingestion and validation step is still needed before claiming that successor state is present in the twin.
A useful record connects the exact target, source revision, host, resource policy, outcome and supporting log. A later reviewer can then ask what completed, what was reused, and what still requires a check. Our research-memory article explores the related problem of completed work being lost between investigations.
A repeatable way to approach an oversized job
Start with the job's actual dependency structure and supported scheduling controls. Preserve completed artifacts, retain source and toolchain identity, and measure the active process group's resource use. Adjust the amount of simultaneous work within a declared budget, then record each attempt separately.
This approach has established ingredients: build-system reuse and operating-system resource controls. 8DB's opportunity is to keep the resulting evidence connected to the research question and its remaining obligations. That is a different job from inventing a faster proof checker.
The next useful comparison would measure complete execution schedules on the same source, including preparation, retries, disk use and total elapsed time. Energy and operating-cost benefits would require their own measurements. The current result supports a practical method, not a universal efficiency claim.
This is one route to wider access: schedule the same required work within an available memory budget. Other workloads may benefit from reusing a result or choosing a representation that avoids unnecessary work. Each route needs its own evidence for completion, quality and total cost.
Bring us a verification task whose resource guidance appears to put it out of reach. The source, the available machine and the exact checks you need are enough to begin separating essential requirements from choices about execution. Discuss a research workflow.
Evidence scope: historical Windows logs recovered on September 18, 2026; Lean 4.32.2; upstream source pin d0124689. No new performance run was conducted for this revision. This is engineering work around an external formalization, not a database-throughput benchmark or a new mathematical result.
Lead illustration: conceptual artwork, not a product screenshot or a deployed customer system.
Evidence scope Recorded build and axiom audit complete · Resumed work · Separate fresh replay remains open. Explore the evidence.
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work