Skip to main content

​
Control plane

The Enoch control plane is the runtime authority for queued work. It owns dispatch decisions, pause and maintenance controls, worker preflight, publication automation, events, and the bounded read models that the operator dashboard consumes. For current runtime topology and storage authority, see current runtime snapshot. When the store backend is Postgres, the same operator questions are answered from bounded SQL read models rather than full-table scans. Raw states still exist for debug and compatibility, but they should not drive the first-screen workflow.

​
What it owns

  • Queue and run state — queue items move through execution, callback, blocked, paused, and terminal states.
  • Dispatch safety — /control/dispatch-next checks whether a candidate can launch and supports dry-run requests.
  • Pause and maintenance controls — /control/pause, /control/resume, and the related state expose operator intent.
  • Worker preflight — /control/api/preflight and /control/worker/preflight call the worker-gate API before live dispatch.
  • Publication automation — paper records and automation records support drafting, checklist updates, status transitions, finalization packaging, and artifact reads.
  • Bounded read models — /control/dashboard and /control/api/v1/* answer operator questions with paginated, capped views.
  • Events and projections — the control plane stores audit events and exposes control-plane projections, with legacy Notion compatibility views only when that sync path is enabled.

​
What the dashboard shows first

Dashboard V2 (/control/dashboard-v2) is the canonical React/TypeScript operator shell, merged to main as of 2026-05-21. It leads with bounded operator cards:
  • What needs my attention?
  • What is running?
  • What can be written?
  • What can be finalized?
  • What is ready to publish?
  • What is already imported?
The shell uses cards, tables, search, pagination, and collapsed debug panels. Raw JSON, raw lifecycle labels, and artifact previews stay in drill-down views. All operator lanes consume bounded /control/api/v1/* read models.

​
Read-model semantics

The dashboard and the v1 read models separate operator questions from raw evidence.
  • operator_counts and operator_detail_counts drive the primary cards and drill-downs.
  • paper_pipeline.write_needed means actionable positive paper work only.
  • paper_pipeline.raw_completed_no_paper_candidates is informational/debug only.
  • paper_pipeline.not_writable_by_decision_gate counts completed rows that the decision gate rejects.
  • paper_pipeline.publish_ready means finalized drafts that still need a corpus-import ledger row.
  • paper_pipeline.published_imported means the paper is already represented in the corpus-import ledger.
That split keeps the dashboard honest: raw completed/no-paper rows are not the same thing as papers to write.

​
Dispatch safety

A dispatch is safe only when the control plane has a dispatchable queue item, pause and maintenance flags allow work, no active lane is already running, and worker preflight passes. The control plane is the lock holder; callers should not bypass it with ad hoc scripts. Use dry-run dispatch first when testing a new deployment. It exercises the guard path without launching a real agent job.

​
Relationship to intake tools

Control-plane idea intake helps decide what is worth queueing. It is not the execution authority. Once work enters Enoch, the control plane decides what is queued, what is active, what is blocked, and what evidence is available.

​
Important boundaries

The control plane cannot prove that a generated research claim is true. It can preserve the operational state and artifacts needed for audit. Independent review and replication still matter before treating a generated artifact as reliable science.