> ## 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

> Mandatory outcomes, SLA enforcement, and the closed-loop system that makes Revenue Impact attribution possible.

# 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:

1. An outcome modal appears automatically
2. The user selects an outcome: **Renewed**, **Churned**, **Expanded**, or **Lost**
3. The user provides an outcome reason (text field)
4. 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 the `propose_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.