Skip to content

Pillar Reference

The 5-pillar architecture (see the table on the homepage) each has a summary document plus a folder of numbered concept docs (ORCH-1.x, KG-2.x, AHE-3.x, ECO-4.x, OS-5.x) — one file per concept, cross-referenced to code via CONCEPT: markers and to docs/concepts.yaml (the single source of truth for the concept registry. See Concept Registry). Start with a pillar's summary page, then drop into its concept docs for implementation detail — parallel in structure to how architecture/index.md organizes the cross-cutting subsystem docs.

Cross-pillar overviews

Whole-system views that cut across all five pillars.

Pillar 1 — Graph Orchestration

Routing, planning, execution, and state management via directed acyclic graphs. Concept docs cover the RLM runtime, GEPA program optimization, workflow lifecycle, and swarm/agent-runner execution.

Pillar 2 — Epistemic Knowledge Graph

The Single Company Brain: memory, ontology, retrieval, and structural reasoning. The largest pillar (39 concept docs) — includes the dedicated Company Brain detailed review subfolder below.

Pillar 2 detailed review — Company Brain

The operational state layer that turns the epistemic graph into a multi-writer, multi-reader, multi-tenant organizational memory — architecture, ontology, permissions, provenance, and concurrency.

Pillar 3 — Agentic Harness Engineering

Continuous evaluation, interpretability, and self-improvement loops — the evolution engine, backtesting/curriculum, and distributed agent state.

Pillar 4 — Ecosystem & Peripherals

Dynamic capability discovery, MCP servers, the hardened multiplexer, connectors, and governance policy for everything around the core.

Pillar 5 — Agent OS Infrastructure

Kernel, server-minted identity, externalized state, engine sharding, fleet autonomy, observability, and safety sandboxes.

Pillar 6 — GeniusBot Cockpit

The desktop cockpit frontend for SI agents.

Documentation standards for this tree

This repository employ a strict Concept ID Registry to ensure 1:1:1 traceability between Code (docstrings), Tests, and Documentation. If the operator are contributing a concept doc, follow the standard file naming conventions:

  • Pillar summary: {N}_{pillar_name}.md
  • Concept reference: {ID}-{Name}.md (e.g. KG-2.5-Topological_Analysis.md)

All new concept proposals go through the DSTDD design phase — see the development guide for the required KG analysis, and Status — the Codex for the generated, always-current concept count (never hand-typed here or anywhere else).