Verdict-of-Record

When Veritas runs a TEST against a claim, the result has to live somewhere as the canonical answer. That somewhere is a Mattermost post in the verification channel, posted under the veritas handle. The post is the verdict-of-record. The same content also gets serialized into a YAML file at axon_veritas/verdicts/<slug>.yaml so that consumer-render surfaces can read it at build time, but the YAML is a derivative of the post — not the other way around.

This precedence matters because the discipline of who-can-write-a-verdict has to be enforceable. If anyone could edit the YAML, a verdict could be silently flipped. If only the veritas Mattermost handle can post the verdict, the audit trail of who-asserted-what is preserved by the channel itself.

A verdict-of-record reads as a short structured post: which claim, which TEST result, which substrate-pin the verdict was issued against, which verdict-pin the manifest was emitted to. Verdicts can supersede earlier verdicts — when a substrate-pin advances or a claim’s cat-1 fields are edited, Veritas re-fires the TEST and re-posts. The earlier verdict stays in the channel as historical record; the new post becomes the canonical-current.

The verdict-of-record discipline is the load-bearing piece that lets the four-state routing framework be auditable. A reader who wants to know why a per-row badge says ungrounded can trace the badge to the verdict YAML, the YAML to the Mattermost post, the post to the TEST run that produced it.

Schema encoding

The schema field that pins the canonical source-of-record is register_canonical. The verdict YAML carries register_canonical: "mattermost" as a const-pin, with a required derived_from block naming the post id and channel id.