Workflows

Each node has a type (one of the 16 catalogued types), a category (data / transform / logic / output), a config object specific to its type, and zero or more output handles consumed by downstream nodes.

An edge connects an upstream node's output handle to a downstream node's input handle. The graph must be acyclic — the builder rejects edge proposals that would close a loop.

Each node type declares typed config fields. Selecting a node in the builder opens the side panel where you can edit them:string, number, select,multi-select, and textarea inputs are supported. Defaults are pre-populated.

Every workflow must terminate inoutput.emit_strategy. This is a hard constraint — the executor refuses to run a graph without it, and the builder shows a validation error if it's missing. The rationale: strategies are how workflows' findings get actioned (backtest, deploy, monitor), so the contract is strict.

Each pulls live data from one of Augur's tools and emits a per-candidate table.

• data.top_movers — gainers / losers / most-active.
• data.screener — quant filter on the equity universe.
• data.snapshot — live OHLC + volume per candidate.
• data.sentiment — Sentimentor sentiment composite.
• data.options_flow — sweeps, premium, call/put skew.
• data.dark_pool — off-exchange institutional prints.
• data.insider_sentiment — net insider buy/sell pressure.
• data.financial_metrics — P/E, EPS, margins, dividends.
• data.analyst_recommendations — consensus + target prices.
• data.earnings_calendar — upcoming earnings dates.
• data.economic_calendar — CPI / FOMC / NFP / GDP releases.
• data.cftc_commitments — commercial vs speculator positioning.
• data.news — recent headlines + AI sentiment per row.
• data.sentimentor_prediction — proprietary directional read.

• transform.filter — drop candidates that don't match a condition.
• transform.rank — sort candidates by a composite score.
• transform.score — compute a numeric score per candidate.

• logic.if_threshold — branch on a threshold check.

• output.emit_strategy — generate a runnable PineNode strategy per pick. Required.
• output.email — deliver result by email. Fires on scheduled runs (any paid tier).
• output.webhook — POST result to a configured URL.

Nodes are grouped by category (data / transform / logic / output) and colour-coded: blue for data, purple for transforms, amber for logic, green for outputs. Drag-and-drop onto the canvas to add.

Click any node to populate the right panel with its config fields. Edits commit live to the in-memory graph — the workflow doesn't persist until you clickSave.

Hover a node's output handle to grab a connector, then drag onto another node's input handle. Invalid edges (cycle introduction, type mismatch) are rejected with a hover tooltip explaining why.

Any node can carry a config.customCode override — an inline PineNode script the executor runsverbatim instead of the node's built-in tool call. This lets you drop hand-tuned logic (custom indicators, bespoke ranking, third-party API stitching) into an otherwise catalogue-driven workflow without forking the node type.

Open the side panel for any node and pick a saved strategy or click Override to write a fresh script in the inline code editor. Reset to preset restores the catalogue default. Placeholders in the form {{param}} in the override get substituted at run time from the node's config — everything else runs unchanged.

Before save and before run, the builder checks:

• Exactly one output.emit_strategy terminal exists.
• No orphan nodes (every node must connect to the terminal somehow).
• No cycles.
• All required config fields are populated.

Failures surface inline as red badges on offending nodes; the run button stays disabled until everything is clean.

Chat-generated workflows open in the builder in a read-only preview. Click Unlock & edit to enter full edit mode: every node's side panel exposes its full config, and the PineNode override editor becomes available on all steps (not just the emit-strategy terminal). Save to persist your edits as a new revision of the workflow — the original chat proposal stays as the prior revision so you can revert.

From /workflows or from a workflow detail page, click Run. The run page opens immediately and starts streaming node-level status as the executor walks the graph.

Any paid tier (Pro, Elite, Trader) can schedule workflows. Cron-style expressions are supported (0 9 * * 1-5 = 9:00 AM Mon–Fri). Scheduled runs trigger the same executor as manual runs and produce the same run-page output.

• pending — queued, executor not yet started.
• running — executor is walking the graph.
• succeeded — all nodes ok, terminal emitted.
• failed — at least one node errored; the executor short-circuits and stamps the run as failed.

Each node card may surface up to four tabs:

• Description — what the node did, in plain English.
• Table — the per-candidate output as a sortable table.
• Chart — bar / line / timeseries / scatter / equity / gauge rendering, when applicable.
• Code — the exact JavaScript-formatted operation and inputs used for that node; the emit-strategy node shows the generated PineNode source itself.

Which tabs appear depends on the node type. Data nodes with a chartKind declared (e.g.data.top_movers → bar) get the chart tab; everything else falls back to description + code.

Chart tabs pick their shape from the data itself rather than a fixed per-node chart type. The router inspects the emitted table and chooses:

• Radar for multi-dimensional signal tables (bullish / bearish / neutral score columns per entity) — overlays up to four top entities on up to six dimensions.
• Scatter for two numeric axes without a natural category dimension (e.g. price vs. volume).
• Bar as the fallback when the shape is a single-metric ranking (top movers, sentiment leaderboard).

AutoChart blacklists metadata columns from the auto-picked metric list — updated, timestamp,id, uuid, order,rank, round_lot, and anything whose values look like epoch-second timestamps (min ≥ 1e9 with a tight spread). This prevents charts of "last update time" showing up in place of the real metric.

Each node card shows which tool calls produced it. When the backend supplies node_outputs, the attribution is exact; when it doesn't, the run page falls back to each node type's declared tools list.

The terminal output.emit_strategy card displays the generated PineNode strategy source with an Open in editor button. Multiple picks produce multiple strategy artefacts in one run; each can be opened independently. The terminal therefore does more than summarize the preceding analysis: it composes the surviving node-level evidence into executable, editable strategy logic that can be backtested and shared through /verify.

Branching is fine — multiple downstream paths from one upstream node are valid, and they can re-converge into a later transform. What's not allowed is a true cycle (a node depending on its own downstream output).

Yes. output.emit_strategy emits one strategyper candidate coming in on its input edge. If the upstream rank node passes 3 candidates, you get 3 strategies.

Each save snapshots the graph; older runs reference the snapshot they were built from. Editing a workflow doesn't rewrite the history of its prior runs.

Sharing creates a read-only public URL for a specific run. Exporting (coming soon) downloads the workflow graph as JSON for import into another account.