> ## 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. # BUILDER overview > What BUILDER is, how it fits with PILLAR and DRAFTER, and what it ships with on day one. BUILDER is the third layer of PILLAR, the Revenue Architecture Operating System. The dashboard — your account 360, your scoring, your signals. The assistant — ask any question, get answers grounded in your data. 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. If PILLAR is the eyes and DRAFTER is the brain, BUILDER is the hands. With three safety nets so the hands don't move until the brain has watched them long enough to trust them. ## 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. Fires when something happens in your data: critical signal fires, deal stage changes, score crashes. Fires when the calendar says it's time: daily 6am ET, every Monday, first of the month. Fires when a deadline elapsed: save play has been open 48h with no activity. ## Three execution modes (with mandatory progression) 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. BUILDER does almost everything. When conditions match, it creates a **proposed action** in your approval queue. A human approves or rejects with one click. BUILDER does the action directly. Logs everything. Reversible via the global kill switch. Every new rule **must** spend at least 7 days in shadow before promotion to propose. And at least 14 days in propose with an 80%+ approval rate before promotion to execute. The system enforces these gates — they're not suggestions. ## Ten action types Every action is mode-aware (shadow / propose / execute), idempotent, and logged with provenance. In-app, email, Slack, or Teams notification. Drops a task in someone's queue with a due date. Kicks off a play from your play templates. Reassigns to a manager + bumps severity + notifies. Acknowledge / resolve / suppress a signal. Forces an immediate scoring run. Creates a new signal — used to chain rules together. Generic field update (with high-impact gate). Calls an external webhook (Slack, Zapier, etc.). Escape hatch — calls any tool in PILLAR's MCP catalog. Plus `require_approval` which can be inserted as a "pause here for a human" step in the middle of any action chain. ## Three authoring paths `/builder` route — form for the common case (90% of rules), JSON DSL textarea for conditions and actions. Export any rule as YAML, edit in your code editor, version-control alongside scoring config, reapply with `pillar rules apply` from the CLI. Describe a rule in plain English. DRAFTER calls `propose_builder_rule`, returns a structured draft, you refine + save. ## Where to go next How BUILDER is shaped during implementation — the most important thing about BUILDER. The four out-of-the-box rule sets, with the rules in each. Every guardrail BUILDER ships with: shadow mode, kill switch, Guarantee runtime, more.