The analysis drives the model. Never the other way around.
ADM starts with the decision that needs to be made. That decision determines what to model, how much detail to include, and how the result should be tested.
By Michael Key · ORCID
The method in three steps.
Define the decision, build only the fidelity it requires, and validate the result for its intended use. If validation falls short, add detail only where sensitivity analysis shows that it matters.
If validation falls short, return to Step 02. If it clears the bar, stop building.
What ADM adds
Good modeling practice already includes verification, validation, and uncertainty. ADM puts three choices ahead of the model: the decision bar, the places where added detail could change the answer, and the point at which the model is sufficient. Its distinctive claim is procedural, not magical: use sensitivity to spend fidelity where the decision needs it, and stop when validation clears the bar.
Let the question set the bar
Modeling projects often go wrong before the model exists: a team begins with a favored method, then looks for a question it can answer. ADM reverses that sequence. The decision comes first, along with the evidence needed to support it. That defines the fidelity bar.
Before writing code, four things need to be clear:
- What decision will this model inform? Not “what will it simulate,” but what decision will a human or system make differently because this model exists?
- What evidence would be sufficient? A preliminary screen and a consequential operational decision require different precision, calibration, and validation.
- What physics and dynamics matter? Every real-world system is more complex than any model of it. The art is knowing which dynamics are load-bearing for your specific question and which can be safely abstracted.
- What would change the answer? State the operating threshold and the assumptions that could move the result across it.
A model can run beautifully and still be irrelevant. A useful fidelity bar makes sufficiency testable before complexity accumulates.
Build to the fidelity bar
Once the decision and validation bar are clear, build the least complicated model that can meet them. This is where many projects add detail without evidence that it will improve the decision.
The fidelity spectrum runs from arithmetic, lookup tables, and statistical surrogates to high-resolution physics simulations. More detail is not automatically more truthful. A model can overfit its data, exceed its validation basis, or become too opaque to explain why the answer moved.
The fidelity ladder
The right level is rarely obvious at the start, so ADM uses a repeated four-part test:
- Start with a screening model. Build the simplest representation that could plausibly answer the question.
- Run sensitivity analysis. Identify which inputs, assumptions, and components can move the decision.
- Increase fidelity selectively. Add detail only where sensitivity shows that it could change the answer. Keep the rest simple.
- Validate and stop—or repeat. If the model clears the evidence bar, stop. If it does not, escalate the next decision-sensitive component.
This prevents both over-building and discovering too late that a load-bearing part of the problem was oversimplified. Uncertainty analysis belongs inside that loop whenever the decision depends on tail risk, confidence intervals, or the chance of crossing a threshold.
A current research example
The molecular-aggregation study asked a deliberately limited question: can a simple amyloid-beta-specific model screen held-out single-substitution assay outcomes while stating uncertainty honestly? Marginal coverage was nominal by construction, but subgroup checks exposed undercoverage for unseen substitutions and the familial extreme. Group-conditional intervals fixed the seen/unseen split on this holdout, but not the eight-example familial tail. The study therefore stops at screening evidence, publishes the subgroup boundary, and does not claim clinical interpretation. That is the fidelity ladder in practice: escalate where the answer is sensitive, then keep the limit when more modeling has not earned a stronger claim.
Validate what matters
The model doesn’t need to be perfect — it needs to be good enough for the decision it serves. Sensitivity analysis tells you which inputs actually move the answer. Uncertainty quantification tells you how much to trust it. If the model is more precise than the decision requires, you’ve overbuilt.
The defense Modeling and Simulation community has spent decades developing rigorous Verification, Validation, and Accreditation (VV&A) practices. These practices exist because the consequences of trusting an unvalidated model in defense are measured in lives. But the underlying principle applies everywhere: a model without validation is a hypothesis, not a tool.
Verification asks: “Did we build the model right?” Does the code implement the intended equations? Are the algorithms numerically stable? Do the outputs make dimensional and physical sense?
Validation asks: “Did we build the right model?” Does its behavior match reality within acceptable tolerances for the intended use? A model validated for one question may be inappropriate for another, even when both use the same underlying physics.
The V&V blind spot
It’s a common blind spot in AI work. Teams validate model accuracy on held-out test sets but never ask whether the model is actually useful for the decision it was built to support. A predictive model can have excellent test-set accuracy and still be useless if it fails to capture the dynamics that matter for the downstream decision. ADM insists on end-to-end validation: does the chain hold all the way from data through the model to the actual decision? If it breaks at any link, the model hasn’t been validated for its intended purpose.
Keep the answer tied to its basis.
Hard problems often require a chain of questions rather than one large model. Each step should use the method its own decision requires, then pass only traceable results to the next step. A simulation may establish a breaking point; a later economic analysis may use that result to compare choices. Forcing the whole chain into one tool usually obscures more than it clarifies.
The same rule governs publication. A reader should be able to move from a claim to the script-written result, the method that produced it, the input provenance, and the limits that control its interpretation. Negative results and abandoned escalations remain part of that record.
ADM is compatible with the decision-first principles in the OSD Mission Engineering Guide 2.0, which links the intended decision to the required fidelity and analytic rigor. ADM is my own working methodology, not an official Department of Defense framework or endorsement.
AI coding agents can accelerate implementation, testing, and sensitivity sweeps. They do not set the question, relax the evidence bar, or decide when a model is sufficient.
Supporting research. Health-AI Watch tracks selected AI systems and is developing an end-to-end benchmark for whether AI-assisted health research survives protocol, execution, audit, and publication. It supports the research process; it is not part of the neurodegeneration study portfolio.
The method does not override the terms.
Clinical data adds obligations that ordinary modeling work does not. Access is applied for, never assumed, and each repository’s agreement governs storage, execution, disclosure, retention, and destruction. Restricted participant records never enter an AI context.
For prognosis work, ADM also does not replace clinical-research standards. Calibration, risk of bias, external validation, and intended use must be addressed at the level the claim requires. Reference to standards such as TRIPOD+AI or PROBAST+AI is not a claim of compliance or clinical readiness.
The full operating boundary—including researcher-only execution for PRO-ACT, the solo-researcher human-subjects posture, and dataset-specific controls—is maintained on Data Stewardship. Current study status belongs on Research.
Decision-first modeling, with stricter clinical-data boundaries.
Define the decision, build only what it requires, and validate the result before publishing it.