BUILDER is the third layer of PILLAR, the Revenue Architecture Operating System.Documentation Index
Fetch the complete documentation index at: https://hc.pillargtm.com/llms.txt
Use this file to discover all available pages before exploring further.
PILLAR
The dashboard — your account 360, your scoring, your signals.
DRAFTER
The assistant — ask any question, get answers grounded in your data.
BUILDER
The automation — when something happens in your data, the right thing happens automatically. Or, more often, the right thing gets proposed to a human and they click “approve” in one tap.
What BUILDER does
BUILDER takes a rule like:“When a customer with annual contract value over $250,000 has their health score drop by 15+ points in 7 days, schedule an executive sponsor sync.”and turns it into a real thing that runs while you sleep — but only after watching it operate safely for at least 7 days first.
Three trigger types
Most revenue automation is one of three shapes — something happened, the calendar says it’s time, or a deadline elapsed. BUILDER unifies all three under one rule model.Event
Fires when something happens in your data: critical signal fires, deal stage changes, score crashes.
Schedule
Fires when the calendar says it’s time: daily 6am ET, every Monday, first of the month.
SLA timer
Fires when a deadline elapsed: save play has been open 48h with no activity.
Three execution modes (with mandatory progression)
Shadow
BUILDER watches every signal and writes down what it would have done. No actions taken. Read the log every few days; decide whether the rule is matching the right things.
Propose
BUILDER does almost everything. When conditions match, it creates a proposed action in your approval queue. A human approves or rejects with one click.
Execute
BUILDER does the action directly. Logs everything. Reversible via the global kill switch.
Ten action types
Every action is mode-aware (shadow / propose / execute), idempotent, and logged with provenance.notify_user
In-app, email, Slack, or Teams notification.
create_task
Drops a task in someone’s queue with a due date.
start_play
Kicks off a play from your play templates.
escalate_play
Reassigns to a manager + bumps severity + notifies.
update_signal_status
Acknowledge / resolve / suppress a signal.
rescore_account
Forces an immediate scoring run.
fire_signal
Creates a new signal — used to chain rules together.
update_field
Generic field update (with high-impact gate).
dispatch_webhook
Calls an external webhook (Slack, Zapier, etc.).
invoke_mcp_tool
Escape hatch — calls any tool in PILLAR’s MCP catalog.
require_approval which can be inserted as a “pause here for a human” step in the middle of any action chain.
Three authoring paths
The UI
/builder route — form for the common case (90% of rules), JSON DSL textarea for conditions and actions.YAML config-as-code
Export any rule as YAML, edit in your code editor, version-control alongside scoring config, reapply with
pillar rules apply from the CLI.DRAFTER
Describe a rule in plain English. DRAFTER calls
propose_builder_rule, returns a structured draft, you refine + save.Where to go next
Configuration
How BUILDER is shaped during implementation — the most important thing about BUILDER.
Preset libraries
The four out-of-the-box rule sets, with the rules in each.
Safety rails
Every guardrail BUILDER ships with: shadow mode, kill switch, Guarantee runtime, more.