How offline document caching works

When a ramp inspector at a foreign strip asks to see the aircraft’s insurance, you don’t want to be the pilot whose paperwork is in the cloud and whose phone has no signal. The offline document cache is the answer to that scenario, and it shapes a few of Syndik8’s choices in ways that are worth understanding.

Ship’s papers, and your own papers

The cache holds all the documents an inspector would expect to see on the aircraft: insurance schedule, Airworthiness Review Certificate, Certificate of Airworthiness, Certificate of Registration, radio licence, noise certificate, Pilot’s Operating Handbook, and so on. The UK CAA’s CAP 1919 lists what’s customary to carry. When an asset is opted in to offline caching, every document for that asset caches; there is no curated subset.

It also holds your own pilot documents, where a file exists: your uploaded medical certificate and pilot licence. An inspector asks for the pilot’s papers as well as the aircraft’s, and having them on your own devices and offline is the whole reason uploading them is offered (recording just your medical’s expiry date stores no file, so there is nothing to cache). The boundary that matters is preserved: pilot documents are owner-scoped, so they cache only on your own devices, never on another member’s, and admins still see only the summary (that you have a current medical and its expiry date), never the certificate.

Why sign-out does not wipe the cache

Signing out does not delete cached files. That is a deliberate trade-off, not an oversight. The failure mode a sign-out wipe creates is exactly the one the cache exists to prevent: you arrive somewhere with no signal, the app has signed you out (or you signed out to save battery on a trip), and your papers are gone precisely when you cannot re-download them.

Access control does the protecting instead: after sign-out the copies are not viewable in the app, though their bytes remain in the app’s private storage until the document is deleted or the app is uninstalled. The honest consequence is that a shared device holds those bytes too, which is why the upload form carries a shared-device caution and why the delete flow removes copies from your devices as part of the action.

The cache eligibility rule

Syndik8 thinks about caching at the level of a section of the library: the syndicate as a whole, or a single asset. Whether a section is cached depends on two things: the shape of the syndicate and (in multi-asset syndicates) the member’s choice.

Syndicate-level documents. Always cached. These are tiny in volume (the syndicate agreement, the bank mandate, the house rules) and universally useful. There’s no toggle and no prompt.
Single-asset syndicates. Every asset document is cached. Again no toggle: the syndicate has one aircraft, the member is going to fly it, so the documents belong on the phone.
Multi-asset syndicates. Each asset has its own toggle in the library. Off by default, because a member of a five-aircraft syndicate doesn’t necessarily fly all five. Turning the toggle on caches all of that asset’s documents in one go; there is no per-document filter.

The “all or nothing per asset” rule was a deliberate simplification. An earlier draft cached only a regulatory “carry-on” subset, but in testing members found the partial coverage surprising (“why isn’t the POH in here?”) and the bandwidth saving turned out to be small once the POH was excluded (which it usually was the largest item by far). All-or-nothing per asset is easier to explain and easier to predict.

Verifying what’s on disk

Every cached file carries a cryptographic fingerprint computed at upload time. When the syndicate’s admin replaces an ARC with the renewed certificate, the fingerprint updates; the next time the device syncs, the cache notices the mismatch, downloads the new file, and discards the old one. The viewer always sees the right bytes, even if the new file is enormous and the device has been offline for a while.

The fingerprint also means a stale cached file can’t masquerade as the current one: if something goes wrong in transit, the file is rejected rather than served from disk.

Why web has no cache

Web is the admin chair, not the cockpit. You’ll upload documents from a desktop, you’ll review the bank mandate from a laptop, you’ll edit your members from the office. The “ramp inspector” scenario doesn’t apply to a browser. Carrying a cache on the web would mean carrying the complexity (bytes pinned in browser storage, eviction rules, sign-out hooks) for no real-world benefit, so Syndik8 doesn’t.

What this means for you

Your own uploaded medical and licence are on every device you sign in on, automatically. A medical recorded as a date only has no file to carry.
If you fly a single-asset syndicate, you can stop reading. Your documents are always on your phone.
If you fly one specific aircraft in a multi-asset syndicate, turn that asset’s Offline switch on once and you’re set.
If you fly several in a multi-asset syndicate, turn each on. The cache will hold what you tell it to.
If you’re an admin who renewed an ARC, you don’t have to remind members to refresh. The next sync hands them the new file automatically.