Maturity Active development 33 of 120 roadmap tasks complete (1 of 6 phases). Not a released product.
Interfaces
Seven surfaces are designed. Three exist. This page pairs each with what it cannot do, because that is the part that decides whether it is usable.
Each surface, what it supports, and what it does not.
Operator health surface in detail
Local k3d preview and Nile Valley integration design (opens the Episodic repository)Python module surface in detail
Project README (opens the Episodic repository)Terminal user interface in detail
Episodic TUI API design (opens the Episodic repository)WebSocket event streaming in detail
Roadmap step 4.5 (opens the Episodic repository)Only what the application defines. Where a contract is undefined, this page says so rather than assuming a convention.
Authorization middleware runs ahead of every resource except health routes, which bypass authentication. It supplies the authenticated principal; tenancy isolation is roadmap phase 5.
Side-effecting POST requests to the intake surface require an Idempotency-Key. The key is scoped to the authenticated principal. A repeat with the same canonical body replays the stored response; the same key with a different body returns 409 Conflict.
Profile and template updates carry expected_revision. A stale revision is refused rather than overwriting a concurrent edit.
A single error serializer produces a consistent error body across every resource.
Pagination, filtering, and role enforcement are delivered by the request surfaces that expose them.
No rate-limit contract is defined yet; do not assume one.
Read down the left column for the job, across for whether anything serves it.
| Task | Interface | Status |
|---|---|---|
| Store show configuration and editorial guardrails | REST API | Available |
| Bind reusable style guides and presenter profiles | REST API | Available |
| Submit source material and track its ingestion | REST API | Available |
| Retrieve a structured brief for a downstream generator | REST API | Available |
| Check a deployment is live and ready | Health surface | Available |
| Run work off the request path | Worker runtime | Available |
| Retrieve evaluator findings for an episode | None yet | Planned |
| Approve or reject an episode | None yet | Planned |
| Watch a generation run in real time | None yet | Planned |
| Import the package and call it from Python | None supported | Planned |
Kept separate from the live catalogue on purpose.
A terminal client, a web console, and WebSocket event streaming are all specified in the interface design notes. None of them ships. The design documents are worth reading as design documents and should not be read as documentation for something installable.
The Python module surface is the case most likely to mislead. The package imports and the modules are there, but nothing in them carries a compatibility promise. Treat it as internal until a supported API is documented.