Use cases

Five shapes of work this API is built for. Each names who it is for, the problem it addresses, what we actually do about it, and what a pilot would look like.

A note on scope that applies to all five: we do not claim measurement accuracy. What we provide is an independent, recomputable second opinion on data you already hold. Read the verified-facts page before evaluating any of these.

1. Reproducibility as the deliverable

Who: research groups running off-axis or lensless digital holographic microscopy who reconstruct with their own script or an open-source package.

The problem: the script works — often you wrote it. What it cannot give you is a record a third party can independently recompute. A reviewer asks whether a result is reproducible; a collaborator asks whether you ran the same configuration as last spring; a funder asks for a data-management artifact. Today the answer is a folder and a promise.

What we do: every reconstruction returns a report whose identity is a hash of its own content. The same input and configuration produce the same report ID. We commit to your input and your configuration by SHA-256 without publishing either — you can prove configuration identity by rehashing, and your parameters stay yours.

A pilot looks like: a set of your frames reconstructed through the API, with the report IDs and commitments as the deliverable you attach to a paper or a data-management plan.

2. An escape hatch from a closed file format

Who: labs running a commercial instrument whose data lands in a proprietary binary format, readable only by the software that wrote it.

The problem: your measurement is locked inside a format you do not control. Proving what you measured depends on the vendor's software agreeing with you.

What we do: accept the hologram and return an independent reconstruction with a report that commits to the input by hash. What you measured becomes provable without depending on any single vendor's software to attest it.

A pilot looks like: a batch of exported frames run alongside your existing output, so you have two independent reconstructions of the same input and a committed record of both.

3. Inter-laboratory comparison

Who: metrology groups coordinating instrument-comparison studies across sites.

The problem: each participant runs their own instrument and their own processing, and the coordinator then has to establish whether the results are comparable at all. The organisational difficulty is reproducibility across sites. Published comparisons operate at real scale — one 2025 study in Surface Topography: Metrology and Properties circulated material measures across 15 laboratories in 9 European countries, covering 658 areal measurements over 120 measurement configurations (DOI 10.1088/2051-672X/addff0).

What we do: every participant issues the same call, and the coordinator verifies they ran the same thing by rehashing — rather than by trusting a methods section. Determinism is the whole product here, not a supporting feature: pinned seeds and numerical-library threading, plus a content-addressed report.

A pilot looks like: one circulated sample, every participating site submitting through the same endpoint, and a coordinator-side check that the configurations match by hash.

4. Batch workloads

Who: groups reconstructing large numbers of frames in bulk — for example microfluidics work imaging flowing cells.

The problem: volume and consistency, rather than surface height. You need many frames processed the same way, and you need to be able to show they were processed the same way.

What we do: a batch-oriented HTTP surface where every result carries its own provenance record. Over the size ceiling the API returns a predictable HTTP 507 with an estimate attached, rather than failing partway through — for a batch caller, a refusal you can plan around is worth more than an optimistic attempt.

A pilot looks like: a representative slice of your frame set run end to end, measuring consistency across the batch and establishing the throughput figure we decline to quote in advance.

On throughput: we do not publish a rate, because we have not committed a benchmark at a stated field size on stated hardware. If throughput is your deciding criterion, that benchmark is the pilot's first deliverable.

5. Verification between service visits

Who: quality and metrology teams running an optical profiler or interferometer outside its warranty window.

The problem: confidence in an instrument drifts between service visits, and the interval between them is long.

What we do: provide a second, independent measurement point on data you already capture — beside your instrument, not instead of it. We are not a replacement for the measurement your quality process depends on, and our own report says so in writing.

A pilot looks like: periodic reconstruction of a stable reference target alongside your instrument's own output, building a recomputable record over time.

We publish no cost comparison for this use case. Figures circulating in this market come from interested parties, and we have not sourced them ourselves.

For agent and tool builders

Not a use case so much as an open surface. /llms.txt, /llms-full.txt and /SKILL.md provide keyless self-onboarding for automated callers, and the public endpoint needs no account. If you are building tooling against this API, those three files are the fastest way in and you do not need to talk to us first.