Method
A method the products are held to.
Confidence should come from a process you can inspect, not from adjectives on a website. This page sets out how a research effort becomes a product, what leaves each stage, and the standards applied whether the work is firmware or a distributed platform.
The five stages
Every effort, same shape
Scaled to the size of the work — a short study compresses these into days, a product gives each its own phase — but never skipped. A stage closes only when its output exists.
Frame
Establish what is actually being solved before anyone writes code.
We separate the requirement from the proposed solution, identify the constraints that are genuinely fixed from the ones that are merely habitual, and name the risks that could invalidate the whole approach. Projects rarely fail in the build; they fail here, and find out in the build.
Leaves this stage
- Problem statement and success criteria
- Constraint register — technical, regulatory, commercial
- Risk list with the mitigations that matter
- A go / no-go recommendation, including "do not build this"
Design
Make the expensive decisions deliberately, and write down why.
Boundaries, contracts, data ownership, failure modes and capacity. Every significant choice becomes an Architecture Decision Record capturing the options considered and the consequences accepted — so in two years the reasoning is on paper rather than in somebody’s memory.
Leaves this stage
- Architecture description (C4 or equivalent)
- Interface and contract definitions
- Architecture Decision Records
- Capacity model and performance budget
- Threat model and security review
Build
Working software at every step, never an integration cliff at the end.
Small reviewable increments behind automated verification. Trunk-based development with short-lived branches, CI that runs the full gate on every change, and a deployable artefact from day one. A running increment exists continuously, not a reveal at the end.
Leaves this stage
- Reviewed, tested, documented source
- CI pipeline with the full quality gate
- Reproducible builds and signed artefacts
- Demonstrable increments on a fixed cadence
Harden
Break it while breaking it is still cheap.
Load and soak testing to the design ceiling, deliberate fault injection, power-loss and failover testing where relevant, security review and dependency audit. The goal is to find the failure modes in a test rig rather than in an incident channel.
Leaves this stage
- Performance characterisation with methodology
- Fault injection and failover results
- Security review findings and remediation
- Known limitations, stated plainly
Ship
Put it into service, and keep running it.
Documentation aimed at the person on call, runbooks for the failure modes we know about, and telemetry already in place. We are that person. A product we cannot operate ourselves is not finished, regardless of whether the software builds.
Leaves this stage
- Operations and architecture documentation
- Runbooks and incident playbooks
- Dashboards, SLOs and alerting
- A stated operating envelope, including what is not proven
Engineering standards
The bar, regardless of the project
These are not aspirations. They are the conditions under which a change is allowed to ship, on a one-week experiment and on a product that is already in service.
Code review is not optional
Every change is reviewed against a defined bar before it merges: correctness, failure handling, test coverage of the new path, and whether the next person to touch it can understand it.
Tests that test the risky part
Unit tests for logic, contract tests at every boundary, property-based tests for state machines and protocol code, and integration tests against real dependencies where a mock would hide the actual failure. Coverage percentage is a diagnostic, never a target.
Security is a design input
Threat modelling during design rather than a scan before release. Dependencies pinned and audited, secrets never in source, least privilege by default, and an SBOM produced at build time so we know what a product is actually running.
Documentation that stays true
Documentation lives with the code and changes in the same pull request. Decision records are immutable — superseded rather than edited — so the history of the design remains readable.
Honest status
If something is late, blocked, or less proven than it looks, the product page says so. A maturity line that flatters the work is a defect, not a marketing choice.
We own what we ship
Source, infrastructure, documentation and the operating burden stay with the company. A product is not finished by handing it to someone else.
Contact
Read it against a real product.
The method is only meaningful next to something it produced. The products and the research designs are published with their current limits stated.