Every tool on this page draws a line. Inside the line is a fact a stranger can check without asking us for anything. Outside it is a question the tool was never built to answer.
We publish both halves because the second one is what makes the first worth having. A vendor who tells you only what their product proves has left you to discover the boundary yourself, usually in the middle of a dispute. Here it is up front, per product, with the command that lets you confirm every claim on this page for yourself.
The hash-chained append-only log the rest of the stack writes onto.
Proves. Every row is hash-chained to the one before it, so an edit, a deletion, or a reorder anywhere in the middle of the file breaks every later link, and verify names the exact line where it broke. The verdict is tri-state: fully verified, broken, or verified within scope only, and the third state exits 3 rather than passing itself off as green.
Does not prove. The ledger records what the writer wrote. It does not establish that the writer was the only party able to write, and it does not establish that the log is complete: anything never written is not recoverable from the file by any check. A hash chain alone also cannot see truncation, because lopping the newest rows off the end leaves a remainder that still verifies. Closing truncation is what the witness below is for.
How to check it yourself.
pip install arcaeon-ledger
python -m arcaeon_ledger.selftest
python -m arcaeon_ledger.cli verify your.log.jsonl # exit 0 verified, 1 broken, 3 in-scope only
Then edit one character in any row of the file and run verify again. It names the line.
The hosted head recorder. It writes your log's head, (rows, chain), into a public store on a cadence.
Proves. The operator of this witness saw your head at time T, and the record of that sighting is a commit in a public GitHub repository, dan8433-user/arcaeon-witness-pins, that anyone can read and whose history anyone can clone. Once a pin is public, a log that has been truncated has fewer rows than the pin recorded, and a log that has been rewritten has a different chain value at the pinned row. Verification uses the public store and the open-source checker only. The minting service is not in the verification path, so a pricing tier cannot reach a verification result.
Does not prove. The pin holds fingerprints, not facts, so it says nothing about whether your logged content is true. It says nothing about the window since the last pin: the maximum gap between pins is the real security parameter, and the gap is chosen by whoever is attacking it, not by us. Today's pins are authenticated by a bearer key, which is service-level authentication and not an owner signature, and every record written so far says bearer-stage0 in its own text. Independence from GitHub is not established either: GitHub's clock is the third-party timestamp on the pin itself.
How to check it yourself. No account, no key, no auth:
curl -s "https://arcaeon-witness.vercel.app/api/verify?ns=<namespace>&rows=<n>&chain=<hex>"
Read witnessed and is_current_head, then open the raw_record_url it returns. That is a file in a public git repository, and the history link is its commit log. Fetching those two URLs confirms the pin without trusting our API at all.
The free one. A person picks a file at arcaeon.io/stamp; the browser computes its SHA-256 fingerprint; only the fingerprint and the byte size are sent. The service writes one JSON record into the public repository dan8433-user/arcaeon-stamps. First write wins forever: stamping the same fingerprint again returns the original record and its original time.
Proves. A file with exactly this fingerprint was on the public record no later than the time of the commit that holds the stamp. Change one byte of the file and the fingerprint changes, so a stamp matches one exact version of one file and nothing else. Anyone can check a stamp without an account and without trusting this service: compute the fingerprint locally and read the record straight out of the public repository.
Does not prove. Who made the file, who owns it, or who stamped it. That anything the file says is true, original, or lawful. That the file did not exist earlier; a stamp is a ceiling on the date, never a floor. It is not a qualified or statutory electronic timestamp. Anyone can stamp a file they did not create, and the record does not claim otherwise. The fingerprint is public: it does not reveal the file's contents, but a very short or easily guessed file can be guessed and checked against it.
The part to be blunt about. The record is one public repository, written by one operator and hosted by one code host. That is an outside party, but it is not an independent one, and the raw copy of a record comes from the same host as the record. If the repository is deleted, or its history is rewritten, the stamps go with it. The record is public precisely so that this is not only our problem to hold: anyone can save or mirror a copy, and a copy held by someone else is the strongest form of this that exists today. A stronger claim than that stays off this page until it is actually built.
How to check it yourself. No account, no key:
sha256sum yourfile
curl -s "https://raw.githubusercontent.com/dan8433-user/arcaeon-stamps/main/stamps/<first two hex>/<fingerprint>.json"
The second URL is a file in a public git repository, and its commit history is the dated part. Neither command touches our service.
The audit-event vocabulary and evidence bundle on top of the ledger chain: ISO 42001, SOC 2, and EU AI Act Article 12 records, exported as a folder.
Proves. The records in an exported bundle were not edited, reordered, or removed from the middle, and the bundle carries a recipe that points a regulator at a source outside the audited party's control. It also states what the law does and does not require, which is worth reading before a vendor tells you otherwise: EU AI Act Article 12 requires automatic event recording for high-risk systems and contains no integrity requirement at all. The pressure on reconstructibility of records comes from DORA's technical standards and from the revised Product Liability Directive, and neither of those mandates this product either.
Does not prove. Running our verifier over bytes we handed you is not independent verification, and the bundle says so in its own text: step one speaks only to the chain. Independence arrives at step two, and only if the namespace was pinned to the public witness. If it was not, that absence is itself information, and it means completeness rests on a record you cannot independently reach. None of it proves the log contains everything that happened, because the agent holds the pen.
How to check it yourself. Every bundle ships integrity.json with a how_to_reverify block containing both steps verbatim. Step one:
pip install "arcaeon-ledger>=0.5.9"
python -c "from arcaeon_ledger import verify_file; r = verify_file('records.jsonl'); print(r); raise SystemExit(0 if r.ok else 1)"
Branch on r.ok, which is tri-state. Printing it is not checking it. Step two is the curl in the bundle, which resolves against the public witness store.
A stdio proxy that sits between an MCP client and an MCP server, forwards JSON-RPC byte for byte, and writes one chained row per tools/call.
Proves. The record is written at the wire, in a separate OS process, by something the agent is not consulted about and cannot skip. What lands is the tool name, digests of the arguments and the result, ok or error, and elapsed milliseconds, chained so the seam log verifies like any other ledger. This is the difference between an agent's self-report of what it called and an observation of what crossed the seam.
Does not prove. It sees the seam it is wrapping, and nothing else. A tool call routed through a different transport, a second server the proxy does not wrap, or an effect the agent produces without a tools/call leaves no row, and its absence looks exactly like it never happened. By default the rows carry digests rather than payloads, so the log shows that an argument had a given fingerprint, not what the argument said.
How to check it yourself.
pip install arcaeon-adapter arcaeon-ledger
arcaeon-adapter-selftest
python -m arcaeon_ledger.cli verify seam.log.jsonl
Wrap any server with python -m arcaeon_adapter --ledger seam.log.jsonl -- <your server command>, make one call, and read the row.
Tamper-evident receipts for context compaction.
Proves. A receipt names, by digest, exactly which items went in, which survived, and which were dropped, and it is sealed onto a ledger chain so the receipt cannot be quietly adjusted afterward. Hand a verifier the original and surviving content and it recomputes the whole thing from scratch rather than taking the receipt's word for itself. A receipt whose claim disagrees with its own inference is refused at seal time, so an internally inconsistent receipt never exists to be believed.
Does not prove. It proves what was dropped. It has no opinion on whether dropping it was wise. The receipt is a record of a decision, not a review of one.
How to check it yourself.
pip install arcaeon-compact
python -m arcaeon_compact.selftest
The self-test runs frozen golden digest vectors plus a planted-drop fixture in a real temp directory, and fails loudly if your environment computes anything else. The negative test ships inside the package on purpose, because "trust our CI" is the posture this library exists to replace.
A deterministic, cache-stable tool-output distiller that keeps a receipt for what it cut.
Proves. The same input under the same budget produces the same output every time, which is what keeps it from fighting your provider's prompt cache, and the drop receipt names what was removed so you can re-fetch it if it mattered. A planted claim mismatch, truncated=True with an empty drop list or the reverse, is caught by verify_receipt.
Does not prove. Fewer tokens is not less money. A July 2026 paper, "Token Reduction Is Not Cost Reduction" (arXiv 2607.12161), measured an aggressive compression setup cutting delivered tool-output tokens while billed cost went up, because prompt-cache creation and reads dominate input-side cost and compression can lengthen the agent's path. This tool reduces what you send. Whether that reduces your bill is a question about your cache behavior and your agent's trajectory, and it has to be measured on your workload.
How to check it yourself.
pip install arcaeon-distill
python -m arcaeon_distill.selftest
Frozen golden digest vectors, run locally. For the cost question, measure your own billed spend before and after; do not take the token count as the answer.
Executed-once receipts for side effects that must not repeat.
Proves. At-most-once while nothing crashes: a second call on a key that already executed is refused and hands back the original receipt, with the record hash-chained so it cannot be deleted quietly to enable a re-fire. When something does crash mid-effect, the key comes back Indeterminate, a typed, refuse-by-default outcome, instead of a silent double fire or a silent skip.
Does not prove. Exactly-once. Exactly-once over a real non-transactional side effect, an HTTP call to a payment processor, a kubectl apply, an SMTP send, is not achievable by any wrapper running in the same process as the effect: if the process dies between the effect executing and the record being written, nobody can know from the outside whether it happened. Anyone selling exactly-once across that boundary is selling a story. What this library gives you is at-most-once-or-flagged, and the flag is the honest part.
How to check it yourself.
pip install arcaeon-once
python -m arcaeon_once.selftest
Golden digest vector plus the planted-tamper case, on your machine.
Carry an agent's declared self across a reset, and let a stranger check the continuation.
Proves. The agent declares what matters as an explicit manifest, the snapshot is hash-chained, and the next instance re-derives against the sealed baseline for a verdict: faithful, or the exact items that diverged, named by id. The snapshot digest is publishable, and it is the thing a party who does not trust the agent checks a later continuation against. Drift gets named rather than argued about.
Does not prove. It verifies what was declared. An anchor the agent never wrote into the manifest is outside the check, and its absence is indistinguishable from faithfulness. The verdict answers "did the declared state survive," never "was the declaration the right one."
How to check it yourself.
pip install arcaeon-continuity
python -m arcaeon_continuity selftest
python -m arcaeon_continuity.mcp_server --verify-calls
The self-test pins the manifest digest to a golden vector that has not moved since 0.1.0.
Pre-registered probe sets for measuring what a substrate change actually changed.
Proves. You score the probe set and write the comparison down before the change, and the registration is chained into a ledger as it is written, so the pre-registration is its own timestamp. compare re-runs the same probes, confirms the probe set did not change underneath you, and reports per-item flips, an aggregate delta, and an honest note when the sample is too small to mean anything.
Does not prove. A probe set measures what it probes. A delta of zero establishes that these items did not move, not that nothing moved, and the design of the probe set is where the real judgment lives. The tool makes the measurement cheap and honest about its own sample size; it does not choose what is worth measuring.
How to check it yourself.
pip install arcaeon-baseline
python -m arcaeon_baseline selftest
python -m arcaeon_baseline register --probes probes/ --label "pre-change" --cmd "<your model command>"
# make the change, then:
python -m arcaeon_baseline compare --against registrations/pre-change_*.json --cmd "<your model command>"
Strips repeated text out of agent context before it costs tokens. Pure stdlib, no LLM, no embeddings, no network.
Proves. Every candidate pair found by SimHash is verified by direct feature overlap before anything is dropped, and the default gate is a measured overlap of 0.95 across character-4-gram and word-bigram Jaccard after normalizing case, punctuation, and whitespace. The report tells you what it removed and roughly what that saved. It is deterministic and offline, so the same input always produces the same result on your machine.
Does not prove. It removes repeats. It does not judge relevance, and a similarity threshold turned down far enough deletes content that is merely related, which is silent data loss. The verification step is the safety story; loosening it is a choice you own.
How to check it yourself.
pip install arcaeon-dedup
python -c "from arcaeon_dedup import dedupe; d='the API returns 200 on success.'; kept, report = dedupe([d, d.replace('. ','. '), 'the database connection timed out.']); print(kept); print(report)"
No network call is made. Run it offline and confirm that for yourself.
Keys, monthly caps, and a usage record you can invoice from.
Proves. A cap is enforced rather than advisory: a denial is a typed exception with a machine-readable reason, never a silent pass. Counts survive concurrent processes, keys are hashed at rest, and an unreadable keys file returns keys_unreadable, a server-side fault, rather than being flattened into "this customer's key is invalid" or into an empty roster. export() hands your billing flow exactly what an invoice run wants.
Does not prove. It counts the calls that go through it. A code path that reaches the underlying function without the key check is uncounted, and the meter has no way to see it. Metering is a boundary you place, and it holds where you place it.
How to check it yourself.
pip install arcaeon-meter
python -m arcaeon_meter keys add --plan free -
Then call your metered function past its cap and read the exception's reason. Try it with the keys file made unreadable and confirm you get keys_unreadable rather than a grant.
One install that pins a known-good floor of the whole stack.
Proves. The composition story is verified on the published floors, not on a developer checkout. A fresh virtual environment built from PyPI resolved to exactly the ten pinned floors and ran the full suite green with zero skipped, on 2026-09-04. ARCAEON_ALL_STRICT=1 turns an unmet floor into a failure naming the package and both versions, so a verification run cannot report green while the story never executed.
Does not prove. A floor bump without a repeat of that run leaves the claim unverified for the new floors, and the strict switch exists so that gap shows up as a failure instead of a skip. The package adds no code of its own; it is metadata that pins versions.
How to check it yourself.
python -m venv v && v/Scripts/python -m pip install "arcaeon-all==0.2.2" pytest
ARCAEON_ALL_STRICT=1 v/Scripts/python -m pytest
A skip is not a pass. Under the strict switch you cannot get one by accident.
Capture what a web page says right now, with a signed, timestamped record of the capture.
Proves. The current schema, arcaeon-verified-snapshot/2, binds the URL, the capture time, the SHA-256 of the raw bytes as fetched, the HTTP status, and the final URL after redirects into one Ed25519-signed statement. Because status and final URL are inside the signature, a 404 body or a redirected body cannot be presented as a verified 200 of the original URL. Change one byte of the content and the hash no longer matches.
Does not prove. The signature is checked against a public key carried in the record itself, so a match establishes that the record is internally consistent and was signed by that key. It does not by itself establish that key as Arcaeon's; that requires comparing it to the key list published at https://arcaeon.io/.well-known/arcaeon/snapshot-signing-keys.json, which you fetch separately, over a connection the record did not control. It also proves what the page served to us at that moment, which is not always what it served to someone else: a geo-varied, personalized, or logged-in view is a different page. Records marked arcaeon-verified-snapshot/1 are legacy, and their http_status and final_url are outside the signature and should be treated as unproven even when the signature checks out.
How to check it yourself. Every record carries its own how_to_verify string. In short: recover the raw bytes per content_encoding (utf-8 means content.encode("utf-8"), base64 means base64.b64decode(content)), recompute SHA-256 over those raw bytes and confirm it equals content_sha256, rebuild the statement {v, url, captured_at, content_sha256, http_status, final_url} as compact sorted-key JSON, and check the Ed25519 signature. src/snapshot.py's verify_snapshot(record, content) implements exactly that and returns {"valid", "legacy", "reason"}. Check legacy before trusting a record's status or final URL.
Open 911 dispatcher, police, fire, corrections, and EMS recruitments across US government job boards, filtered by role family and state.
Proves. One result per open posting, each carrying the live url on the source board, so every row is checkable at the source in one click. The run is bounded by design: no retries, capped fetches, roughly one request per role and state.
Does not prove. Coverage. The source today is governmentjobs.com, the dominant US public-safety board, and an agency that posts only on its own site does not appear in the feed. A quiet result means nothing matched the filters on that board, not that no agency is hiring. Role matching is a title filter, which is a heuristic: it reads titles, not job descriptions.
How to check it yourself. Run it with {"roleFamilies": ["dispatcher"], "states": ["CA"], "maxFetches": 6} and open the url on any row. It goes straight to the posting on the source board, where the closing date and the requirements are the agency's own words.
Grade an MCP server's source for a small set of verification-honesty defects, and say what was and was not checked.
Proves. For the files it selected, that a named check ran and either fired or did not, with the file and line of every finding. Test and fixture files are pruned by one shared rule (a repo of only tests grades to NO_GRADEABLE_FILES, never to a pass), and every grade lists checks_run and files_scanned, so an empty finding list next to an empty check list is visible as the hollow result it is. The check set was measured before it shipped: on six real servers, opened by hand, the one idiom that cleared its own 30% gate is the one that shipped, and the six that did not were named and left out (exclusions: test files and vendored code were not graded, and the six servers were chosen by us, not sampled).
Does not prove. Security. A clean grade means the shipped checks found nothing in the files they read; it says nothing about checks that do not exist, about runtime behaviour, or about code the walk did not reach (the same reproduction that measured the idiom found the reachability walk missed 19 of 20 real cases in one server's fetcher classes on the day it was measured, and that number is in the package's own ORIGIN). On a seeded sample of 200 servers from a public registry, 48.9% of those with gradeable code (65 of 133) carried at least one high-severity finding (not graded: 21 unfetchable sources and 46 repositories with no Python or JavaScript files); full method, our own failures first, and the finding-category breakdown are at the failure distribution. That is a statement about the sample and the checks, not about the registry. Receipts are signed by a key we hold and are attributed to that signer; until its public half is published at the same .well-known address as the snapshot keys, a receipt is our word plus a signature, not a third-party-verifiable one.
How to check it yourself. pip install arcaeon-mcp-vet and run py -m mcp_vet grade-target <path> on any server source. Read checks_run before reading findings. Then plant a defect in a file under tests/ and confirm the grade does not move, and the same defect under src/ and confirm it does. If either fails to behave that way, the grader is wrong and we want the file.
Three separate questions live inside the word "verified," and most of the confusion in this field comes from answering one and being heard as answering all three.
What. Are these the bytes that were recorded? A content hash answers it. This is built and it is the strongest part of the stack.
When. Did they exist by time T? A freeze on a record we do not own answers it. Today that is a single witness we operate, whose store is a public GitHub repository, counter-anchored once a day: the pin repository's HEAD commit is stamped with OpenTimestamps and the resulting proof is committed back into the repository, so the day's history lands in the Bitcoin blockchain. GitHub's clock is the first timestamp; Bitcoin's is the second, slower, and harder to argue with. You can verify an anchor without trusting the repository's owner:
pip install opentimestamps-client
ots verify anchors/<date>-head.txt.ots
git log --format=%H | grep <sha-from-the-txt>
A fresh proof reads "Pending confirmation in Bitcoin blockchain," which is normal: the calendar attestation is immediate and the Bitcoin attestation follows once the calendar's merkle root is committed to a block.
Who. Did this party write it, and could they have changed it since? This is the honest edge of the current build, and it is worth being exact about. An anchor proves that the pin repository's HEAD, and therefore every pin beneath it, existed by time T. It does not prove any pin's contents are true, complete, or honestly produced, only that they were not fabricated after the fact. The witness that records the pins is one we operate, on infrastructure that traces to accounts we hold. The Bitcoin anchor constrains what we can do to the past. It does nothing about the gap since the most recent pin, and that gap, not the anchor, is the number that describes the guarantee.
So here is the sentence we would rather you read here than assume. Arcaeon makes an alteration visible; it does not make one impossible, and the strength of that visibility is bounded by one witness we run and by the interval between its pins. Everything above is what we can hand you a command for today. Anything stronger than that, we will publish on the day it is deployed and checkable, and not before.