Automation SLOs for Operators

A workflow can be available all month and still fail the operator every day.

The API responds. The queue drains. The automation job completes. The dashboard stays green. Meanwhile, a source is stale, a command is accepted but never verified, an exception has no owner, or a facility remains in the wrong visible state.

Uptime measures whether a technical boundary was reachable. It does not measure whether operating work was current, complete, reconciled, or recoverable.

Self-storage operators need a second reliability layer: operating service-level objectives for automation. The useful objectives are not copied from a cloud-service status page. They are built around the decisions and state changes that a facility team must be able to trust.

This paper proposes four: freshness, completion, reconciliation, and recovery. It is an operator method and reference design—not a service commitment, product capability, customer case study, or performance result.

Open the full-size automation SLO control-loop diagram.

Objective	Operating question	False substitute
Freshness	Was every required source current enough when the decision was evaluated?	A recent dashboard refresh
Completion	Did due work reach an approved terminal operating state?	Queue acceptance or an email send
Reconciliation	Did the governing readback match the authorized intended state?	A provider success response
Recovery	Was the exception contained, restored or limited, reconciled, and owned?	Acknowledgment alone

Start with the operator, not the server

Google’s Site Reliability Engineering guidance defines a service-level indicator as a measure of a service behavior and an SLO as a target value or range measured by that indicator. It advises starting with what users care about rather than what is easiest to measure.

That is the right starting point, but the user in an operating workflow is not only the person clicking a screen. It may be:

• a facility manager deciding whether an exception is safe to close;
• a regional operator deciding which facilities need intervention;
• a customer relying on current office or access information;
• an accounting reviewer waiting for a posted result;
• a technician acting on an approved dispatch; or
• an AI-assisted workflow that must stop when required context is missing.

The reliability question is therefore not “Was the service up?” It is “Could the authorized user make or complete the intended operating decision with current evidence, within the required time, and recover when the path failed?”

Three definitions before four objectives

Keep the method simple:

• Operating indicator: the exact evidence-backed measure, including numerator, denominator, population, window, source, exclusions, and unknowns.
• Operating objective: the approved target and consequence-specific response when the indicator misses it.
• Operating error budget: the declared amount of ordinary failure or delay the workflow can absorb during the window before change, rollout, or automation expansion must slow or stop.

An error budget is not permission to spend harm. One unauthorized access change, duplicate financial side effect, privacy breach, or safety-relevant command may trigger an immediate stop even when an aggregate objective is technically inside target. Aggregate reliability and consequence floors belong in the same policy, but they are different controls.

Objective one: freshness

Freshness asks whether every required source was current enough at the moment a decision was made.

Freshness SLI = eligible decisions with all required source observations inside their approved freshness thresholds ÷ all eligible decisions evaluated during the window.

The unit is a decision opportunity, not a message. A workflow that reads five sources should not improve its score by emitting five successful API calls. Either the evidence packet met the declared freshness rule for that decision, or it did not.

Design the indicator with:

• the decision type and consequence class;
• the required source set and version;
• a freshness threshold for each source;
• the source’s occurrence or effective time;
• the time the workflow observed it;
• the decision evaluation time;
• the rule for clock skew and missing timestamps; and
• the required result when any source is stale, missing, or conflicted.

Missing evidence is not silently removed from the denominator. It is usually a bad or unknown decision opportunity. If a source was not required for that cohort, the cohort definition should say so before the measurement window begins.

A dashboard refreshed two minutes ago can still contain a facility-hours record last verified six months ago. Pipeline recency and source freshness are separate clocks.

Objective two: completion

Completion asks whether valid work reached a defined terminal operating state within its objective.

Completion SLI = in-scope cases due during the window that reached an allowed terminal state within the objective ÷ all in-scope cases due during the window.

The denominator is based on work due for completion, not only work that finished. Otherwise, abandoned cases disappear from the calculation.

Define allowed terminal states. reconciled, denied_by_policy, cancelled_by_authorized_owner, and limited_with_follow_up may all be legitimate for different workflows. queue_accepted, email_sent, work_order_created, and API_200 are usually intermediate technical states.

Completion should be segmented by workflow and consequence. A two-minute objective for an AI-drafted response review should not be averaged with a two-day maintenance inspection. A portfolio-wide average can remain green while the highest-consequence cohort is failing.

Objective three: reconciliation

Reconciliation asks whether the governing source or approved user path shows the intended authorized state after a command.

Reconciliation SLI = consequential commands due for verification that matched the intended state within the objective ÷ all consequential commands due for verification.

“Due for verification” matters. A command issued near the end of a reporting window should not be counted as a failure before its declared readback interval, or excluded forever because the window closed first. Use a mature-cohort rule: include commands whose reconciliation deadline has passed.

Preserve at least:

• command reference and idempotency key;
• facility and target entity;
• authorized intended state;
• provider or receiving-system receipt;
• governing reconciliation source;
• expected verification interval;
• observed state and observation time;
• match, mismatch, missing, or stale result; and
• exception owner and rollback path.

A provider-accepted request without readback remains accepted_not_verified. A technically successful reconciliation job that observes the wrong state is an operating failure and a technically successful measurement. That distinction is the point of the indicator.

Objective four: recovery

Recovery asks whether an operating exception was made safe, restored, limited, rolled back, or transferred to a qualified owner within the consequence-specific objective.

Recovery SLI = exceptions due during the window that reached an approved recovered or safely limited state within the objective ÷ all in-scope exceptions due during the window.

Do not use one recovery timer for every exception. Useful clocks include:

• time to acknowledge;
• time to assign a qualified owner;
• time to contain or stop further side effects;
• time to restore or roll back;
• time to reconcile the recovered state; and
• time to close with retained evidence.

A case can meet acknowledgment and containment objectives while missing restoration. Report those separately. “Someone looked at it” is not recovery.

Evidence integrity surrounds every objective

An SLO is only as trustworthy as its measurement boundary. Add an evidence-integrity control that answers:

• What percentage of eligible work produced the required measurement records?
• Which facilities, integrations, or time intervals have telemetry gaps?
• Did the metric definition, unit, aggregation, or attribute set change?
• Were duplicates, retries, late arrivals, and replayed records handled consistently?
• Did a collector restart reset a cumulative series?
• Did high-cardinality labels overflow, aggregate, or disappear?
• Can a reviewer trace a metric point back to a governed event or record?

OpenTelemetry’s Metrics Data Model distinguishes metric identity through the resource, instrumentation scope, name, point type, unit, and other intrinsic properties. It also distinguishes delta and cumulative temporality, defines timestamps for points, and describes resets and gaps. Those are valuable technical semantics. They do not decide which facility work belongs in the numerator, which source governs completion, or whether a missing business record should be counted as bad.

Keep an unknown bucket. A score based on 980 observed cases out of 1,000 eligible cases should not present itself as a complete 99% result because 970 of the 980 observed cases were good. The visible statement is:

• 970 good;
• 10 bad;
• 20 unknown;
• 1,000 eligible; and
• measurement coverage 98%.

Whether unknown counts as bad for the objective is a policy decision. Hiding it is not.

Build the denominator before the dashboard

For each SLO, write the denominator in plain language before selecting a chart.

A complete denominator definition names:

1. the workflow and operating question;
2. the facility and actor scope;
3. the consequence class;
4. the inclusion event;
5. the due or maturity rule;
6. the reporting window and timezone;
7. the duplicate and retry rule;
8. the cancellation and planned-maintenance rule;
9. the late-arrival and backfill rule;
10. the unknown-data rule; and
11. the definition version.

Do not exclude planned maintenance merely because it was planned. Exclude it only when the SLO definition said so in advance and the operating user did not lose the promised behavior. A planned outage that leaves customers or staff with an incorrect facility state is still an operating event.

Use windows without rewriting history

A rolling 30-day objective and a calendar-month report answer different questions. A short window can detect a fast failure. A longer window can show whether the workflow is consuming its allowed error budget.

When late evidence arrives, preserve both views:

• as originally reported: what the operator could know at the reporting cutoff;
• restated: the result after approved late evidence was incorporated; and
• restatement reason: the count, source, and rule that changed the result.

Never rewrite a prior period without a revision record. Reliability reporting is itself an operating artifact.

An operating error budget needs a stop policy

Google SRE describes an error budget as the acceptable amount by which a service may miss its SLO during a period, often used to balance reliability and change. The same idea can help an operator decide whether to expand, hold, or narrow automation.

For each objective, define:

• the allowed number or proportion of bad outcomes;
• the observation window;
• early-warning and exhausted states;
• which workflow changes pause when the budget burns too quickly;
• who can authorize continued operation;
• which exception classes bypass the aggregate budget; and
• what evidence permits re-enablement.

A simple burn indicator is:

Budget burn = observed bad outcomes during the window ÷ allowed bad outcomes for the same window.

A value above 1 means the allowed budget has been exceeded. Do not choose alert thresholds from a generic example. Use the workflow’s consequence, volume, observation delay, staffing, reversibility, and available history.

AI quality and operating reliability are not the same score

A model evaluation may measure classification accuracy, groundedness, abstention, or reviewer agreement. Those measures do not replace the four operating SLOs.

An AI recommendation can be judged correct while the source packet was stale. A reviewer can approve a sound recommendation while the command is duplicated. The provider can execute the right command while the governing source never reconciles. The workflow can recover correctly while the original model output remains wrong.

Link the records, but preserve the layers:

1. model and prompt evaluation;
2. decision-context freshness;
3. authority and human review;
4. command completion;
5. reconciliation; and
6. exception recovery.

NIST AI RMF 1.0 frames AI risk management through Govern, Map, Measure, and Manage. The functions support the organizational discipline around these layers. They do not provide a self-storage SLO, a certification, or a numeric target.

A fictional temporary-hours workflow

The following example is fictional. It describes no real facility, customer, provider, deployment, or result.

A demonstration portfolio allows qualified regional reviewers to approve temporary office-hours notices. An AI assistant may assemble the current facility identity, public-hours source, weather observation, affected appointment window, and proposed notice. It cannot publish.

The team defines:

• Freshness: every review packet must contain an approved facility identity and public-hours observation inside their declared thresholds.
• Completion: every approved notice case must reach published-and-verified, denied, cancelled-by-owner, or safely limited within its consequence-specific time.
• Reconciliation: every publish command due for verification must match a fresh public-page readback before the notice is called live.
• Recovery: every readback mismatch must be acknowledged, contained, assigned, corrected or rolled back, and reconciled within its declared clocks.

During a fictional exercise, 100 cases mature for reporting. Ninety-six are good, two miss their objectives, and two have missing reconciliation telemetry. The report does not say “98% reliable.” It says 96 good, 2 bad, 2 unknown, 100 eligible, and 98% measurement coverage. Policy then determines whether unknown is treated as bad and whether either known failure crosses a consequence floor.

A release gate for automation SLOs

Before publishing or governing work from an automation SLO, verify:

• the operating user and promised behavior are named;
• the indicator is different from the objective and the agreement;
• the numerator, denominator, window, cohort, source, and definition version are explicit;
• freshness measures required source state at decision time;
• completion uses due work and approved terminal states;
• reconciliation uses mature commands and a governing readback;
• recovery separates acknowledgment, containment, restoration, reconciliation, and closure;
• unknown and uninstrumented work remain visible;
• duplicates, retries, late arrivals, replay, and resets have declared rules;
• facility, workflow, and consequence cohorts are not averaged into false comfort;
• high-consequence floors can stop automation regardless of aggregate budget;
• error-budget exhaustion has an owner and predeclared response;
• restatements preserve the originally reported result; and
• one operator can reconstruct the score from retained evidence.

Run the worksheet

Download the automation SLO design worksheet. It contains four fictional objective rows for a temporary-hours workflow and no real company, facility, customer, vendor, or performance data.

1. Choose one bounded workflow and write the operating promise in plain language.
2. Define the freshness, completion, reconciliation, and recovery populations.
3. Insert one missing source observation. Confirm it becomes bad or unknown rather than disappearing.
4. Move a command across the reporting cutoff. Confirm the mature-cohort rule prevents premature failure or permanent exclusion.
5. Duplicate a command receipt. Confirm business idempotency prevents a second outcome.
6. Remove reconciliation telemetry. Confirm measurement coverage falls.
7. Trigger one high-consequence exception while the aggregate objective remains green. Confirm the stop policy wins.
8. Ask a second operator to reproduce the numerator and denominator using only the worksheet and evidence references.

The method succeeds when the score drives a responsible operating decision—not when the dashboard stays green.

Sources and limitations

Observed August 22, 2026:

• Google Site Reliability Engineering: Service Level Objectives, for user-centered SLIs, SLOs, validity conditions, and error-budget concepts.
• Google SRE: Production Services Best Practices, for defining SLOs in user terms and using error budgets in change decisions.
• OpenTelemetry Metrics Data Model, whose overview and core model sections are marked Stable while the page as a whole reports mixed status, for metric identity, aggregation, temporality, timestamps, resets, and gaps.
• NIST Cybersecurity Framework 2.0, published February 26, 2024, for voluntary Govern, Identify, Protect, Detect, Respond, and Recover outcomes.
• NIST AI Risk Management Framework 1.0, published January 26, 2023, for voluntary Govern, Map, Measure, and Manage functions. NIST’s AI Resource Center currently states that version 1.0 is being updated and a revised version is in progress.

Google SRE guidance describes general software-service practices, not a self-storage standard or contractual service level. OpenTelemetry defines technical metric data semantics, not operating denominators, authority, completion, or truth; its Metrics Data Model page reports mixed status even though its overview and core model sections are marked Stable. NIST CSF 2.0 and AI RMF 1.0 are voluntary, high-level frameworks and do not certify this method or supply numeric targets; the cited AI RMF version is under revision. The four-objective model, definitions, worksheet, consequence floors, and fictional exercise are proposed here and require local operational, technical, privacy, legal, security, and source-owner review.

Disclosure

I am Chief Operating Officer of modSTORAGE and CEO and Co-Founder of Facily.ai. This paper is an authored operating method. It is not a product SLO, service-level agreement, reliability result, customer case study, certification, facility relationship, or product-availability claim.