The receipts

Kepter's whole pitch is that your files stay on your Mac. That's not a feeling, it's a claim, and claims are cheap. This page is the rule we hold ourselves to: a claim doesn't go on kepter.app, in an App Store listing, or in a social post until it's verified against the shipping code and listed here first, with how we checked it. If a claim on the site and a claim on this page ever disagree, this page is right and the site is wrong; tell us.

Every test cited below was re-run the same day: 21 crypto tests, 98 shared-library tests, and 21 Mac-app tests, 140 in total, all passing.

Anything we couldn't verify against the code is left off this page. We do not write "we believe."

The network-call inventory

As of build 1.0.0 (2026-08-29), here's every place the shipping Mac app can reach the network, and what has to happen for each one to fire. This list is written to be re-checked, not counted and bragged about, because one line item (RevenueCat) is a placeholder today and will start making real calls once billing goes live. When that happens, this section gets re-verified and re-published before the "live" line changes anywhere else.

/auth/apple and /storage/presign (kepter-trust-kernel.fly.dev): fire only if you tap Sign in with Apple. Today the app kepter.app distributes is the direct, notarized download, and Sign in with Apple is gated out of it entirely; in the build you can download today, there is no on-screen path that calls either endpoint.
The Sparkle update check (https://kepter.app/appcast.xml): fires automatically only for a real .app bundle, and only asks; Sparkle does not auto-download or auto-install without you saying yes. It checks for a new version and verifies any download against a signature baked into the app before installing it.
RevenueCat SDK: configured, and able to reach the network, only when the shipped key is a real one. The key shipping in the app today is a test-store key, which is rejected before configuration, so the SDK makes no calls in this build. This is the one line item that will change: once a real key is set at launch, RevenueCat starts making its own calls at purchase time, and this entry needs restating then, not assumed.
Two links that open your browser, not a background call: the Settings "kepter.app" link and the "Manage plan" link both hand the URL to your default browser. The app itself does not fetch anything from them.
What we searched and found nothing: no calls to any AI vendor exist in the code path the shipping app runs. A dormant cloud reader, built against a possible future cloud-reading tier, exists in the shared library as an unused fallback; nothing in the app ever constructs it.
The cloud storage/replication code exists but is off by default: a multi-vendor backup path compiles and is tested, but returns an empty vendor list, and therefore never opens a connection, unless a specific environment variable is set. It is not set in the shipped app. The only way to trigger the cloud-restore code path at all is a command-line diagnostic flag, not anything a person can reach from the UI.

Reading happens on your Mac

Text extraction runs through Apple's on-device frameworks only: PDFKit for document text, Vision for OCR, and, on macOS 26 and up, Apple's on-device Foundation Models for the plain-words summary. None of these calls leave the machine. A search for AI vendor hosts and API key headers across the whole reading path turns up nothing wired into the live code path.

Voice memos: transcribed on-device or not at all

Audio and video get a transcript only if the Mac's speech recognizer reports on-device support. If it does not, Kepter skips transcription rather than falling back to a cloud speech service, which would be a real files-leave-your-Mac exception. The file is still kept and still findable by name; it's just not searchable by what was said.

No copy: Kepter keeps a record, not your file

Per file, Kepter's local store keeps three things: a thumbnail, the memory record (extracted text, dates, amounts, plain-words nicknames), and the path back to the original. It never writes the file's own bytes into its store. This was proven against the whole 2026-08-29 test corpus at once: every keepable file in the corpus was run through the real ingest path, and the store's blob directory stayed empty.

Deletion is honest: it goes to the Trash

Deleting an item in Kepter moves the real file to the macOS Trash, the same mechanism Finder uses. It's recoverable. Kepter only forgets its own record once it has re-checked that the file is actually gone from its path; a file that failed to trash stays visible.

Never a false merge: doubt splits, it never merges

Two documents are only ever treated as the same file when they are byte-identical or render identically. Everything else short of that goes through a resemblance check requiring a minimum count of shared rare phrases before two documents can even be compared, and a high resemblance threshold to call something a version. Near-identical images are never called duplicates; they surface as "related, you decide."

The test suites, plainly

Re-run against commit c64e29c on 2026-08-29:

suite	location	tests	result
crypto	`crypto/Tests`	21	all passing
shared	`shared/Tests`	98	all passing
Mac app	`kepterui/Tests`	21	all passing
total		140	all passing

The crypto suite covers key wrapping, content addressing, and chunked sealing. The shared suite covers the on-device reader, ingest policy, the no-copy guarantee above, and the storage-client request contract. The Mac-app suite covers document rendering and the duplicate/version clustering rules above.

Compiled 2026-08-29 against commit c64e29c of the Kepter Mac app source. Nothing on this page describes a plan, a roadmap item, or code that exists but isn't wired into what ships; anything we couldn't verify against the code was left off rather than softened.