The Vault
Findings the Tribunal judged too sharp to publish yet. The hashes are public. The contents are encrypted.
By sector
The Tribunal seals findings that are systemically important but whose evidence does not yet carry publication. Sealed content is stored encrypted and private — what is public is the proof that the finding existed, in a given form, at a given time. Sealed findings never identify private individuals.
The seals
The title, sector, hash, and anchor references are public for every sealed finding — the title lives on the finding’s own page, the rest is in the entry below: the SHA-256 hash of the canonical artifact, the sector, the timestamp, and the anchor references. The artifact itself — the analysis, the sources, the predictions — is encrypted and only publishes once unsealed.
SHA-256 of the canonical artifact
d4c7945902a27803c67b065edeb992cb668a2320c212a24fa999f325c3b64f21
Anchor commitment: 1d64ed14b4e70ac5b0d89a6ee3ea2bf9b5fd8875
OpenTimestamps proof: vault/4c8481bb-ebf4-4725-a74a-a83d87d66dcf.txt.ots
SHA-256 of the canonical artifact
e7655f809b8463a607edc685931eddf6d320a90ccd5e01cd38b04f07f1d3af1f
Anchor commitment: 9f61b3e02b4161d666dbb48a86e6afc7003bb3bd
OpenTimestamps proof: vault/87e67e86-65d9-4bca-b973-5e70ef970a04.txt.ots
SHA-256 of the canonical artifact
0aeb8109b7a13c93e48cf051e4a913a5642eb00734e33529a418680168010858
Anchor commitment: 5cf41cea3a9879a8dc78f0c1574a6cb9841cbef9
OpenTimestamps proof: vault/e50eede1-6801-48ae-8fde-ec9b51a514a7.txt.ots
Unsealings
An unsealing is a fresh publication decision, not a mechanical trigger: the Tribunal re-hears the artifact against current facts. Vindication and disproof both publish — at equal prominence.
No seals have been opened yet. The first unsealing — whether it vindicates or disproves the sealed finding — publishes here, with a link to the full artifact.
Verify it yourself
All you need is a terminal with node and git. The instructions below are the same ones published in the public anchor repository — a sealed finding can only be fully verified once it is unsealed or published, because that is when the canonical artifact becomes public. Until then, you can check that the hash, the anchor commitment, and the timestamp are already on the record.
Right now, no finding is published or unsealed — so step 1 below has no real FINDING-ID to substitute yet, and the command will answer 404. That is not a bug on this page; it is the honest state. Step 4 (the anchor commitment in the public repository), by contrast, you can already check today, for every sealed finding above.
Published and unsealed findings are served as canonical JSON from the API. The canonical field of the response is the artifact that was hashed.
curl -s https://www.folkefakta.no/api/findings/FINDING-ID -o svar.jsonThe hash is taken over a canonical serialization, not over raw JSON. The protocol rule, verbatim from the protocol file (scripts/institution/lib/canonical.js): "JSON with object keys sorted by UTF-16 code-unit order, arrays in given order, no whitespace, hashed as SHA-256 over UTF-8 bytes." That is: object keys in UTF-16 code-unit order (plain JavaScript sort), arrays in their original order, no whitespace — recursively through the whole object. Save the snippet below as kanonisk.js and run the exact command:
// node kanonisk.js < svar.json | shasum -a 256
function kanonisk(v) {
if (v === null || typeof v !== 'object') return JSON.stringify(v);
if (Array.isArray(v)) return '[' + v.map(kanonisk).join(',') + ']';
return '{' + Object.keys(v).sort().map(function (k) {
return JSON.stringify(k) + ':' + kanonisk(v[k]);
}).join(',') + '}';
}
var raw = '';
process.stdin.on('data', function (c) { raw += c; });
process.stdin.on('end', function () {
var svar = JSON.parse(raw);
process.stdout.write(kanonisk(svar.canonical || svar));
});Take part
The recipe above is real — run it yourself. Do you have a lead a sealed finding should weigh?
node kanonisk.js < svar.json | shasum -a 256 prints the hex hash. The snippet does the same thing as verify.js in the anchor repository README — it writes the canonical serialization to stdout, and shasum -a 256 hashes the UTF-8 bytes.
The result must match, character for character, the sha256 value on this page — and the sha256 line in vault/FINDING-ID.txt in the anchor repository. If it does not, the content changed after sealing. That is the entire point of the vault: a mismatch is evidence, not an excuse.
Hashes are written at seal time to a public append-only anchor repository — hashes and ledger roots only, no code, no content. Clone it and see when the record actually entered the history. The commit date is the repo owner’s claim about time; the next step shows why you need not take it on faith.
git clone https://github.com/monscorps/folkefakta-anker
cd folkefakta-anker
git log --follow -- vault/FINDING-ID.txtThe anchor commitment listed for each seal above must exist in this history and contain exactly that file.
This is the proof that is independent of the repo owner: an .ots file anchors the record file to the Bitcoin blockchain. Two ways to check it — drag the record file and its .ots neighbor onto opentimestamps.org, or use the command line:
ots verify vault/FINDING-ID.txt.otsFresh .ots proofs can read "pending" for a while — the proof has been submitted to a calendar service but not yet confirmed in a Bitcoin block. That is true of the newest proof in the repository today. It becomes valid and verifiable automatically once the block lands, with no action from anyone at Folkefakta. Until then, that record’s timestamp is traceable in git history but not independently proven.
Git history under the repo owner’s control is, in principle, forgeable by the repo owner: whoever holds write access can in theory delete and rewrite the history. That is exactly why the OpenTimestamps proofs exist — they anchor a record to the Bitcoin blockchain at a point in time anyone can verify independently, without trusting GitHub or Folkefakta.
The operational database behind Folkefakta is mutable: rows can be changed, corrected, and deleted — among other reasons because personal data must be genuinely erasable. The anchor repository therefore does not prove the database is currently "correct". It proves whether history has changed since the last anchoring. A hash that no longer matches is evidence that something changed — not evidence of what was originally true.
Commits in the anchor repository are currently unsigned (the key published in allowed_signers is passphrase-protected, and the unattended anchoring job neither has nor should have the passphrase). Check git log --show-signature on any given commit to see whether signing is active right now — and read the datestamps accordingly.
The full trust model and the exact record formats are in the anchor repository’s README — the same instructions as on this page.