Operations

このコンテンツはまだ日本語訳がありません。

The Operations console is where you run and watch a project’s background jobs — the work that turns incoming communications into registers, the graph, and health. You reach it from a project’s admin area; it shows live counts and refreshes every few seconds.

Most work is split into self-describing operation cards. Each card tells you what it does, whether it acts on This project or the Whole workspace, whether it calls an LLM (No LLM, Haiku, or Sonnet), and — for LLM jobs — a cost estimate before you run it. Cards that don’t use an LLM are marked Free; LLM cards show “≈” or “up to” a dollar figure. Once an op has run, its estimate is calibrated from your real usage history; until then it shows an uncalibrated estimate.

What an operation covers

An operation you start works only on what you can see. That covers the inbox sweeps, the backfills, the relation and duplicate jobs and the repairs, both here and on the Duplicate review page. An item or record your clearance hides from you is left exactly as it is. The operation does not change it, does not send it to the AI model, and does not count it or name it in its log. A workspace admin can see everything, so their run covers the whole project.

A cost estimate counts exactly what the run would process if you started it now, which is the items and records you can see. Your estimate and your run always agree. (Run dedup is the one case an estimate cannot fully cover: its first step may find new pairs, and those are judged too.)

A few rules follow from this:

Pairs and groups. A duplicate or relation job acts on a pair only if you can see both records. It links or re-resolves a group, such as one person’s linked records or a chain of decisions that replace each other, only if you can see every record in it. A group that includes a record you can’t see stays as it is until someone who can see all of it runs the job. Auto-merge leaves out the members you can’t see and merges the rest.
Repairs give the same answer whoever runs them. Backfill event dates and Backfill action owners recalculate a value, such as a record’s date or a task’s owner. Everyone gets the same value, so two people’s runs never undo each other. Yours simply covers fewer rows.
Background runs. Backfill sentiment and Backfill action completion finish in the background. The background run is still you: it checks again that you have permission, and it stops if you’ve lost it. You must start these as yourself, not with a service-account token.

Some things are not limited to what you can see:

Cancel pending classify and Clear failed jobs tidy the queue and change no item (see Queues).
Run janitor sweep runs tonight’s clean-up now, over the whole project. That clean-up re-queues stuck items, fits topics and re-resolves relations. Because it covers every record, only someone who can see every record in the project can run it. That means a workspace admin. Nobody else sees the button, however senior their role on the project, and the clean-up still runs every night on every active project.
Seed tag vocabulary and Backfill organisations work only on things everyone on the project can see: the tag list, and people who didn’t come from a private source.
The nightly duplicate scan and clean-up are started by no one, so they cover everything.

An operation’s live log is shown only to the person who started it, and only on this project’s page.

What a backfill is for

A backfill replays existing data to catch something up — for example after you connect a source, enable a module, or fix how a piece of data is derived. The backfills here are idempotent: safe to re-run, because already-applied work is skipped. (A backfill differs from a reconcile, which corrects drift without reprocessing everything — see the Glossary.)

The tabs

Pipeline

Controls the classify queue for this project. Reclassify all re-runs the classifier on every item (the most expensive action here — one Sonnet call per item plus one per attachment). ClickUp items, business-card scans and filed documents are excluded: a filed document’s knowledge comes from Files, not the classifier. Retry failed / stuck resets failed items and zombies (stuck classifying for more than 15 minutes) back to the queue, re-running the Sonnet classifier on each (filed documents again excepted, as in the nightly clean-up). Cancel pending classify, Clear failed jobs, and Reprocess attachments are free queue operations.

Queues

Live status of the classify and attachment-ingest queues (waiting, active, delayed, failed), a breakdown of items by status, and lists of any stuck or failed items you can re-run individually. The breakdown and both lists show only items your clearance lets you open, so two people can see different numbers here.

The queue figures count only this project’s jobs, and only jobs for items you can open. Other workspaces and other projects share the same queues, but their work never appears in your numbers. There is no completed count: the queues keep only the most recent finished jobs across every workspace, so it could not be counted for one project.

Cancel pending classify and Clear failed jobs act on every queued or failed job in the project, including jobs for items you cannot see. They tidy the queue and change no item. The number they report back counts only the jobs for items you can open.

Backfills

The idempotent maintenance jobs, including Backfill sentiment (score every not-yet-scored message), Backfill action owners (populate My work), tag seeding and tagging, and several one-off repairs. Jobs that span every workspace on the deployment (the graph backfill and reconcile, and the user-email and stakeholder-link backfills) are run by ddx, not from a workspace.

Tag existing artefacts tags only the items you can see. Its count, its cost estimate and its log (including a dry run’s list of suggested tags) cover those items only. A workspace admin’s run covers the rest.

Relations

Classify and resolve relationships between event-register items — duplicate, supersedes, contradicts, relates — per register kind (decisions, risks, issues, action items, meetings), or for all kinds at once. Classify uses an LLM (Haiku); resolve does not. Each kind’s classify card shows its own estimate. Both steps cover only what you can see, as described in What an operation covers.

Hygiene

Retire stale items — archive still-open items that are long overdue or years old out of your work surfaces (My work, Project work, the registers, and overdue counts). They’re retired, not deleted: each row stays in the graph and on its detail page, and you can un-retire any of them. Applies to action items, risks, issues, and decisions. Preview the counts before you commit. The preview and the sweep cover only the items you can see. A workspace admin’s sweep covers the rest.

Replay

Re-feed a project’s source data — raw emails (Postmark webhook JSON) and bulk-imported .eml files kept in object storage — back through the ingest and classify pipeline. Plan replay previews what would run; Execute replay enqueues it. Items already present are skipped.

Danger

The isolated factory reset. It deletes this project’s derived data (ingested items, registers, evidence links, attachment metadata, documents, audit log) and writes a recovery manifest to object storage first. Original source data is untouched, so you can rebuild with Replay.