How it works
From a document to a defensible answer.
The lifecycle below is the same whether the source is an academic paper, an internal model specification or a regulatory document. What changes is the data it gets calibrated against.
- 01
Stage one
Ingest the source
AlphaIQ reads the material that defines the model — a PDF, a specification document, existing code, a dataset schema. The analyst agent extracts the model's semantic content rather than its prose: which entities exist, what state they carry, and which rules govern their behaviour.
This stage produces a structured draft specification and, importantly, a list of ambiguities — the places where the source is underdetermined and a human decision is required. Those decisions get recorded rather than absorbed silently into code.
Artifact — Draft specification + open questions
- 02
Stage two
Agree the specification
You review the specification with us and resolve the open questions. This is the highest-leverage half hour in the entire process: it is far cheaper to disagree about a behavioural rule here than to discover the disagreement in a result three weeks later.
The agreed specification becomes the contract. Everything downstream is generated from it, and any later change to the model is made by changing the specification and regenerating — not by patching code and letting the two drift apart.
Artifact — Signed-off model specification
- 03
Stage three
Generate and review code
The developer agent writes executable simulation code from the specification. A separate review pass scores the code against the specification and iterates where the two disagree. Individual agent behaviours are tested in isolation before the full model is assembled.
Isolation testing matters more here than in ordinary software: in a simulation, a subtly wrong agent rule does not throw an error. It produces plausible output that is wrong in a way nobody notices.
Artifact — Reviewed model code + isolation tests
- 04
Stage four
Calibrate against data
Agent-level parameters are fitted so that aggregate model behaviour reproduces observed behaviour, using approximate Bayesian computation and history matching. Where real data is unavailable or restricted, synthetic data with known properties is used to test that the calibration machinery itself works.
We report the accepted parameter region rather than a single best-fitting point, and we list separately the parameters that were fixed by assumption. Those are where the judgement lives.
Artifact — Calibration record + accepted parameter region
- 05
Stage five
Validate before use
Residual analysis, distribution comparison against the target series, sensitivity sweeps across the parameters that matter, and plausibility checks on emergent behaviour. Where the data allows it, out-of-sample or out-of-regime testing.
The output of this stage includes the failure map: the specific input combinations under which the conclusion reverses, and an assessment of whether those combinations are plausible.
Artifact — Validation record + failure boundaries
- 06
Stage six
Interrogate the model
Only now do scenarios get run — and they get run with your team, live, so that the questions people actually have are the ones that get asked. Each result traces back through calibration to a line in the specification.
The measure of success is not that the model produced a number. It is that when someone challenges the number, the answer is a specific rule, a specific parameter and a specific piece of evidence.
Artifact — Scenario results with full provenance
Common questions
Asked early, usually.
How long does a first model take?
It depends almost entirely on data access rather than on modelling. Scoping conversations are more useful than a generic estimate: bring the question and the data situation and we will give you a timeline for that specific case.
Do we need an in-house modelling team?
No, though results are better where one exists. Where there is no internal team, we build the model and work through the results with the decision-makers directly. Where there is one, we work alongside it and hand over.
Does our data leave our environment?
The pipeline is designed to be deployed inside your cloud account or on-premises so that it does not have to. Tell us your specific requirements and we will confirm plainly whether we currently meet them rather than assuring you in general terms.
What if we already have a model?
Then a model review is usually the better starting point. We reconstruct its specification, check its calibration independently and produce the validation evidence, which is frequently the part that is missing.
Is this a replacement for our existing risk models?
Rarely, and we would be cautious about anyone who says otherwise. Aggregate models are the right tool for most questions. Simulation earns its cost on transitions, thresholds, distributional effects and adaptation.
What does it cost?
Engagements are scoped individually against the question and the data. We would rather quote something specific after one conversation than publish a number that turns out not to apply to you.