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.
Governance & Enforcement
PILLAR’s governance layer ensures that the signal-to-outcome attribution chain is complete. Without enforcement, signals get ignored, plays go unfinished, and outcomes aren’t logged — breaking the Revenue Impact dashboard.Mandatory Play Outcomes
When all tasks in a play are completed, PILLAR requires the user to log an outcome before the play can close.Outcome Modal
When the last task checkbox is checked:- An outcome modal appears automatically
- The user selects an outcome: Renewed, Churned, Expanded, or Lost
- The user provides an outcome reason (text field)
- On submit, PILLAR marks the play as completed, updates the linked renewal disposition, resolves the trigger signal, and logs a governance entry
Why This Matters
Without mandatory outcomes:- Revenue Impact shows $0 in ARR Protected (no attribution chain)
- Renewals stay in approaching/urgent indefinitely
- Signal resolution never happens
- The board can’t see what PILLAR actually contributed
Auto-Disposition
When a play outcome is logged, PILLAR automatically updates the linked renewal:| Play Outcome | Renewal Disposition |
|---|---|
| RENEWED | RENEWED |
| CHURNED | CHURNED |
| EXPANDED | RENEWED |
| LOST | CHURNED |
SLA Enforcement
PILLAR enforces SLAs on two dimensions:Signal Acknowledgment SLA
PILLAR enforces configurable acknowledgment SLAs by signal severity. Critical signals require faster acknowledgment than warning signals. When a signal exceeds its acknowledgment SLA, PILLAR generates an escalation signal and logs a governance entry.Play SLA Breach
When an active play exceeds its configurable SLA, PILLAR generates a breach signal and logs a governance entry. Escalation signals are deduplicated to avoid alert fatigue.Default SLA thresholds are configurable per organization and available in the PILLAR Implementation Guide provided to active customers.
Governance Log
All enforcement actions are written to a governance log for audit purposes, tracking compliance status, entity type, severity, and category.MCP Integration
Every governed write is addressable via the MCP server so AI agents (Claude Desktop, Cursor, VS Code, ChatGPT, Zed, Windsurf) can take action through the same enforcement layer as the UI:| MCP Tool | What It Does | Governance |
|---|---|---|
acknowledge_signal | Mark a signal ACKNOWLEDGED / IN_PROGRESS / RESOLVED | Status transitions logged |
create_play | Create a save / expansion / onboarding play | SLA timer starts on creation |
complete_play | Close a play with mandatory outcome (RENEWED / CHURNED / EXPANDED / LOST) | Auto-updates linked renewal disposition + logs governance entry |
create_task | Create a platform task from NBA / signal / play / MQL handoff / manual | Governance log entry automatic |
update_task | Change task status, assignee, priority, or due date | Transition logged |
update_signal_status | Set signal status including SNOOZED / DISMISSED with reason | Reason required for non-standard transitions |
set_renewal_disposition | Set renewal disposition directly | Governance log entry automatic |
opt_in_benchmarks | Opt the org in/out of anonymized peer-cohort benchmarking | Cohort reassignment logged |
External MCP vs In-App Drafter
External MCP clients invoke write tools directly with the caller’s API-key permissions. The in-app Drafter agent does NOT call writes directly — it routes every mutation through thepropose_action meta-tool, which surfaces the proposal in the drawer with approve / reject / edit controls. Every decision is written to agent_actions for audit and flywheel learning. Both surfaces share the same 129 MCP tool catalog, so an AI acting via Claude Desktop and a user acting via Drafter land in the same governance trail.