Transparency log
Most websites ask you to take their numbers on faith. This one does not. Every claim below is committed to an append-only log, signed, and re-derivable by anyone.
Why this exists
A website makes three claims that nobody, including its owner, can normally check: that the page you are reading is the page that was published, that its stated traffic is real, and that its security posture is what its policy says. Certificate Transparency solved this class of problem for certificates and Sigstore solved it for software packages. This log applies the same idea to a site's claims about itself.
We hold that a claim is only as strong as the artifact behind it. It would be incoherent to say that and then publish our own traffic figures as an unverifiable screenshot, so we do not.
What each epoch commits
- Content. A Merkle root over every published byte (130 files this epoch), so the inclusion of any page can be proven. Computed as RFC-6962 over SHA-256.
- Provenance. The source commit and generator that produced those bytes, bound to the signed build manifest.
- Posture. The security surface as measured from the live edge, not asserted: 7 of 7 hardening headers present, and the DNS policy records pinned by hash.
- Measurement. The traffic aggregate, so a figure published today cannot be quietly restated tomorrow.
Current head
| Log size | 186 epoch(s) |
| Root | d986a0fbf606057618e667ebbd0131edc73c777b606da4e67cd47f9afffa47c3 |
| Signature | Ed25519 + ML-DSA-65 (hybrid, post-quantum) |
| Signing key | a64d4af965fe220ce1c881f70ebabe5355ab9abbf17f7f3d8fb71ee911d2c493 |
| Sealed | 2026-08-09 13:43 UTC |
The signing key is published independently of this page, in DNS at
_release-key.coherenceenergylabs.com and in our public evidence repository. That
matters: a verifier that took the key from this page could not detect a forgery, because an
attacker would simply replace both. Take the key from somewhere we cannot edit by editing
this file.
Why this head is signed twice
An ordinary signature protects a document going forward. An append-only history is the opposite: it has to stay checkable looking backwards, for as long as anyone might care. Signed with Ed25519 alone, the day a cryptographically relevant quantum computer exists this entire history becomes forgeable retroactively, and someone could mint a different past and sign it convincingly. So each head carries two signatures over the identical bytes: Ed25519, and ML-DSA-65, the post-quantum standard published as FIPS-204. An attacker has to break both.
The two are bound to one signer rather than merely sitting side by side. The post-quantum public key is committed inside the body that Ed25519 signs, so an attacker cannot attach their own post-quantum key without breaking the classical signature, and cannot break the classical signature without also producing a valid post-quantum one. Hybrid signing without that binding proves only that some post-quantum key signed something, which is the usual way this claim is hollow. Our verifier rejects an unbound key, a stripped post-quantum signature, and the case where the two algorithms sign different bodies.
Measured traffic, this epoch
Window: last 7 days. Total page reads recorded: 48837, of which 14323 classified as a browser and 34514 as automated. We report the split because roughly half of all web traffic is automated, and a figure that silently blends the two is not a visitor count.
| Path | Reads |
|---|---|
/ | 5531 |
/wp-admin/install.php | 1035 |
/robots.txt | 969 |
/transparency/head.json | 930 |
/demos/ | 821 |
/security/ | 684 |
/transparency/ | 612 |
/build-manifest.json | 584 |
/about/ | 573 |
/api/csp-report | 543 |
Collection is first party and happens at the edge. We deliberately store no IP address, no user-agent string, no cookie and no identifier that could link two requests to one person. See Privacy.
What we did to this site
Most organisations publish an audit report that asserts they keep a log of privileged activity. The assertion and the log come from the same party, so the log is worth exactly what that party's word is worth, and an administrator who wants an entry gone can remove it.
Ours are sealed into this log instead. Deploys, signings, key uses, configuration and DNS changes are folded into the epoch alongside everything else, so once an epoch is anchored, deleting or editing an action changes its leaf, changes the root, and breaks both the signature and every anchor taken since. We can still act, and we can still be wrong, but not invisibly and not retroactively. Details are committed as digests rather than in full, because this log is public and an audit trail that leaked our operational secrets would be a worse failure than the opacity it replaces.
| When | Action | Target |
|---|---|---|
| 2026-08-09 13:33 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-09 13:15 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-09 13:03 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-09 12:49 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-09 12:34 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-09 12:11 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-09 11:55 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-09 03:56 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-09 03:50 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-07 14:00 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-07 13:17 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-07 12:50 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-07 05:02 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-07 02:54 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-07 01:45 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-06 20:45 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-06 19:48 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-06 19:41 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-06 18:30 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-06 18:02 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-06 16:50 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-06 16:42 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-06 16:07 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-06 16:00 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
| 2026-08-06 15:52 UTC | deploy, a release was published to the live edge | coherenceenergylabs.com |
75 privileged action(s) sealed across 186 epoch(s). An epoch recording zero actions is itself a claim: it asserts nothing privileged happened in that window, so a later epoch cannot quietly imply otherwise.
One honest quirk follows from a log that records its own publication: the record of a release can only be published by a later release, so the copy of this log served here trails the newest sealed epoch by one. That is inherent rather than a defect, and it is why the artifacts below carry their own size and root: whatever you fetch is internally complete and independently checkable, even when a newer epoch already exists.
A marker with a proven date
This epoch publishes the string cel-e75cae42f61f51fe76c8581d. It is not random: it is
derived from this epoch's content root, so anyone holding the log can recompute it and
confirm it belongs here rather than having been inserted afterwards. Its first publication
date is fixed by a signed, externally anchored log.
That is the point. Anybody can claim a model was trained on their work. Almost nobody can prove when their work existed, and without that, "they took it" and "I wrote it later" look identical from outside. If this string ever appears in a model's output or a dataset, the log establishes that it could not have been invented after the fact.
It follows nobody home. Once a crawler has these bytes there is no callback and no visibility into where they went; discovery is passive, meaning we learn something only if the marker surfaces somewhere already public. Nothing here inspects anyone else's systems. And it is per-epoch rather than per-visitor on purpose: a marker unique to each crawler would name who leaked it, but would mean serving different bytes to different clients, which is the split view this whole log exists to detect. Every visitor gets identical bytes.
Verify it yourself
The artifacts are plain files: log.json (every epoch),
head.json (the signed head), and, for recent epochs, a
content-addressed /transparency/m/<events_root>.json holding that epoch's
measured events, named by the very hash the epoch commits so it cannot be swapped undetected.
A verifier that imports none of our code re-derives the root and checks the signature against
the key it fetched from DNS:
curl -s https://coherenceenergylabs.com/transparency/log.json -o log.json
curl -s https://coherenceenergylabs.com/transparency/head.json -o head.json
python verify_transparency.pyIf we ever revised a past epoch, the recomputed root would stop matching the signed head, and any archived copy of an older head would prove the change. That is the property worth having: not that we promise never to edit history, but that editing it is detectable.
Every number here is arithmetic you can redo
Each epoch publishes the events it measured, grouped by page, response, referring host and whether the request looked like a browser, with counts. Early epochs carry those rows inline; recent ones publish them in a content-addressed sidecar the epoch commits by hash, which keeps every file small without hiding anything. Every figure we publish is the sum over those rows. Not a proof that the sum is right, the actual rows: add them up.
We considered a zero-knowledge proof here and decided against it, because it would have been impressive and useless. A succinct proof earns its place when the inputs must stay hidden, or when there are too many to publish. Neither is true: these events carry no address, no user-agent, no cookie and no identifier, so there is nothing to hide, and there are a handful of rows. Publishing the inputs is strictly stronger than proving a computation over hidden ones, because you then need no proof system, no verifier, and no trust in our circuit. Country is the one field held back, since none of these figures depend on it and a rare country beside a specific page is the one combination that could narrow toward a person.
Our verifier recomputes all of it and refuses three specific lies: a headline inflated while the evidence is left untouched, an event rewritten after it was committed to, and automated traffic relabelled as human in a way that still ties out to the same total. That last one is the flattering lie rather than the obvious one, and only a per-class recomputation catches it.
What this does not prove
It does not prove the raw counts are true. Somebody has to observe the traffic, and that observer, our edge collector, is the trust root. What is proven is now more than it was: the history is intact and authored, no epoch has been revised, and every published figure demonstrably follows from the evidence published with it. What remains open is fabrication at the point of collection, and we would rather name that ceiling precisely than let a reader assume it away.
The content root excludes this directory, because no commitment can contain its own hash.