# AM-RP-001: proposed service ownership and decision preparation

Author: Anant Mishra. Prepared 7 November 2026. **Unassigned, unapproved and unexecuted.** This guide and service-ownership.template.json prepare a fictional local read-only knowledge assistant. They appoint nobody, authorize no operation and establish no operational coverage. Anant Mishra is the preparation byline, not the fictional service's appointed owner.

## Proposed boundary

Permitted task: authorized internal staff find approved procedures and receive source-backed explanations. Excluded: approvals, eligibility decisions, changes to source systems and actions on external equipment. Actual service identity, intended use and accepted scope remain null. Deployment, authority enforcement and a review interface are not implemented.

## Five proposed accountabilities

- Service owner: permitted purpose, scope and material operating decisions.
- Operator: technical actions inside an expressly accepted mandate.
- Information owner: source authority, access-policy questions and relevant information lifecycle decisions.
- Evaluation reviewer: evidence scrutiny and review limitations.
- Risk escalation: issues outside the agreed local mandate.

These are design choices, not prescribed job titles or existing appointments. Real completion requires identities, delegates, working contact routes and evidence that each mandate is accepted. If roles overlap, disclose the overlap and arrange proportionate scrutiny; do not claim independent review that has not occurred. Access to an administrator account does not itself establish authority to approve organizational use.

## Six planned decision exercises, zero executed

1. Adopt an initial permitted scope and its limitations.
2. Authorize a bounded evaluation, permitted inputs, reviewer and test window.
3. Decide whether to promote a changed configuration or source set.
4. Place an affected path on hold under an already accepted protective mandate.
5. Decide whether to resume that path after review of evidence and limits.
6. Retire or transition the service, including users, integrations and information lifecycle review.

A role label and list of required evidence are proposed inputs. They must never populate actual decision, person, time, evidence or review fields. Preserve the published template unfilled; use a separate attributable record only after actual authorization and execution.

## Before an actual exercise

Name authorized participants and delegates; verify accepted authority, scope, access and contact routes. Define availability, waiting-time, quality and access responses separately. Establish justified objectives and review windows; all numerical objectives remain null here. The Google reliability example supplies no target for this design. Access or quality concerns do not become an acceptable availability allowance.

Agree who may apply a bounded protective suspension, what changes require a scope decision, and who can decide resumption. Define disagreement escalation and how users learn which functions remain available. An operator mandate is a proposed organizational arrangement requiring actual adoption, not an instruction to change a machine now.

Capture missed handoffs, refused changes, dissent and unresolved evidence as well as any successful decision. Require the exact configuration/source scope and review limitations to remain visible. A retirement exercise should identify the relevant policy owner for information/record handling; this guide supplies no legal retention or deletion rule.

## Structural reproduction

From repository root:

```sh
PYTHONDONTWRITEBYTECODE=1 python3 scripts/check-research-preparation.py
```

The release gate checks five unique role slots, six unique planned decisions, valid role references, required-evidence labels and blank actual fields. It contacts no person, assistant, model or hardware and executes zero exercises. A passing structure check is not adoption, staffing, incident readiness, independent review or risk acceptance. Existing permission scenarios, recovery drills and DGX measurements remain unexecuted.

## Primary references and limits

- NIST AI RMF Playbook, Govern: https://airc.nist.gov/airmf-resources/playbook/govern/ — responsibilities, communication and authority. The page currently notes that AI RMF 1.0 is being updated. This is planning guidance, not certification or a five-role mandate.
- Google SRE, Example Error Budget Policy: https://sre.google/workbook/error-budget-policy/ — a written reliability decision policy with review/approval and escalation. Do not import the example service, people, thresholds or targets.

Reviewed 7 November 2026. AI assistance was used in preparation. No staff appointment, organization/client relationship, adopted policy, deployment, measured improvement, empirical paper, peer review or Scholar indexing is claimed. Actual people, authority evidence, objectives, exercise records and accountable review remain required.