Transparency demonstration · synthetic data · local only

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?

Two different integrity questions

A strong record and a complete history are not the same claim.

01

Trust Record

Hybrid signatures and deterministic verification expose changes to the protected content of an individual record.

Question answered: has this record changed?

02

Transparency layer

Append-only Merkle proofs, signed tree heads and independently retained checkpoints expose inconsistent history.

Question answered: has the observed log history changed?

Important boundary

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.

Interactive model · runs entirely in this browser

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.

Why this matters

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.

What this page demonstrates
  • 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.
What it does not establish
  • 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.
Design-partner pilot

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.

Discuss the pilot