EOS is an engineering operating substrate focused on:
- explicit engineering intent
- bounded execution
- deterministic governance
- persistent engineering memory
- iterative verification
- stateful orchestration
- governed capability growth
- durable engineering causality
- evidence-preserving trajectories
- Kubernetes-native execution and reconciliation
- component-based ecosystem evolution EOS is currently under active architectural and implementation development.
- Purpose
- Core Thesis
- System Model
- Architecture Overview
- Foundational Substrates
- Core Components
- Component Ecosystem Model
- Capability Model
- Governed Causality
- Documentation
- Core Directions
- Horizon Material
- Status
EOS exists to explore an engineering operating system model where engineering work is governed through explicit intent, bounded execution, persistent memory, deterministic control, verification, and recorded evidence. EOS is not intended to be:
- an agent framework
- a chatbot shell
- an unbounded automation system
- a generic workflow engine
- a prompt wrapper around model output EOS treats models as reasoning components inside a governed engineering substrate. The system, not the model, owns authority. Back to top
EOS is based on the idea that serious engineering work requires more than code generation. It requires:
- intent capture
- decomposition
- bounded execution
- deterministic governance
- persistent engineering memory
- capability management
- verification
- provenance
- stateful orchestration
- durable evidence
- controlled system evolution A core operating principle is:
Models reason.
Systems govern.
Evidence judges.
Humans retain authority at canonical boundaries.
EOS separates probabilistic reasoning from deterministic authority.
LLM proposes.
EOS decides.
Runtime executes.
Evidence records.
EOS is best understood as:
kernel
+
governed components
+
foundational substrates
+
capability ecosystem
EOS is not a monolith. It is a component ecosystem where independently useful systems may also become EOS-integrated components.
flowchart TD
classDef kernel fill:#f3f2ee,stroke:#8f8575,stroke-width:2px,color:#111
classDef component fill:#eef4f7,stroke:#6b8797,stroke-width:2px,color:#111
classDef substrate fill:#eef6ef,stroke:#6f8d72,stroke-width:2px,color:#111
classDef boundary fill:#f3eef7,stroke:#88739e,stroke-width:2px,color:#111
EOS[EOS<br/>Engineering Operating System]:::kernel
KERNEL[EOS Kernel<br/>Deterministic event-state machine]:::kernel
POLICY[Policy / Authority Layer<br/>Boundaries, trust, approvals]:::boundary
CAPREG[Capability Registry<br/>Governed system abilities]:::boundary
PROV[Provenance Layer<br/>Causal lineage and evidence]:::boundary
MS[Memory Steward<br/>What the system remembers]:::component
IS[Intent Steward<br/>What the system owes]:::component
RR[Relentless Rekrow<br/>Governed engineering-change factory]:::component
DEAN[The Dean<br/>What the system may learn from]:::component
PG[(PostgreSQL<br/>Canonical relational state)]:::substrate
KAFKA[(Kafka<br/>Durable causality stream)]:::substrate
OBJ[(Object Storage<br/>Artifacts, evidence, datasets)]:::substrate
QD[(Qdrant<br/>Semantic retrieval)]:::substrate
K8S[Kubernetes<br/>Execution and reconciliation]:::substrate
LLM[LLM Runtime<br/>Bounded reasoning roles]:::substrate
EOS --> KERNEL
KERNEL --> POLICY
KERNEL --> CAPREG
KERNEL --> PROV
KERNEL --> MS
KERNEL --> IS
KERNEL --> RR
KERNEL --> DEAN
KERNEL --> PG
PROV --> KAFKA
PROV --> OBJ
MS --> QD
IS --> PG
RR --> OBJ
DEAN --> OBJ
DEAN --> QD
CAPREG --> K8S
MS --> LLM
IS --> LLM
RR --> LLM
DEAN --> LLM
EOS is currently oriented around the following architecture:
intent-driven
event-informed
policy-bound
capability-oriented
evidence-preserving
Kubernetes-native
Intent provides the reason. Events provide signals. Policy defines boundaries. Capabilities perform bounded work. Provenance preserves causal history.
flowchart LR
classDef reason fill:#edf5f7,stroke:#6b8a96,stroke-width:2px,color:#111
classDef signal fill:#f3f2ee,stroke:#8f8575,stroke-width:2px,color:#111
classDef control fill:#f3eef7,stroke:#88739e,stroke-width:2px,color:#111
classDef work fill:#eef6ef,stroke:#6f8d72,stroke-width:2px,color:#111
classDef memory fill:#f4f4f4,stroke:#777,stroke-width:2px,color:#111
INTENT[Intent<br/>Reason for action]:::reason
EVENT[Event<br/>Signal or fact]:::signal
POLICY[Policy<br/>Boundary and authority]:::control
CAP[Capability<br/>Bounded system ability]:::work
EXEC[Execution<br/>Runtime work]:::work
EVIDENCE[Evidence<br/>Verifier and artifact output]:::memory
PROV[Provenance<br/>Causal memory]:::memory
INTENT --> POLICY
EVENT --> POLICY
POLICY --> CAP
CAP --> EXEC
EXEC --> EVIDENCE
EVIDENCE --> PROV
PROV --> EVENT
EOS relies on distinct foundational substrates. These should not be collapsed into a single database or generic storage layer.
| Substrate | Role |
|---|---|
| PostgreSQL | Canonical relational state |
| Kafka | Durable event and causality stream |
| Object storage | Artifacts, evidence bundles, datasets, reports |
| Qdrant | Semantic retrieval and vector memory |
| Kubernetes | Execution, reconciliation, namespaces, RBAC, CRDs |
| LLM runtime | Bounded probabilistic reasoning roles |
| EOS should distinguish logical substrate from physical backing service. | |
| Examples: |
ObjectStorage = logical EOS substrate
Backing service = MinIO, S3, or compatible storage
EventLog = logical EOS substrate
Backing service = Kafka, Redpanda, or compatible durable log
LLMRuntime = logical EOS substrate
Backing service = local vLLM, Ollama, llama.cpp, or remote model endpoint
flowchart TD
classDef logical fill:#edf5f7,stroke:#6b8a96,stroke-width:2px,color:#111
classDef backing fill:#eef6ef,stroke:#6f8d72,stroke-width:2px,color:#111
classDef warning fill:#faf4e8,stroke:#a48854,stroke-width:2px,color:#111
EOS[EOS Logical Substrates]:::logical
STATE[StateStore]:::logical
EVENTS[EventLog]:::logical
ARTIFACTS[ObjectStorage]:::logical
SEMANTIC[SemanticStore]:::logical
RUNTIME[ExecutionRuntime]:::logical
MODELS[LLMRuntime]:::logical
PG[(PostgreSQL)]:::backing
KAFKA[(Kafka / Redpanda)]:::backing
S3[(MinIO / S3)]:::backing
QD[(Qdrant)]:::backing
K8S[Kubernetes]:::backing
LLM[Local or Remote LLM Endpoint]:::backing
SEC[Encryption, identity, integrity,<br/>least privilege, auditability]:::warning
EOS --> STATE --> PG
EOS --> EVENTS --> KAFKA
EOS --> ARTIFACTS --> S3
EOS --> SEMANTIC --> QD
EOS --> RUNTIME --> K8S
EOS --> MODELS --> LLM
PG --> SEC
KAFKA --> SEC
S3 --> SEC
QD --> SEC
K8S --> SEC
LLM --> SEC
EOS currently orients around several current and candidate components.
Memory Steward governs persistent memory admission, semantic recall, and context preservation. It is responsible for:
what the system remembers
Relentless Rekrow is a governed engineering-change factory. It produces validated engineering artifacts such as:
- code changes
- tests
- documentation deltas
- verifier evidence
- review evidence
- implementation trajectories Inside EOS, Relentless Rekrow may serve as a capability foundry. It is responsible for:
how the system produces governed engineering changes
Intent Steward is an intent-aware scheduler and commitment orchestrator. It manages accepted future obligations, deferred objectives, eligibility evaluation, and capability-bound execution requests. It is responsible for:
what the system owes
The Dean is a proposed learning governance component. It manages dataset curation, trajectory transformation, training oversight, evaluation, and model maturation. It is responsible for:
what the system may learn from
UNICOP is a serious validation target for EOS ideas. It provides a high-complexity infrastructure-control-plane environment where EOS concepts can be tested against real engineering requirements. Back to top
EOS components may exist in two roles:
- internal system component;
- provisioned component instance. A component type may have:
- an EOS-internal instance;
- a project instance;
- a user instance;
- a sandbox instance;
- a candidate environment instance. This lets EOS act as a component ecosystem platform, not merely a collection of internal services.
flowchart TD
classDef type fill:#edf5f7,stroke:#6b8a96,stroke-width:2px,color:#111
classDef internal fill:#f3eef7,stroke:#88739e,stroke-width:2px,color:#111
classDef provisioned fill:#eef6ef,stroke:#6f8d72,stroke-width:2px,color:#111
CT[Component Type]:::type
INTERNAL[EOS Internal Instance<br/>system role]:::internal
USER[User Instance<br/>provisioned capability]:::provisioned
PROJECT[Project Instance<br/>workspace capability]:::provisioned
TEAM[Team Instance<br/>shared capability]:::provisioned
SANDBOX[Sandbox Instance<br/>candidate or test environment]:::provisioned
CT --> INTERNAL
CT --> USER
CT --> PROJECT
CT --> TEAM
CT --> SANDBOX
Example:
Relentless Rekrow
├── EOS internal capability foundry
├── user engineering instance
├── project engineering instance
└── sandbox engineering instance
Example:
Memory Steward
├── EOS internal memory governance
├── user memory instance
├── project memory instance
└── team memory instance
EOS should treat capabilities as governed system abilities. A capability is not merely a script, tool, or service. A capability includes:
- identity
- version
- owner
- input contract
- output contract
- runtime mode
- required permissions
- policy class
- risk class
- provenance requirements
- maturity level
- authority envelope
flowchart LR
classDef need fill:#edf5f7,stroke:#6b8a96,stroke-width:2px,color:#111
classDef decision fill:#faf4e8,stroke:#a48854,stroke-width:2px,color:#111
classDef foundry fill:#f3eef7,stroke:#88739e,stroke-width:2px,color:#111
classDef cap fill:#eef6ef,stroke:#6f8d72,stroke-width:2px,color:#111
classDef run fill:#f4f4f4,stroke:#777,stroke-width:2px,color:#111
NEED[Intent / Need]:::need
RESOLVE[Capability Resolution]:::decision
EXISTS{Capability exists?}:::decision
RR[Relentless Rekrow<br/>Capability Foundry]:::foundry
VERIFY[Verification / Review / Evidence]:::decision
REGISTER[Capability Registry]:::cap
RUN[Run Capability<br/>under authority envelope]:::run
NEED --> RESOLVE
RESOLVE --> EXISTS
EXISTS -->|Yes| RUN
EXISTS -->|No| RR
RR --> VERIFY
VERIFY --> REGISTER
REGISTER --> RUN
Authority envelope defines what the capability may do. Examples:
- allowed namespaces
- allowed resources
- allowed verbs
- allowed secrets
- allowed external endpoints
- maximum runtime
- storage limits
- network boundaries
- approval requirements Core distinction:
Capability knows how.
Authority envelope decides whether and where.
EOS should preserve causal linkage between intent, execution, evidence, and consequence. Weak model:
LLM decided to do X
EOS model:
intent
→ event
→ policy
→ capability
→ execution
→ evidence
→ provenance
→ next state
Kafka is the likely durable causality substrate. Object storage preserves larger artifacts and evidence. PostgreSQL preserves canonical state. Qdrant preserves semantic recall.
sequenceDiagram
autonumber
participant User
participant Kernel as EOS Kernel
participant Policy as Policy Layer
participant Capability
participant Runtime
participant Evidence
participant Kafka as Kafka EventLog
participant Store as Object Storage / Postgres
User->>Kernel: Submit intent or request
Kernel->>Policy: Check authority and boundaries
Policy-->>Kernel: Allowed / denied / escalation required
Kernel->>Capability: Resolve governed capability
Capability->>Runtime: Execute under authority envelope
Runtime-->>Evidence: Produce results, logs, verifier evidence
Evidence->>Store: Persist artifacts and state
Evidence->>Kafka: Emit durable causality events
Kafka-->>Kernel: Feed future state and analysis
The EOS documentation set is organized as numbered documents. Expected document map:
| Document | Title | Status | Purpose |
|---|---|---|---|
| 00 | Style / Foundation / Manifest Entry | Foundational | Defines documentation structure and project foundation. |
| 01 | Manifest | Canonical / Foundational | Defines the EOS thesis, identity, and core architectural principles. |
| 02 | Ecosystem Analysis | Canonical / Analysis | Compares EOS against adjacent systems and clarifies what EOS is and is not. |
| 03 | EOS Architecture | Canonical / Architecture | Defines the kernel, component model, authority boundaries, and minimum viable EOS direction. |
| 04 | Roadmap / Sequencing Material | Planning | Captures implementation sequencing and near-term architectural direction. |
| 05 | Engineering Trajectory Intelligence | Design / Exploratory | Describes how engineering trajectories become analyzable evidence and system learning substrate. |
| 06 | EOS Horizon | Exploratory | Captures long-term directions: governed self-evolution, self-instantiation, trust budgets, The Dean, training, federation, and the commons. |
| 07 | Roadmap | Planning | Defines phased delivery and implementation sequencing after the expanded document set is normalized. |
Current core directions include:
- Memory Steward
- Relentless Rekrow
- Intent Steward
- The Dean
- UNICOP validation target
- governed capability expansion
- Kubernetes-native EOS substrate
- durable event and provenance model
- trajectory intelligence
- capability trust and maturity
- self-evolution under explicit governance Back to top
Document 06, EOS Horizon, is explicitly exploratory. It captures long-term directions such as:
- governed self-evolution
- self-instantiation through
EOSInstance - trust budgets
- progressive autonomy
- capability maturity
- The Dean
- training and model improvement
- day/night learning cycles
- corpus admission gates
- community compute contribution
- enterprise federation
- trust mesh architecture Nothing in the horizon document is committed, implemented, or scheduled. The purpose of Document 06 is to preserve ambitious future-facing ideas without allowing them to contaminate canonical architecture before the minimum viable EOS is real.
flowchart TD
classDef now fill:#eef6ef,stroke:#6f8d72,stroke-width:2px,color:#111
classDef next fill:#edf5f7,stroke:#6b8a96,stroke-width:2px,color:#111
classDef horizon fill:#f3eef7,stroke:#88739e,stroke-width:2px,color:#111
classDef guard fill:#faf4e8,stroke:#a48854,stroke-width:2px,color:#111
MVP[Minimum Viable EOS<br/>Memory Steward + RR handshake]:::now
TRAJ[Engineering Trajectory Intelligence]:::next
INTENT[Intent Steward<br/>Accepted future obligations]:::next
CAP[Capability Registry<br/>Governed abilities]:::next
DEAN[The Dean<br/>Learning governance]:::horizon
EVOLVE[Governed Self-Evolution]:::horizon
INSTANCE[EOSInstance<br/>Candidate environments]:::horizon
FED[Community / Enterprise Federation]:::horizon
GUARD[Canonical boundary<br/>human authority + evidence]:::guard
MVP --> TRAJ
TRAJ --> INTENT
INTENT --> CAP
CAP --> DEAN
DEAN --> EVOLVE
EVOLVE --> INSTANCE
INSTANCE --> FED
GUARD -. constrains .-> TRAJ
GUARD -. constrains .-> INTENT
GUARD -. constrains .-> CAP
GUARD -. constrains .-> DEAN
GUARD -. constrains .-> EVOLVE
GUARD -. constrains .-> INSTANCE
Early-stage architecture and implementation effort. The project currently focuses on:
- engineering decomposition
- executable slice orchestration
- deterministic execution governance
- persistent engineering memory
- verification-driven progression
- capability modeling
- durable provenance
- engineering entropy reduction Immediate work remains grounded in making the minimum viable EOS path real before expanding into horizon capabilities. Back to top