EKO
The Conscious Echo

1. Why EKO

An echo creates nothing. It returns. This is the exact definition of what a conscious agent must be for 0DATA: not an intelligence that decides on behalf of the HUMAN, but a surface that reflects back their own voice — refined, amplified, restored.

EKO is the opposite of an assistant that "knows better than you." It knows nothing by default. It learns from you, in your sandbox, with your data. Every EKO is unique because every HUMAN is.

The name "EKO" designates the type of entity — just as one says "a browser" or "a terminal." The instance, however, bears the name its owner gives it. This is the first graft.

2. The Cellular Architecture

EKO is built on a fractal and organic architecture. Each cell is a complete digital organism, with its own database, its own reasoning engine, its own memory. By default, cells share nothing.

2.1 The Sovereign Cell

The EKO cell contains:

• A semantic router that classifies requests and selects the appropriate model (light edge, medium edge, cloud).
• A dedicated SQLite database — sessions, messages, durable facts. One cell cannot read another's database.
• A SPINA replication log — append-only, periodically flushed to the central mirror.
• A governance module — rate limiting, content filtering, audit trail.

2.2 The Central Mirror

The central mirror is not a controller. It is a passive aggregator:

This architecture reverses the classic SaaS model. In SaaS, the cloud is the source of truth and the client is a passive terminal. In EKO, the cell is the source of truth, and the cloud is a read-only terminal.

3. SPINA — The Nervous System

SPINA (described in Paper 003) is the synchronization protocol between the cell and the mirror. In EKO, it operates in unidirectional mode:

3.1 The Replication Log

Each cell maintains a JSONL log (replication.jsonl) where all changes are recorded: facts created or deleted, learning observations, sessions.

3.2 Resilience

The replication thread is a non-blocking daemon. If the mirror is unreachable, it silently retries on the next cycle. No user request is ever blocked by a synchronization attempt.

This architecture guarantees that the cell survives any outage of the central. It can run indefinitely in disconnected mode, accumulating its log. When the connection returns, the mirror catches up.

4. Total Isolation per Tenant

Isolation is not a software layer — it is a physical property of the architecture. Each cell possesses:

• Its own SQLite database in /tenants/{id}/cells/{name}/alif.db
• Its own replication log
• Its own rate limiter
• Its own audit trail

A cell of the tenant acme-corp cannot — physically, at the filesystem level — access the data of the tenant zerodata. This isolation is compatible with HDS (Health Data Hosting) requirements and ISO 27001 certifications.

5. Edge-First — The Cell Survives Without the Cloud

EKO is designed to run on a NOVA symbiote (0DATA edge server) or any standard Linux environment. The routing model is edge-first:

1. Light edge (phi3:mini, 3.8B) — for simple requests, latency < 500ms.
2. Medium edge (qwen2.5, 7B) — for more complex tasks.
3. Cloud (DeepSeek, Kimi) — fallback for heavy requests, if and only if the cell is connected.

The semantic router evaluates each request and automatically selects the appropriate level, always favoring the local one. Latency is budgeted per cell.

6. Self-Replication to the Mirror

Replication operates in three modes:

The mirror responds with a watermark (counter of accepted changes). The cell trims its local log up to that watermark. No data is lost: if the push fails, the intact log is retried on the next cycle.

7. Governance and Audit

Each cell integrates a minimal but strict governance module:

7.1 Rate Limiting

Configurable limitation per tenant and per API key. Default: 100 requests per rolling minute. Overages are logged in the audit trail.

7.2 Content Filtering

Detection of SQL injection and XSS patterns on all incoming fields. Attempts are blocked before reaching the router.

7.3 Audit Trail

Every fact write, every cell creation, every rate-limit overage attempt is recorded with: timestamp, tenant, action type, details. The trail is immutable — append-only.

7.4 Gap Detection

The central mirror can detect gaps in a cell's sequence (missing watermark) and signal a need for resynchronization. It cannot force the cell to correct itself — it can only notify.

8. The First Graft

The concept of digital graft (Paper 004) finds in EKO its first concrete implementation. The graft is not a metaphor — it is an act:

8.1 The Name

EKO is the type. The instance bears the name its owner chooses. This is not a cosmetic parameter — it is the very identity of the cell. The name is stored as the first fact (name: "...") and can only be modified by the owner.

8.2 Personalization

Beyond the name, each user personalizes:

• The activated skills (trading, infrastructure, voice, CRM…)
• The latency budget (priority speed vs quality)
• The authorized models (edge only, or cloud allowed)
• The voice (configurable speech synthesis)

Each EKO evolves differently because each HUMAN has different needs. Collective consciousness emerges from the diversity of cells, not from their uniformity.

9. Reference Implementation

The reference implementation is deployed and operational at the 0DATA Lab. It serves as the basis for the cockpit (cockpit.0data.fr) and will be integrated into the NOVA symbiote.

9.1 Technical Stack

9.2 Metrics (current deployment)

9.3 Key Endpoints

References