Prove what a system decided — and that no one changed it after.
Secoya seals a decision at the moment it is made into a portable, cryptographically signed evidence record. An auditor can verify it later, independently of the system that produced it.
Current evaluation build · @secoya/pq-sdk 0.4.0-rc.5 · developer preview · Trust Record Format v0.3 RC1 · verified in TypeScript, Python and Rust
One workflow. Ten weeks. Five pass/fail gates.
A £30,000 plus VAT engagement to connect one consequential decision to customer-controlled signing, durable replay protection, independent time evidence, observable history and workflow reconciliation.
Your logs record what happened. Can an independent reviewer trust them?
The current timetable, the difference between logging and evidential integrity, and an interactive digest demonstration.
A valid record can still be deleted. See how an independent monitor exposes rewritten history.
Explore Merkle inclusion proofs, signed tree heads, rollback detection and a clearly labelled split-view simulation — using synthetic data in your browser.
A log is not proof.
Systems already record what they do. But a log lives inside the system that wrote it, and can be edited, truncated or lost. When a regulator asks you to prove a specific decision was authentic and within policy, a log is weak evidence — it asks them to trust the same system under question.
A record that stands on its own
Each decision is sealed with a hybrid signature — Ed25519 today, ML-DSA-65 for the years an audit trail must survive. Any later change breaks the seal. A verifier with the published format, release package, trust material and policy can verify the record without access to Secoya or the originating system.
Limitations are part of the evidence
A valid signature does not prove the workload was authorised, that every event was captured, that a key was never compromised, or that declared time is trustworthy. Secoya states these boundaries rather than implying them away.
Four commitments the format keeps.
- 01 / durabilityEvidence must outlive the algorithm that signed it. Long-lived records carry explicit algorithms, key identifiers, renewal policy and preserved lineage.
- 02 / contemporaneityTrust is strongest at the moment of creation. A record sealed beside the event is more defensible than a reconstruction assembled after a dispute.
- 03 / independenceVerification should cross infrastructure boundaries. A verifier checks the record without privileged access to the system that produced it.
- 04 / honestyIdentity, key custody, trusted time, completeness and audit status must be stated — not implied by a valid signature.
Read the implementation, not the pitch.
The SDK, its conformance vectors and its claim boundaries are all published for inspection.