nuRemics is an open-source Python framework for building software-grade scientific tools.
Most R&D teams never turn their research scripts into lasting tools. Not because they lack talent, but because nobody ever showed them how. A research script solves a problem once: it's written fast, in a notebook or a standalone .py file, by one person, for one purpose. It works brilliantly, sometimes. Then it gets used once, saved somewhere, and forgotten. Six months later, nobody can run it. Not even the person who wrote it.
A research tool is fundamentally different:
- Documented — not just for you, but for a stranger.
- Tested — not just "it ran on my machine", but verified against known results.
- Modular — so others can extend it without breaking everything.
- Versioned — so every result can be traced back to the exact code that produced it.
- Collaborative — so the whole team builds on the same foundation.
The difference isn't about the quality of the underlying science. It's about whether the science can grow beyond the person who created it.
nuRemics bridges this gap. It's an open-source Python framework that brings software engineering best practices into scientific development, without requiring a team of software engineers. The goal isn't perfection. It's durability.
Overview
The nuRemics framework provides a dedicated environment to build custom software tools designed for the automated production of scientific results at scale, ensuring systematic reproducibility and full traceability across every execution. This is achieved through a clear separation of concerns, organized into the following layered structure:
APP
It is the execution engine where the core scientific logic is formalized and implemented in a codebase. It operates as a structured workflow composed of autonomous software processes (e.g., Process1-3) executed in a sequential order. Each software process encapsulates a specific stage of the computation and acts as an independent functional item.
INPUTS
It defines the entry points required by the application to function (e.g., Input1-6) and ensures that each input is routed to its respective software process, in order to satisfy the corresponding data requirements.
OUTPUTS
It defines the delivery points where results are produced during execution (e.g., Output1-4). Each software process generates its own outputs, which are either stored as final results or re-routed as inputs of subsequent software processes within the workflow.
CONFIGURATION
It orchestrates how the application is controlled by the operator across different study scenarios (e.g., Study1-2). For each study, the operator defines which inputs are Fixed (constant throughout the study) and which are Variable (changing between individual tests). This enables automated batch execution of multiple tests (e.g., Test1-3) by systematically updating the inputs.
TRACEABILITY
It automatically generates a structured directory tree (Study > Process > Test) where each output is stored within a hierarchy that directly links it back to the specific configuration that produced it. This provides a permanent, auditable record of every production run.
