I’ve been working on a question:
What does AI look like when the model, infrastructure, privacy, and interface are designed together from the beginning?
That work is becoming a complete private AI stack:
PLMN — Private Language Model Node
The user-facing layer for discovering, verifying, and interacting with private model infrastructure. Nodes move through an explicit verification lifecycle before being considered inference-ready.
PLMH — Private Language Model Hub
The execution layer where models run on locally controlled compute and data, connected to PLMN through a unified transport and protocol.
INTENT — Native Model Family
My experimental model architecture exploring how much capability can be extracted from smaller models when the model and the system around it are designed together.
PLMN now also includes an AES-GCM encrypted knowledge vault, PII sanitization, airgap controls, and a SHA-256-chained audit ledger for inference and security events.
The architecture is becoming:
INTENT → Intelligence
PLMH → Execution
PLM Protocol → Trust + Transport
PLMN → Interaction + Orchestration
The screenshots are from the system running today.
I’m interested in more than building another local LLM interface. I want to explore what becomes possible when the entire path—from model to infrastructure to user—is treated as one system.
That’s what I’m building at Global Intent Company.
#PrivateAI #LocalAI #AIInfrastructure #EdgeAI #MachineLearning #AIEngineering #GlobalIntentCompany
Global Intent Company is live. An independent research and systems engineering umbrella covering Machine Learning, Virtual Lab, Systems Research, and Shipped Software.Autonomous scientific discovery. Verified systems. Software that actually ships.Explore the architecture:
https://t.co/DWpH3KDIqe
#AIResearch #MachineLearning #OpenSource #BuildInPublic #IndieHacker
VirtualLab has reached a point where I no longer see it as just a project I am building by myself.
SensorNode is one visible piece of it, but it is really only a proof of concept for the instrumentation layer.
The larger goal is a scientific research environment that can connect simulation, physical measurements, AI-assisted research, evidence, provenance, reproducibility, and eventually real laboratory instrumentation inside the same architecture.
I wrote a longer article about where I would like VirtualLab to go next, what would actually be required to get it there, the kinds of people I would like to collaborate with, and whether this could eventually justify becoming a startup.
I am especially interested in hearing from people working in scientific computing, computational biology, instrumentation, embedded systems, AI/ML, causal inference, research reproducibility, security, and experimental design.
At this stage, external criticism and expertise are becoming just as important as writing more code.
If this direction interests you, I would genuinely like your perspective.
#VirtualLab #ScientificComputing #ScientificAI #Instrumentation #ComputationalBiology #DeepTech #ResearchTools #OpenScience #Startup
https://t.co/NvORA4pQa1
Most scientific software lives on one side of a divide.
Computational tools model what should happen. Laboratory instruments measure what actually happens. The data then moves through different applications, formats, notebooks, analysis tools, and often disconnected provenance systems.
I’ve been building VirtualLab around a different idea:
The model and the experiment should exist inside the same scientific environment.
The video attached to this article is an early demonstration of that architecture working across the computational and physical boundary.
At the beginning of the video, VirtualLab is operating as a computational research environment. The current reference program is RHO P23H retinitis pigmentosa, with views for molecular structure, biological state, simulation, evidence, numerical analysis, comparison, AI-assisted experimentation, and provenance.
Then the workflow moves into the Instruments workspace.
A physical Android device running VirtualLab SensorNode connects to the desktop application and begins transmitting real sensor measurements. The graphs shown in the video are not generated simulation traces—they are measurements arriving from the device.
The same connection can expose the phone's camera as an imaging instrument, allowing VirtualLab to receive physical image data alongside other measurements.
That distinction matters.
The phone's magnetometer, gyroscope, accelerometer, or camera are not evidence that a retinal disease model has been experimentally validated. Those quantities have nothing to do with RHO rescue by themselves.
What they prove is the infrastructure:
Scientific model
↓
Virtual experiment
↓
Prediction / simulation
↓
Physical instrument
↓
Measured observation
↓
Analysis
↓
Provenance
That is the boundary I wanted to cross.
Why build it this way?
VirtualLab is being designed around explicit scientific states.
A result can be:
MEASURED — directly observed by an instrument CALCULATED — produced by a numerical calculation SIMULATED — generated by a computational model PREDICTED — a model's prediction for an unobserved condition DERIVED — calculated from underlying measurements INFERRED — obtained through statistical inference MODEL_ASSUMPTION — an assumption required by the model
The software should never quietly blur those categories.
If a phone measures angular velocity, VirtualLab should know that it is a physical measurement.
If an ODE model predicts a change in surface rhodopsin, VirtualLab should know that it is a simulation.
And eventually, when a compatible laboratory assay measures that same biological quantity, VirtualLab should be able to compare the prediction against the experiment while preserving how both were produced.
The phone is only Instrument #1
SensorNode is deliberately simple.
Its purpose is to prove that VirtualLab can communicate with an external scientific instrument through a defined protocol rather than being permanently tied to one piece of hardware.
The same architecture can eventually support very different instruments:
calibrated microscopy
spectroscopy
electrochemistry
microfluidics
environmental sensors
tissue monitoring
automated experimental platforms
The instrument changes.
The scientific workflow does not.
Instrument
↓
measurement
↓
experiment
↓
analysis
↓
evidence
↓
provenance
Where this is heading
My longer-term goal for VirtualLab is not simply to create another simulation application or another instrument dashboard.
It is to build an executable scientific research environment where scientific knowledge can become a model, the model can generate a testable prediction, a physical experiment can measure reality, and the difference between the two can feed the next experiment.
The loop becomes:
Model → Predict → Experiment → Measure → Compare → Refine
There is still substantial work ahead. A phone is not a molecular analyzer, a simulation is not a clinical trial, and an AI-generated hypothesis is not scientific evidence.
Those distinctions are exactly why I am building provenance and epistemic state into the architecture rather than adding them later.
But the video represents an important step:
VirtualLab is no longer confined to simulated data.
It now has a working path from a computational scientific environment to a physical device producing real measurements.
And to me, that is where this project starts becoming much more interesting.
#VirtualLab #ScientificSoftware #LabInstrumentation #ReproducibleResearch #DataProvenance #ComputationalBiology #BiomedicalEngineering #OpenScience
VirtualLab crossed an important boundary this week: from simulation into physical measurement.
This is a live test of the VirtualLab SensorNode running on a Galaxy S25 FE and streaming real device measurements into the desktop runtime.
The phone exposes its physical sensors as an instrument node — including magnetometer, accelerometer, gyroscope, ambient light, barometer, and Camera2 hardware — while VirtualLab handles the scientific runtime, visualization, experiment state, and provenance.
The phone itself isn’t the end goal. It’s a proof that the architecture can connect computational experiments to real physical instrumentation.
The longer-term path is:
simulation → physical measurement → calibrated imaging → microscopy → external instruments → wet-lab integration
I’m especially interested in what happens when the same research environment can connect models, evidence, AI, physical instruments, measurements, and provenance without treating them as separate systems.
This is the first physical node.