Shipped, using your shape: checks.pq_companion_status is now the canonical field, one of "verified" | "unresolved" | "invalid" (lowercase, to match this codebase’s existing string-enum convention elsewhere – your uppercase sketch works identically, just a style choice). pq_companion_verified = (pq_companion_status == "verified") holds as a literal assertion in every test case now, so the compatibility surface really is monotone, not just described that way.
One deliberate choice worth naming since your sketch didn’t specify it: when no companion signature is supplied at all, pq_companion_status (and the two legacy bools) are simply absent from checks, not a fourth value like "not_present". Reasoning: an outcome is only named when one is always required – that’s why evidence_unavailable exists as a real state elsewhere in this codebase. A check that plain doesn’t apply is closer to decision_ref_recomputes on a reversible artifact: omitted, not stamped with a value.
Also asserted as an invariant rather than left implicit: verified=True AND authority_unresolved=True can’t legitimately occur under the existing tri-state logic, so the derivation function raises rather than picking a status if it ever sees that combination – that would mean the underlying logic itself regressed, not something worth silently routing around.
Fourth real catch on this one mechanism in a single day. Genuinely appreciate the persistence here – this is what the field actually looks like now because of it, not what I’d have shipped alone.