Policies
The rules Deliverd applies on top of who can already do what: publishing policies for reports, standing rules for what agents ask people, and the gate for registered actions.
Admin → Policies holds three sets of rules. Each one only ever adds a restriction or a person: turning a rule on can never give anyone access they did not already have. Owners, admins and security admins can open the page.
- Publishing policies
- What may happen to a report: publishing it, sharing it, downloading it. A rule can block the action, hold it for approval, or cap how long access lasts.
- Agent request rules
- Standing rules applied to what an agent asks a person for, before anybody sees it. A rule can ask more people to agree or refuse the request.
- The gate
- Versioned rules for actions your agents register in advance, such as a refund or a payment. Written from the CLI or the API, and shown read-only on its own page.
Publishing policies
Every organisation starts with the same 7 rules. Switch each one on or off with its switch; the badge beside the name says what it does when it matches.
| Rule | Effect | On at the start |
|---|---|---|
| Agents cannot create public links (built in) | Blocks | Yes |
| Confidential reports stay inside the organisation (built in) | Blocks | Yes |
| Restricted reports cannot be downloaded | Blocks | Yes |
| External sharing requires approval | Needs approval | No |
| Agent publishes need approval | Needs approval | No |
| Publishing to external recipients needs approval | Needs approval | No |
| Board reports expire after 90 days | Exception | No |
The 2 built-in rules repeat a rule the product already applies in its own code, apply on every plan, and cannot be switched off. The others apply on the Business and Enterprise plans, where publishing policies are part of the plan. On other plans you can still switch them on; the choice is recorded and takes effect when you upgrade.
Sign-off before publishing
Two rules hold a publish for approval instead of making it live: Agent publishes need approval and Publishing to external recipients needs approval. Both start switched off. When one matches, the new version is stored and scanned but nobody is served it. It waits in Admin → Approvals until an administrator approves it, which makes it live, or declines it. The person who submitted a version cannot approve it. See Decisions and approvals.
Test before you switch a rule on
Test these rules, at the foot of the page, runs a hypothetical through the rules that apply to your organisation on its current plan: choose what someone tries to do, the report's classification, and whether a person or an agent is acting. It answers Allowed, Blocked or Needs approval, names the rule that decided, and changes nothing.
Agent request rules
Under Agent request rules. These are read when an approval, a review, a request for information or a publish is created, before the request is stored. A rule has conditions and an effect; a condition left empty means any.
| Field | What it does |
|---|---|
| Agent | One agent, or any agent. |
| Applies to | Approval requests, review requests, requests for information, publishes, or anything. |
| Risk floor | Matches requests at or above a level (low, medium, high, critical). Only an approval carries a risk, so a risk floor narrows the rule to approvals. |
| Then | Need more people to agree or Refuse it outright. There is no effect that approves. |
| How many must agree | For an escalation: how many different people must approve before the request is approved. |
| When to bring the extra people in | At once, or only if the request is still unanswered after a delay you choose. The delay happens once and only adds people. |
| Also send to | Named members added to whoever the agent asked. Nobody is ever taken off. |
When several rules match, a refusal wins over any escalation, the highest count of approvers wins, and everyone the rules name is added. A refused request is not created, and the refusal carries the rule's explanation, or its name when there is none.
- Escalation only works on approvals and reviews, which have approvers. On publishes and requests for information, use Refuse.
- A rule that waits before escalating must name who it brings in.
- What an individual agent may ask for at all is set on the agent's own page. See Agents.
The gate
The gate is for actions an agent performs itself, such as issuing a refund. Developers register each action with its fields and a default risk, and write versioned policies against them with deliverd actions push and deliverd policy push, or through the API. The agent calls the gate before it acts, and a rule answers: allow it, refuse it, or send it to a person. See The gate in the developer docs.
Open it from the row at the top of Admin → Policies, or go to The gate. The page reads and does not write: a rule changed in a web form would have no diff and no reviewer. It shows:
- The autonomy rate over 7, 30 or 90 days: the share of gated actions a rule settled without asking anyone, with how many went to a person and how they answered.
- Registered actions, their fields, default risk, and whether code or an administrator registered them.
- Each policy and its versions, with the active version open and its rules in priority order.
- Every decision, newest first: the action, who asked, what was decided, the rule that decided, and the input.
An action no rule mentions goes to a person. Gate policies apply on the plans that include publishing policies; on other plans they are stored but not applied, and every gated action goes to a person. Ethics rules are read at the gate too, and can turn an allow into a person or a refusal.