Model card vs per-output manifest
Per-output beats per-model for a decision under review — the unit of audit is the decision.
A model card describes a model. A manifest describes a decision. When an examiner asks about a specific output, only one of them answers the question that was asked.
The model card became the default artifact for "responsible AI" documentation, and it is fine for what it is: a static description of a model’s intended use, its limitations, its training data in broad strokes. The problem is not that model cards are bad; it is that they are the wrong unit. A decision under review is not "the model"; it is one output of the model, on one input, at one time, with one set of versions behind it. The model card does not carry any of that.
The unit of audit is the decision
When a regulator flags a credit call, they are not asking "tell me about your model." They are asking "tell me about this decision: which version of the model, which input NodeVersions, which agents ran, who overrode, and can I replay it." A model card answers none of those. A per-output manifest (BR-842) answers all of them, because it is built at the unit the question is asked at — the output, not the model.
What a model card is good for
A model card is good for the things that are true of the model across all its uses: intended scope, known limitations, the provider’s stated evaluation. That is documentation, and it is worth keeping — as the NIST AI RMF and ISO/IEC 42001 (both voluntary) would put it, it is governance documentation on top of the binding tier, not a substitute for it. But a model card is a static description of a class; a decision is a specific instance, and a class description does not attest an instance.
A model card describes a model. A manifest describes a decision. When the examiner flags one credit call, only one of those answers the question that was asked.
Why per-output is the right granularity
The per-output manifest is hash-chained and append-only. Each one carries the model version (hash-pinned, not named), the input NodeVersions (L1-L4 refs), the agent trace (the 23-agent A2A swarm, CRDT-merged), the output bytes, and a replay anchor. Swap the model tomorrow; the historical manifest still verifies against the historical model, because it pinned the model by hash, not by name. A model card pinned to a name rots the day the name moves.
- Model card = per-model, static, descriptive. Good for scope and limitations; bad for a specific decision.
- Manifest = per-output, hash-chained, attestational. The only unit that answers "show me how you decided."
- The card documents the class; the manifest attests the instance. Both are useful; only one is evidence.
- Pin the model by hash, not by name — the manifest survives the swap; the card does not.
What neither certifies
Neither artifact certifies that the decision was correct. The model card describes intended use; the manifest attests provenance and reproducibility. Certified ≠ True: the manifest certifies that the computation is reconstructable, not that the output was right. Accuracy is a calibration loop in progress — Gate 1 requires the bytes to match (reproducibility), Gate 1b requires a shadow run to beat a disclosed baseline on one series before any forecast side is positioned as accurate. We are pre-revenue, building the POC; the manifest fields exist, and calibration is gated.
The model card is the story you tell about the model. The manifest is the evidence you hand about the decision. A review asks for the second; write the first only if you also write the second.
— audit posture note