What the cryptography controls — and what it does not.
Verification establishes integrity and policy satisfaction against supplied trust material. Everything it cannot establish is stated here, on purpose.
What the build enforces.
- Signed metadata binding prevents undetected substitution of key ID, authority ID and creation time.
- Record context, policy, purpose, record ID, nonce and predecessor are included in the protected signing input.
- Encrypted-envelope recipient identifiers, key fingerprints, suite parameters and application context are authenticated as additional data.
- Verification fails closed for malformed records, unknown formats and algorithms, unavailable keys, resolver failures, untrusted authorities, revoked or unusable keys, unsatisfied policy and replay-check errors.
- Resource limits constrain nesting, canonical size, object keys and signature count.
- Forbidden prototype-related keys are rejected.
- Strict schemas reject additional properties in frozen protocol structures.
- Deterministic fuzz cases confirm malformed input is rejected without verifier exceptions.
A valid result can establish that particular protected bytes were signed, that subsequent protected-content changes are detectable, and that the supplied key and policy artifacts satisfy the requested verification profile. It does not by itself establish that the source data was truthful, the represented person or organisation was authorised, every expected event was recorded, the workflow enforced issuance, a production HSM was securely operated, or the surrounding AI system was legally compliant.
Historical-verification testing examines whether evidence remains verifiable through operational and trust change without an operational Secoya service or the originating application. Verification still requires the applicable published trust material and an independently accepted trust anchor. Current versions and results are maintained in the technical reference.
- No durable replay database ships in the current developer preview; a deployment must supply atomic, persistent replay claiming.
- No vendor-specific KMS, key registry or trusted-time integration is claimed.
- The default Node provider is not a substitute for managed production key custody.
- Cross-language verification and internal clean-room historical-verification evidence are published in the technical reference. External third-party validation is not yet claimed.
- No independent cryptographic audit or production-system penetration test is claimed.
- Omission and completeness are established only when a deployment supplies an authenticated expected-event population, sequence or reconciliation control; a signature alone cannot prove that nothing was omitted.
- FIPS validation, Common Criteria certification and formal verification are not claimed.
- The website is informational; it does not currently receive or retain evidence submissions.