# Account request objectives

> Prepare a paused observed-request objective and distinguish fresh burn reads from original-trigger evidence.

Canonical page: https://anectico.com/docs/respond/account-objectives/


## Current activation limit

You can preview and save a paused account objective, validate its configuration, and read its
control state. Activation currently refuses; a saved definition or successful configuration test
does not establish a working alert. A fresh burn read and an original-trigger read remain separate
read-only capabilities, with explicit unavailable states when their evidence cannot be measured.

## Define one objective

An account request objective applies a target and burn policy to the
[observed customer request definition](/docs/investigate/customer-reliability#choose-the-request-population).
It binds one exact project, service, optional environment and operation, and one explicit account
type and key. Use the definition's outcome, exclusion and account-stamp rules unchanged. Unknown
outcomes have an allowance of zero unless the person explicitly chooses another value.

Use an existing alert rule with `query.data_type: customer_requests`, typed
`query.customer_requests` and one `account_slo_burn` condition. Explicitly set the target,
compliance, long and short windows, factor, minimum samples, strict coverage requirement,
cadence, timeout and notification routing. Review the returned normalized paused rule,
`account_objective_admission`, installed history, source and coverage checks, effective work
limits and notification effects before confirming identical arguments. Creation is paused;
activation currently refuses with `account_objective_activation_unavailable`. The saved proposal
does not establish retained, settled and unsampled accepted-intake history or a qualified runtime. Neither observed reads nor a
metadata preview prove that prerequisite. A preview measures no sample counts and reserves no
objective slot.

Every tier has the same safety ceiling: 20 active account objectives per project, cadence at
least five minutes, and the existing organization concurrency and source resource limits.
These are safety limits, not plan allowances or a usage price. Creation and work edits require
`alerts:rules:write`, `groups:read`, `traces:read` and `agents:content:read` with current project
policy. Generic validation also advertises `evals:read`; MCP adds `mcp:write`. Rule metadata
uses its existing read authority, with source fields and identifying text withheld when access
is absent. Pause-only needs rule-write authority without a source read, and deletion uses
`alerts:rules:delete`. No unavailable source should stop a person pausing a rule.

```bash
anectico alerts rules create --project PROJECT_UUID --file objective.json --idempotency-key INTENT_UUID -o json
anectico alerts rules get RULE_UUID -o json
anectico alerts rules test RULE_UUID --project PROJECT_UUID -o json
anectico slo account-burn RULE_UUID --project PROJECT_UUID --as-of AS_OF_UTC -o json
anectico alerts account-objective-evidence ALERT_UUID --project PROJECT_UUID -o json
```

Create and update first return a complete server preview and confirmation token. Confirm only
identical approved arguments. A different revision, source definition, policy, authority,
owner, privacy generation or routing requires a fresh preview; `--yes` answers only a local
prompt. Keep the same creation key after a lost response to recover the original rule and
version. Manual `alerts rules evaluate` remains a separately approved, state-changing and
potentially notifying write. It cannot bypass strict activation; a burn read is no substitute
for that approval.

The fresh read is `GET /api/v1/slo/{rule_id}/account-burn` or gateway action
`get_account_slo_burn` through `execute_read_action`. Select the project and optionally one
RFC3339 `as_of`; the server normalizes it to UTC and refuses future instants. Policy, window,
definition, factor, target and account overrides are refused. The response keeps the objective,
controls, definition, actual policy and counts from one exact rule revision, with requested
and effective windows, classified and unknown denominators, budget, consumed and remaining
budget, per-window burn, sample and coverage states, owner boundary, reason, redactions and
limits. Missing rates and `would_fire` set to `null` mean **not evaluated**, never false or healthy.
A paused rule remains visibly paused. Reads reserve no objective slot, mutate no alert state
and send nothing; actual source scans still use query budgets and resource admission.

Both burn and original-trigger reads require current `alerts:read`, `groups:read`,
`traces:read` and `agents:content:read`, plus project policy. MCP also needs `mcp:read`.
Customer API keys and verified member sessions are supported. External OAuth, operator and
SYSTEM source actors refuse before evidence assembly. Scheduled work separately records an
API-key or organization-member grant and rechecks it; readers never borrow that stronger owner.
Revocation or source-policy loss can pause scheduled work; fresh approved authority is needed
to resume. An unmeasured interval neither fires nor recovers an alert and interrupts continuous
measured recovery.

An external `alert.fired` or `alert.recovered` event retains its minimal reference, state and
severity. Follow the alert reference with
`GET /api/v1/alerts/{alert_id}/account-objective-evidence`, gateway
`get_account_objective_alert_evidence`, or the CLI command above. This is the immutable original
triggering definition, revision, windows, counts and coverage; a later fresh burn does not
replace it. Erasure, privacy invalidation, expiry or shortened source history withholds
measurements immediately and cleanup removes account-bearing copies, retaining permitted
control receipts. Delivered external messages cannot be recalled.

There is no aggregate account or objective proof viewer. Returned exact person and trace
links from ordinary reliability reads open current contextual evidence, which may be partial
or erased. See [customer reliability](/docs/investigate/customer-reliability) and
[permissions](/docs/reference/permissions). The person chooses routes and any existing owned
agent destination; Anectico runs no investigation or remediation loop.

## Evidence lifetime and privacy

Account request objectives remain paused until their source and runtime qualification is
available. Their evidence follows the history of the requests it measured. When any required
interval expires, history is shortened or a contributor is erased, the evidence is withheld;
missing history authority is not a healthy result. An original trigger, when available, keeps
its original definition, policy, revision, window and counts. A fresh measurement cannot
replace that history.

Reading or delivering account evidence requires current alert, account, trace and content
permissions plus the current account-attribute policy. Alert-read permission alone returns
control information without restricted account coordinates or measurements. Agent event
messages contain closed references and state, not account keys, measurements or private
authority. Authority is checked again for queued retries. An erased account remains unevaluable.

Queued evidence is cleared under the same source lifetime, including restored old
copies. Minimal response receipts can retain identity, status and clocks without reconstructing
the account measurement. Shared account aggregates are not included in one person's export:
other contributors' data is protected. Messages already delivered to external destinations
cannot be recalled.

## Ask your agent

Use `create_alert_rule` for the separately approved paused proposal. Use
`get_account_slo_burn` and `get_account_objective_alert_evidence` through
`execute_read_action` for the two evidence reads. The native commands are shown above.

> Prepare a paused objective for this exact account and service. Show its normalized definition,
> source checks and activation limitation before I approve saving it. Do not describe it as active.