# Policy

Policy says who may do what to which stored records. Each entity, a kind
of stored record such as a todo, lists who may create, read, change and
delete its records. The compiler applies those lists to every read and
write your code makes, so you never write a permission check yourself.

This todo may be created, read, changed and deleted only by its owner:

```jadpo
// domains/todos/entities/todo.jadpo
entity Todo {
    id: Uuid
    owner_id: User.id {
        on_delete: OnDelete.restricted
    }
    title: TodoTitle

    policy: {
        create: [owner_id]
        read: [owner_id]
        update: [owner_id]
        delete: [owner_id]
    }
}
```

`owner_id` is a reference to a `User`, so the person it points to is the
one let in. A caller no list names is refused, and a todo they may not
read behaves as if it didn't exist ([When policy says no](when-policy-says-no.md)).

Each entry in a list names who it lets in, in one of four ways:

| Who | Written | Lets in |
|---|---|---|
| [A user field on the record](a-user-field-on-the-record.md) | `owner_id` | the user that field points to |
| [A membership role](a-membership-role.md) | `CompanyRole.editor` | a user with that role in the record's company |
| [Anyone signed in, or anyone](anyone-signed-in-or-anyone.md) | `Access.authenticated`, `Access.public` | anyone signed in; anyone at all |
| [Background work](background-work.md) | `Access.system` | schedules and subscribers, limited to the tenant their event came from |

When your app is shared by many customer companies, [Tenancy](tenancy.md)
keeps each company's records to its own members, whatever the lists say.