Requirements, calculations, and checks
Core turns a bounded technical question into a reproducible chain of inputs, methods, evidence, and explicit requirement verdicts. Its headless CLI and thin native workbench use the same Rust implementation.
A Core contract specifies requirements and acceptable evidence. The headless CLI or native workbench checks the contract, runs locally connected tools, and records the inputs, execution receipts, and requirement verdicts.
Researchers and software agents can propose changes. Scientific tools perform the calculations, and Core records the checks and unresolved requirements.
Project integrations
We develop Core through Avila Labs’ research projects. It connects existing scientific tools and reuses their calculation records across studies.
- OpenBNCT integration. Core runs OpenBNCT nuclear-data checks and records the results against specified requirements.
- ACTINV research case. The coupled-shield case connects transport outputs to ACTINV activation calculations and records where nominal results cannot establish the required bounds.
- Fusion and thermal research cases. Core records candidate comparisons, feasibility checks, and missing evidence. These are tests of the infrastructure, not qualified engineering products.
- Planned Avify integrations. We plan to connect response-bounding methods with transport and inventory tools once their methods and applicable ranges are established. This integration is not implemented.
Documented research cases
These internal research cases link to source records at fixed revisions. They do not measure customer outcomes or productivity gains.
A completed check with 102 unresolved findings.
In a September 2026 OpenBNCT nuclear-data check, the checker ran successfully but retained 102 unexplained in-domain findings. Core bound the inputs and executable, preserved OpenBNCT’s rejection, and returned FAIL against the contract’s zero-finding limit. The integration also exposed a missing checker-descriptor identity in Core’s reuse logic, which was corrected.
OpenBNCT performed the scientific assessment. Core recorded its execution and the failed requirement. This case does not measure time savings.
Read the OpenBNCT use-case logA nominal result did not meet a bounding requirement.
A shielding case connected transport calculations with ACTINV activation estimates. Its first contract treated a nominal activation result as evidence for a requirement that needed a response bound. Core refused to run it. The corrected case records that bounded activation evidence is still missing.
This synthetic research case tests a mismatch between a requirement and its evidence. It does not validate the underlying physics or qualify a shielding design.
Read the coupled-shield caseA model ceiling below the improvement target.
A passive coil-support study asked whether any support in a deliberately generous mathematical model could reach a 1.5× improvement target. The domain checker found a ceiling of 1.1347×. Core recorded five passing validity gates and a failing ceiling gate, supporting the decision not to start a topology search under that formulation.
The ceiling belongs to the declared discretized, passive-linear model—not every possible fusion support. The mathematical argument came from the domain checker, not Core.
Read the passive-compliance ceiling casePlanned development
We plan to support engineering tools maintained by other organizations, with a common format for requirements and calculation records.
The library starts with versioned contract templates. Each records its author, intended use, limits, and revision history. We would like domain organizations to maintain their own templates and document the scope of their reviews.
Longer-term plans include connecting tools from multiple providers, rerunning only the calculations affected by a change, and exporting records for independent checking. These integrations, independent governance, and a provider marketplace are not yet established.
Source and library preview
The engine is pre-alpha, open-source software under AGPL-3.0-only. The Core website is a separate public library of versioned templates and a browser-local workspace preview; it does not run scientific solvers as a hosted service. Templates are experimental starting points, not independently audited standards.