Matilda, on your GPUs
Our models, trained for your domain and delivered into your data centre. Take the weights, the serving stack, the API, or the entire product.
Take the stack as far down as you want
Each level contains the ones before it. Most teams start at the API and move down when accreditation requires it.
The machine as well, built to our blueprint
Most organisations that want a model inside the perimeter do not yet have anywhere to put it. We design, build, and validate the cluster too, on NVIDIA or AMD, to the same blueprint we run for MC-1 and MC-2.
Compute and accelerators
Nodes sized to the work, training tier separate from serving.
Network fabric
Switching, RoCE, and NICs configured from version control.
Storage
Shared filesystem and S3-compatible object storage for weights and checkpoints.
Bare-metal provisioning
A racked node provisions itself from inventory, not installed by a person.
Platform and runtimes
Kubernetes, GitOps, secrets, registry, and GPU runtimes from playbooks.
Observability
Metrics, logs, and traces from switch port to token.
NVIDIA
CUDAThe most mature serving path in the industry. Where NVIDIA is what your estate is standardised on, that is what we build for you.
AMD
ROCmOur own production fleet runs on AMD. We have done the work to make vLLM perform on ROCm at cluster scale.
Your domain, trained into the weights
Retrieval and adapters hold up until the task gets genuinely hard. We continue training Matilda on your domain and your task, so the capability ends up in the weights rather than in the prompt. Post-training is not one recipe, and the strategy that suits a bank is not the one that suits a defence workload, so choosing it is most of the skill.
Domain-adaptive training
We keep training Matilda on your corpus so the vocabulary and conventions of your field are native to it rather than explained on every request.
Task post-training
Supervised training on how the work is actually done in your organisation, drawn from the examples your people have already produced.
Preference and reinforcement
Training against your judgements so the model learns the calls your experts make, not only the format they write in.
Continuous retraining
The model keeps learning as your work changes, on a cycle you set, rather than freezing on the day it was handed over.
Sized to your hardware
Distillation to a model your GPUs can hold, keeping the behaviour you trained for instead of the parameter count.
Model observability
Monitoring points between layers that report what the model is doing while it does it, so your assurance team can inspect it.
It runs on your hardware, not ours
Everything runs inside your network, under your change process. These are claims your security team can check for themselves.
- It does not call us
- No usage telemetry, no licence check. Your network team can verify exactly what it talks to.
- Air-gap capable
- Delivered offline where accreditation requires it, with signed and verifiable updates.
- Your data stays put
- Prompts, completions, documents, and logs stay on your hardware. Nothing trains on it.
- Your identity, your keys
- Bring your own IdP for SSO, your own KMS for secrets, your own SIEM for the audit stream.
- You choose what changes
- Updates land when your change process says. Nothing updates itself underneath you.
- Your operators, our engineers
- Runbooks and dashboards you own, with a named engineer at Maincode to escalate to.
- Defence and national security
- Isolated networks and long accreditation cycles
- Banking and financial services
- Customer data under obligations that name the boundary
- Government and critical infrastructure
- Onshore residency and a control set your assessors know
- Health and medical research
- Patient and participant data that stays in the institution
Australian-made, all the way down
It matters who trained the model, who built the weights, and where your traffic goes. Those questions have short answers here.
How we build in Australia- Melbourne
- Where the models are trained
- Maincode
- Who built the weights
- Australian
- Company and headquarters
- Your hardware
- Where your traffic stays
- Maincode, in Melbourne, on hardware we own and operate
- We train them ourselves, which is what makes handing them over possible
- Australian, incorporated and headquartered in Melbourne
- It stays on your hardware, so it is never ours to hold
- The MC-2 AI Factory, which we own and run in Melbourne
- A named engineer in Melbourne, in your timezone
Built for the assessment
A deployment inside your perimeter is your system. The authority to operate is yours to hold, and our job is to supply what your assessors ask for.
- Architecture and data-flow documentation for the deployed system
- Control mapping for the components we ship
- Software bill of materials and signed release artefacts
- Configuration baselines for the environment as installed
- An engineer on the call with your assessors
From the first call to the first token
A deployment is an infrastructure project. It moves at the speed of your change board and your assessors.
- 01
Scope
What the work is, what it is classified at, and what silicon you already have.
- 02
Design
Reference architecture covering model sizes, node counts, network topology, and identity.
- 03
Install
We deploy alongside your platform team, on your change process, connected or air-gapped.
- 04
Accredit
We supply the evidence pack and sit with your assessors while they work through it.
- 05
Operate
Model updates on your schedule, benchmarked before they land, with a named engineer to escalate to.
Before you bring it inside
The questions security and procurement ask, answered before the first call, with the rest in the docs.
Bring the model to the work
Tell us what the work is and what you are running on, and we will tell you whether Matilda fits and at which level, including when the answer is that you do not need any of this.