BioSense

Accelerating cell-based therapy with agentic orchestration and real time evidence detection.

Define your purpose. Watch agents work it. Read why every choice was made.

Use the hosted app · Run it yourself · Synthetic example · Real examples · Example reports · Data & evidence · Host your own

---

BioSense turns a cell-production objective — more viable macrophages from iPSC, keeping identity — into evidence, a quantified hypothesis and one recommended protocol, with every number labelled by where it came from. A reasoning orchestrator directs specialist AI agents; deterministic tools own every statistic, simulation and decision envelope; a person approves.

Where it stands. Live AI discovery runs work on the hosted service — https://biosense-production-e48f.up.railway.app — and learn across runs through a shared cell production library and process reference. The bioreactor is a synthetic stand-in: nothing here has closed the loop on real cells. What this is not sets out the limits.

The problem, and what BioSense does about it

BioSense is designed to accelerate the development of cell-based therapies by tackling one of the biggest bottlenecks in the field: biological manufacturing and experimental optimisation are complex, slow, and still heavily dependent on fragmented data, manual interpretation, and repeated trial-and-error. Instead of forcing scientists to navigate literature, datasets, experimental variables, and process measurements separately, BioSense turns a high-level biological objective into an iterative design → run → measure → decide workflow.

An agentic orchestration layer coordinates specialised AI agents for literature evidence, bioinformatics, data analysis, simulation, and experimental planning, continuously combining prior knowledge with new results. During execution, feedback from the bioreactor and multiple sensors, detectors, and analytical measurements provides real-time information on how the cell product is responding, allowing the system to refine conditions and propose the next experiment. Scientists interact through a simple interface — asking a question, defining the desired outcome, and reviewing transparent assumptions and reasoning — while BioSense manages the complexity underneath.

The long-term goal is a closed-loop discovery and manufacturing system that learns from every experiment, reduces unnecessary iterations, and helps move safer, more effective cell therapies toward patients faster.

Architecture

Reading the picture: the green boxes are the reasoning agents — the orchestrator at the top, and the literature, bioinformatics and data-analyst specialists it dispatches. The blue boxes are deterministic code: they execute the analyst's plan over the data, compute every statistic, and keep provenance through evidence synthesis. The red decision envelope refuses anything the verdict does not permit, and the only dashed box — the real bioreactor — is the part that does not exist yet.

Agent	What it does	What it may not do
Orchestrator	reads the evidence, forms hypotheses, decides	approve a protocol, invent a number
Literature	searches Europe PMC and PubMed, reads full texts, quotes every value; starts from the library	cite a value it has not read
Bioinformatics	gene records (Ensembl, UniProt, STRING), finds and registers public datasets (GEO, any species)	state an effect no source states
Data analyst	inspects data, plans and repairs the analysis, runs it, interprets it with a capped confidence	compute a number by hand
BioSimulator	plays a protocol, an edit or a new factor through the reactor model	call a simulation a measurement
Analysis · Outcome	read a bioreactor run against fixed targets and QC	move a target after seeing results

Language models are good at reading and reasoning. They are not good at being trusted with the arithmetic, the pass/fail calls, or the authority to spend a week of someone's cells. So those jobs are split apart:

The agent chooses. Separate, deterministic code decides what it is allowed to choose — and refuses the rest.

Everything a model writes is a proposal. Everything that counts as a fact — the verdict, the QC calls, the metrics, the comparison between arms, every statistic — is computed. If the agent proposes something the verdict does not permit, the envelope refuses it and says why.

The model does	The code does
Reads papers, extracts cited claims	Computes every metric and verdict
Decides what evidence is missing	Refuses an analysis that names no uncertainty
Designs an analysis	Executes it deterministically, and does the statistics
Forms a hypothesis about why a run failed	Decides which actions the verdict permits
Chooses one action and explains it	Refuses anything outside that set
Writes the brief for the next protocol	Enforces that only a revision costs an iteration

The loop it runs

An analysis never changes a parameter. It produces evidence; the orchestrator decides, and the envelope can refuse.

Capabilities

Evidence	Literature with quotes and paragraph locators; proxies with their conversion when the exact value is not reported; widening search circles; a server-wide cell production library every run starts from
Data	Public GEO series of any species made analysable (NCBI processed counts, or the depositors' own table) with an evidence weight; private uploads; deterministic statistics over cytometry, bulk expression (genes, named gene sets, Reactome/GO pathways), proteomics and secretome panels, single-cell identity and purity, and chromatin peaks; one readout pooled across series
Analysis	An AI data analyst plans against the data, repairs refused plans, writes labelled scripts for what the tools cannot express, and interprets each result with a confidence capped by species, route and closeness
Hypotheses	Direction, magnitude and confidence as typed estimates (measured, derived, simulated, predicted, judgement); contradicted and superseded ideas kept
Protocol	The production chain as a timeline: stages by days, factors over their windows, every value with provenance (R/A/D/GAP) and a confidence bar; shared setpoints filled from the process reference; new levers registered into your project
Simulation	The calibrated iPSC→monocyte stand-in; edited lines and new factors as assumed effects; new parameters with a stated response played in their stage
Watching	Live insights while agents work; the Loop Tracker follows a running AI run; runs saved per project, pausable and extendable

Synthetic example

The demonstration path runs every stage on committed, invented fixtures, so anyone can see the whole flow without a model key. The protocol it ends with, drawn as the production chain — click any value for what it rests on:

And the same run as the Loop Tracker shows it, agent by agent:

A worked demonstration

SYNTHETIC DEMONSTRATION. Every input is an invented fixture committed to this repository and the simulator is a mechanistic stand-in. No number below is a measurement of any real cell.

Is M-CSF limiting monocyte output? — project ipsc_macrophage v1.0.0, run offline with no model API and no network.

uv run --frozen python -m biosense.benchmark.cli run \
  --config benchmarks/configs/macrophage_mcsf_demo.json

BioSense started from the objective "Increase viable macrophage production while maintaining macrophage identity and viability.", identified the unresolved question GAP-mcsf-dose, and planned an analysis against it.

It ran cytometry.population_comparison v1.0.0 over facs-mcsf-fixture:

• CD14_pos_pct: 41.18 in control vs 67.58 in mcsf_high (+26.4) — Welch's t-test, p=0.00132, BH-q=0.00176, n=3 vs 3, 95% CI [21.5, 31.5]
• CD206_pos_pct: 33.5 in control vs 57.52 in mcsf_high (+24.02) — Welch's t-test, p=0.000335, BH-q=0.000671, n=3 vs 3, 95% CI [21.4, 26.7]

The hypothesis it formed

Changing M-CSF may improve the objective: Increase viable macrophage production while maintaining macrophage identity and viability.

Outcome	Baseline → Candidate	Change	Provenance
CD14 pos pct	41.18% → 67.58%	+26.4 pp (+64.1%)	DERIVED
CD16 pos pct	16.93% → 31%	+14.06 pp (+83.04%)	DERIVED
viability pct	93.96% → 91.04%	-2.922 pp (-3.11%)	DERIVED
CD206 pos pct	33.5% → 57.52%	+24.02 pp (+71.69%)	DERIVED
Monocytes per input iPSC	17.99 cells/input_cell → 29.66 cells/input_cell	+11.67 cells/input_cell (+64.87%)	SIMULATED
Harvested cells	8.995 1e6 cells/mL → 14.83 1e6 cells/mL	+5.835 1e6 cells/mL (+64.87%)	SIMULATED
Final viability	80.78% → 80.78%	+0 pp (+0%)	SIMULATED
Cells in the monocyte gate	76.66% → 90.25%	+13.59 pp (+17.73%)	SIMULATED
Peak viable cell density	4.762 1e6 cells/mL → 4.762 1e6 cells/mL	+0 1e6 cells/mL (+0%)	SIMULATED
Mean aggregate diameter	273.9 um → 273.9 um	+0 um (+0%)	SIMULATED
Mean condition score	92.7 score → 92.7 score	+0 score (+0%)	SIMULATED

Confidence: moderate. supported by 2 source(s) across 2 evidence class(es) capped below high: no real experimental measurement of this process supports it yet

Simulator coverage

Every candidate parameter is accounted for. A parameter the model cannot predict is labelled, never dropped and never predicted anyway.

Next experiment. Test M-CSF at 20, 50, 80 ng/mL against the current process, measuring monocytes per input ipsc, harvested cells, final viability.

Capability scorecard: 17 PASS / 0 FAIL. This is a SYSTEM CAPABILITY scorecard. It records whether BioSense identified an uncertainty, planned an analysis, executed it deterministically, quantified what it could, checked simulator coverage and labelled every number. It does NOT measure biological truth, and a run can pass every row while being biologically wrong.

Full bundle — report, figures, tables, provenance and the audit package → benchmarks/public/macrophage_mcsf_demo/ · how benchmarks work → docs/BENCHMARKING.md

One protocol at the end, and the ideas that did not survive

A run forms several hypotheses and some of them are wrong. Reading eight cards and working out which survived is not the deliverable; one protocol is.

It is stamped PROPOSED — NOT APPROVED and names the act that would approve it: approve-protocol --approved-by "<a person>", which is a command-line act with a human behind it. No part of the web application can do it on their behalf.

Every value carries how firm it is — R reported, A adapted from cited claims, D a design choice, GAP no evidence at all. A gap is never filled with a plausible number; it is listed, and it blocks the wet lab.

And the hypotheses that did not make it stay on the page with the reason. Showing only the winner would hide that three alternatives were considered and ruled out, which is the part a reviewer most needs.

A worked result

Two questions, one run each:

1. Optimise wild-type T cells grown from iPSC.
2. Now do it with a BACH2 knockout that must reach the same target.

	Arms	Iterations used	Outcome
Wild type alone	WT	3 of 30	25.7 — target met
With the knockout	WT + BACH2 KO	25 of 30	25.7 and 26.0 — both met

The number to look at is 3 against 25. Adding one knocked-out arm multiplied the search eightfold, and the loop says why in its own words:

IL-7 cannot be set to one shared value: moving it 16 → 25.6 ng/mL improved BACH2_KO and degraded WT. The arms are being given separate values of this parameter from here on.

That is the finding: no single shared recipe could serve both genotypes. The search established it from measurements rather than assuming it, then split the parameter per arm. The knockout ended up needing more IL-7 at every stage and a weaker TCR stimulus.

Reports, committed and readable without running anything → reports/ · the full write-up, including everything this does not show → docs/IPSC_TCELL_EXAMPLE.md

The BioSimulator: the stand-in bioreactor

BioSense runs no real cells. In place of the bioreactor sits the BioSimulator — a mechanistic stand-in model of a stirred-tank iPSC→monocyte process. Its job is to let a candidate protocol be played before anyone commits a week of real cells to it, with every number it produces labelled SIMULATED and never passed off as a measurement.

You meet it in three places:

1. Inside the loop. The orchestrator sends a candidate protocol in; trajectories for growth, viability and harvest come back, each labelled.
2. Factor comparison. Something the model has no term for — an edited line, a new cytokine, a parameter you registered with a stated response — is played as an assumed effect on growth or differentiation in its stage, against the same run without it, and labelled as an assumption every time.
3. Simulator mode. The same reactor driven by hand: ten setpoints, a vessel you can watch day by day, and the instrument readings each condition produces.

The screenshot below is a factor comparison (the second of those). At the top is the assumed-effect verdict; in the middle, growth curves for viable density, viability and cumulative harvest — one line for the run with the added factor, one without; at the bottom, a table of the outcome metrics (harvest per input cell, peak density, viability, differentiation efficiency) for both runs side by side.

How each parameter moves the model — the growth, death and differentiation equations and the knob-by-knob table — lives with the model's own documentation: docs/BIOSIMULATOR_MODEL.md. The same table sits at the foot of the Simulator page, generated from the knob list the sliders use.

The console asks the loop to find a condition. Simulator mode hands you the same reactor — ten setpoints, a vessel you can watch day by day, and the instrument readings each condition produces.

Nothing in the drawing is decorative: circle size is the measured aggregate diameter, a dark core means that fraction of aggregates is past the diameter where the centre goes hypoxic, the specks are released LDH. Each day is scored good / strained / failing by arithmetic over stated thresholds, and the thresholds ship with the page.

Pick a probe fault from the Starting culture menu and the same exercise the analysis agent faces appears: one channel says the culture is thinning, three others disagree, and nothing about the biology has changed.

Hold two conditions, compare them, and carry one into a loop run — where every quantity arrives as a design_choice, the provenance class that blocks the wet lab until a named reviewer accepts it. A sandbox cannot launder a number into a protocol.

Choosing a process this model is not for does not render borrowed sliders. It lists that project's own knobs read-only and says why there is no trajectory: an M-CSF control on a CAR-T process would invite a setpoint nobody can run, and a prediction for it would be invented outright.

Details, including what it does not model → docs/SIMULATOR_MODE.md

Data extraction

Literature. Each value is extracted with the sentence that states it and where it sits in the paper. When the exact quantity is not reported, the closest proxy is reported with its conversion (embryoid bodies per well for a progenitor density), and the search widens in circles before anything is called "not found". A one-time landscape run, started from the Data page, builds the cell production library — papers and quoted values across expansion, aggregates, differentiation, maturation and scale-up — which every later run starts from.

Public and private datasets. The bioinformatics agent finds a GEO series, reads its samples, and registers an analysable table: NCBI's processed counts where they exist, the depositors' own table otherwise, or — where the series holds only a RAW archive — one count file per sample assembled into a table and labelled as such, for any species — each with a confidence ceiling for its species and route. Gene ids become symbols without asking anyone (NCBI's tables, fetched once and kept on the server, then Ensembl), headers like UT_1 are matched to the untreated samples, and a study the run cites is traced to its deposit from the paper itself (GEO's own link, and the accessions its text names). When none of that applies, the refusal names what the series and its samples hold, so the data request to a person is specific — and every request is optional, one line each, with one click to continue without them. The data analyst plans against it, repairs what the tools refuse, and interprets the result for this process, resolving a named uncertainty.

Samples are grouped by what they actually say, and time is kept. A label that lives only in the sample title (CD43- rep2) groups as title_label, or through a pattern over any field (title~(CD43[+-])); a control written two ways is pooled on purpose and said to be. A series sampled at several times keeps a timepoint column (--time-key), and an analysis of it names the timepoint it compares at — or pools them on purpose, which the result states — because a timing lever cannot be read from a pooled series. A series of called peaks (.narrowPeak.gz, .broadPeak, .bed) becomes a peak-set dataset for chromatin.peak_overlap, with replicates combined only as an explicit consensus or union (fetch-peaks); a single-cell series with a count matrix becomes a per-sample pseudobulk of one annotated population, with its time axis (fetch-sc); .tab.gz tables read like any other. Nothing here calls peaks, clusters cells or annotates a population.

BioSense weighs published literature, public datasets, a person's own unpublished data, simulation and real measurements — and keeps them apart.

Three facts stay separate, because collapsing them is how provenance gets lost. An analysis of somebody's own FACS run is:

evidence_class        : derived_analysis      ← what it IS
source_evidence_class : private_user_dataset  ← what it came FROM
source_visibility     : private               ← who may SEE it

No analysis may run without naming the uncertainty it would reduce. Not as a convention — AnalysisPlan requires uncertainty_ref, and a plan citing a hypothesis the loop never raised is refused by name. That is the difference between a bioinformatics capability and a dashboard.

What runs today, and what is only declared:

The Data page answers the three questions people ask before starting: what data is here, what analysis can run, and which processes BioSense knows how to tune. The four capability states read differently on purpose — runs here, needs an install, needs a program, not written yet — because only the last has no remedy.

Each process exposes only its own knobs, with its own limits and the origin of any bound narrower than the global one. A parameter the model has no term for is marked not modelled rather than hidden: it is a real design variable you can set in the lab, and what it lacks is a prediction.

Every number knows how it was produced

The most dangerous thing a system like this could do is let a simulated figure and a measured one sit side by side looking alike. So the estimate type travels with each number rather than with the card, report or hypothesis holding it, and a comparison takes the weaker of its two inputs.

The hypothesis card is where that shows up: the badge sits beside each number, because one card holds a measured baseline and a simulated candidate at once and a single badge over both would be a claim about neither.

A change computed from two measured values is derived, not measured: no instrument measured a difference, code subtracted two readings, and a reader who sees MEASURED beside "+26 percentage points" would believe something stronger than is true. 42% to 68% is +26 percentage points and +62% relative, reported as two figures, because one standing for both is a larger-sounding claim about a different quantity. A prediction whose magnitude is not yet estimated is a state the contract can express, with a required reason, rather than a blank somebody fills in later.

The loop closes at the residual. A prediction is hashed when it is committed, and a commitment timestamped after the run is refused — otherwise the comparison is a model fitted to a result and then congratulated for matching it. Agreement is reported; the model is never called validated.

Your own data stays yours: it lives outside every served directory, is git-ignored, is never listed by the web app, and can never become a literature citation — a claim needs a source, a paragraph and a verbatim quote, and a measurement has none of those. It can support a hypothesis, contradict public evidence and suggest a parameter. It cannot be cited.

Full detail → docs/BIOINFORMATICS.md

---

Real examples

Real runs, exported without anything that must not be committed (full texts, raw logs, private-data results). To add one: run it in the app with a real runtime, then

uv run --frozen python -m biosense.production.export_example \
  --run runs/ai-YYYYMMDD-xxxxxx --name short-name --out examples/real

add screenshots to the new folder, and link it here. The full checklist is in examples/real/README.md.

No real example yet — the next live run will be the first.

Quick start

Use the hosted app — no install: https://biosense-production-e48f.up.railway.app

Pick a project, state your objective, press Run AI discovery. Or run it on your own machine: docs/RUN_ON_YOUR_PC.md.

BioSense is a web application, and the hosted one runs the real agents. For most people there is nothing to install and no terminal to open.

Just use it

Open the hosted app: https://biosense-production-e48f.up.railway.app

Pick a project, state your objective, press Run AI discovery. The badge on screen says REAL AI — ONLINE, and the discovery agents do the work: real literature search, real analyses over the data you selected, a real quantified hypothesis, one recommended protocol.

Zero terminal commands. You do not install Omnigent, start a server, register an agent, or keep anybody's laptop switched on. The service runs the Omnigent runtime and the agent bundle inside itself.

Which image is behind that link matters, and the page says so. A service deployed from deploy/Dockerfile.ai with a model key offers REAL AI — ONLINE. One deployed from deploy/Dockerfile — the original, credential-free image — offers SYNTHETIC DEMO only, and shows the real option greyed with the reason. The badge on screen is always the truth about which one you are using. Switching an existing service over is a Dockerfile path, a volume mount at /app/runs and one secret: deploy/README.md.

What it costs you: nothing. What it costs the service: model credits — which is why real runs on the public instance are capped, and the caps are shown in the page before you press anything:

Cap	Default on the hosted instance
Real AI runs per visitor per day	3
Real AI runs across the service per day	40
One run's wall clock	30 minutes, then it is stopped
Between one visitor's runs	60 seconds

Reaching a cap refuses the run and says when to come back. It never hands you a synthetic run wearing a real badge — that substitution does not exist anywhere in this codebase.

Also in the page, with no cap at all: the synthetic demonstration path (deterministic code over committed fixtures — every stage, every card, the protocol, the simulator, the benchmarks), simulator mode, and the benchmarks.

If the hosted runtime is down, the page says which part is missing and that the demonstration path still works. It never disappears and never pretends.

Projects and runs

A project is a durable scientific workspace — a name, a species, a cell type, a goal — and it is a file on the server, so it survives a refresh, a restart and a redeploy. Create one from the Discovery page; it is selected immediately.

A run is a background job on the server, not a page's state. Open Runs, open the Simulator, switch project, create another project, refresh, or close the browser: the investigation keeps working. Only Stop run ends it. Reopen BioSense later and the run is where you left it — still running, or finished — with no duplicate session started.

Discovery and Runs show the same run, from the same object, through the same viewer: the status, the engine, elapsed time, last activity, the workflow stages as a count, which agent is working and on what, a timeline of what happened, and the tool refusals that are findings rather than log lines. The activity bar is indeterminate on purpose — it means the system is active, and no percentage is invented. A header indicator says when AI is working somewhere else: ● 2 AI RUNS ACTIVE.

A run also survives the computer going to sleep. While one is working the process asks the machine to stay awake (caffeinate on macOS, systemd-inhibit on Linux, SetThreadExecutionState on Windows); when it sleeps anyway, the time it was away is measured — the wall clock counts the sun, the monotonic clock counts this machine running — and given back, because a suspended run spends no model credit and a time limit is a bill cap. The run says so in its timeline, and the page rebuilds its event stream on waking instead of showing a frozen run. Nothing executes while a machine is suspended, so a run that has to carry on unattended belongs on a server that does not sleep.

You can ask the orchestrator to work other leads up as experiments. A run surfaces more good ideas than one round can test, and they usually end as prose nobody puts a vessel on. In the same conversation you ask questions in, name the ones you want: each comes back as a claim, the arms that would settle it, what it costs to run, and what to do with either outcome — beside the main hypothesis, never inside round 1, whose rules were fixed before any result existed. Confidence is capped by what it rests on, and an alternate that restates the main plan is refused rather than written.

The answer reads in the order you act in: the hypothesis first — the claim, with the one-line action it implies inside it — then round 1 at the bench, then the current estimated parameters. Round 1 carries what an arms table never did: the medium per stage, the reagents with stock, storage and handling, how the culture is actually run, and the do's and don'ts with what goes wrong if they are ignored. A supplier or catalogue number appears only where a source states it, quoted; everything else says to use your own qualified stock, because a catalogue number nobody checks before ordering is the most expensive thing this system could invent. Stage lengths are your project's own and you can change them — d0–7 was fixed in the profile, and it is a fact about your process, not about this software.

A run can be asked for in the vessel you actually have. Nobody starts in a bioreactor, so a run can be pointed at a 6-well plate, a CERO 3D rotating tube or a stirred tank, and a finished protocol can be laid out in any of them afterwards. A concentration carries between vessels and the amount per well or per tube is worked out for you (100 ng/mL in 2 mL is 200 ng); an impeller speed and a tube rotation rate do not carry in either direction, and no conversion is offered because none exists; a dissolved-oxygen setpoint is dropped for a vessel with no probe rather than printed as a number describing nothing. What the new vessel needs you to decide is listed instead of filled in, and the simulator says which of its terms stop meaning anything there.

Two runs of the same question can be compared. Ask the same thing twice and a language model does not write the same file twice, so the run list offers a comparison: the inputs that differed first (model, objective, effort, datasets — each explains anything that follows), then lever by lever — agreed, same direction with a different dose, pushed opposite ways, or raised by one run only. A lever one run of two found is a candidate for the round plan, not a finding. Neither run is called the better one: agreement says the pipeline is stable, not that the biology is right.

The protocol exports as a Word document or a PDF for the bench, in the order a scientist reads it: what is still undecided first, then the whole process on one page (each stage, its days, what goes into the medium, the vessel settings, what to measure), the materials with working concentrations, then each stage as lines to tick off with every dose in bold and the letter that says what stands behind it, the settings an operator enters, the round one row per vessel, and — after the procedure — the reasoning, the letters and an approval block for a named person to sign. "PROPOSED — NOT APPROVED" is on it twice. The PDF is written on the standard library like the Word file and opens the same everywhere.

The round also exports as one picture. "Round at a glance" is a single landscape page: the stages drawn to scale over the days, then one row per arm and one column per stage, each arm shown as the control plus what it changes — a change shaded, a gap shaded red with "decide before the round" — with the vessel, working volume and arms × replicates = vessels above it. It is never read as approved.

Literature and bioinformatics export from their own sections. Each section has PDF and Word links. The literature document lists every paper once with who found it and whether it was read in full, the evidence the hypotheses rest on, and the notes as the agent read. The bioinformatics document pairs each analysis plan with its result and interpretation, and lists the datasets analysed, the datasets found from the papers and the genes looked up. Both are built from the run's files, so they work after a restart, and a file that does not parse is named, not mended.

The orchestrator also designs past the apparatus. Round 1 is designed for the vessel you have. Once it is written, the orchestrator writes one more thing: the experiment it would run if the apparatus were not the limit — a staged harvest, a coated carrier, perfusion, a co-culture, a sensor the vessel lacks — the one that gets closest to your aim. Each constraint it lifts says what it is now, what it becomes and why it stands between the process and the aim. Only the apparatus is lifted: the aim, the QC limits and any safety bound are kept by BioSense whatever the draft says. Every quantity keeps its provenance, the round-1 process in the new apparatus is the control, and the expected outcome is a judgement range. It is shown under "Beyond the apparatus", exports as Word or PDF, can be asked for again from the Ask box ("Design past the apparatus"), and is never runnable here or approved.

The run page can be laid out as a canvas. "Arrange as a canvas" frees every box from the reading order: drag one by its title, widen it from either side, heighten it from the bottom. Any single box can also be detached into a floating window and docked back. Closing a box leaves it as a translucent title strip, and clicking the title brings it back. The arrangement is remembered in your browser for every run, "Reset layout" starts it again, and "Back to the page layout" returns to the reading order. A phone keeps the reading order.

You can change the bench copy in the same conversation. "Change the protocol document" tells the orchestrator what you want in the copy you take to the bench — the vessel it is laid out for and its working volume, a value of your own, a note in your words, a section left out — and it writes exactly one file (protocol_edits), which every export then carries. A value is checked like any design choice (a parameter the project has, in its unit, inside the project's bounds, with a rationale and what it was reasoned from) and is marked D with your name; a note is marked P as your own instruction; nothing is converted silently and nothing becomes evidence. The run's own protocol, hypotheses and round 1 are untouched, and the same edits can be given directly on the run page without an orchestrator.

Full design, including what happens on a backend restart → docs/PRODUCT_STATE.md

Hypotheses: four claim levels

BioSense proposes hypotheses and designs the experiments that settle them, so it does not require proof before it may propose one. A missing dataset, a refused analysis or an absent simulator lowers the claim and the confidence; it does not produce silence.

Level	Needs	Example
CANDIDATE	a plausible relationship, evidence that may be indirect	"Increasing G-CSF during granulocytic commitment may increase neutrophil output. Magnitude: NOT ESTABLISHED."
QUANTIFIED	a magnitude from measurement or derivation	"50 → 100 ng/mL is estimated to increase output by ~20%."
SIMULATED	a model with a term for that parameter	labelled SIMULATED, never a measurement
ADOPTABLE	the full protocol gates	a named human approver, registered parameter, provenance

A candidate is a real output, not a failed quantified one — and it can never change a protocol. When nothing can responsibly be proposed, the reason is the output rather than an empty panel → docs/HYPOTHESIS_POLICY.md

Accounts

BioSense accounts keep each scientist's projects, private datasets, discovery runs and reports separate. A run belongs to the account that started it and to the project it was run against; another account asking for it by id gets a 404, not a copy. Not signed in, on a hosted instance, your browser still gets a workspace of its own — it just has no name and does not follow you to another machine.

Sign-in is an Omnigent account: BioSense forwards your credentials to the configured accounts server once, keeps only the session it returns, server-side, and stores no password of its own.

Hosted Real AI currently runs on BioSense-managed demo access — this deployment's own model credentials, under the caps above. A later version may let you connect your own model-provider credentials; that is planned and not implemented, and nothing in the interface asks you for a key.

Operators of a deployment can be given an ADMIN role, which skips the demo caps and nothing else — not the run timeout, not the one-at-a-time gate, and not anybody else's data. How to designate one: docs/ACCOUNTS.md.

Run it yourself, if you need one of these

You want	Why the hosted app cannot give it to you
Real AI with no caps, on your own key	the hosted instance pays for its own runs, so it limits them
Your own private data analysed	a private dataset never leaves the machine that ingested it, by design
To develop or evaluate the code	—

Two commands, and the second one is optional:

git clone https://github.com/AbhinavSoni20191995/Biosense.git
cd Biosense
./scripts/start_local_ai.sh          # real AI: installs, starts and verifies everything
./scripts/check_local_ai.sh          # "READY", or the one thing to fix

start_local_ai.sh installs the Omnigent extra into the project, starts a loopback Omnigent server with the agent registered, registers your machine as an executor, asks BioSense itself whether a session could run, and only then opens the app on http://127.0.0.1:8000. If any step fails it stops with the reason and the fix — it never starts BioSense in a state where the button quietly produces a demonstration instead.

It needs model credentials in the shell you run it from (export ANTHROPIC_API_KEY=sk-..., or claude auth login on a subscription). Without them it still starts, and tells you that the key is the missing part.

For the synthetic path alone, nothing but uv is needed:

uv sync --locked
uv run --frozen python -m biosense.production.app --runs runs --static webapp

Using it

1. Pick or create a project — it decides which parameters exist, what their bounds are, and whether anything can predict them.
2. State your objective in your own words.
3. Optionally add research context, your datasets, the values you want tested, and your process constraints.
4. Choose a runtime — real AI, or the synthetic demonstration.
5. Press Run AI discovery.

You then watch it work, and read the evidence, the analyses, the quantified hypothesis, the candidate parameters, the recommended protocol and the benchmark — all in the page. Reload the tab and the run comes back: a run journals itself beside its artifacts, so a refresh, a lost network or a redeploy does not lose one. A run that was stopped mid-flight says so; it is never shown as finished.

Hosting your own

One Railway service, one Dockerfile, one secret:

# deploy/Dockerfile.ai — BioSense + Omnigent server + executor, one container
ANTHROPIC_API_KEY=sk-...             # the only secret
# mount the volume at /app/runs, not /data/runs

GET /readyz then answers, without exposing anything: is the runtime reachable, is the agent registered, is there an executor, does it have model credentials. Full instructions, the environment variables and the reasoning: deploy/README.md.

Real AI needs a host that lets the agents' sandbox start. Railway does not (its containers refuse user namespaces), so real runs are refused there with the reason. One command puts the same image on a small VM with HTTPS and auto-redeploy: deploy/vm/README.md.

Running it on your own machine, remote Omnigent servers, signing in, Windows → docs/RUN_ON_YOUR_PC.md

What was built for the hosted service, what was verified by running it, and what was explicitly not verified → docs/PHASE3_DELIVERABLES.md

Supplementary

Where the repository stands against the long-term goal. The specialist agents exist, live model-driven discovery runs work end to end, the data analyst plans and executes real analyses over public and private datasets, and runs learn across each other through the shared cell production library and process reference. The largest part of the goal is not reached: the loop runs against a synthetic stand-in, not a real bioreactor, and no loop has closed on real cells with a result-dependent decision. Everything below describes what runs today, and What this is not sets out the limits in full.

These are different claims about the same question, and BioSense never substitutes one for the other. The runtime badge is on screen the whole time.

The badge reads SYNTHETIC DEMO, REAL AI — ONLINE (the hosted service runs the runtime itself) or REAL AI — LOCAL (your own machine). The middle one is the same runtime as the last: local in a browser would mean your computer, which it is not.

	SYNTHETIC DEMO	REAL AI
Who does the work	deterministic code over committed fixtures	the discovery agents, through Omnigent
Literature search	a committed fixture index	real, against Europe PMC
Data analysis	real statistics over fixture tables	real statistics over your datasets
Needs credentials	no	yes — a model provider, via Omnigent
Costs money	no	yes
The bioreactor	a synthetic stand-in	still a synthetic stand-in

That last row is the one to read twice. With real AI, the evidence, the analysis and the hypothesis are real work over real data. The reactor is not: BioSense touches no actuator, and a prediction for a new project comes from one of three things, each labelled wherever it appears — the single calibrated stand-in model (MODELLED), a response the agents proposed from cited claims (DE NOVO, uncalibrated), or one you declared from experience (EXPERT-DECLARED, a design choice). Real measurements enter only when a person runs the experiment and brings the results back.

How the simulator turns a setpoint into an output, term by term → docs/BIOSIMULATOR_MODEL.md

There is also a Quick loop tab: type a question in plain language and watch the deterministic stand-in loop run it in about a second and a half, with the agents announcing each step. It is the fastest way to see the shape of the thing and it calls no model at all.

BioSense has no universal control panel, and the Quick start's project is an example, not the product.

Every stirred-tank process shares the vessel — impeller, dissolved oxygen, feed schedule, seeding density, temperature, stage length. Those are offered to every new project with the canonical registry's own bounds and meanings.

Nothing else is shared. You add the parameters your biology actually has, and each arrives with a declared relationship to the simulator:

	What it means
Design variable only	real, usable in the lab, and not predicted. The honest default.
AI-proposed response	the agents propose how it behaves from cited claims. It predicts, and every number says DE NOVO · UNCALIBRATED.
You describe it	you supply the shape and the constants. Private expert knowledge: it predicts, and any value resting on it is a design choice, never a cited one.

MODELLED cannot be chosen from a form at all. That claim belongs to a fitted model, and no dropdown can confer it.

Projects you create are stored in your workspace under the private data root — never written into this repository, never served as files. Sign in through your own Omnigent account and they belong to you; without a server configured there is one local workspace, private because the machine is, and the interface says so in those words rather than implying more.

A benchmark records whether BioSense did its job — identified an uncertainty, planned an analysis, executed it deterministically, quantified what it could, checked simulator coverage and labelled every number. It does not measure biological truth, and a run can pass every row while being biologically wrong.

You can read the built ones and re-run a published configuration from the browser, under either runtime, without cloning anything. A benchmark built from a finished run is assembled from the artifacts that run already produced — the biology is not run again — and one whose lineage touches private data is marked PRIVATE — DO NOT PUBLISH and refused a public export rather than anonymised.

The benchmark CLI stays exactly as it is, for CI and automation.

The console shows the answer. The exported report carries the justification:

• every decision — its reasoning, the alternatives the envelope refused and why each was refused, the hypotheses raised and the basis for each;
• every search move — what it changed, for which arm, what happened, and whether it survived or was reverted;
• every quantity in the protocol with its provenance, so the line between a cited value and a chosen one is visible at a glance;
• references with DOIs, what each was used for, and whether its full text was ever actually retrieved.

A decision made by deterministic code is labelled as such. The report never presents a rule as a model's reasoning.

Not conventions — things the software refuses to do:

Rule	Where
A wet-lab run always needs a named human approver, whatever the autonomy mode says	production/autonomy.py
The web app refuses any request that is not a synthetic stand-in	production/engine.py
Agents never read the stand-in's hidden answers; no server ever serves a file named truth	production/serve.py, report.py
A gap in a protocol blocks the wet lab	production/protocol.py
Targets and QC limits can never be changed after results are seen	production/orchestrator.py
An unannotated gene returns found: false with the public queries to run — never a guessed effect	bioinformatics/tools.py
An analysis that names no uncertainty cannot be planned	bioinformatics/plan.py
A missing experimental-design field refuses the analysis and names the field	data/manifest.py
Private data is identified by where it is, not what it is called, and no server may be rooted inside it	data/roots.py
A dataset can never become a literature citation	the claim schema needs a source, paragraph and quote
An external-tool result with no software version is refused	bioinformatics/external.py
A parameter name that is not canonical is refused, never fuzzy-matched	parameters.py
A project cannot widen a canonical bound, and a narrowed one names its origin	projects.py
A simulated effect on a parameter the model does not cover is refused	evidence/hypothesis.py
Plain-language prose is rejected if a number in it is in no structured fact	evidence/narrative.py
Expert knowledge can never become a citation or set a protocol value	evidence/expert.py
A public benchmark export refuses when private lineage exists, rather than anonymising	benchmark/privacy.py

uv run --frozen python -m unittest     # 1694 tests
bash scripts/check.sh                  # + offline loop smoke tests + agent-spec validation
uv run --frozen python -m biosense.production.selfcheck          # a prompt's whole chain, no model
uv run --frozen python -m biosense.production.selfcheck --live   # + a real agent round trip

The system check runs every link a real run depends on, the way the agents run it — inside their OS sandbox when it can start — and says which one breaks: the sandbox, the agent bundle, every command the brief names, the bioinformatics tools on a SYNTHETIC fixture, the simulator, the hypothesis and context builders (biosense.evidence.cli), the protocol, and the stand-in bioreactor loop. It runs in CI and at every hosted boot; operators can run it, including --live, from the Runs page.

Path	What it holds
webapp/console.html	the console you see above
webapp/simulator.html	simulator mode: the knobs, the vessel, the timeline
biosense/production/	the loop: designer, optimiser, analysis, envelope, reports
standins/	synthetic stand-in reactors
discovery_loop/	the Omnigent agent bundle for the live, model-driven path
biosense/production/runtime.py	which runtime answers, and why one cannot
biosense/production/health.py	/readyz: the four-part readiness truth, with no secrets
biosense/production/budget.py	what a visitor may spend on real AI
biosense/production/authz.py	the three roles, and the one place any of them is decided

Deeper reading: the production loop · simulator mode · bioinformatics, data and evidence · benchmarks and demonstrations · the worked example · running it yourself · the literature agent · bioinformatics knowledge sets · max-mode instruments · hosting · Omnigent setup

---

What this is not

An evaluator should know the limits before the features.

• The bioreactor is a synthetic stand-in. It is a phenomenological model, not a digital twin. No number this produces is a measurement of any real cell.
• The stand-in was built to reward the levers the annotations suggest. That is what makes the demonstration legible, and exactly what makes it worthless as biology. A real experiment could reward the opposite.
• No protocol value is attributed to a publication. The citations support the direction of a lever; every number is a design choice. The reports show that count rather than hiding it.
• The cited BACH2 work is in peripheral and engineered T cells, not iPSC-derived ones. The knowledge set separates what a paper reports (local_annotation) from a transfer to this cell type (inference).
• One replicate per arm. Every between-arm difference is directional only.
• A loop that reaches a target has not produced a validated process. Confirmation runs, replicate design and human QA sign-off are all outside it.
• The reactor stays a stand-in even with real AI on. Real AI makes the evidence, the analysis and the hypothesis real work over real data. It does not make the bioreactor real: nothing here actuates anything, and a prediction for a new process comes from the one calibrated stand-in model, a response the agents proposed, or one you declared — each labelled, none of them a measurement.
• A proposed response is not a fitted one. A DE NOVO or EXPERT-DECLARED term predicts because deterministic code evaluates a shape somebody chose with constants somebody supplied. Nothing was fitted to data, the effect it may have is bounded in the contract and clamped again in code, and every number it touches carries the calibrated value it started from.
• Live AI runs work; the loop has not closed on a real bioreactor. Live discovery runs — literature, bioinformatics, data analysis, hypothesis and a recommended protocol — have run end to end on the hosted service. A loop that runs a real bioreactor and makes a result-dependent decision has not, and nothing here claims it has.
• The committed dataset fixtures are invented. Every committed example table is synthetic and every fixture accession begins with SYNTHETIC-GSE. A run can now fetch a real public GEO series (any species) and register it as a public dataset; no result from one is committed here.
• The live GEO fetch is unverified from this repository. Outbound access to NCBI is blocked in the environment it was developed in, so the fetch is tested against recorded response shapes; its first contact with the real service is a hosted run. A failure there is reported, never filled in.