STRATALIZE
TrustReference

Every output signed.
Every action governed.
Every claim verifiable.

This page is the reference material behind those three sentences: the public signing key, what the signature does and doesn't cover, how the governance model enforces access, and what the infrastructure runs on.

Fig A — VerifyInteractive
Verify Any Output

Paste a synthesis ID, a link containing ?synthesis_id=, or raw JSON with a _stratalize block — verified in the browser with no Stratalize API for pasted JSON.

Verification service operational · trust.stratalize.com

Assessment methodology: Stratalize AGM v1.0 →

Verifies in the browser. No Stratalize API for pasted JSON.
Trust referencesKey and threat model
Public signing key

Every receipt is signed with ML-DSA-65 under FIPS 204. Verification runs against the key below, published here and nowhere else. Anyone can check a receipt offline with no account and no request to Stratalize.

AlgorithmML-DSA-65
StandardFIPS 204
Key IDstz-prod-01
Fingerprintf9e8d7c6 a1b2 4e07 9d3f
Threat model

A signature is only worth what it covers. Both lists below are part of the specification.

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 names who authorized 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 is recorded, not second-guessed.
Anything outside a governed call. Work done in another tool produces no receipt.
Security guarantees
Signature

Post-quantum from day one

ML-DSA-65 under FIPS 204 on every output, not as an upgrade path. Records created today are read in audits and claims years out.

Retention

Retention you configure

Source data is released at the end of a session, with hashes and signed records persisting. Beyond that you set the window, from signed artifacts only to a full forensic chain. Where a workspace needs history to function, that content persists under your retention setting.

Verification

Independent of us

Pasted JSON verifies in the browser against the published key. No account, no API call.

Continuity

A chain, not a folder

Every receipt references the one before it, which is what makes the record worth entering into evidence.

Access controlSix controls
Per-user permissions
Every request is checked against that person’s scope before anything executes.
Field-level controls
Sensitivity tiers are enforced per field, not per document.
Four-eyes approval
Write actions and material changes route to a named approver.
Agent passports
Tools, data reach, and sensitivity tier are locked at issue and revocable instantly.
Attributed actions
Every action is recorded against the person or agent that took it.
Scoped API keys
Keys carry a permission scope and a budget, never blanket access.
InfrastructureSix controls
Encryption in transit
TLS 1.3 on every connection.
Encryption at rest
AES-256 on all persisted storage.
Tenant isolation
Organization data is separated at the storage layer, not by query filter.
Key custody
Signing keys are held in a hardware security module and never leave it.
Audit logging
Administrative actions are logged separately from the signed record.
Backup and recovery
Point-in-time recovery with tested restore procedures.
Read the documentation →