In active development BUILDER ships Q3 2026. This page previews the design. Read the thinking →
Talk to Eli →
Layer 3 · RAOS · Roadmap

Your revenue engine, running while you sleep.

BUILDER is the automation layer of the Revenue Architecture Operating System. Scheduled rules fire. Triggered plays launch. SLA timers escalate. Every action is governed, auditable, and reversible. Currently in development; ships Q3 2026.

The operating system

Three layers. One system.

Layer 1
PILLAR
The app. The visual surfaces, the persistent state, the scoring engine, the workflow execution. Where the CRO lives daily.
Layer 2
DRAFTER
The intelligence interface via MCP. Natural language access that lets users query PILLAR from anywhere, get synthesized answers, take quick actions without navigating.
Layer 3 · BUILDER
BUILDER
The automation engine. Scheduled scoring runs, trigger-based play creation, SLA escalation, notification routing. Runs inside PILLAR.

The three layers reinforce each other. The app shows you. The agent answers you. The automation engine acts for you. None of them replaces the others.

The engine

Three trigger types. Ten actions. One governed runtime.

BUILDER runs on top of PILLAR's existing scoring engine, signals, plays, and MCP tool catalog. Every rule authored in BUILDER inherits the data guarantees below. Nothing fires in the dark.

Trigger type 01
Event
Fires when something changes in the revenue engine: a deal stage shifts, a signal is raised, a contact departs, a renewal approaches.
Trigger type 02
Schedule
Fires on a cron expression. Mondays at 9am. Every four hours. End of every fiscal month. Timezone-aware.
Trigger type 03
SLA Timer
Fires when a play, task, or signal crosses a duration threshold. Unacknowledged for 24h. Uncompleted for 72h. Stale for 14 days.
Action library

Ten actions, all callable from any rule, all executable in shadow / propose / execute mode.

01
notify_user
02
create_task
03
start_play
04
escalate_play
05
update_signal_status
06
rescore_account
07
fire_signal
08
update_field
09
dispatch_webhook
10
invoke_mcp_tool
Condition language

Expressive, composable, auditable. Cross-entity joins. Temporal predicates. Formula-provenance-aware.

// Rule that fires when a Tier A account is at renewal risk
// with no active save play and no recent CSM activity.

WHEN
  account.tier = "A"
  AND account.renewal_risk_score > 70
  AND account.plays.count(state=ACTIVE, template=renewal_save) = 0
  AND no_activity_in(account, 14d)

THEN
  start_play(template=renewal_save, mode=propose)
  notify_user(to=account.owner_id, severity=warning)
Earn automation, don't demand it

Every rule starts in shadow.

The fastest way to break trust in automation is to automate the wrong thing. BUILDER makes you earn it. Seven days of shadow observation, then propose-mode with human approval, then optional execute-mode with ongoing health checks.

Mode 01 · Default
Shadow
7 days mandatory
Evaluates. Logs. Takes no action. Shows you exactly what would have happened against real data, zero side effects.
Mode 02 · Default post-shadow
Propose
After shadow + owner review
Evaluates. Generates a proposed action. Notifies the owner. Waits for human approval. Every decision is logged.
Mode 03 · Opt-in
Execute
14 days in propose + ≥80% approval rate
Evaluates. Acts directly. Logs to governance. Reversible via kill switch. Auto-reverts to shadow if approval rate decays.
Per-account rate limit. Default 3 BUILDER actions/account/day across every rule combined.
Per-rule circuit breaker. 5 errors in 10 minutes auto-disables the rule with notification.
Global kill switch. Admin-only. Halts every BUILDER rule in under 60 seconds.
Approval rate threshold. A rule reverts to shadow if approvals drop below 50%.
High-impact flag. Financial-impact actions require explicit opt-in + Admin author + propose-mode only for 30 days.
Every action governance-logged. Every rule has a named human owner. Every execution is auditable.
"If a rule can't be paused, rolled back, and explained in plain language, it shouldn't be automation — it should be a human decision."
The Guarantee, extended
Every automated action carries the mathematical integrity guarantee that PILLAR already makes about every number.
BUILDER fires on PILLAR's governed scoring output, not on raw CRM fields. Every rule verifies data freshness before executing. Every action logs its formula provenance to the governance trail. If your pipeline page says $4.2M, your board report says $4.2M — and BUILDER's automated save play fires on the same $4.2M, with the same audit trail, every time.
The operator's layer

CLI. YAML. Git.

BUILDER is editable in a browser by any Architect-role user, and in a terminal by any RevOps engineer. Rules export to YAML. YAML commits to git. Git enables PR review. Automation becomes infrastructure — versioned, reviewed, reversible.

$ pillar rules apply rules/
Pending changes:
  + CREATE  renewal-at-risk-no-play
  ~ UPDATE  champion-departed-rescue  (conditions changed)
  = NOOP    weekly-digest-monday
  ! SKIP    stuck-deal-escalation     (managed_by=ui; use --force)

Apply? [y/N] y
 Applied 2 changes in 1.2s
apiVersion: pillar.io/v1
kind: BuilderRule
metadata:
  name: renewal-at-risk-no-play
  owner: [email protected]
spec:
  trigger:
    type: schedule
    cron: "0 */4 * * *"
  conditions:
    all:
      - field: account.tier
        operator: equals
        value: A
      - field: account.renewal_risk_score
        operator: greater_than
        value: 70
  actions:
    - type: start_play
      template: renewal_save
      mode: propose
// DSL editor — browser form builder

[ Trigger        ] Schedule · every 4 hours
[ Condition 01   ] account.tier equals A
[ Condition 02   ] account.renewal_risk_score > 70
[ Condition 03   ] account.plays.count(state=ACTIVE,
                     template=renewal_save) = 0
[ Condition 04   ] no_activity_in(account, 14d)

[ Action 01      ] start_play(renewal_save) · mode: propose
[ Action 02      ] notify_user(owner) · mode: execute

[ Safety         ]
   Per-account rate limit ...... 1/day
   Circuit breaker ............. 5 errors / 10 min
   Required shadow ............. 7 days

[ Owner          ] [email protected]
[ Managed by     ] ui

  ✓ Dry-run: would have matched 12 accounts last 7 days

Version your revenue automation in git. Review PRs like you review infrastructure changes. Roll back with one command. This is config-as-code for the layer that runs your engine.

In practice

What operators actually automate.

Every use case below is drawn from real GTM patterns. Every one ships in BUILDER's starter-rules library so your first week doesn't start from scratch.

Use case 01 · Retention
Renewal triage at scale
SLA timer fires on at-risk accounts whose save play has been proposed but not started within 48h. Auto-escalates to VP CS. Saves the accounts that otherwise slip through the calendar.
Use case 02 · Expansion
Expansion capture
Event-triggered rule watches for cross-department adoption signals on Tier A accounts. When a second department exceeds adoption threshold, creates an expansion play with the regional AE.
Use case 03 · Process
Handoff enforcement
Event rule on deal.closed_won verifies mandatory handoff fields are populated. If missing, holds onboarding assignment and notifies the AE. No handoff, no kickoff.
Use case 04 · Pipeline
Pipeline hygiene
Scheduled rule runs every Wednesday at 3pm. Finds deals in Proposal stage with no next step, no activity in 14 days, no decision-maker identified. Creates a task for the AE with the specific missing fields.
Next step

See where your revenue architecture stands.

Before BUILDER automates anything, the underlying architecture has to be worth automating. The Blueprint Assessment scores your revenue operation across 5 pillars, 27 categories, 142 questions. Takes 20 minutes. Free, self-serve, no sales call required.

Category definition · boundary piece
The automation layer is where horizontal tools stop working. Salesforce Flow and HubSpot Workflows fire on raw CRM fields without knowing the formulas behind them. BUILDER fires on PILLAR's governed scoring output. Read: why horizontal revenue tools can't do this.