Make it inspectable.
Keep the source, specifications, and experiment records close to the result. A claim should have somewhere to lead.
An independent software organization
Formal verification. Local intelligence. Traceable systems.
Four projects, connected by a belief that good software should stand up to a closer look.
01 — The collection
From a mathematical contract to the system underneath it. Each project explores a different part of the same question: what can we actually trust?
A specification language that checks programs across seven proof systems, and challenges every result with a deliberately broken twin.
An offline assistant for documents, files, and computer tasks, with reviewable changes, sandboxed commands, and a path to formally checked code.
A transformer training toolkit covering tokenization, training, exact checkpoint resumption, and inference, with an inspectable experimental record.
A Linux From Scratch build driven by recorded commands, hashed source archives, explicit deviations, and independent boot witnesses.
Public source, documented results, explicit limitations. See each repository for its license.
02 — The connections
These projects grew together. Explore how the assistant, its learning tools, its verifier, and its foundation relate.
The checking layer behind dawnr. A model can propose a program; the proof systems decide whether it meets its stated contract. The same engine also checks standalone math and flight-code routines.
Inside t-proof-engineThe place the projects meet. dawnr uses the proof engine to check generated programs and connects the model research to practical work on a computer. It carries a pinned engine version so its results remain traceable.
Inside dawnrThe model research layer. locallm investigates training from scratch, while the proof engine provides a demanding way to evaluate generated code. Its record includes both successful engineering and experiments that did not transfer.
Inside locallmThe foundation. A verifier depends on the software underneath it. tup extends the evidence trail toward the operating system: which source bytes were used, which commands ran, and what the released image actually did.
Inside tupA closer look / t-proof-engine
In the published math showcase, each solution is checked against a specification, challenged with a broken twin, and run against the judge’s stored outputs.
Read the complete resultsProof coverage varies by problem. Some specifications encode mathematical models. The full record names the scope and limitations.
03 — Our approach
Tup brings independent software research into one place. The aim is useful tools with enough evidence for someone else to inspect, question, and build on.
Keep the source, specifications, and experiment records close to the result. A claim should have somewhere to lead.
State what was tested, under which conditions, and what the result establishes. A passing example is only the beginning.
Failed predictions and corrected results belong in the record. They tell us where the next useful question starts.
04 — Get in touch
Questions about the projects, research, or a possible collaboration?