QuoxFlow

Accountable workflow engine with visual builder, AI-assisted creation, real-time monitoring, enterprise governance, and full audit trails.

QuoxFlow is an accountable workflow engine. You define workflows as JSON DAGs — nodes connected by edges — and execute them via CLI, REST API, cron schedules, or event triggers. For infrastructure, it executes directly through your SSH bastion and HTTP APIs. For SaaS integrations, it wraps n8n's 400+ connectors with full audit trails.

What makes it different: every execution — infrastructure or SaaS — runs through a 7-layer audit pipeline. Policy gates can block or require human approval for destructive operations. Every result produces immutable evidence. You always know what ran, who authorized it, and what happened. 500+ tests across the engine and collector ensure production reliability.

Quick Start

# Execute a workflow with input data
quoxflow run health-check.json --data '{"host": "nw-web-01"}'

# Import an n8n workflow
quoxflow import n8n-export.json --output converted.json

# Validate a workflow definition
quoxflow validate workflow.json

# Query audit envelopes
quoxflow query --corr exec_01ABC --db postgres://...

The Problem with Workflow Middleware

General-purpose workflow tools like n8n were designed to connect SaaS applications — Slack to Google Sheets, Jira to email, CRM to billing. They have 400+ connectors because that's what SaaS integration requires.

Infrastructure operations are fundamentally different. You don't need a "Proxmox connector" — you SSH to the node and run pvesh. You don't need a "Prometheus connector" — you call its HTTP API directly. You don't need a "Docker connector" — you SSH to the host and run docker ps.

When you route infrastructure operations through general-purpose workflow middleware, you get:

• No audit trail — when something breaks at 3 AM, you can't trace what happened or who triggered it
• No governance — anyone can trigger any workflow, no approval gates, no policy rules
• A black box — middleware sits between you and your infrastructure as an opaque layer
• No evidence — no immutable proof of what was executed, when, and who authorized it
• Unnecessary complexity — a connector layer solving a problem infrastructure doesn't have

Workflow Format

Workflows are JSON files with nodes, edges, and optional variables. Each node has a type, configuration, and position. Edges connect outputs to inputs and can have conditional expressions.

{
  "id": "health-check",
  "name": "Docker Health Check",
  "nodes": [
    {
      "id": "trigger",
      "type": "trigger:webhook",
      "config": {
        "path": "/health-check",
        "method": "POST"
      }
    },
    {
      "id": "check",
      "type": "integration:bastion",
      "config": {
        "host": "${input.host}",
        "command": "docker ps --format json"
      }
    },
    {
      "id": "branch",
      "type": "flow:condition",
      "config": {
        "expression": "${input.unhealthy > 0}"
      }
    },
    {
      "id": "alert",
      "type": "call",
      "config": {
        "url": "https://alerts.example.com/api/v1/alerts",
        "method": "POST",
        "body": { "alert": "${input.host} unhealthy" }
      }
    },
    {
      "id": "evidence",
      "type": "control:evidence",
      "config": {
        "label": "all containers healthy"
      }
    }
  ],
  "edges": [
    { "source": "trigger", "target": "check" },
    { "source": "check", "target": "branch" },
    { "source": "branch", "target": "alert", "condition": "${input.unhealthy > 0}" },
    { "source": "branch", "target": "evidence", "condition": "${input.unhealthy === 0}" }
  ]
}

Execution: Two Paths, One Audit Trail

QuoxFlow runs operations through two paths — both produce the same audit trail, policy gates, and evidence.

For infrastructure, you don't need connectors — SSH and API calls are native. For SaaS, add n8n and every connector gets wrapped with accountability.

CLI

QuoxFlow ships as an npm package with a full CLI.

$ quoxflow run health-check.json --data '{"host": "nw-web-01"}'

▸ Ingress     envelope created
▸ Identity    authenticated: admin
▸ Route       → health-check workflow
▸ Policy      ✓ allowed (read-only)
▸ Execute     SSH nw-web-01: docker ps
▸ Verify      3 containers healthy
▸ Audit       evidence stored

✓ Completed in 1.2s
  Correlation: exec_01HQXM...

REST API

30+ endpoints for workflows, executions, policies, approvals, evidence, and templates.

21 Node Types

Purpose-built for infrastructure across 7 categories. No SaaS connector bloat.

Triggers

Control Flow

Actions

Data

Error Handling

Events

Utilities

Expression Engine

Expressions use ${...} syntax and run in isolated V8 sandboxes via isolated-vm — not eval. Each expression gets 8MB memory and a 1-second timeout. No access to process.env or Node.js APIs.

Available Context

• input — data passed into the current node
• nodes — outputs from previous nodes (e.g., nodes.ssh_check.exitCode)
• vars — workflow-level variables
• workflow — workflow metadata

Built-in Helpers

• $.now() — current ISO timestamp
• $.uuid() — generate a UUID
• $.jsonPath(obj, path) — extract data using JSONPath
• $.base64Encode(str) / $.base64Decode(str) — base64 operations

Examples

// Condition node
"${input.amount > 10000}"

// Transform node
"${input.items.filter(i => i.status === 'active')}"

// HTTP body template
{
  "alert": "${input.host} is unhealthy",
  "count": "${input.unhealthy}",
  "time": "${$.now()}"
}

// Access previous node outputs
"${nodes.ssh_check.exitCode === 0}"

// JSONPath extraction
"${$.jsonPath(input, 'data.results[0].value')}"

Expressions are validated at definition time via quoxflow validate.

7-Layer AOCL Pipeline

Every operation passes through 7 observable layers:

Each layer emits observable events in the AEE envelope format. The entire execution is transparent and queryable.

What This Means in Practice

When someone triggers "stop production VM":

1. Ingress — request logged, envelope created
2. Identity — user authenticated as engineer@team
3. Route — matched to proxmox_vm_action workflow
4. Policy — stop is destructive → requires approval from admin or group:infrastructure
5. Execute — after approval, SSH to Proxmox node via bastion, run pvesh create .../status/stop
6. Verify — confirm VM status changed to stopped
7. Audit — store evidence: who requested, who approved, what happened, when

Not a log line. A full causal chain of AEE envelopes — globally unique ULID IDs, linked via reply_to references, queryable via CLI or API.

Full Accountability

Every operation produces:

• AEE Envelopes — who requested it, who approved it, what happened (immutable, ULID-identified)
• AOCL Layer Events — what each of the 7 pipeline layers decided
• Evidence Records — proof of execution stored in PostgreSQL
• Causal Chains — envelopes linked via reply_to references, fully traceable

Policy Engine

Policies are JSON rules that decide what runs immediately and what waits for a human.

{
  "name": "proxmox-destructive-actions",
  "description": "Require approval for VM stop/reboot/shutdown",
  "rules": [{
    "conditions": {
      "tool": "proxmox_vm_action",
      "params": { "action": ["stop", "reboot", "shutdown"] }
    },
    "effect": "require_approval",
    "approvers": ["admin", "group:infrastructure"],
    "timeout": "1h"
  }]
}

Safe operations run immediately. docker ps, pvesh get /cluster/resources, network checks — these execute without gates.

Destructive operations pause for approval. VM stop, reboot, shutdown — these wait for a human to approve before executing.

Each policy defines:

• Conditions — when the policy applies (action type, resource, parameters)
• Effect — what happens (allow, deny, require_approval)
• Approvers — who can approve (users, groups, roles)
• Timeout — how long to wait for approval before escalating
• Escalation — what happens if nobody approves in time

QuoxFlow + n8n: Wrap It, Audit It

n8n has 400+ connectors. QuoxFlow has audit trails, policy gates, and evidence. Put them together and every n8n execution — every Slack message, every Jira ticket, every PagerDuty alert — becomes fully accountable. No changes to your existing n8n workflows.

How It Works

The proxy:n8n node type forwards execution to an n8n webhook. QuoxFlow wraps the call — audit envelope before, evidence capture after. Your existing n8n workflows keep running unchanged.

Request → QuoxFlow (Audit + Policy) → proxy:n8n → n8n (400+ connectors) → QuoxFlow (Evidence)

What You Get

• Instant audit trail — every n8n webhook call gets wrapped with AEE envelopes (who triggered it, what happened, when)
• Policy gates on n8n — apply approval rules to n8n operations. Destructive n8n workflows can require human sign-off
• Evidence on everything — n8n produces no evidence on its own. QuoxFlow captures immutable proof of every execution
• Transparent middleware — n8n goes from black box to observable. AOCL layer events show exactly what happened inside
• Circuit breaker — if QuoxFlow is down, n8n calls bypass directly (graceful degradation)

Infrastructure vs SaaS

For pure infrastructure (SSH, APIs), QuoxFlow runs natively without n8n. For SaaS connectors (Slack, Jira, PagerDuty), add n8n and QuoxFlow wraps it. Mix both in the same workflow — same audit trail either way.

n8n Migration

QuoxFlow includes a built-in n8n workflow importer that converts workflow JSON files to QuoxFlow format.

• 50+ n8n node types automatically mapped to QuoxFlow's 21 node types
• Expression syntax converted from n8n's {{ }} to QuoxFlow's ${}
• Connections and canvas positions preserved
• No running n8n instance required — converts JSON only
• Warnings for unmapped credentials and unsupported features

CLI Import

$ quoxflow import docker-status.json --output converted.json --pretty

Converting n8n workflow...
  Webhook          → trigger:webhook
  Code             → data:transform
  IF               → flow:condition
  HTTP Request     → call
  Set              → data:set

✓ Converted 5 nodes, 4 edges
⚠ 1 warning: credential 'docker_ssh' requires manual setup

Saved to converted.json

REST API Import

POST /api/workflows/import-n8n
{
  "workflow": <n8n JSON>,
  "options": {
    "includePositions": true,
    "includeDisabled": false
  }
}

Dashboard Integration

QuoxFlow is fully integrated with the QuoxCORE dashboard — no context switching required.

Run Feedback & Re-Run

Click "Run" on any workflow and get instant feedback with the execution ID. A toast notification shows the workflow name and execution ID with a "View" link to jump straight to the detail page. On any execution detail page, click "Run Again" to re-execute the same workflow immediately.

Per-Workflow Execution History

Click any workflow card to expand an inline execution history panel showing the last 10 runs. See status, timestamp, and duration at a glance. Click any execution row to drill into the full APM waterfall timeline.

One-Click Deploy & Import

Browse 1,340+ workflow templates in the library and deploy directly with one click via "Deploy Now". Or use "Import to QuoxFlow" for n8n conversion with automatic node type mapping. Warnings display for unmapped features and credentials that need manual setup.

Approval → Execution Links

QuoxFlow approval requests in the Inbox link directly to their execution detail page. One click from an approval card to the full execution timeline — no hunting for correlation IDs.

Who It's For

Comparison

Deployment

QuoxFlow runs as a Docker container alongside QuoxCORE:

# Default: QuoxFlow runs everything
# n8n is NOT installed
docker compose up -d

# Need Slack/Jira/PagerDuty connectors?
# Add n8n as an optional profile:
docker compose --profile with-n8n up -d

Requirements:

• PostgreSQL (included in docker-compose)
• QuoxCORE auth service (for JWT authentication and credential resolution)
• ~512MB RAM

Evidence & Compliance

Every workflow execution produces evidence — immutable records proving what happened, when, and who authorized it.

• Timestamped and linked to execution envelopes via ULID references
• Queryable by workflow, date range, actor, or approval status
• Exportable for compliance audits
• Stored in PostgreSQL with integrity checks
• Causal chains link related operations across the full execution lifecycle