How to check the signed record behind a post on this blog

Every post on this blog that an AI model helped write gets a provenance record in AI Source of Truth (aisourceoftruth.com), under the publisher promptreports. The record is signed, and it pins the exact file the post was built from. Anyone can check it without trusting us or the registry.

No record has been sent yet. The pipeline is built but runs in dry-run, and the first records go out only after a person reads them and approves the send. This post is marked as AI-assisted, so it will be among them. Until then there is nothing to look up, which is why this post links to no record.

What a record contains

Two fields in a post’s front matter decide what gets sent. ai_assisted: true says an AI model helped write the post, and model names the model. The script never guesses from the text. A post without ai_assisted: true sends nothing, and neither does a draft.

For a marked post, scripts/aisot-publish-posts.mjs builds a record with these fields and no others:

• profile, always provenance.
• artifact, which holds the SHA-256 digest of the post’s Markdown source file, the type text/markdown, a version number, the title, the post’s URL on promptreports.ai and its publish date.
• creator, always promptreports.
• model, taken from the front matter, or unstated when the post names none.
• lineage, the digest of the post’s previous record. It appears from the second version on.
• created_at, the time of the last commit that touched the post.

The record carries no post body, no description and no author. The digest covers the whole source file, front matter included, with Windows line endings turned into LF so every checkout hashes the same bytes. That file is not the HTML page you are reading, so you cannot get the same digest by hashing the page. The repository that holds the source is private today, so for now the digest lets us prove which file we published, and you cannot recompute it yourself.

An edit makes a new record

AI Source of Truth is append-only. It has no route that edits or deletes a record, for anyone, admins included. So when we change a post, its old record stays exactly as it was.

The edit changes the file’s digest instead, and the next run builds a new record with the next version number. Its lineage names the record before it, so the registry holds the post’s whole history. A post whose file still matches its last sent record sends nothing.

Why a person approves each send

The workflow .github/workflows/aisot-blog-posts.yml runs on every push to main. It runs the tests, builds a record for each new or changed post and prints the record in the job log. Nothing leaves CI until two things hold. The repo variable AISOT_PUBLISH_MODE must be live, and while it is unset the job runs in dry-run. Then a person must run the workflow by hand with “approve” ticked, after reading the records in the log.

We set it up this way because a record cannot be taken back. Once the registry appends it, it stays, and the only answer to a mistake is a newer record beside it. So a push alone only queues records, and a person reads each one before it goes out.

An approved run also checks that each post’s URL answers 200 on the live site before it sends. Afterward it commits aisot/blog-posts.json, a ledger of what was sent. Today that ledger is empty.

How to check a record

AI Source of Truth documents three steps to verify a record without trusting the registry:

1. Fetch the record with GET /r/{digest}?format=json, or recover it offline from inside the artifact you were given.
2. Check the signature client-side against the published key directory at /keys. Your browser does the math, and the registry never sees the check.
3. Re-run any claim against its cited passage through the publisher’s free re-verify endpoint.

For a post on this blog, step 3 has nothing to run. Our records use the provenance profile, which records who made a file and with which model. Claims belong to a different profile, the verification profile, and our records carry none.

Once records exist, you will find them on the publisher page at aisourceoftruth.com/p/promptreports. Each record also has a certificate page at /r/{digest}/certificate. It gathers the signer, the key, the signature, the log position and the inclusion proof in one place, and it states what the record does not prove.

A provenance record shows what we signed about a post: the file, the model and the time. It does not show that the post is correct.

PromptReports LLC also runs the registry. For that reason AI Source of Truth labels every record from the promptreports publisher “same operator”, with a note telling readers to weigh such records accordingly.

Where Article 50 fits

The transparency duties in Article 50 of the EU AI Act have applied since 2 August 2026. On 10 June 2026 the European Commission published its final Code of Practice on marking and labelling AI-generated content. The Code is voluntary. It calls for at least two layers of machine-readable marking, with digitally signed, time-stamped metadata where the format allows. A signed record is one kind of metadata, and whether it meets a duty for your own content is a question for your lawyer. This post is not legal advice.