BisQue Ultra 2026.07

BisQue Ultra 2026.07 is a scientific AI workbench for the full path from complex data to reviewable result. It opens scientific files, keeps multidimensional viewers close to the source, routes language into tools and models, persists long-running work, and preserves the figures, tables, metrics, reports, and run events that explain what happened.

The release also adds a missing part of the scientific AI lifecycle: model change is now visible. Teams can freeze a gold set, retrain a model, watch progress, benchmark the candidate, reject regressions, route a canary, promote an active version, and roll back. A new checkpoint is not treated as an improvement until the declared evidence says it is.

This is the product direction in one sentence: BisQue Ultra connects scientific data, model-guided computation, and operational evidence in one durable workbench.

What changed in 2026.07

Earlier versions of Ultra established the durable run contract: a React workbench, Go control plane, Postgres state, NATS JetStream dispatch, Deep Agents workers, BisQue resources, and a replaceable model endpoint.

The current release turns that foundation into a broader scientific product.

Scientific data is a first-class object

Scientific AI fails early when the system treats every input as a flat attachment. A CZI acquisition, NIfTI volume, DICOM series, HDF5 hierarchy, large mosaic, or time-lapse stack carries dimensions, units, channels, metadata, and viewing requirements that affect every downstream interpretation.

BisQue Ultra now launches a dedicated image service and conversion worker as part of the local stack. The service uses libbioimage to decode more than 90 scientific formats and serves bounded representations that the browser can inspect: tiles, planes, histograms, scalar slices, volume manifests, and video posters. Large uploads can become tiled pyramids without blocking the main control plane.

The Resources surface gives that engine an operational home. Files can be searched, filtered, previewed, organized, shared, restored, grouped, or sent into analysis without leaving the workbench.

The viewer layer follows the same principle. Large images use deep zoom. Stacks support z-scrub and plane inspection. Scalar volumes expose windowing and physical units, including Hounsfield Unit workflows where that metadata exists. HDF5 resources can be inspected as structure before a dataset is rendered. Three-dimensional views include transfer functions, lighting, axes, scale cues, and stable camera presets.

The point is not to accumulate viewer features. It is to preserve enough of the scientific object that the model, researcher, and report refer to the same data.

A run is more than a response

Ultra’s control plane treats threads, messages, runs, events, artifacts, idempotency keys, worker heartbeats, and leases as durable API objects. Postgres owns the system of record. NATS JetStream carries jobs, events, and cancellation. Workers can scale as queue-group consumers while the browser reconnects to the same run.

That separation matters because real analysis is not a single request and response. It can include file staging, inspection, tool selection, code execution, model calls, generated figures, report writing, and review. Browsers refresh. Workers restart. Services move. A useful workbench keeps the scientific record intact through those ordinary failures.

The frontend reflects that contract. Past conversations hydrate with their artifacts. Streaming work remains tied to a run. Scientific results can include reports, figures, tables, CSVs, XML, JSON, source files, masks, and metrics. The user can return later and inspect the product of the work rather than a summary of it.

Model change becomes visible

The Training surface is the clearest expression of the 2026.07 release. It treats a model version as a scientific and operational object with inputs, evaluation evidence, serving state, and history.

The workflow is deliberate:

1. Sync new reviewed examples.
2. Freeze an immutable gold set.
3. Dispatch a durable retraining job to the configured compute service.
4. Follow live epoch and metric progress.
5. Benchmark the candidate against the active model.
6. Evaluate per-class floors, regression tolerances, held-out slices, and other declared gates.
7. Reject the candidate, route it as a canary, or promote it.
8. Roll back to a prior active version when required.

The serving resolver reads the active version and can route a deterministic canary fraction by run identity. The UI exposes candidate, canary, active, retired, and rejected states. This makes a critical boundary visible: training can produce weights, but only evaluation and an explicit promotion action can change what the system serves.

The model endpoint remains replaceable

BisQue Ultra uses an OpenAI-compatible worker contract. A deployment can point at Ollama for a simple local setup, vLLM for higher-throughput open-weight serving, or another compatible endpoint without rebuilding the orchestration around one provider.

This is not only a convenience feature. Scientific infrastructure outlives individual model releases. The stable product contract should be the data, tools, runs, artifacts, and evaluation logic. The model can improve or change while the research record remains legible.

Evidence-aware materials research

The current runtime includes bounded materials research capabilities across microstructure, EBSD and DREAM.3D data, structure and thermodynamics, CALPHAD, processing kinetics, crystal plasticity, degradation, advanced characterization, and selected sensor-series inspection.

Those capabilities are deliberately narrower than a claim of autonomous materials engineering. Typed tools expose qualified operations; deterministic validation records bind inputs and outputs; unsupported simulation paths fail closed instead of substituting a toy solver. Provenance, content hashes, evidence ledgers, and release gates are part of the design.

That boundary is a feature of the release, not a footnote. Scientific AI should make uncertainty, evidence, and authority visible before it makes a larger claim.

Run the stack locally

The public repository includes a Docker Compose path for the complete local system. The first build compiles the native imaging engine; later starts reuse the built images.

ollama serve
ollama pull gpt-oss:20b
docker compose up --build

The stack launches Postgres, NATS JetStream, the image service and conversion worker, the Go control plane, a Deep Agents worker, and the frontend. It can run without a cloud account. An existing BisQue deployment is optional and can be connected when shared image, dataset, metadata, and module services are needed.

Model weights and specialized scientific checkpoints are operator-provisioned. They are not silently bundled into the repository. That keeps the software boundary clear and lets each deployment decide which domain services it is qualified to expose.

What we are opening next

We are looking for research teams with workflows that are hard to hold together: complex scientific files, domain models, long-running computation, evidence requirements, or an existing BisQue deployment that needs a modern AI workbench.

The best early collaborations are concrete. Bring a dataset, an instrument format, a model lifecycle, a viewer requirement, or a reproducibility problem. We can evaluate where Ultra already fits, where a domain tool is needed, and what evidence the system must preserve before the result is useful.

Request BisQue Ultra research access or run the local stack on GitHub.

Built at UCSB

BisQue Ultra was created by Amil Khan, a PhD student in the UCSB Vision Research Lab. The lab is led by Professor B.S. Manjunath in the Department of Electrical and Computer Engineering.

The product carries that origin into its design: scientific data remains structured, model work remains inspectable, and the evidence needed to revisit a result remains attached.