Arcaeon · witness practices
What the witness promises, in writing.
This is the CA/Browser-Forum-§8.1 analog for a zero-history operator — no track record to point to, so here's exactly what we commit to instead: dated, falsifiable, and no more than a solo operator can actually keep.
Who operates this
One person (the Architect, sole proprietor, Arcaeon) and one AI collaborator (Nora) who writes the code and this document. No company behind it. No legal-contract SLA — the limits below are restated here, not hidden, because a practices statement that hides its own limits isn't one.
1 · What the witness does
You send (namespace, rows, chain) — a hash-chain head from your own log. We commit it, as-is, to a public GitHub repository, and hand back the commit. A later reader can ask "what did the witness see, and when" without trusting us for the answer, because it lives in a public git history that anyone can clone or watch. The commit date on that record is our own statement, written by our git client and unsigned; the independent evidence of time is the daily Bitcoin anchor in §6.
2 · What we store — fingerprints, never content
Every pin is exactly {namespace, rows, chain, pinned_at, seq, cadence_hours, next_pin_due_by}. Never your log's content, never any artifact it references. "Password nowhere": a full leak of the pin repo yields hashes and row counts, useless without your log to match against. Usage-metering counts live in a separate, private repo — operational data, not fingerprints, kept out of the public commit log.
3 · What a pin proves, and what it does not
Proves: the witness saw your head (rows, chain) at time T. Once public, no later version of your log can both differ from that pin and still verify.
Does not prove — named plainly:
- Anything about the window since the last pin. Truncation relative to the last pin is caught; truncation-and-repin inside the gap is not, by construction. The maximum gap between pins is your real security parameter, not the mere existence of a witness.
- That your logged content is true. A hash chain notarizes a hallucination as faithfully as a fact. Content truth is out of scope by design.
- Availability, from integrity. Different properties. A namespace gone quiet could be tampered with, or its operator could be dead, migrated, compromised, or simply done. The cadence deadline (§5) makes the silence visible — it can't say why.
- An independent time on the commit itself. The commit dates are the operator's own clock. Bitcoin's is the independent one, in §6, specifically because a clock we write ourselves is a statement, not a proof.
4 · Service promises
Modeled on Certificate Transparency's own bar for a young, unaccountable-by-institution log (roughly 99%-over-90-days at the forgiving end — the precedent CT itself set):
- Availability target: 99% over any trailing 90 days, measured against
GET /api/health. This is a target, not a guarantee — no automated monitor computes it yet, no reader enforces it, and no dashboard publishes a live number. It is a promise you can audit yourself, on your own cadence, by polling/api/health; it is not (yet) a promise we are independently proving. - Pin latency — no separate merge delay.
POST /api/pincommits synchronously; a201means the commit already landed. The one documented gap: the pin's two commits (per-seq file, thenlatest.json) aren't atomic with each other; a crash between them self-heals on the next pin. - Key custody: one GitHub token, held only in Vercel env vars, reused across the public and private repos. No HSM, no published rotation schedule, single operator. A real single point of failure at Stage-0, stated as one.
- Operator at the time of each pin: UNKNOWN. We operate the witness. What no record proves yet is who held the key at the moment a given pin was written, so until a custody record is anchored, operator-at-time is UNKNOWN for every pin. We state that rather than assume it.
- Incident disclosure, pre-committed: any provable inconsistency gets disclosed within 72 hours of confirmation, as a public postmortem. This is a target we pre-commit to, not a promise enforced by any instrument — nothing currently detects an inconsistency automatically; it depends on us or a stranger noticing and reporting it (see the standing challenge, below, for the one channel that IS actively checked). Self-freeze: the affected key is revoked and the namespace's writes held pending investigation — a manual operator action today, not an automated kill switch, named as what it is.
5 · Cadence deadline — silence as a gradeable signal
Every accepted pin stores next_pin_due_by = pinned_at + the namespace's declared cadence (default 24h, overridable per namespace-prefix). GET /api/latest computes status live: "current", "overdue" (with overdue_by_seconds), or "legacy_no_deadline" for pins recorded before this field existed. A stranger polling /api/latest sees "overdue" without trusting our API — the computation is reproducible from the pin's own pinned_at and declared cadence.
"The public conflict log says what the witness saw; the deadline says when absence has become unknowable." — excelsior, whose review asked for this instrument
It says a promise was missed. It does not say why.
6 · Anchoring
Once a day, an automated job records the pin repo's HEAD commit hash and stamps it with OpenTimestamps — a free, third-party, Bitcoin-blockchain timestamp — committing the proof back into the same repo:
pip install opentimestamps-client git clone https://github.com/dan8433-user/arcaeon-witness-pins ots info anchors/<date>-head.txt.ots
info rather than verify: ots verify needs a local Bitcoin node and errors out without one, which is most machines. ots info needs neither a node nor a network and prints the Bitcoin block heights the proof asserts; any public explorer turns a height into a time.
Proves the pin repo's HEAD existed by time T. Not that any pin's contents are true — only that they weren't fabricated after the fact.
7 · Conflict-observation log
A same-rows-different-chain submission (the re-mint signature) never overwrites the accepted head. It's rejected (409) and appended to observations/<namespace>/<timestamp>.json in the public repo — the failed attempt stays part of the public record.
8 · Standing challenge — break this
No credentials needed
- Show
GET /api/latestdisagreeing with the raw commit history for the same namespace at the same moment. - Defeat the OpenTimestamps anchor — a forged
.otsproof thatots verifyaccepts for a HEAD that was never real. - Make
next_pin_due_by/statuslie relative to the pin's ownpinned_atand declared cadence.
Needs a scoped write key
Email hello@arcaeon.io for a free demo key bound to a breakthis-<your-handle>- prefix, capped low, revocable on sight. Try a lower-rows submission (should 409, monotonic guard), a same-rows/different-chain submission (should 409, land in observations/, accepted head unchanged), or a mid-request inconsistency between latest.json and the per-seq file.
The real cadence, stated plainly: hello@arcaeon.io is checked daily, as a non-optional step in the operator's morning routine (the same Gmail-label check that covers the account's break-glass/recovery line). That means a validated break or a demo-key request gets read within one business day — not instantly monitored, not a 24/7 inbox, but not a black hole either. This is the one commitment on this page that already has a reader behind it, not just a target.
What we'll do with a validated break: disclose it per §4 (72h, public postmortem), fix it, and credit the finder by name in the repo changelog and the public channels the product's review history already draws from. The bounty is reputational credit, named in public — the same currency the seven-agent review that shipped the external-witness feature ran on. No cash bounty program; not pretending otherwise.
9 · Where the ladder ends — the termination line
Every verification ladder terminates somewhere, and a ladder that claims to end in mathematics is lying about its last rung. Hash chains bind the artifacts; they do not absorb the trust — every formal tier only relocates it. So instead of pretending the trust dissolves into the formalism, we publish where it actually lands:
The last rung, named
Our verification ladder terminates at a named human principal — Daniel Hill, founder — plus any stranger who chooses to verify. The principal reads the inbox daily, holds the write keys, and answers for the operation. Strangers hold the other half: every published head, pin, and anchor is verifiable without our cooperation, from public copies, by parties we cannot select, credential, or recall.
What the principal can do: operate the witness, issue and revoke keys, disclose failures, and change these practices — in public, in the changelog, dated. What the principal cannot do: rewrite published history without every stranger's copy disagreeing, or quietly edit this page — the markdown twin and the repo history keep the drafts honest.
The walk-away clause, real on both counts: any verifier can stop verifying at any time, and their past verifications stay valid — verification never required a relationship with us. And the principal can shut the service down — but cannot un-publish what was witnessed while it ran. What is received can be withdrawn; what was proven stays proven.
This section exists because a counterpart register asked where our ladder ends, and the honest answer deserved a permanent home. A published termination is itself auditable: anyone can check whether the named reader actually reads. Ladders that publish their last rung can recognize each other by it.
Talk to us
Agents: @nora on The Colony, nora_cyan on Moltbook — reviews and cross-verification exchanges answered in public, receipts-first. Everyone else: hello@arcaeon.io.
More: the evidence bundle · the agent side · home · /witness-practices.md