Documenting Model Assumptions for Investment Committees
This page solves one exact task: producing a short, generated document that accompanies every site-selection recommendation and lets a non-technical committee interrogate the model behind it — what it measures, what it assumes, how accurate it has been, and the circumstances in which it should not be relied on.
The document is not a courtesy. A committee approving several million pounds of capital on a ranked list is entitled to know how that list was produced, and the absence of a plain-language description is what allows a score to be treated either as gospel or as noise, depending on whether it agrees with the room.
Prerequisites
- A validation history with measured accuracy, from tracking model decay across refresh cycles.
- The versioned configuration: weights, decay parameters, criterion definitions, and the input versions each run used.
- A documented list of known limitations, maintained as the model is developed rather than reconstructed at the end.
- A template and a generator — the document should be produced from the artifacts, not typed.
Configuration and execution parameters
| Section | Content | Length |
|---|---|---|
| What it predicts | The outcome, in the units a committee uses | 2 sentences |
| What goes in | The criteria and their weights, plainly named | A table |
| Key assumptions | The three or four that drive the answer | 4 bullets |
| Measured accuracy | Correlation, decile lift, signed bias, and the design | A table |
| Where it is weak | Segments and situations with poor accuracy | 3 bullets |
| What it does not consider | Explicit exclusions | 4 bullets |
| Version and date | Every input version, and when accuracy was last measured | 1 line |
The section that changes discussions most is what it does not consider. Committees routinely assume a site model has weighed things it has never seen — landlord quality, staffing availability, planning risk, the chief executive’s view of the town — and stating the exclusions moves those factors into the discussion where they belong instead of leaving them silently assumed.
Annotated implementation
The card is generated, because a hand-written one drifts from the model within a quarter.
from __future__ import annotations
from dataclasses import dataclass
from datetime import date
import pandas as pd
@dataclass(frozen=True)
class ModelCard:
predicts: str
criteria: pd.DataFrame # name, plain_language, weight
assumptions: list[str]
accuracy: pd.DataFrame # design, metric, value, n
weaknesses: list[str]
exclusions: list[str]
versions: dict[str, str]
measured_on: date
def to_markdown(self) -> str:
parts = [
f"## What this model predicts\n\n{self.predicts}\n",
"## What goes into the score\n\n" + self.criteria.to_markdown(index=False),
"## Key assumptions\n\n" + "\n".join(f"- {a}" for a in self.assumptions),
"## Measured accuracy\n\n" + self.accuracy.to_markdown(index=False),
"## Where this model is weak\n\n" + "\n".join(f"- {w}" for w in self.weaknesses),
"## What this model does not consider\n\n"
+ "\n".join(f"- {e}" for e in self.exclusions),
"## Versions\n\n"
+ " · ".join(f"{k}: {v}" for k, v in sorted(self.versions.items()))
+ f"\n\nAccuracy last measured {self.measured_on.isoformat()}.",
]
return "\n\n".join(parts)
def build_card(config: dict, validation: pd.DataFrame,
limitations: list[dict]) -> ModelCard:
"""Assemble from artifacts. Nothing here is typed by a human at build time."""
latest = validation.sort_values("quarter").groupby("design").tail(1)
return ModelCard(
predicts=config["predicts_statement"],
criteria=pd.DataFrame(config["criteria"]),
assumptions=[a["statement"] for a in config["assumptions"]],
accuracy=latest[["design", "metric", "value", "n"]],
# Weaknesses come from the segmented validation, not from memory.
weaknesses=[l["statement"] for l in limitations if l["kind"] == "weak"],
exclusions=[l["statement"] for l in limitations if l["kind"] == "excluded"],
versions=config["input_versions"],
measured_on=latest["measured_on"].max(),
)
Deriving the weaknesses from the segmented validation rather than from a maintained list is the detail that keeps the card current. A segment whose accuracy falls below a threshold appears in the weaknesses automatically, which means the card tells the committee about a problem in the same quarter the modelling team learns of it.
Failure modes and debugging
A card that describes the intended model. Written during development and never regenerated, it describes weights that have since been refitted and an accuracy that was aspirational. Generating from the configuration and the validation record removes the possibility.
Accuracy quoted without its design. “Correlation 0.78” means one thing in sample and another prospectively, and quoting the flattering figure without the design is the most common way a card misleads without containing a false statement. Every accuracy row should carry its design and its sample size.
Exclusions written defensively. A list of exclusions that reads as a disclaimer invites the committee to discount the model entirely. Written as a division of labour — the model handles catchment and competition, the committee handles lease, covenant and operational risk — the same list strengthens the recommendation.
No named owner. A document with no author is a document nobody can be asked about. The card should name the person accountable for the model, which is also what makes the annual review happen.
Verification
- Regenerate the card and diff it against the published version before every committee cycle. A diff of zero when the model was refitted means the generator is reading a stale artifact.
- Check every number appears in the validation record. Any figure in the card that cannot be traced to a measurement is an assertion.
- Ask someone outside the team to read it and say what the model does. If they cannot, the plain-language column is not plain enough.
- Confirm the weaknesses list changes when a segment’s accuracy falls, by injecting a synthetic decline.
Frequently Asked Questions
How long should the card be?
One page, and the constraint is the point. A ten-page methodology document is read by nobody and therefore protects nobody; a single page with seven short sections is read in the meeting. Everything that does not fit belongs in a technical appendix that the card links to, which is where the modelling team’s own detail should live anyway.
Should the card include the weights?
Yes, with plain-language names. Committees are perfectly capable of engaging with the statement that reachable population carries thirty per cent and rent ten, and that engagement is exactly what should happen — the weights encode a business judgement, and the committee is who owns that judgement. Hiding them behind a composite score removes the one part of the model non-technical stakeholders are best placed to challenge.
What if the measured accuracy is poor?
Publish it. A model with a rank correlation of 0.45 that is honestly reported is more useful than one claiming 0.8 on an in-sample fit, because the committee can weight it appropriately against the other evidence. The temptation to withhold a disappointing number is also the mechanism by which a model’s credibility collapses the first time somebody computes it independently.
Who should own the card?
The person accountable for the model, with the validation figures produced by someone else — the same separation that keeps the validation honest. The card is generated, so ownership is about maintaining the assumptions and limitations lists rather than about writing prose, which is a small and genuinely useful responsibility.
How often should the card be reissued?
With every committee cycle, regenerated rather than reviewed. The cost of regeneration is nil once the generator exists, and reissuing it each cycle means the accuracy figures, the input versions and the weakness list are always the current ones. A card reissued only when something changes invites the question of whether nothing changed or nobody checked.
What belongs in the technical appendix rather than the card?
The derivations, the full criterion definitions, the fitting method, the validation designs in detail, and the history of changes. Everything the modelling team needs to reproduce the work, none of which a committee needs to make a decision. Keeping the split clean is what allows the card to stay at one page — and the appendix, being written for a technical reader, can be as long as the subject deserves.
Does the card change how the model is used?
In practice, yes, and mostly by narrowing its use to where it works. Committees given a segmented accuracy table start asking for the model’s view where it is strong and for other evidence where it is weak, which is exactly the behaviour a modelling team wants and rarely gets by asserting it. The card also tends to shorten meetings, because the questions it pre-empts are the ones that previously consumed the first twenty minutes.
What if the committee never reads it?
Then attach it to the decision rather than to the pack. A card referenced in the minutes — the model version, its accuracy, its stated weaknesses — becomes part of the record of why an approval was given, which is where its value ultimately sits. Committees that skip the document during the meeting still benefit from its existence the first time a decision is revisited.
Related
- Validating & Backtesting Site Selection Models — where the accuracy figures come from.
- Tracking Model Decay Across Refresh Cycles — the trend the card publishes.
- Generating PDF Site Selection Reports with Python — the pack this card accompanies.