epos \e-ˌpäs\ — see Merriam-Webster.
Open-source dark factory: declarative specs in, production artifacts out. Vendor-agnostic orchestration that ships software today and unifies platform ops and physical (robotics) execution tomorrow.
EposForge is the open, vendor-agnostic pattern for a dark factory — a fully agentic software, platform, and (eventually) physical-execution factory driven by declarative intent. You describe what should exist; the factory builds, deploys, and operates it.
EposForge defines:
- A vision for unified intent execution across software, platform, and physical substrates.
- A set of architectural components (slots) every dark factory needs.
- A universal Adapter Pattern that plugs concrete products into those slots without locking the factory to any one vendor.
- Maturity roadmaps for both the Platform Factory (ops autonomy) and the Product Factory (dev autonomy).
- A research catalog of candidate Adapters so you don't reinvent the wheel.
Instances pick implementations.
What better way to build an AI driven dark factory than to have AI build it for you?
EposForge delivers value via a Cognee MCP server which LLMs can use for a GraphRag grounding.
eposforge/.eposforge/spec-graph/cognee is the implementation (after container uniformity)
Once agents have access to the server, they can ground their chats and actions by accessing the EposForge ontology grounded knowledge graph through Cognee MCP.
This guides your agents in building a dark factory from scratch in a greenfield scenario, guides them on incrementally moving towards a dark factory in a brownfield scenario, and guides the development of eposforge itself when contributing to the eposforge github project.
00-vision/ # Mission, pillars, principles, horizon
01-architecture/ # Adapter pattern, reference architecture, component contracts
02-roadmap/ # Maturity phases for Platform and Product factories
03-research/ # Surveys of products that can fill each component slot
04-standards/ # Adopted cross-cutting standards and conformance rules
This repo is docs-first. Code lands as components mature.
This repository has three distinct layers. Keep them separate in commits, reviews, and docs so it is always clear what is normative architecture and what is a concrete local implementation.
| Layer | Paths | Meaning | Portability |
|---|---|---|---|
| Architecture definition | 00-vision/, 01-architecture/, 02-roadmap/ |
Normative EposForge pattern, contracts, and maturity models | Reused across adopting repos |
| Standards definition | 04-standards/ |
Adopted cross-cutting standards and conformance requirements | Reused across adopting repos |
| Implementation for this repo instance | .eposforge/, docs/runbooks/ |
Concrete implementation choices used by this repository (uniform container) | Varies by repo |
| Research and candidates | 03-research/ |
Candidate adapters, comparative analysis, and implementation options | Reused as reference, non-normative |
See .eposforge/README.md for a slot-by-slot map of what this repo installs.
The following conventions are intended to be reused by any repo that adopts the EposForge architecture.
Required conventions:
- Separate architecture definition, implementation, and research content.
- Use machine-readable doc classification metadata (for example:
doc_kind,scope,maturity,source_of_truth). - Require adapter metadata for each adapter per 01-architecture/00-adapter-pattern/adapter-pattern.md.
- Maintain a single adapter registry view that shows candidate vs implemented vs active status per component slot.
Repo-local conventions (customizable per adopting repo):
- Folder layout and naming details.
- CI/lint enforcement tooling.
- Runtime stack and specific adapter implementations.
- Rebuild and operational scripts.
This repo implements its own Spec Graph (Component 6) with two adapters: Cognee (default) performs ontology-grounded extraction from the Markdown corpus and writes normalized entities and relationships into Neo4j CE, and Microsoft GraphRAG remains installed as an opt-in fallback path for extraction and community detection. Any MCP-compatible client (Claude Code, Gemini CLI, Cursor, Goose, etc.) connects to Neo4j via the Neo4j MCP extension and gains graph-augmented memory of the full architecture for spec generation, ADR authoring, and consistency checks.
See .eposforge/SPEC.md for the Living Spec and adapter registry, .eposforge/spec-graph/cognee/cognee.md for the default adapter, and .eposforge/spec-graph/graphrag/README.md for the fallback adapter and current invocation surface.
Early. Vision, components, and maturity roadmaps are being extracted from a private reference instance and generalized. Expect active iteration.
Contributions are welcome. See CONTRIBUTING.md — we use the Developer Certificate of Origin sign-off for every commit. No CLA.