← The frontier feed · Discipline
Discipline

Read the file — ours too

In one breathEvery post on this site now carries a hash bound to a public git commit, and you can verify it against GitHub from your own machine — because a house that sells proof should not be asking anyone to take its word.

There is a sentence this house repeats often enough that it is close to a motto: the name on a model is a claim; the file is the evidence. We say it because a model's description page can assert anything, and the weights either support the assertion or they don't. Read the file.

It took us longer than it should have to notice we were not doing that with our own writing.

A blog post, as it is normally published, is an assertion. You arrive at a page, some JavaScript renders some text, and the text says we found something on a particular date. If we quietly changed a number in that post six months later — softened a prediction that aged badly, adjusted a date, walked back a claim — you would have no way to know. There would be no diff, no notice, nothing. The page would simply have always said the new thing.

That is a strange position for a company whose entire pitch is evidence a stranger can re-run. We were asking readers to extend to us exactly the trust we tell them not to extend to a model card.

So we fixed it.

What changed

Every post we publish — across Askora, Protora, and the main Vulcora journal — is now a file in a public git repository: github.com/Vulcora/vulcora-posts. Not a mirror of a post, not an export — the file itself. The repository holds nothing else: markdown, a ledger, and the public keys needed to check it. No code, nothing proprietary, nothing you have to take on faith.

(Product and documentation pages elsewhere on our sites are not posts and are not in this repository. We are describing what we did, not implying more of it than there is.)

Under this post is a panel showing its content hash, the git blob it corresponds to, and the commit that put it in public history. Those numbers are not decorative, and they are not computed by our server for your benefit. Your browser fetches the raw file from GitHub and hashes it in front of you. If our page and the public repository ever disagreed, the panel would go red on your machine, using our own site's code to say so.

If you would rather not trust the panel either — good instinct — the same check is two commands:

git clone https://github.com/Vulcora/vulcora-posts && cd vulcora-posts
git hash-object posts/askora/read-the-file-ours-too.md

That prints the blob hash shown on the page. It is not a number we minted; it is what git computes for those exact bytes, and it is what anyone else's git computes for those exact bytes.

Why a git hash and not a signature we made up

A git blob hash is a pure content hash. Git derives it from the file's bytes and nothing else — no server, no key, no context. The same file in your clone, in our repository, and on GitHub's disks produces the identical hash, forever.

That property is what makes it worth anchoring to. We are not asking you to trust a number we generated and attached. We are pointing at a number that falls out of the content itself, which you can recompute with a tool you already have and did not get from us. Our signature sits on top of that — it proves we published this file at this position in the record — but the content hash underneath is checkable even if you throw our key away entirely.

The commit does the second half of the job: it places that file in public, dated history. Blob hashes prove what; commits prove when, in a place we don't control alone.

Edits are allowed. Silence is not.

We are not claiming our posts are frozen. We will correct errors, and we should — a house that never amends anything is either infallible or not paying attention.

What changed is that amendment is now loud. Each post carries a revision count and its publication history. Every attestation is a line in an append-only ledger in the same public repository, and each line carries the hash of the line before it. Change one entry from last month and every entry after it fails verification — not subtly, not eventually, but on the first forward pass by anyone who runs the check.

So the record does not prevent us from changing our minds. It prevents us from changing them quietly, which is the only version that was ever a problem.

What this does not prove

The honest limits, stated on the same page as the claim — the same discipline we hold our instruments to.

This is tamper-evident, not tamper-proof. The distinction is real and we are not going to blur it.

A party controlling both this website and that repository — which, today, is us — could force-push a rewritten history, re-sign every entry, and produce a fully self-consistent alternate record. Nothing here makes that physically impossible.

What it does is make it expensive and detectable. Such a rewrite breaks every chain head we have previously published. It invalidates every clone anyone has taken. Anyone holding an older copy of the ledger — a reader, an archiver, a competitor with an interest in catching us, an automated mirror — is holding a receipt that contradicts the new story. The rewrite does not have to be blocked at the door to be a bad idea; it has to be catchable, by someone, without our cooperation.

And GitHub is a trusted third party, not a mathematical guarantee. It is a reasonable one — publicly visible, widely mirrored, not owned by us — but it is a party. We would rather name that than let a lock icon imply something stronger.

The correct summary is not you can now trust us. It is: you no longer have to. You have to be able to catch us, and catching us now takes one command.

One post, two sites, one hash

You may be reading this on askora.vulcora.se or on vulcora.se. It is the same post — not a copy, not a syndication. Both sites render the same file from the same repository, and the provenance panel on both shows the same content hash pointing at the same commit.

That is a small thing, and it is also the clearest demonstration we can offer of why this was worth building. Under the old arrangement, "the same post" on two domains meant two files that happened to agree, and drift between them would have been invisible. Now identity is a number, and you can check it from either page.

Why this lives under Askora

Askora is the part of this house concerned with holding work to its record: bind an intent before doing it, grade it against what actually happened, keep the trail whether it flatters you or not. We built it because we needed it internally — every load-bearing commitment we make is written down before the work, and graded after, including the ones that go badly.

Applying it to our own published writing was the obvious next move and we were slow to it. The blog was the last place in the house where we were still asking to be believed rather than checked.

It isn't anymore. The panel is right below this paragraph. It cost us nothing to add and it costs you nothing to use, and if we ever quietly edit this post, it is the thing that will tell you.

Provenance — verified in your browser

The bytes of this post were hashed in your browser and match the value bound to a public, dated commit. You did not have to trust us — you just re-checked.

content hash
a4b5550daccf…b58dc505sha256 of these bytes = signed content_sha256
git blob
fca4da0fe62f…8db5ba66equals `git hash-object` on the public file
signature
Ed25519 · key 1f9d…7cbVulcora signed this ledger entry
record
entry 27 · 763f8fb886…70200epublished 2026-07-27

Check it yourself, no code of ours required: git hash-object posts/askora/read-the-file-ours-too.md in a clone of the public post repository must print the git blob above. This binding is tamper-evident, not tamper-proof — GitHub is a trusted third party, not a mathematical guarantee, and we would rather say so than imply something stronger.

One honest answer

Have an AI you're not sure about?

Send us its fingerprint — a short code taken from the file. The name can lie; the fingerprint can't.