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.

Why the library marks each document, not just each section

Caching is decided per section, so for a while the library reported it per section too: a badge saying the section was kept offline, or a switch saying you had opted it in. That is an accurate description of the rule, and it is the wrong answer to the question a pilot actually asks.

The question is not “is this section covered by the offline rule”. It is “is this certificate on this phone”, asked while an inspector is standing in front of the aircraft. A section badge cannot answer that. A document uploaded an hour ago is covered by the rule and may not have reached your phone yet; a section you opted in on the drive to the airfield is covered by the rule and may have downloaded three of its seven files. In both cases the header says one thing and the file on disk says another, and the header is the one you can see.

So each row carries its own mark. The section controls describe policy; the mark describes a file. When they disagree, the mark is the one to act on. Being unable to produce a document to an inspector is the whole failure the feature exists to prevent, and a member who cannot confirm the feature worked has lost most of its value even when it did.

The mark has three states and no more, because three is all Syndik8 can honestly tell you. It knows which files are on disk. It does not have a reliable “this one is halfway down the wire” signal, so there is no downloading state — a row that claimed to be downloading when the download had silently failed would be a worse lie than a row that admitted the file was not there. And “we could not read the cache” is kept separate from “the file is not in the cache”, because those call for different responses: the first is a shrug and a second look, the second is a reason to find a connection.

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

You can check, rather than hope. Open the library and read the marks down the right-hand edge of the rows: a tick means that file is on the phone, a cloud means it is not.
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. (The marks are on the syndicate library’s rows; My documents does not show them yet.)
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.