Every test programme sits at a different stage. Some teams want a second pair of expert eyes on one critical firing; others need a platform their whole team works in every day. We meet you where you are — from a single pilot report to a deployed platform with standing engineering support — and you move between them as the programme grows.
You send the acquisition export; we return engineering reports. The descriptive layer states what happened — every channel, the phase breakdown across the ignition transient, the steady-state burn window and shutdown, the event timeline, the measured performance. The diagnostic layer explains why — ignition behaviour, combustion stability, feed coupling, propellant conditioning, and deviations against your programme's own limits.
Nothing arrives as a bare number. Each value carries its origin: the channel it was measured on, the time window it was computed over, and the assumption behind the formula. That is what makes a result defensible in a review months later.
Your team works inside the platform, on your own data. It ingests acquisition exports, computes derived parameters through a deterministic core, and keeps one engineering record per test — a record that outlives the engineer who ran it and survives a programme handover.
Campaign views, test comparison and the AI analyst come with it. Channel mapping is configured once per stand; after that a new firing becomes a finished report without manual preparation.
Our analysts work inside your test programme rather than at arm's length: instrumentation and channel review before a campaign, post-test data review with your engineers, sign-off on reports, and programme-level summaries for management, partners and funding bodies.
Where the data points to a procedural cause — conditioning, sequence timing, instrumentation gaps — we say so plainly, including when the honest answer is that the measurement cannot settle the question.
Every engagement returns documents an engineer can put in front of a review board — and the underlying interactive record behind them.
Every acquired channel visualized on a common time base, statistics per phase, the event timeline, and stand video synchronized to the data.
Derived performance, ignition classification, stability assessment, frequency-domain review, and flagged deviations with candidate causes — each stated as a hypothesis with its supporting evidence.
Performance run to run, repeatability, trends in ignition behaviour, and what changed between builds — with the effect of each change quantified where the data supports it.
Reports export to document formats for design reviews, investor and funder reporting, and long-term programme records — with the traceability preserved.
The pilot needs no integration and no change to your stand: send one past firing's acquisition export and receive a full report. If it tells you something you did not already know, we talk about the next step.
We process one past firing. No integration, no instrumentation changes — just the export your acquisition system already wrote.
Analytics through a live test series: a report after each firing, and a review between tests while the result still changes decisions.
The platform is deployed for your programme and your team works in it directly, on your own data, with your own channel schema.
Managed analytics, post-test reviews and programme-level reporting as a standing engagement alongside your engineers.
Each programme is deployed in isolation, with separate admin and engineer accounts. Organisation-level isolation arrives with Hanabi 2.0.
Your test data is never used to train models.
Data location and retention are agreed before the first upload, in writing.
Nothing is published — no logos, no numbers, no test identifiers — without your explicit approval.
One past firing's data — a full report back.