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

# Organization Policy Reference

> Reference the organization policy categories that can affect models, FORGE, Research, files, Knowledge, developer access, and shared usage.

# Organization policy reference

Organization policy is the team-level configuration layer between plan entitlement and individual/resource permissions.

## Policy categories

Depending on the current Organizations 3.0 rollout, policies can govern categories such as:

| Category           | Example controls                                       |
| ------------------ | ------------------------------------------------------ |
| Models             | allowed/blocked models, experimental model access      |
| FORGE              | enabled state, build limits, allowed project contexts  |
| Research           | enabled state, depth/source limits                     |
| Files              | upload availability, file/storage limits               |
| Knowledge          | source creation, organization Knowledge access         |
| Developer Platform | whether members can create keys/apps, API quota policy |
| Projects           | project creation/ownership rules                       |
| Agents             | agent creation and tool eligibility                    |
| Automation         | schedules, watchers, budgets, approval requirements    |
| Usage              | shared credit ceilings or workload limits              |

## Inherit vs override

An effective setting can come from the plan/platform default and then be narrowed by organization policy.

A useful UI distinguishes:

* inherited/default
* explicitly enabled
* explicitly disabled
* custom limit

## Narrowing access

An organization can usually make access more restrictive than a plan's maximum. A plan that includes FORGE does not require the organization to enable FORGE for every member.

## Policy changes

Before changing a policy used by production workflows:

1. Identify affected members/resources.
2. Check automation and developer integrations.
3. Make the smallest change.
4. Verify expected access with a representative non-admin account.
5. Review audit history when available.

## Troubleshooting

If a feature is available to a personal account but missing inside an organization, check organization policy before treating the behavior as a platform outage.

<Warning>
  Policy changes can affect many users at once. Avoid using broad organization policy to solve one person's isolated permission issue when a narrower resource or user override is available.
</Warning>