Account request 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. 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.

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 and 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.