Omniscio documentation
Browse all documentation
  1. Getting Started14
  2. Sessions & Agents129
  3. Inbox & Notifications66
  4. Projects & Tasks96
  5. Automation & Scheduling75
  6. Knowledge & Memory27
  7. AI Features70
  8. Integrations104
  9. Plugins & Marketplace34
  10. Cloud & Teams59
  11. Settings & Customization64
  12. Account & Billing28
  13. Troubleshooting78
  14. CLI & API Reference26
  15. Legal & Policies5
  16. Uncategorised17

Documentation updates (keeping the app's built-in docs current)

A copy of the documentation ships inside Omniscio, and the app quietly checks the published docs site for a newer one. When there is one, it downloads it, checks the whole thing arrived, and starts answering from it — and if anything at all goes wrong, it simply keeps reading the copy inside the app. There is nothing to press: one setting turns the checking off.

What it is

The documentation Omniscio answers from — the pages Ask Omniscio searches, the articles the Help Center lists — travels inside the app so it works with no internet at all. That copy is as fresh as the version of the app you are running, which means it can fall behind what the public documentation site publishes.

Documentation updates closes that gap in the background. The app asks the published site whether it has a newer documentation build, and if it does, downloads it and starts using it — without a restart and without you doing anything. The copy that came inside the app is never removed, so the app can always fall back to it.

Where to find it

  • The switch — Settings → Features → Keep documentation up to date. It is on by default.
  • Nothing to open — the check and the download happen in the background; there is no screen, no prompt and no notification.
  • The documentation itself — wherever you already read it: Ask Omniscio and the Help Center. Those are the surfaces that start giving newer answers once a newer copy is in use.

How it behaves

  • On by default. A fresh install checks for a newer documentation build shortly after it starts, and then at most a few times a day. Neither the check nor the download ever holds up the app: they start after the window is up and run in the background.
  • A newer build is downloaded in one go, then verified before it is used. The app checks that the download arrived whole, that it holds a sensible number of pages compared with the copy already in use, that the size is sane, and that every page belongs to the documentation. Only then does it become the copy the app answers from.
  • The copy inside the app is the floor. It is never deleted or overwritten. If you are offline, the site is unreachable, or the download is cut short or damaged, nothing changes and the app keeps answering from the copy it already had.
  • An older published build is never adopted. The app compares the published build's date with the copy it is currently using. If the site's build is the same age or older — the usual case right after an app update, which ships a newer library than the site had — the app keeps what it has and downloads nothing.
  • Nothing happens when there is nothing to do. If the site has not published a new build, or has not published one at all yet, the check is a quiet no-op and the next check comes later.
  • Only the official documentation site is contacted, over a secure connection, and a response that tries to send the app somewhere else is refused rather than followed. Pages that are not part of the public documentation can never arrive this way.
  • A download only replaces the copy in use once it is complete, because the new copy is built somewhere else and swapped in at the end. There is no moment where the app has half a library.
  • Switching it off stops the checking — the next check does nothing and no download is made; the app reads the copy inside it. Switch it back on and the checks resume on their own, with no restart.

For agents

  • Setting: docsLibraryAutoRefreshEnabled (boolean, default true), surfaced as the Features row docs-library-refresh-enabled; the feature switch id is docsLibraryRefresh in src/shared/feature-switches.ts. Read through standDown('docsLibraryRefresh', undefined, { defaultOn: true }) on every tick, so flipping the switch takes effect without a restart.
  • Subsystem: src/main/services/docs-library/ — docs-library-resolver.ts (which copy the readers get), docs-library-refresh.ts (the scheduled check and the atomic swap), docs-library-bundle.ts (verification), docs-library-ledger.ts (the outcome row). Boot step: src/main/startup/tasks/1605-documentation-library-refresh.ts.
  • Outcome ledger: one JSONL row per pass at <userData>/docs-library-refresh.jsonl; read it back with npm run scripts:run -- docs:refresh-log (--json for the raw rows). An empty ledger means the refresher has not run, not that everything is fine.
  • Published inputs: https://docs.omniscio.com/build-info.json (the build stamp) and https://docs.omniscio.com/llm-library/llm-library.bundle.json (the pages), both written by the help-site publish lane. The copy in use lives under <userData>/docs-library/.
  • Contracts: docs-library-refresh-contract.md (the obligations, under .claude/memory/contracts/) and docs-library-map.md (how the parts fit together, under .claude/memory/).

Related

  • Ask Omniscio — the in-app assistant that answers questions from this documentation.
  • Get Help (Helpdesk) — the help assistant and the article library it reads.
  • The Settings system — where app-wide settings live and how the Features section is organised.

Last verified 2026-10-08