Skip to content
fyrn Docs

Architecture

fyrn has three core layers: the AI generation layer that creates configs, the deterministic runtime that executes them, and the self-healing engine that maintains them.

Design principles

Section titled “Design principles”
  • AI generates, runtime executes. The AI is never in the hot path of message processing. It generates static YAML configs that a deterministic engine runs. This means AI hallucinations can’t cause data corruption — the config is auditable and reviewable before deployment.
  • Declarative over imperative. Flows are YAML definitions, not code. They describe what should happen, not how. The runtime handles retries, circuit breaking, rate limiting, and error handling.
  • Self-healing is continuous. The platform monitors connected APIs for schema changes, field renames, and deprecations. When drift is detected, the AI analyzes the change and generates a fix.

Component overview

Section titled “Component overview”
┌─────────────────────────────────────────────┐
│                  Developer                   │
│  CLI / Dashboard / CI Pipeline               │
└─────────────┬──────────────────┬────────────┘
              │                  │
    "Describe it"          "Deploy it"
              │                  │
              ▼                  ▼
┌─────────────────────┐  ┌─────────────────┐
│   AI Generation     │  │   Runtime       │
│   Layer             │  │   Engine        │
│                     │  │                 │
│ • Prompt → YAML     │  │ • Event intake  │
│ • Schema awareness  │  │ • Transform     │
│ • Connector catalog │  │ • Deliver       │
└─────────────────────┘  │ • Retry/circuit │
                         │ • Rate limiting │
                         └────────┬────────┘
                                  │
                         "It heals itself"
                                  │
                                  ▼
                         ┌─────────────────┐
                         │  Self-Healing    │
                         │  Engine          │
                         │                  │
                         │ • Drift detect   │
                         │ • Mapping fix    │
                         │ • Confidence     │
                         │ • Human review   │
                         └─────────────────┘

AI generation layer

Section titled “AI generation layer”

When you run fyrn generate, the AI:

  1. Parses your natural language intent
  2. Identifies the source and target systems from the connector catalog
  3. Looks up the current API schemas for those systems
  4. Generates a YAML flow definition with appropriate field mappings
  5. Validates the config against the DSL schema
  6. Writes the file to your project directory

The generated YAML is a static artifact. You can read it, edit it, diff it in a PR, and deploy it. The AI is not involved at runtime.

Runtime engine

Section titled “Runtime engine”

The runtime is a deterministic event processing engine. It:

  • Receives events from trigger connectors (webhooks, polling, or batch)
  • Evaluates filters and conditions
  • Executes transform steps (field mapping, validation)
  • Delivers to target connectors
  • Handles retries with exponential backoff
  • Implements circuit breakers for failing endpoints
  • Respects rate limits per connector
  • Logs every message for audit and debugging

There is no AI in the runtime. It executes exactly what the YAML says.

Self-healing engine

Section titled “Self-healing engine”

The self-healing engine runs as a background process that:

  1. Monitors connected API schemas for changes (field renames, new required fields, type changes)
  2. Detects when a flow’s mapping references a field that has changed
  3. Analyzes the change using AI to determine the correct mapping update
  4. Fixes the mapping if confidence is above the threshold (default: 95%)
  5. Routes to review if confidence is below threshold
  6. Logs every detection, analysis, and fix for audit

Learn more in Self-Healing.

Next steps

Section titled “Next steps”