> ## Documentation Index
> Fetch the complete documentation index at: https://closedloop.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Proof Permissions

> Log a permission request for a proof candidate and track whether it was approved, denied, or is still pending, scoped to one kind of use.

You picked a proof candidate, and now the ask needs a record. This skill drafts and logs the permission request, then keeps its status, so every piece of proof has an auditable answer to "are we allowed to use this?"

## Usage

```
/closedloop-proof-permissions log a permission request for candidate 1
/closedloop-proof-permissions mark request <id> approved
/closedloop-proof-permissions what is the status of request <id>?
```

Pick a candidate from [Sales Proof](/docs/skills/sales-proof), [Reference Customers](/docs/skills/reference-customers), [Case Study Scout](/docs/skills/case-study-scout), or [Customer Proof](/docs/skills/customer-proof) first.

## What You Get

* **A request record** with its own id, the usage scope, the person, and the account
* **A drafted email, logged rather than sent**: recipient, subject, and body, kept as the record of what was asked
* **A status**: approved, denied, or pending
* **The actions** that move the status as the real conversation progresses

## Permission Is Always Scoped

`website`, `sales`, `case_study`, and `live_reference` are four separate approvals. One never implies another: a quote approved for a sales deck is not approved for the homepage.

## Design Principles

**Never sends customer email.** The request is drafted and logged. Having the conversation is yours.

**A logged request is not consent.** The status is one you set by hand after the real conversation, not one the customer sets. Nothing claims approval until you mark it approved.

**Real ids only.** The skill uses request ids it was given, never invented ones.