The automation builder

Describe it in a sentence. Ship it as a plan you can read.

Write what you want in plain English. Viziers compiles it into a visual trigger → condition → action plan — one you review, test against real signals, and arm only when you're satisfied. No YAML, no drag-and-drop maze, no black box.

New automation

In plain English

“When CI fails on main, tell #ops — at most once an hour.”

When

github.workflow_failed

a CI run fails

If

branch is main

condition

Then

slack.notify · #ops

auto · at most once / hour

Compiled · confidence 72%Approve plan

Prose in, plan out

Say it like you'd say it to a coworker.

You write the intent; Viziers does the wiring. It reads your sentence, maps it onto the signals and actions your workspace actually has, and lays out a plan as a graph you can see. Nothing arms until you approve it — the compile step is a proposal, not a commit.

  • “When CI fails on main, tell #ops — at most once an hour.”
  • Compiled into named trigger → condition → action rules.
  • Every plan comes with a confidence score before you commit.
New automation

In plain English

“When CI fails on main, tell #ops — at most once an hour.”

When

github.workflow_failed

a CI run fails

If

branch is main

condition

Then

slack.notify · #ops

auto · at most once / hour

Compiled · confidence 72%Approve plan
Test

Simulate a signal — the same judgment the live wheel runs, no side effects.

github.workflow_failed{ branch: "main" }
Notify ops on CI failurewould fire
  • branch == main
  • conclusion == failure

Would deliver

#ops — “CI failed on main · build #4821”

The test loop

Dry-run a signal. See exactly what would happen.

This is the part developers ask about first. Before an automation touches anything real, you simulate a signal through it and get a clause-by-clause trace: what matched, what didn't, whether it would fire, and the exact message it would send. And because the test harness runs the very same rule engine as production — not a lookalike — a green test means the live path is green too.

  • Feed a rule a sample signal and watch it evaluate, clause by clause.
  • See the literal delivery each rule would send — before it sends anything.
  • The dry-run uses the same evaluator as the live wheel. A test can't drift from production.

Expressive without a language to learn

Simple by default. Precise when you need it.

The plain-English layer covers the common cases. Underneath, the rule model is genuinely expressive — so the hard automation is still one plan away.

Match precisely

Real conditions

Operators (gt, contains, in), any/all/not groups, and dot-paths into the payload.

Control the noise

Cooldowns & thresholds

“At most once an hour,” or “only after three in a day” — rate limits and windowed counts are first-class.

Compose steps

Chaining

When a rule fires, it emits its own signal — so one automation can trigger the next, and multi-step flows just fall out.

Say the right thing

Templated actions

Pull fields straight from the signal into the message: {{payload.branch}}.

On a clock

Scheduled signals

A built-in hourly tick means “every morning” or “each hour” automations need no external cron.

Beyond keywords

Learned extraction

Conditions can match on what the vizier understood a signal to be about — topic, intent — not just its raw fields.

The gate

Auto where it's safe. Your sign-off where it counts.

Every action carries a gate. Notifying your own team can fire on its own; creating a public issue, emailing a customer, or publishing release notes waits for you. The vizier drafts it, holds it, and asks — so automation never means handing over the decisions that carry your name.

  • Low-stakes actions (post to Slack, log a lead) just run.
  • Anything customer-facing parks at the gate for your approval — with a timeout you set.
  • Approve, edit, or decline from the web or your phone.
Viziers

Marcus asked for references. I've drafted a reply with the three you usually send. Send it?

See the trail
  1. Signal

    github.workflow_failed received

  2. Synthesis

    matches “Notify ops on CI failure”

  3. Gate

    auto — confidence 0.91 over threshold

  4. Reaction

    posted to #ops

Nothing unaccountable

Every automation leaves a trail.

Automation you can't inspect is automation you can't trust. Every run records an append-only trail — the triggering signal, which rule matched, how confident the vizier was, whether it gated, and what it did. “See the trail” is one click from anything that happened.

  • See why a rule fired — the signal, the match, the confidence, the result.
  • Each stage is recorded: signal → synthesis → gate → reaction.
  • When something looks off, you can read exactly what the vizier decided and why.
The plan is readable, the test can't lie, and the gate is yours. That's the whole contract.
Why the builder works this way

Built for the signals developers already live in — GitHub, Slack, and Linear — with more on the way. See Viziers for developers.

Automate the plan you can actually read.

Join the waitlist and we'll reach out as Viziers opens to early businesses.