L1 — What should happen
Express the objective, required procedures, conditions, fallbacks and outcomes. Keep the programme understandable without embedding device or provider details.
Let AI contribute knowledge. Let programmes control execution.
Neutrino combines explicit programmes with reusable domain knowledge. Models help interpret information; a workflow runtime executes typed instructions and follows the programme’s declared transitions.
How it fits together
Example · the product page · compiled and run in your browser
Real: the programme the VM runs (the product page, compiled from its declarative intent), its declarations, its steps and the generated interface’s operations; the VM run below is live in this page, with scripted answers. Illustrative: the text pad’s phrases and the knowledge graph (the product page binds no ontology yet). Modelled: the durations. Compile and run it yourself.
1. Intent → programme
Describe the objective, required procedures, conditions and outcomes in L1. An LLM may help author the programme, but the resulting source—not an ongoing conversation—defines its obligations.
2. Knowledge → specialization
L2 expresses the workflow through abstract, typed procedures. The translator queries ontology knowledge and combines it with the target’s role and capabilities to produce concrete L3 bindings, without changing the programme’s obligations.
3. Instructions → execution
The specialized programme lowers to executable instructions. A workflow VM runs them through generated native interfaces, connecting the programme to models, sensors and external services.
4. Uncertainty → controlled progression
An operation can return evidence, uncertainty, failure or unavailability. The programme’s declared transitions determine what happens next; a model response does not independently rewrite the workflow.
Neutrino is under active development. The diagram combines implemented mechanisms with illustrative examples; it does not represent a deployed email-automation product.
Why not put every decision in an LLM loop?
Today, an LLM often does two jobs: understanding the domain and deciding what happens next. Neutrino separates them.
A programme states its objective. Ontology knowledge specializes how it can be achieved. A workflow VM executes explicit instructions through the application’s native interfaces.
Models remain useful—without becoming the hidden programme.
One programme, three levels
L2 — How the workflow is structured
Lower that intent into explicit, typed procedures: inspect information, request a decision, create a task, send a notification. Inputs, results and transitions are defined—not improvised during execution.
L3 — How it works here
Specialize those procedures using domain knowledge, the application’s role and its available capabilities. The implementation becomes concrete without changing the programme’s obligations.
Knowledge is an input—not hidden application code
How knowledge enters the programme
The ontology connects reusable concepts and relationships with domain-specific knowledge.
Its spine aligns with the programme’s typed requirements. Domain corpora supply the details needed to specialize them. Knowledge can grow without requiring every application workflow to be rewritten.
LLMs, curated sources and specialized models can help build that knowledge. Their proposals pass through explicit preparation and admission boundaries before becoming specialization inputs.
Execution belongs to the runtime
How execution is structured
The resulting instructions run in a workflow VM embedded in the host application.
Generated native interfaces connect instructions to real capabilities: classifiers, sensors, business systems and external services. Operations may complete immediately or asynchronously; their typed outcomes determine the next programme transition.
The model can interpret an email. The programme decides whether approval is required before a task is created or a message is sent.
Beyond a better prompt
An agent harness gives a model tools and execution scaffolding. Neutrino makes the workflow itself an explicit, inspectable programme.
Use models where interpretation is valuable. Use ordinary computation where rules are known. Keep authority, side effects and progression visible.
Flexible knowledge. Explicit procedures. Native execution.