> For the complete documentation index, see [llms.txt](https://docs.nerovasystems.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nerovasystems.com/guides/operate-the-digital-employee/mandate.md).

# Set the autonomy mandate

The mandate is the tenant's autonomy contract: per verb, how independently the employee may act, bounded by a platform ceiling the tenant can never exceed. This guide builds the autonomy settings screen your merchants use to read and change it.

Action policy and approvals remain distinct from the fixed native campaigns and escalation-routing engine removed in the [local source retirement](https://docs.nerovasystems.com/documentation/console/platform-access#campaign-and-escalation-retirement). Those source changes are not a generation, compilation, or deployment claim.

> **Experimental.** The `/api/v1/**` operations on this page are callable with your Live key (`nrv_live_`), which runs on the free testing allowance until a commercial agreement is signed or a card is saved. See [Lifecycle and availability](https://docs.nerovasystems.com/documentation/api/lifecycle).

## What you'll build

A settings surface that renders each verb with its ceiling, the merchant's configured level, and the level actually in force, and applies changes safely under concurrent edits.

## Prerequisites

* An activated tenant and an API key with `mandate:read` and `mandate:write`; see [Authentication](https://docs.nerovasystems.com/documentation/getting-started/authentication).

## 1. Read the mandate

```bash
curl --request GET \
  --url "https://api.nerovasystems.com/api/v1/tenants/{tenantId}/mandate" \
  --header "Accept: application/json" \
  --header "Authorization: ******"
```

Every verb carries three values from one scale, ordered from most to least autonomous: `JustDoIt`, `DoItTellMe`, `AskFirst`, `Never`.

* `platformCeiling`: the most autonomous level Nerova permits for the verb. Examples in the existing source: `clientReplies` = `JustDoIt`, `bookingsAndReschedules` = `DoItTellMe`. Verbs without an explicit ceiling are capped at `Never`.
* `configuredLevel`: what the merchant chose.
* `effectiveLevel`: the level actually in force, the less autonomous of the two.

Render all three; showing only the configured level hides why the employee is behaving more conservatively than the merchant asked.

**First-release boundary:** the deprecated customer WhatsApp payment flow is not offered. The legacy `paymentLinks` verb and its `AskFirst` ceiling in existing source are not a recommendation to enable merchant payments. Read the actual manifest and distinguish source compatibility from released capabilities; this documentation does not retire the backend duty or change its wire value. Nerova SaaS billing and Testing credits are separate. See [First-release scope](https://docs.nerovasystems.com/documentation/console/platform-access#first-release-scope).

## 2. Apply changes

Send only the verbs that change, with the mandate's current `version`:

```bash
curl --request PUT \
  --url "https://api.nerovasystems.com/api/v1/tenants/{tenantId}/mandate" \
  --header "Accept: application/json" \
  --header "Authorization: ******" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: mandate-42145-2026-02-06" \
  --data '{
    "version": "v1:8c7d6e5f4a3b2c1d0e9f8a7b",
    "changes": [
      { "verb": "bookingsAndReschedules", "level": "DoItTellMe" }
    ],
    "actor": { "actorReference": "operator:jane.d", "delegationReference": null }
  }'
```

Two rules keep this honest:

* A level above the platform ceiling is rejected outright with `409`. Nothing is silently clamped, so what the merchant confirmed is what is stored.
* A stale `version` is rejected with `409`. Re-read the mandate and replay the change on top of the current state.

## 3. Know where the first mandate comes from

The initial mandate is recorded during activation with `PUT /api/v1/tenants/{tenantId}/activation/mandate`, validated against the ceiling published in the activation manifest, and receipted. This endpoint is for changes after go-live; the activation flow is walked end to end in [Provision and activate tenants](/guides/provision/partner-playbook.md) and specified in the [Activation reference](https://docs.nerovasystems.com/api-reference/activation).

## Can versus may

Two different questions govern every action the employee takes, and the mandate answers only the second:

* **Can** — what the employee is able to do at all. This is decided by verified capabilities: operations your integration has proven against the [capability model](https://docs.nerovasystems.com/documentation/platform/capability-model). Anything unverified is never attempted.
* **May** — how independently the employee acts on what it can do. That is the mandate: per verb, capped by the platform ceiling.

The split is visible on the tenant's two lines (the roles are defined in [Two channel roles](https://docs.nerovasystems.com/documentation/concepts/channels#two-channel-roles)):

* The **booking line** is the public number where customers book, reschedule, and cancel. Anyone can message it, but the employee only does what it has verified it can do — everything else hands off to a human.
* The **management line** is the merchant team's private line to the same employee for explicit requests. It is not a promise of proactive operational briefs, campaign reports, or escalation alerts. Customers never see this number, and access is closed: portal members verify automatically when they accept their invite, and unknown numbers are rejected — [routing fails closed](https://docs.nerovasystems.com/documentation/concepts/channels#routing-fails-closed), always, never a best guess.

The remaining source console messages cover explicit owner relay, template rejection, and booking-created/cancelled/changed notices. These are not a replacement escalation engine or scheduled campaign. Empty owner chat starts with a neutral prompt, not on-open operational brief/model work. Template presence does not prove transport or recipient delivery.

Explicit customer notification requests and approvals remain subject to their documented policy and channel requirements. Voice follows the same contract: when a number answers calls, it is the same employee with the same capabilities, the same fail-closed rules, and the same per-task price (see the [usage reference](https://docs.nerovasystems.com/api-reference/usage)).

## Next steps

* See what the granted autonomy produces: [Audit work and receipts](/guides/observe-and-account/work-and-receipts.md).
* Catch the moments the employee asks a human instead: [Work the attention queue](https://github.com/Nerova-Systems/Project-Songbird/tree/main/docs/guides/attention.md).
* Full request and response shapes: [Mandate reference](https://docs.nerovasystems.com/api-reference/mandate).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.nerovasystems.com/guides/operate-the-digital-employee/mandate.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.