A log that cannot quietly forget.
A Secoya Trust Record can show whether one sealed decision changed. A transparency log addresses the next question: could an operator later delete, reorder or rewrite part of the decision history?
A strong record and a complete history are not the same claim.
Trust Record
Hybrid signatures and deterministic verification expose changes to the protected content of an individual record.
Question answered: has this record changed?
Transparency layer
Append-only Merkle proofs, signed tree heads and independently retained checkpoints expose inconsistent history.
Question answered: has the observed log history changed?
The transparency layer does not prove that every event which should have been submitted was actually submitted. That requires workflow controls and reconciliation at the source.
Try to rewrite the history.
Start by asking the monitor to retain the current signed tree head. Then append decisions or try the simulated attacks. Select any ledger entry to display its compact inclusion proof.
Sealed decisions, in order
Select an entry to light its path to the root. Gold nodes are the audit path — the hashes needed to prove that entry is in this tree.
Inclusion proof
Select an entry.
Merkle tree
Signed tree head
Monitor
A real monitor is independently operated and retains every signed head it accepts. This in-page monitor models that behaviour in memory.
Make the control failure visible before a dispute.
Internal audit
An auditor can test inclusion against a previously retained checkpoint instead of relying only on a live query to the system being reviewed.
Supervisor or client review
An external party can retain signed heads and compare them over time. That requires an independently operated monitor in a real deployment.
Disputed decision
A record schema can bind the decision to its declared model, policy and authority; the log can show that the observed record remained in the published history.
Control-path reconciliation
If the workflow says a consequential decision must be logged, reconciliation can turn a missing expected record into an auditable control-failure signal — not automatic proof of deliberate bypass.
- Compact proof that a selected entry is included in a particular tree.
- Detection when an observed history is altered, deleted or rolled back.
- Why independently retained checkpoints and gossip matter.
- Deterministic browser behaviour using synthetic records.
- No persistence, authentication, production key custody or external time.
- The monitor runs in the same browser page; it is not independently operated.
- The conflicting-head action is a simulation, not verification of a second signed head.
- Tree heads use Ed25519 where supported; this is separate from the SDK’s hybrid Trust Record path.
- No independent security audit, legal conclusion or production assurance.
Test the complete evidence path on one real decision.
A pilot connects issuance, customer-controlled key custody, durable replay protection, trusted time, retention, reconciliation and independent verification around one bounded workflow.
