Skip to main content
Enoch is an agentic research control plane that treats autonomous AI work as a reliability engineering problem, not a scripting problem. It queues research ideas sourced from an upstream LLM scouting process, gates dispatch through authenticated preflight checks, supervises agent runs on local AI hardware using process-tree tracking and CPU/GPU telemetry, captures evidence into structured bundles, and generates publication-style research artifacts with provenance instead of free-floating model output. Key transitions are guarded by idempotent APIs, stale-state reconciliation, and operator-visible status so you can inspect what is running, what is queued, and what the hardware appears to be doing.

​
The problem Enoch solves

Autonomous research runs fail in mundane but important ways:
  • an agent session can finish while child processes keep running;
  • a GPU worker can still be busy when a queue item looks idle;
  • queue state can become stale across dashboard views, intake projections, and runtime files;
  • evidence can be scattered across worker folders;
  • generated reports can overstate unsupported claims if provenance is lost.
Enoch addresses those problems with explicit state, authenticated APIs, worker preflight, process tracking, telemetry thresholds, evidence bundles, claim ledgers, packaging/provenance lint, and an explicit strict claim/evidence audit status.

​
Architecture flow

LLM-assisted idea scouting
  -> structured idea card
  -> control-plane idea/project/queue rows
  -> Enoch queue candidate
  -> FastAPI control plane
  -> worker preflight and dispatch safety checks
  -> worker gate
  -> agent run with process + telemetry supervision
  -> evidence sync
  -> generated research artifact
  -> corpus quality and provenance gates
Control-plane intake and the upstream scouting workflow are intake surfaces. Notion sync remains a legacy compatibility path. Runtime authority begins when an idea becomes an Enoch queue item. Current production storage is local Postgres on enoch-core; older Supabase wording is migration/compatibility terminology. For the canonical current host, storage, worker, decision-artifact, automation, and compatibility boundaries, see current runtime snapshot.

​
Main components

  • Control plane API — queue/project/run/paper state, pause controls, dashboard data, dispatch decisions, and publication automation APIs.
  • Worker gate — process-tree and CPU/GPU quiet-window checks for long-running local jobs.
  • Worker preflight — authenticated checks against the worker API before live dispatch.
  • Single active lane — the control plane blocks overlapping active queue work.
  • Evidence sync — copies evidence from worker project folders before artifact generation when enabled.
  • Artifact writer — creates draft research artifacts from evidence context using a deterministic template or an optional OpenAI-compatible provider.
  • Corpus packaging — stores generated artifacts with provenance and quality metadata.

​
What Enoch is not

Enoch is not a peer-review system, a guarantee of scientific novelty, a replacement for expert review, or a collection of old workflow-tool exports. The corpus is useful because it preserves generated work and evidence boundaries, not because every generated claim is true. The current public status separates 388/388 packaging/provenance lint from 389/389 strict claim/evidence audit pass.

​
Recommended next step

If you are new, read the quickstart first. If you are reviewing generated papers, read authorship and provenance before judging or citing any artifact.