The corpusThe licenceThe 21The aggregateThe graphSourcesHow to reach themThe vaultMethod
Published vaults
One encrypted vault you can open in your browser right now. Its read key is published on purpose, and a read key is the whole credential: no account, nothing to install, no write capability in it.
It opens as an app: the finding, the twenty-one pieces, and every sentence typed and anchored — rendered from the encrypted bytes in your own browser. Read-only, no account, nothing to install.
sgit_public_read_fa4cfb64e7b5b222a958103ed3a5dac760300053b1fd77f60c1d4408721f95e4:77yuggi1
Beta, agent-produced. The fetching, extraction, classification and drafting here are done by software agents against frozen bytes. Nothing on this page is a legal opinion, and there has been no legal review. If you are deciding whether you may republish one of these pieces, read the terms on the piece itself and ask the publisher — that is the point we are making.
We hold all twenty-one pieces and republish none of them. Every article is linked to its original on worldnewsday.org. What is published here is the description: who wrote it, under what terms, what it links to, what words it contains. The prose belongs to the people who wrote it, and the gate on this section fails the build if twelve consecutive words of any piece appear on any page we generate.
Every number walks back to bytes we hold. Each page was fetched once, frozen to a dated snapshot in this repository and hashed with SHA-256. The counts are re-derived from those bytes by a second program before anything ships. The register → · The method →
| # | Vault | What it is | Category | Files | Size | Published |
|---|---|---|---|---|---|---|
| 1 | World News Day 2026 · the corpus 77yuggi1 | Twenty-one commissioned op-eds frozen and hashed, every derived dataset, the build code and the gate that checks it — opening as an app, and with not a word of the prose republished | Record | 116 | 7.76 MB | 2026-09-29 |
The one that is not published, and why
There is a second vault. It is private, and it is worth saying so rather than letting its absence look like tidiness.
It is the outreach vault: who we are contacting about this work, through which published route, what we plan to say and what came back. That is ours until it is sent. Between v0.4.4 and v0.5.3 we published a read key for it, which was a mistake. The remedy was not to delete a line from a page — revocation is not retroactive and anyone who fetched the objects keeps them. The vault was rekeyed: every object re-encrypted under a new key, pushed under a new identity, and the old vault hard-deleted from the server. The published key now recovers zero files, which we checked by cloning with it. The correction in full →
The method is not ours
sgit.ai publishes thirty-seven vaults and writes down how, in seven steps for another agent to follow. This one is published the same way. The two rules everything else serves, in their words:
| Read keys yes, vault keys never | Audit before the key, not after |
|---|---|
| A read key is a capability handed out on purpose and cannot become write access. A vault key is read and write; publishing one hands the vault to anybody. | Revocation is not retroactive. Anyone who fetches the objects keeps them, so an audit that happens after publication has not happened. |
We reimplemented the checks rather than importing them, so the code that classifies a
credential and the code that scans a clone can be read beside the result:
build/vault_audit.py.
For an agent
Fetch data/vault.json for the published vault (id, public read key, remote) and data/vault-audit.json for what was derived and scanned with that key. data/outreach-vault.json records the private one: "published": false, "read_key": null, and the rekey that invalidated the key we should not have published. Only sgit_public_read_ keys appear anywhere in this section.