# Federation | Chainsaw

> One org-wide policy set, with rules scoped by repository and exceptions that carry an expiry and optional two-person approval. For estates with several business units, we scope the rollout with you.

Source: https://chain305.com/federation/

---

Multi-BU rollout

# One policy across every business unit.

One org-wide policy set, with rules scoped by repository and exceptions that carry an expiry and optional two-person approval. For estates with several business units, we scope the rollout with you.

[Book a 30-min architecture review](https://cal.com/chain305/30min)

Exception lifecycle

## Auto-expiry kills allow-list rot

Billy runs the queue.

1.  01 · Request
    
    Requested
    
    `chainsaw exception create`
    
    pre-filled
    

3.  02 · Approval
    
    Approved
    
    reason and scope, by your approvers
    

5.  03 · Expiry
    
    Expires
    
    default 30 days
    

7.   Refusal returns
    
    nobody renewed; the rule snaps back on the install path
    
     Renewed
    
    `chainsaw exception renew <id>`, new audit row
    

Several business units?

## 30 minutes, your org chart on screen.

Your BU layout mapped to one org-wide policy and repository-scoped rules. We scope the rollout with you.

[Get started](https://chain305.com/chainsaw/signup) [Read /architecture](https://chain305.com/architecture/)

---

## Long form

The full text behind this page, including detail the page itself leaves out.

Federation

### One policy across every business unit.

One org-wide policy set, with rules scoped by repository and exceptions that carry an expiry and optional two-person approval. For estates with several business units, we scope the rollout with you.

[Book a 30-min architecture review](https://cal.com/chain305/30min) [Read /architecture](https://chain305.com/architecture/)

Policy scope

#### One policy set, scoped by repository

-   Org-wide policy set
    
    One set of rules for the organisation.
    
-   Repository scope
    
    A rule can target specific repositories.
    
-   Exceptions
    
    Each carries an expiry, with optional two-person approval.
    

Exception lifecycle

#### Auto-expiry kills permanent allow-list rot

Billy runs the queue. Expiry is the default, not the exception.

1.  01
    
    ### Request
    
    Developer hits a refuse on the install path. CLI prints the rule that blocked them and a one-line \`chainsaw exception request\` command with the package, version, repo, and proposed expiry pre-filled.
    
2.  02
    
    ### Routing
    
    The request goes to your approvers.
    
3.  03
    
    ### Approval
    
    Reviewer sees a Billy queue entry with reviewer identity, written reason, scope, and a blast-radius preview computed against the live inventory: how many other repos would be affected if this exception widened.
    
4.  04
    
    ### Expiry
    
    Every exception carries an expiry. Default 30 days, configurable per policy. At expiry the rule snaps back to refuse on the install path — no permanent allow-list rot.
    
5.  05
    
    ### Renewal
    
    Renewal is a new request, not a silent extension. Same routing, same approval, fresh signed audit row. If nobody renews, the refuse returns automatically.
    
6.  06
    
    ### Audit
    
    Every transition — request, approve, expire, renew, deny — writes a signed audit row to the central stream. Same row format as enforce/refuse decisions.
    

Several business units?

#### 30 minutes, your org chart on screen.

Your BU layout mapped to one org-wide policy and repository-scoped rules. We scope the rollout with you.

[Get started](https://chain305.com/chainsaw/signup) [Read /architecture](https://chain305.com/architecture/)