Engine Modes

Choose the right engine backend for your workflow — from UI development through production use.

You launch Fabriq and some buttons are greyed out. The "Run Validation" option is disabled, and the CDR pipeline shows as unavailable.

That's your engine mode at work. The engine mode controls which capabilities are available. Changing the mode changes what you can and can't do.

The four modes

Mode	Best for	Capabilities	Reliability
Stub	UI development, testing the interface	Mock responses only	Always works (no real engine)
Inline	Development and testing	All capabilities	Fast, but shares process (restart on crash)
Subprocess	Production daily use	All capabilities	Process isolation, independent recovery
Local	Full local control	All + local-only capabilities	All on local machine

Stub mode

Returns predefined mock responses for every capability. The UI works exactly as in production — you see confirmation prompts, the activity log updates, badges appear — but nothing actually happens.

When to use: You're developing the Fabriq UI itself, or you want to demonstrate the workflow without a real engine or agent.

What's missing: Real capability execution. Validity reports are fake. Changes don't actually write to disk.

Inline mode

The engine runs in the same process as the desktop app. Full feature set, fast response times, but if the engine crashes, the app crashes with it.

When to use: Development and testing. You want the full Fabriq experience without setting up a separate engine process.

What to watch for: If you're running heavy validation or CDR scans, Inline mode can slow down the UI since it shares the process.

Subprocess mode (recommended)

The engine runs as a separate subprocess. Process isolation means:

If the engine crashes, the app stays running (and vice versa)
Independent error recovery — restart the engine without restarting the UI
Clean resource cleanup

When to use: Production daily use. This is the default and recommended mode for regular work.

What to watch for: Slightly higher latency than Inline (IPC between processes), but the reliability tradeoff is worth it.

Local mode

All capabilities run on your local machine. This enables capabilities that require local-only access — reading specific filesystem paths, running local commands, accessing local databases.

When to use: You need full control over all capabilities and your data stays entirely local. Best for sensitive projects or offline work.

How to change modes

Go to Settings → Engine
Select your desired mode from the dropdown
Fabriq reloads the capability map
The UI updates — greyed-out buttons may become available (or vice versa)

Settings → Engine
┌──────────────────────────────────────────────────────┐
│  Current Mode: Subprocess                            │
│                                                      │
│  ○ Stub        — Mock responses (UI development)    │
│  ● Inline      — Same process (development)         │
│  ○ Subprocess  — Separate process (recommended)     │
│  ○ Local       — All capabilities local              │
│                                                      │
│  [Apply]                                             │
└──────────────────────────────────────────────────────┘

Which mode should I choose?

I want to...	Choose
Test the Fabriq UI without a real engine	Stub
Develop features on my machine, single process	Inline
Run Fabriq daily for real work	Subprocess (default)
Work offline with full capabilities	Local
Debug a capability issue	Inline (easier to debug, same process)
Run heavy validation without UI slowdown	Subprocess

Greyed-out buttons? Check your mode first

If a button is disabled:

Hover over it — the tooltip usually says "Requires X engine mode"
Go to Settings → Engine
Switch to a mode that supports the capability

Capability availability depends on mode. The capability map shows you what's available in each mode.

Next steps

Configuration Overview — other config areas
Connecting Agents — set up your agent backend
Troubleshooting — common issues and solutions