TrustVerification

How verification works

What is signed

Every applied schedule change and every exported submission is signed. Monthly packages carry one hash per file in the package. Schedule-change receipts carry the input hash and the output hash, plus a hash of the structural change manifest when the change alters the schedule's structure. Altering anything a hash covers breaks the signature.

Signed with

ML-DSA-65 under FIPS 204. The key is published on the trust page.

AlgorithmML-DSA-65

StandardFIPS 204

Key IDstz-prod-01

Fingerprintf9e8d7c6 a1b2 4e07 9d3f

Verify offline

You need the published key and the receipt JSON. Paste the receipt into the verify page and it checks the signature in your browser against the key. No account and no request to Stratalize.

What the signature covers

Protects against

Alteration of a signed output after the fact. Any change breaks the signature.

Backdating or deletion of a record. Each receipt references the one before it, so a missing link is detectable.

Release of data outside the requesting user’s permission scope. The scope is bound into the signature.

Disputed authorship. The receipt records who or which policy approved the action, not only that it occurred.

Vendor dependence. Verification runs offline against the published key, so the proof survives us.

Doesn't protect against

Substantive correctness of the output. A signature proves an action was authorized and unaltered, not that its conclusion is right.

Compromise of an authorized user’s credentials. An action taken with valid credentials will sign as valid.

Errors in source data. Stratalize signs what it was given.

Judgment inside an approval. The approver or approving policy is recorded, not second-guessed.

Anything outside a governed call. Work done in another tool produces no receipt.

Where approval is recorded

A change applies after approval. Approval comes from a named person in the review screen; for progress updates, from an approval policy the organization sets; or, where the organization's policy allows it, from a caller that asserts approval, which the receipt marks as asserted rather than reviewed. The receipt records the approval channel, who or which policy approved, and the time it was signed, next to the hashes it signs.