> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getgriffinapp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> How Griffin's components work together

Griffin follows a hub-and-agent architecture. The CLI pushes monitor definitions to a central hub, which schedules and executes them on a recurring basis.

## Components

| Component                | What it does                                                    |
| ------------------------ | --------------------------------------------------------------- |
| **griffin-core**         | TypeScript DSL for writing monitor definitions                  |
| **@griffin-app/griffin** | CLI and public package for local development and hub management |
| **griffin-hub**          | Control plane — stores monitors, schedules runs, tracks results |
| **griffin-executor**     | Execution engine that runs monitors and reports results         |

## Data flow

```mermaid theme={null}
flowchart TB
    Code["Your code\n__griffin__/ monitor files"] -->|plan / apply| Hub["Griffin Hub\nScheduler · API · Storage"]
    Hub -->|runs / metrics| Code
    Hub -->|enqueue| Executor["Executor\nHTTP calls · Assertions · Results"]
```

1. You write monitors in `__griffin__/` directories using the TypeScript DSL
2. `griffin apply` pushes monitor definitions to the hub
3. The hub's scheduler enqueues jobs based on each monitor's frequency
4. The executor picks up jobs, makes HTTP requests, runs assertions, and reports results
5. Results flow back to the hub for storage, metrics, and notifications

## Deployment modes

### Standalone

The hub and executor run in a single process. Simpler to deploy, suitable for single-instance setups.

```mermaid theme={null}
flowchart LR
    subgraph Hub["Griffin Hub (single process)"]
        Scheduler --> Queue --> Executor
        Queue <--> PostgreSQL
    end
```

### Distributed

The hub and executor(s) run as separate processes. Enables multi-region execution and horizontal scaling.

```mermaid theme={null}
flowchart LR
    subgraph Hub["Griffin Hub"]
        Scheduler
        API
    end
    Hub -->|queue| E1["Executor\n(us-east)"]
    Hub -->|queue| E2["Executor\n(eu-west)"]
```

Executors register with the hub, receive jobs via a queue (PostgreSQL or SQS), and report results back.

## Monitors

A monitor is the unit of work in Griffin. It's a JSON document containing:

* **Nodes** — the steps in your monitor (HTTP requests, waits, assertions)
* **Edges** — the execution order between nodes
* **Frequency** — how often the monitor runs
* **Locations** — where the monitor executes (in distributed mode)

The TypeScript DSL compiles to this JSON format. You never need to write JSON directly.

## Execution model

Monitors are executed as directed graphs. Each node runs in order defined by the edges, and results from earlier nodes (status codes, response bodies, headers) are available to later nodes for assertions and variable extraction.

<Card title="Execution Model" icon="diagram-project" href="/concepts/execution-model">
  Learn more about graph-based execution.
</Card>