Edit an SLO without changing its name

An SLO's name is its stable identity for critical user journey links and clients.

• Targets, rolling windows, lifecycle, alert policies, service, source, sampling interval and queries can be edited as new configuration revisions.
• Correcting a counter selector does not require a new SLO name.

Portal review and apply

1. Open the existing SLO and select Edit definition.
2. Edit its structured measurement in Measurement, use Settings for custom queries, or edit YAML. Keep the same metadata.name.
3. In Measurement, select Verify telemetry and review SLO. In Settings or YAML, select Validate and plan. Review the resulting definition and expected revision.
4. In Measurement, confirm that you reviewed the measurement and evidence limitations, then Save reviewed SLO. Other tabs require the measurement-reset acknowledgement when applicable before Apply definition.
5. Check the telemetry connection deployment policy. Automatic mode queues the new revision after save; manual mode requires Rules → Apply reviewed rules. Check runtime evaluation separately.

• The tabs edit one definition.
  • Guided measurement edits appear in YAML; YAML changes repopulate the matching guided fields, including availability versus latency.
  • Settings changes to targets, windows and policies carry back into Measurement.
  • Switching tabs or editing any field discards the previous review and acknowledgement, so saving requires a fresh review.
  • Invalid YAML or a filter that cannot be represented unambiguously keeps the current editor and its input intact until corrected.
  • Existing custom-query and shared-measurement SLOs stay in Settings/YAML; opening Measurement never guesses a replacement measurement.
• The API/CLI uses the same revision checks.
  • A stale editor or client receives a conflict instead of overwriting another change.
  • A matching definition is a no-op and does not create an archive or reset coverage.
• The default SLO owns spec.measurement; edit it and the objective together. No separate measurement revision needs changing.
  • A guided edit retains the stored intent description and journey reference, and synchronizes its measurement, scope, objective and policy fields with the resulting reviewed SLO.
  • This authoring context is not a new model recommendation or approval: the original conversation, frozen recommendation evidence and audit history remain attached to their original revisions.
  • Use an intent conversation when a fresh goal/evidence/approval trail is needed.
  • For an explicitly shared legacy measurement, update spec.measurementBinding through a verified compilation using the selected binding revision, or select Use custom queries in the editor.
  • Switching to custom queries explicitly removes the binding and intent provenance in the proposed revision.
  • Editing queries while retaining a binding that declares different semantics is rejected.
  • Previous revisions retain their original binding reference.

What happens to existing evidence

• Every replaced server-managed SLO revision is frozen with its definition, the observations still retained at edit time, collection/alert state, replacement time and authenticated replacing actor.
  • The archive and new definition commit in the same memory-store snapshot or PostgreSQL transaction, including atomic intent apply/rollback.
  • Failed writes and aborted multi-resource batches do not leave a partial archive.
• A measurement edit clears active interval samples, provider-window observations and measurement health.
  • The new revision begins with unknown attainment until fresh collection supplies enough evidence.
  • Outstanding collectors cannot insert old observations or overwrite the new revision's collection health.
  • Target/policy-only interval-count edits retain their compatible underlying samples; provider-window observations remain configuration-revision scoped and require fresh collection.
• Archives preserve evidence that had not already aged out of active retention.
  • They cannot recover expired samples, recreate revisions edited before this feature was enabled, or undo consumed error budget.
  • Archives persist with PostgreSQL and last only for the process lifetime in memory mode.
  • They have no automatic expiry or application purge endpoint in this alpha; include them in database capacity and retention planning.

Read previous revisions

• The edit dialog's Previous revisions section lists archived definitions, actors and evidence counts.
  • The list is paginated and each revision exposes its original YAML.
  • Current SLO charts continue to show the current definition only.
• Read-only, tenant-authorized API endpoints:

• GET /api/slos/SLO/revisions?limit=20&beforeRevision=0 lists archived revisions, newest first. Pass nextBeforeRevision back as beforeRevision for the next page.
• GET /api/slos/SLO/revisions/REVISION returns one archived definition and metadata.
• GET /api/slos/SLO/history?revision=REVISION&rangeSeconds=3600 evaluates its retained observations using that revision's original definition and archive-time horizon. Existing alignment, chart limits and optional policy filters apply.

CLI example:

nines history my-objective --context playground \
  --revision 1 --range 1h --resolution 1m --agent

• An archived-revision read does not query a provider, collect data, apply a definition or deploy rules.
  • Authorized owners/editors may deliberately reapply reviewed previous YAML as another new revision.
  • Agent-assisted changes and rollback continue through their separately approved exact-digest workflow.

Recording rules and operator behavior

• Both interval-count and provider-window recording outputs carry nines_revision.
  • Interval aggregate and burn-alert selectors pin the revision as well as tenant, source, SLO and operator resource UID.
  • New rules cannot sum recordings produced by a different measurement revision.
  • Historical series remain in Prometheus/Mimir according to the provider's retention.
• After a definition edit, existing rule deployment/evaluation evidence is out of date until the new revision is deployed and verified.
  • An automatic source queues that deployment after save; a manual source requires reviewed apply.
  • Deployment, successful rule evaluation and measured attainment remain distinct states.
• The Kubernetes operator accepts same-name measurement edits and reconciles rules using the new generation (or the portal's explicit configuration revision).
  • Kubernetes/GitOps remains the definition history for standalone operator resources; server-side archives cover portal/server-managed definitions. Resource ownership checks remain enforced.
  • Moving an operator resource between source/destination routes still requires withdrawal/cleanup on the original route before recreation; an edit does not transfer ownership or leave unmanaged rules behind.
• Server-managed rule destinations stay pinned after publication.
  • Withdraw the owned rules before changing their source/destination.
  • Retiring an objective is a separate reviewed archive/delete operation; archived objectives retain historical reads and cannot be edited.