Skip to content
The world does revolve around you.

Doctor – the Hub dashboard#

Doctor is the Ostler Hub's local control panel. It lives at http://localhost:8089/doctor on the Hub Mac and bundles diagnostics, configuration, pairing, corrections, and a handful of operational tools into one place. This page covers what each panel does and when to reach for it.

Doctor binds to 127.0.0.1 only. It is not reachable from another device on your network unless you specifically tunnel to it (e.g. via Tailscale). The hostname localhost is hardcoded; there is no setting that exposes Doctor publicly.

Opening Doctor#

On the Hub Mac, open your browser to:

http://localhost:8089/doctor

That works in Safari, Chrome, Firefox, Arc, or anything else. Bookmark it; you will come back often.

If the page does not load, the Hub services are not running. See troubleshooting: Hub starts but the diagnostic dashboard reports failed services for the cycle-services flow.

The panels#

Health#

The top panel. One row per Hub service. Each row shows:

  • A coloured dot: green (healthy), amber (slow / catching up), red (failed).
  • Service name and version.
  • Last-checked timestamp.
  • A copy-paste command if the row is amber or red. This is usually a launchctl bootout / bootstrap cycle, or colima start, or ollama pull <model>.

Healthy services include:

  • The Hub API server (ostler-api).
  • The wiki compiler (ostler-wiki).
  • The Doctor service itself (ostler-doctor).
  • Qdrant (vector store).
  • Oxigraph (graph store).
  • Redis (cache + message bus).
  • Ollama (local AI engine).
  • Each messaging bridge you have wired up (iMessage, WhatsApp, email).

A red row almost always has a copy-paste fix next to it. If it does not, escalate via Contact.

Imports#

Shows what is in your knowledge graph and what is queued to come in.

  • Current totals – count of people, organisations, places, conversations, AI conversations, events, todos, notes, bookmarks. Click any count for the wiki listing.
  • Import history – every import run, with status (ok / partial / failed) and a row count.
  • Watcher status – the four-hourly ~/Downloads scanner. Last run time, files found, files imported.
  • Manual import – paste a path or drag a ZIP onto the panel to import on demand. Equivalent to ostler-import <path> from the Terminal.

Pairing#

Manages paired iOS Companions.

  • Pair iOS device – generates a one-time QR code. Scan it with the Ostler iOS Companion on first launch. The QR encodes the Hub's LAN address, the Tailscale address if set, a short-lived pairing token, and the cryptographic material the Companion pins. See pairing the Companion for the full flow.
  • Manual code entry fallback – if the QR scanner cannot read the code, a six-digit short code is also shown. The Companion has a manual-entry field underneath the camera viewfinder.
  • Paired devices – every iPhone, iPad, or future device currently paired. Each row shows the device name, pair date, last contact, and a Revoke button. Revoking is immediate; the Companion drops to a "this device has been unpaired" screen.

Notifications#

The morning brief and evening wrap configuration plus delivery status.

  • Morning brief – tick to enable, pick a delivery channel (WhatsApp, iMessage, email), pick a time (default 9 am). The brief covers today's calendar, people you have not heard from, threads you owe a reply on, birthdays this week.
  • Evening wrap – same shape, default 6 pm. Covers what got captured today and a heads-up on tomorrow.
  • Delivery log – every brief sent, its delivery status, and the channel used. Failed deliveries show here with a reason; the v1.0 implementation surfaces failures here rather than swallowing them as silent warnings.

Messaging channels#

One row per messaging integration. Each row has:

  • An on / off toggle.
  • The allow-list of phone numbers and contacts the assistant will respond to.
  • A connection-status indicator.
  • Channel-specific controls (e.g. Re-pair WhatsApp Web for the WhatsApp channel; Sign in to Gmail for the email channel).

The default allow-list is empty for v1.0; only you can talk to the assistant until you add others.

Corrections#

The data-correction surface for the wiki. See wiki: Doctor corrections UI for the full flow. Common operations:

  • Merge or split duplicate people.
  • Rename a person, organisation, place, or topic.
  • Reclassify a conversation's privacy level.
  • Exclude an entity from the wiki and the assistant.

Every correction is logged in ~/.ostler/corrections.log.

Ollama models#

Manage the local AI models Ollama holds.

  • Installed models – every model currently on disk, with size. Click a model to set it as the active assistant model, or to delete it.
  • Pull a new model – paste a model identifier (e.g. qwen3.5:9b, gemma4:e2b, qwen3.6:35b-a3b). The pull happens in the background; progress is shown inline.
  • Auto-selected model – the row showing which model the assistant currently uses. The installer picks this based on your RAM at install time; you can change it here.

For the model-tier story – which RAM tier gets which model – see first run: AI model selection.

Privacy posture#

A read-only summary of the privacy decisions baked into your install. Useful for verifying the install is in the shape you think it is.

  • FileVault status (encrypted / not).
  • Passphrase set / not.
  • Recovery key stored in Keychain / not.
  • TLS certificate fingerprint for the Hub API.
  • The default privacy level (L0 / L1 / L2 / L3) for newly-captured conversations and AI conversations.
  • The list of TCC permissions granted to the Hub and its child processes.

What Ostler knows#

A structured summary of every category of data the Hub holds about you. Useful sanity check after an import run, or when explaining the product to someone else.

The view groups by category (people, organisations, places, conversations, events, etc.) and shows the source of each fact – which import run, which conversation, which FDA extraction. Right-click an entity to jump to its wiki page.

Acknowledgements#

The third-party attribution catalogue – every open-source component shipped inside the Hub, with its licence and version. Mirrors ~/.ostler/THIRD_PARTY_NOTICES.md. The iOS Companion has its own Acknowledgements view in-app that mirrors the same catalogue.

Send by email (optional, off by default)#

A debug-only flow for sending the install posture and a redacted log to [email protected] if we ask for it. Off by default; you click the button to fire it. Every send shows the payload before you confirm, and the payload contains:

  • Container states, model names, service health, disk usage, OS version.
  • Hub version, install date, recent error codes.

The payload deliberately excludes: knowledge-graph data, contact names, conversation content, email content, calendar details, file contents.

A local log of every payload ever sent lives under ~/.ostler/diagnostics-sent/. You can read every previous payload there at any time.

Configuration UI#

Most of ~/.ostler/config/.env is editable from Doctor's Settings tab. The same applies to ~/.pwg/settings.yaml (the conversation-processing config – locale, coaching tone, redaction policy, model routing). Doctor is the friendlier surface; the files on disk are the canonical source and survive a reinstall.

If you edit the file by hand, click Reload settings in Doctor to pick up the change without restarting the Hub.

Telemetry – there isn't any#

Doctor does not phone home. Every panel above reads from local state. Even the Send by email flow requires a manual click; nothing leaves the Mac without you initiating it.

If you want to verify, disconnect from the internet and reload Doctor. The Health panel will flag a degraded state on services that need network (the wiki compiler does not, the messaging bridges may), but Doctor itself works fine.