Seven practices, one engineering team. We design, build, benchmark and operate the compute layer beneath your hardest problems — on-premise, hybrid or sovereign cloud.
A genomics pipeline and a trading engine are not the same machine. We start from your regulatory perimeter, your data gravity and your deadlines — then design backwards.
Industries · Health Tech & Life Sciences
Throughput under privacy law is the constraint we design around first. Genomics, diagnostic AI and imaging research only become useful at cohort scale, and cohort scale is exactly where consent, ethics approval and the Privacy Act bite hardest. The architecture has to satisfy both requirements, and produce evidence that it did.
The constraint we design around first
Statistical power comes from pooling records. Legal risk comes from the same act. Most health platforms resolve that tension late, in policy documents, after the build. We resolve it early, in the topology, where it is still cheap to change.
The conflict is rarely abstract. It appears as a specific engineering decision: whether a cohort can be assembled in one filesystem, whether a GPU node may mount identifiable imaging, whether a researcher's notebook can reach the internet. Each of those is answerable in advance, and each answer changes the design.
None of this is a reason to run slow infrastructure. Containment and throughput only conflict when containment is added afterwards as a set of prohibitions. Designed in, it mostly changes where the compute sits.
Genomics & secondary analysis
Teams arrive asking for more cores. We profile the run first, and in most cases the accelerators and CPUs are already idle for long stretches while the storage layer answers millions of small metadata operations.
01
Every task in a large fan-out wants the same reference genome, the same indices and the same annotation databases. Read those from shared storage a thousand times concurrently and the run becomes a metadata benchmark. We stage read-only reference sets onto node-local NVMe, or pin them in a cache tier, and the fan-out stops contending with itself.
02
Bioinformatics workflows generate enormous numbers of small files: per-sample logs, per-interval shards, work directories, symlink trees. Aggregate bandwidth is irrelevant to that pattern. Metadata operations per second, and how the file system distributes them, decide the wall-clock time. We size metadata capability explicitly rather than inferring it from a throughput figure.
03
Nextflow, Cromwell and other WDL or CWL engines are good at describing a pipeline and indifferent to how the cluster behaves. We tune the executor layer — Slurm partitions, array job sizing, Kubernetes pod density, retry-on-preemption — so a run degrades gracefully rather than collapsing when one queue fills.
04
Secondary analysis produces intermediates several times larger than the inputs. Keeping them all on the fastest tier is how a storage budget disappears. Keeping none of them means re-running a fortnight of compute to answer a reviewer. We set a retention policy per artefact class and let tiering enforce it.
05
Container digests, workflow revision, reference build, parameter set and input checksums are captured per run and stored with the outputs, not in a researcher's notebook. This is the difference between a result you can defend and a result you can only repeat by memory.
| Pipeline stage | Dominant IO pattern | What we tune |
|---|---|---|
| Instrument transfer and basecalling | Large sequential writes, bursty, tied to instrument run completion | Landing tier sized to a full flow cell, checksum-on-write, transfer window scheduling |
| Alignment | Streaming reads of FASTQ, heavy random reads of reference indices, high thread count | Reference staged local or cached, thread-to-core pinning, memory bandwidth headroom |
| Sort and duplicate marking | Large temporary spill, read-modify-write, highly sensitive to scratch latency | Node-local NVMe scratch, spill directory placement, merge fan-in width |
| Variant calling | Thousands of interval shards, small files, metadata dominated | Shard granularity, metadata capability, array job batching, output aggregation |
| Joint genotyping and cohort merge | Wide fan-in, memory pressure, long-running single tasks | Large-memory partition, checkpointing so a twelve-hour task survives a preemption |
| Annotation and interpretation | Random reads against annotation databases, repeated per variant set | Database co-location or caching, version pinning so results stay comparable |
| Archive and release | Large sequential writes, rare reads, long retention obligation | Object tier with immutability, integrity scrubbing, restore tested rather than assumed |
Medical imaging pipelines
An imaging study is thousands of individually addressed objects with metadata attached to each one. That format is excellent for clinical interchange and awkward for the sequential, high-bandwidth reads a training job wants.
The clinical archive belongs to the health service and stays where it is. We build alongside it: a read path that pulls studies on approval, a de-identification stage that strips and audits the header fields, and a research-side object layout shaped for the workload rather than for interchange.
Imaging volume rises with modality upgrades, not with patient numbers. One replacement CT with thinner slices can outweigh a decade of caseload growth. We model capacity against the modality roadmap and the retention obligation, then size a tier that can absorb a step change without a forklift.
Diagnostic AI workloads
We build and operate the training and inference infrastructure. The clinical claim, the validation study and the regulatory pathway stay with the sponsor. This page describes how we support that work, and stops short of asserting anything about its outcome.
Cohort assembly happens inside the enclave, under the approval that authorised it. Training containers run without outbound network access, so weights and samples cannot leave by accident. Access to the identifiable layer is separate, time-limited and logged.
Constraint — consent scope and approval duration
Where data cannot be pooled, training can sometimes move instead. We deploy the compute node at each participating site and coordinate rounds centrally. It is slower than a pooled data set, sensitive to site heterogeneity, and it does not remove privacy risk on its own — gradients can leak. It is a tool, not an exemption.
Constraint — network between sites, and site heterogeneity
Infrastructure decides whether a validation study is reproducible. We version the data set, the container, the random seeds and the hardware configuration together, and hold a frozen hold-out set the training environment cannot read. Inference inputs are monitored for distribution shift after deployment.
Constraint — reproducibility across hardware generations
Software intended for a diagnostic or therapeutic purpose may fall within Australia's medical device framework, administered by the Therapeutic Goods Administration. Classification, clinical evidence and post-market obligations are the sponsor's responsibility. Our part is a platform that can produce the technical records those obligations rely on.
Constraint — evidence you can retrieve years later
Privacy & governance
Strip the direct identifiers and a record can often still be narrowed to one person by combining rare attributes. Postcode, date of birth and an unusual diagnosis are frequently enough. Architecture should assume that, rather than treat the de-identified set as public.
We are engineers, not your privacy counsel, and the summaries below are orientation rather than advice. What matters technically is that each obligation maps to a mechanism in the platform, and that a reviewer can be shown the mechanism.
We will put our own assurance position in writing for a tender, with reference details you can check with the issuing bodies. We will not put a compliance badge on a web page and hope nobody asks.
If the only thing standing between a cohort and a USB drive is a policy document, the control does not exist.
How an engagement runs
The most common failure we are called in to fix is a platform that received sensitive data before its controls were finished. The order of these steps is not a formality.
Start from the analysis, not the available data. Fields that the question does not need are not collected, which reduces both risk and the volume that has to be secured, moved and retained.
We take a de-identified sample and measure where the time goes — metadata operations, scratch latency, task fan-out, accelerator idle periods. Sizing without this step is a guess dressed as a quotation.
Who approves access, who reviews egress, how long approvals last, what happens when a researcher leaves. These answers become configuration, so they need to exist before the platform is built rather than after.
Access control, logging, key separation, egress review and backup are proven against synthetic data. We attempt to exfiltrate from inside, and record what the controls caught. Only then does real data arrive.
Linkage keys and payload land in separate stores with separate administrators. Re-identification requires two independent approvals, and the attempt is logged whether or not it succeeds.
Researchers work inside the enclave with the tools they already use. Outputs leave through a review step sized to the risk — automated checks for small cell counts, human sign-off for anything novel.
Approvals expire and projects end. Retention and destruction are executed on schedule and evidenced, including copies in backups and snapshots. An undocumented copy in a snapshot is the most common way a closed project stays open.
Reliability & operations
The same organisation usually runs both. We separate them deliberately, because a research cluster that shares a failure domain with anything clinically adjacent inherits the strictest change control in the building.
Availability targets tighten, maintenance windows shrink to the hours a department is closed, and every change needs a rollback that has been rehearsed. Degraded behaviour has to be specified in advance, because in a clinical setting an ambiguous failure is worse than a clear outage.
99.98%
Trailing twelve months on managed health platforms, excluding agreed maintenance windows.
15min
Imaging archive replication lag target, verified by scheduled restore tests.
11min
Priority-one incidents, measured from alert to a named engineer responding.
4per yr
Full recovery of a production study set, timed, with the result reported to the client.
Questions we get asked
Short answers, including the ones that are less convenient for us. If a question here is answered with a qualification, the qualification is the point.
Often, yes. The legal position turns on whether an individual is reasonably identifiable from the data, in context, including what else is available to the holder. That is a judgement for your privacy officer and counsel. Our engineering default is to treat a de-identified derivation as sensitive until a named custodian records a different decision, with the reasoning attached.
Sometimes, and residency is only part of the question. The harder questions are who holds administrative access, which foreign legal processes could compel disclosure, and whether the support model puts data in front of offshore staff. We will map those for a specific service and region and give you the answer in writing, including where we think the residual risk sits.
No. Sponsorship, clinical evidence and post-market obligations belong to the organisation making the clinical claim. What we can do is build a platform that produces the technical records those obligations depend on — versioned data sets, reproducible training runs, immutable audit trails and retrievable artefacts years later. Any vendor offering more than that in an infrastructure contract is worth a second look.
Possibly not. In genomics work the accelerators and CPUs are frequently waiting on storage metadata rather than saturated. In imaging the limit is often the conversion from study-shaped objects to training-shaped batches. We profile before we quote, and we have told clients to buy nothing more than once. If the profile does show a compute ceiling, you get the evidence for the business case.
No. Federated training changes what moves between sites; it does not change that patient data is being used for research. Approvals are still required at each participating site, and the shared updates themselves can leak information about individuals. It is a useful technique where pooling is impossible, with real costs in convergence speed and operational complexity.
A representative workload we can run, ideally on synthetic or already de-identified data. The cohort size you are planning for, the retention obligation, the modality mix if imaging is involved, and the approvals that govern the data. From that we return a profiled bottleneck analysis, a sizing with its assumptions exposed, and an honest view on whether we are the right team.
Let's Talk
A representative run on synthetic or de-identified data is enough to start. You get a bottleneck analysis, a sizing with its assumptions written down, and a straight answer about whether more hardware is the right purchase.
Australian owned and staffed. We will sign a confidentiality agreement before you describe a data set.