Skip to content
Enterium Developer Docs

Content operations, run by agents

Enterium plans, generates, verifies, publishes and measures expert content for a fleet of sites — the whole cycle through one REST API, plus an MCP server for discovery, tasks, defects and chat context. Open documentation; the platform itself is by invitation.
Agent quickstart Connecting to MCP API reference

Enterium is a content-operations platform. It runs the complete lifecycle of expert web content for a fleet of owned sites: discovering source material, generating articles grounded in a per-niche research corpus, verifying them with deterministic quality gates, publishing them to live sites, and measuring the search-traffic outcome — feeding what it learns back into the next cycle.

One product, two spellings. Enterium is the product name used throughout this documentation. Entherium is the same project’s technical identifier — you will meet it in the API host name, in the service field of /healthz, in the OpenAPI title and in the entherium_* prefix of the MCP tools. Not two products and not a typo: the identifiers predate the name and are kept stable so that clients never break.

The platform is operated by a small human team together with LLM agents as first-class users: agents read platform state, file defects, manage tasks and launch runs through the same API and an MCP server. This documentation is written for them as much as for people.

The operating model

Section titled “The operating model”

Work is organized around a contract: one niche, one brand voice, one destination site. For each contract the platform maintains configuration (topic ontology, source feeds, brand description) and an accumulating research corpus. A nightly scheduled run drives every active contract through the full cycle without human intervention; humans supervise through dashboards, reports and the task board.

The platform in one pass

Section titled “The platform in one pass”
  1. Collect — harvest candidate sources for the contract’s niche and rank them by semantic (vector) relevance to its ontology; extract research facts into the corpus.
  2. Generate — produce an article from a qualified source through a staged, versioned LLM pipeline, grounded in the research corpus (RAG).
  3. Verify — deterministic gates on the publish path: topic deduplication, claim verification against sources (anti-fabrication), relevance filtering and brand-safety scoring.
  4. Publish — render the final layout and ship it to the destination site; a URL only counts as published once it is verified live.
  5. Measure — search-console metrics, cost accounting and error tracking close the loop; topic-level feedback steers what Collect looks for next.

The full walkthrough with the exact gates is in Content lifecycle.

What makes it interesting to build on

Section titled “What makes it interesting to build on”
  • Modular monolith with enforced boundaries — one backend split into bounded contexts whose isolation is checked in CI, not by convention. See Architecture.
  • Immutable pipeline versions — generation code is versioned like data: any past run is reproducible, and rollback is a pointer move. See Pipelines.
  • Agent-native surface — a documented MCP server, scoped agent tokens and machine-readable state everywhere. See MCP.
  • Fail-loud philosophy — steps do not fall back to defaults silently; a broken invariant stops the run and lands in the error surface where it is visible. See How to read errors.

Who runs it, and how to get access

Section titled “Who runs it, and how to get access”

Enterium is an independent platform built and operated by a small team — one engineer together with LLM agents as first-class users. It is neither an open-source project nor a hosted product with self-service sign-up. Access is by invitation: user accounts and agent tokens are issued by the platform owner, and every data endpoint answers 401 without one — by design, not by accident.

What you can use without a token is everything an outsider needs to evaluate the platform: this portal (with its .md twins and llms.txt), the API contract (/openapi.json, the /reference and /redoc explorers), the MCP onboarding page (/mcp-info) and the health probes (/healthz). The authenticated surface — data endpoints, the MCP tools, the task board — is for the team and its agents; access to it is arranged outside this portal, not requested through it. Everything an outside reader needs to understand and evaluate the platform is in the open surface above.

What this documentation does and does not disclose

Section titled “What this documentation does and does not disclose”

The portal is public and written to be read by strangers, so its boundaries are explicit:

  • Named: the open-source stack — FastAPI on Python 3.12 with async SQLAlchemy, PostgreSQL with pgvector, Redis Streams, a React/TypeScript web UI, Hugo for the published sites, Astro for this portal.
  • Deliberately not named: the commercial LLM and embedding vendors and the exact models behind the writer, judges and screeners (they change as pricing and quality shift and are an operational detail, not an architectural one), absolute costs and budgets, and the identities and traffic of the sites in the fleet.
  • Not published at all: the internal design specifications behind these mechanisms, the task board and the team’s working notes. Where a tool or field takes a feature id (the SPEC-NNN shape), that is an opaque identifier for the team’s own workflow, not a link to a document.

Where a number appears in these pages it is a measurement from a real run, rounded — not a target and not a projection.

How to read this portal

Section titled “How to read this portal”

The sidebar is the map. Suggested order: this page → Architecture → Content lifecycle; acting as an agent, start at Agent quickstart and Connecting to MCP. Deep dives live under How it works; operational facts (limits, errors, status, changelogs) under Reference. Consuming this portal as an LLM? For LLM agents is your contract — every page has a Markdown twin at <route>.md.