What “database-enforced”
Means Here, Exactly.

Both tables carry a before-update-or-delete trigger that raises an exception reading "Signal ledger rows are immutable". This is enforced inside the database, not in application code, so it holds for every writer including our own server workers. Those two tables, and only those two: the limits below name what the trigger does not cover, because the scope of this guarantee is narrower than the phrase "append-only ledger" suggests.

The anon role holds no privilege on signals, signal_versions, signal_targets or signal_events. A signed-in session is granted select on all four and insert or update on signals and signal_versions only; row-level security then narrows those writes to the analyst who authored the row and holds the signals.manage capability, and any update that reaches signal_versions is rejected outright by the trigger above. signal_targets and signal_events accept no browser writes at all.

Recomputing a period inserts a new row whose revision is the previous revision plus one and whose supersedes_snapshot_id points at the row it replaces. Nothing updates an existing snapshot, so a figure we published in the past stays readable at the revision that published it, alongside the figure that replaced it and the link between them.

Each snapshot stores a source_fingerprint: a SHA-256 over the sorted source signals, covering id, direction, status, the triggered, completed, winner, loser and breakeven flags, the recorded return, and the target-hit events. Recomputing that digest over the same rows reproduces the same value, so any change to an input the figures depend on produces a different fingerprint. The digest is also the job's skip condition, which is why its coverage has to match the summary's inputs exactly rather than approximately.

Each market event the monitor writes (trigger, target, stop, invalidation, expiry) carries a SHA-256 key derived from the signal id, the event type, the provider's market timestamp, and the target ordinal. A worker that retries after a network failure cannot append the same trigger twice, so the market-event count is a count of things that happened rather than a count of times we asked.

The immutability triggers cover signal_versions and signal_events. The signals row -- its status, trigger price and close price -- and the signal_targets rows that record which target was hit and at what price carry no such trigger. An authoring analyst can update the signals row through row-level security, and our server workers can update both. These are the outcome-bearing fields the published performance figures are computed from, which makes this the most load-bearing gap on this page.

No record stores the digest of the record before it. The immutability above is enforced by the database, not by a structure that would make tampering self-evident to you. Someone with direct database ownership could, in principle, disable a trigger. We would know; from the outside, you would not.

There is no private key signing published theses, triggers, or performance figures, and therefore no signature you could verify against a public key. Where the site says a thesis is recorded in a version, read it as: written to a version record the database rejects updates and deletes to.

No digest of the ledger is published to a blockchain, a transparency log, or any third party. The record's integrity currently rests on our database configuration. An external anchor is the thing that would let you verify our history without trusting us, and we have not built it.

No external auditor has examined the ledger, the reconciliation job, or the published performance figures.