Automations

An automation is a workflow that runs without a human in the loop. Automations trigger on a schedule, on a feed event, or on a Codex change, and execute a sequence of Jax operations under a defined permission scope.

What an automation is

Concretely, an automation is a JSON file in the Codex:

Each file declares:

• Trigger. Cron expression, feed event, or Codex path watcher.
• Scope. Project, branch, and permission set the automation runs under.
• Steps. Ordered Jax operations — reads, writes, runs, solves — each with

inputs and a timeout.

• On-failure. Retry policy, escalation channel, and rollback behavior.

The format is declarative and version-controlled like any other Codex file.

The canvas

Automations have a visual editor — a node-based canvas inspired by Palantir Foundry's pipeline builder. Drag triggers onto the canvas, connect steps, set inputs. Saving the canvas updates the underlying JSON file; editing the JSON updates the canvas.

The canvas is not the source of truth — the JSON file is. The canvas is a faithful renderer of it.

Common patterns

• Daily replan. Every morning at 06:00, regenerate field-crew routes from the

current work-order queue and post to the dispatch channel.

• Anomaly escalation. Watch the pressure-sensor feed; when a sensor crosses

a configured threshold, open a Jax investigation, run the pressure-drop solver, and page the on-call engineer.

• Territory rebalancing. Weekly, recompute CRM territories against the

current account list and pipeline value; surface proposed changes for review.

• Schema sync. When a vendor catalog updates, refresh the agent skill and

re-validate every active design against the new constraints.

Permissions

An automation runs under an explicit role. It cannot escalate; it cannot exceed the role's authority set. Automations that need write or solve access are visible in the audit stream and can be paused per-rule by an admin.

Limits

• Per-run wall-clock budget defaults to 5 minutes; configurable per automation.
• A single automation cannot span multiple projects.
• Long-running multi-day workflows should be modeled as a sequence of

shorter triggered runs, not as one long automation.