Explainability before automation
A component that cannot account for its output does not enter the decision path, regardless of how well it performs.
There is a standard order of operations in automated systems: build something that works, then add an explanation layer so that people can follow it. The order is backwards, and the reason is not ethical.
The principle: a component that cannot account for its output does not enter the decision path, however well it performs.
Why the usual order fails
An explanation produced after a decision, by a different mechanism than the one that produced the decision, is a reconstruction. It has access to the inputs and the output and it infers a plausible path between them.
Sometimes the plausible path is not the actual path. And the failure is undetectable from outside: a reconstructed explanation and a truthful one look identical, and the only way to catch a discrepancy is to already know what the system did — which is what the explanation was for.
The result is a component that is fluent, confident, and occasionally lying about the system it describes. That is worse than no explanation, because no explanation at least announces the absence.
What the principle requires instead
The justification must be produced by the same process that produced the decision, in the same pass, from the same values. It is part of the decision's structure rather than a report about it — the difference between a witness and a narrator.
A decision therefore carries the observations it rested on and their confidences, the prediction it trusted and how far, the constraints that were active at that moment, and the counterfactual: what it would have done had any of those differed.
The counterfactual is what makes the record useful rather than merely honest. "The signal held because queue length exceeded threshold" is a description. Adding "and would have released at a queue length two lower, or had the emergency constraint been active" produces something a person can argue with.
The cost, stated plainly
This principle disqualifies methods. A component whose output cannot be accounted for may not sit in the decision path, no matter how much better it scores, and this is not a preference to be traded away under deadline pressure.
The justification is the same one that runs through why VECTOR exists: a system that performs well and cannot account for itself cannot be corrected, cannot be audited, and cannot be defended when it was right. Its good performance is not knowledge. It is luck that has not yet run out, and nobody can tell the difference from the outside.
Relationship to the previous principle
Explainability is only possible because of observation before action. A decision can record what it rested on only if what it rested on arrived with its provenance intact. The two principles are one requirement observed at two points in the pipeline.