# Architecture

<figure><picture><source srcset="/files/E2xTv3QLaoYQKuapijej" media="(prefers-color-scheme: dark)"><img src="/files/7dYwZesbHbdbj9MtHuuv" alt=""></picture><figcaption></figcaption></figure>

*<mark style="color:$info;">Layered RAVID architecture with a central coordination core.</mark>*

\
RAVID is organized as a layered system with a central coordination core and independently adaptive network, infrastructure, and storage layers:

1. **Network Layer (Dynamic Routing)**\
   RAVID operates over a virtual network layer in which communication paths are established dynamically and rotated over time. Network routes are not intended to be long-lived or addressable through fixed endpoints. This reduces reliance on static network topology. The network layer is responsible only for connectivity and path selection, not identity or policy enforcement.
2. **Infrastructure Layer (Workload Placement)**\
   Compute workloads are deployed across available infrastructure without being bound to specific servers or fixed locations. Workload instances may be created, terminated, or relocated based on availability and operational conditions. This layer does not assume persistent hosts or static service placement.
3. **Storage Layer (Fragmented Data Placement)**\
   Data is stored as encrypted fragments distributed across multiple storage locations. Complete datasets are not persistently stored in a single location. Reassembly occurs only when required for execution or retrieval. Storage placement may change over time without requiring changes to application logic.
4. **RAVID Core (Coordination and Timing)**\
   The RAVID core coordinates timing and state transitions across the network, infrastructure, and storage layers. It does not execute workloads, route traffic, or store data. Its function is to ensure that changes across layers occur in a controlled manner so that independent adaptation does not result in system instability.
5. **External Verification and Enforcement (Optional Integration)** \
   Operational activity occurs off chain. Verification of outcomes and enforcement of economic conditions may be delegated to an external system. In Ethereum-aligned deployments, cryptographic attestations are verified, commitments are recorded, and incentives or penalties are enforced by Ethereum smart contracts. Ethereum does not participate in coordination, routing, or execution.

\
In summary:

| **Layer**      | **Function**       | **Motion Type**             |
| -------------- | ------------------ | --------------------------- |
| Network        | How data travels   | Routes change, paths rotate |
| Infrastructure | Where work happens | Workloads relocate          |
| Storage        | Where data lives   | Shards redistribute         |
| RAVID Core     | Coordination       | Synchronizes all motion     |
| Ethereum       | Enforcement        | Verifies and settles        |

## **Primitive Stack Mapping:**

When we map each RAVID layer to the specific cryptographic, networking, and consensus primitive it uses, we show how the system is built from standard, well-understood components:

| RAVID Layer         | Primitives Used                                                            |
| ------------------- | -------------------------------------------------------------------------- |
| **Stealth Network** | mTLS, ECDH (X25519), ChaCha20-Poly1305, X.509, Overlay Mesh, Dark Services |
| **Infrastructure**  | Virtualization, IaC (DAG, State), HSM, Leader Election (RAFT)              |
| **Storage**         | Shamir SSS (2-of-3), HD Derivation, Merkle Trees, Append-Only Logs         |
| **RAVID Core**      | BFT Consensus (80% threshold), RSM, Threshold Signatures, BLAKE2B          |

{% code overflow="wrap" %}

```angular-ts
NETWORK PRIMITIVES:

mTLS Handshake:
  Client ────── ClientHello ──────► Server
  Client ◄───── ServerHello ─────── Server
  Client ────── Certificate ──────► Server    // Both sides prove identity
  Client ◄───── Verify ───────────── Server

Key Exchange (ECDH/X25519):
  Alice: a = random, A = a·G
  Bob:   b = random, B = b·G
  Shared = a·B = b·A = ab·G   // Same secret, never transmitted

Symmetric Cipher (ChaCha20-Poly1305 AEAD):
  Plaintext + Key + Nonce → Ciphertext + Auth Tag
  Properties: Confidentiality + Integrity + Authentication
```

{% endcode %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.engma.io/ravid/architecture.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.