The HELM glossary

AIOps is the application of machine learning and analytics to operations telemetry so that noisy logs, metrics, and alerts become correlated incidents rather than a stream a person must read one line at a time.

The term covers anomaly detection, alert correlation, and noise reduction over logs, metrics, and traces. It predates agentic systems: classic AIOps surfaces a ranked, correlated view for a person to act on, but does not itself propose or take a bounded action. Analysts now describe a shift from AIOps toward agentic operations as platforms add agents that investigate and recommend a fix rather than only correlating signal.

Common mistakeMarketing any dashboard with a machine-learning badge as AIOps, even when it only correlates alerts and never recommends or takes a bounded action.

See alsoagentic operations, event correlation, noise reduction, observability

SourceForrester Wave: AIOps platforms Q2 2025

Agentic operations is the practice of assigning bounded, observable AI agents to investigate and propose fixes for operational problems under a named human approval boundary, rather than only surfacing alerts for a person to work by hand.

Where AIOps correlates and ranks, agentic operations adds an agent that reads telemetry, forms a hypothesis, and proposes or takes a next step, always inside a stated authority boundary. Gartner frames 2026 as a shift from AIOps to Agentic Ops, while also predicting that over forty percent of agentic AI projects will be cancelled by the end of 2027 over cost, unclear value, or inadequate risk controls. The distinction that survives that cancellation wave is whether the agent's proposal is grounded in evidence a person can check.

Common mistakeCalling a system agentic because it can call a large language model, when nothing in it actually proposes or takes an action against a live system.

See alsoAIOps, agentic AI, human-in-the-loop, graduated trust

SourceGartner: agentic AI cancellations forecast

Observability is the property of a system that lets an operator infer its internal state, including states the system was not explicitly built to report, from the logs, metrics, and traces it externally emits.

The classic formulation names three pillars: logs, metrics, and traces. Agentic platforms extend the same idea to an agent's own reasoning, adding agent traces and tool-call records as a fourth kind of telemetry a reader must be able to inspect. Observability is a property an estate either has or lacks for a given failure mode; buying a tool does not itself grant it if the estate never emits the telemetry the tool needs.

Common mistakeTreating observability as a product category rather than a property, so buying a tool is assumed to grant it regardless of what telemetry the estate actually emits.

See alsoagent observability, agent trace, event correlation, coverage

SourceDynatrace: third-generation platform announcement

Event correlation is the process of grouping related telemetry events, such as several monitoring alerts describing one underlying fault, into a single incident record instead of leaving each alert to be worked separately.

Correlation typically groups by shared topology, timing window, or a common upstream dependency. It is the first reduction stage in a signal funnel that runs from raw records admitted, through incidents, to situations and decisions, and its output ratio is exactly what a noise-reduction number reports. Correlating alerts together says nothing on its own about which of them caused the fault.

Formularatio(incidents, records)

Common mistakeAssuming correlation alone explains a fault, when grouping related alerts together says nothing about which one of them is the cause.

See alsonoise reduction, AIOps, situation, incident

SourceMoogsoft: executive summary

Noise reduction is the decrease in the number of items an operator must review as raw events are correlated into incidents and incidents are consolidated into situations.

It is usually reported as a ratio of one funnel stage to the one before it, for example situations as a percentage of the incidents that fed them. The number only means something alongside the two stage counts it came from. A vendor-quoted noise-reduction percentage without those counts cannot be checked against the underlying record.

Formularatio(situations, incidents)

Common mistakeReporting a noise-reduction percentage without stating the two stage counts it was computed from, so the ratio cannot be checked against the record.

See alsoevent correlation, situation, coverage

SourceBigPanda: product overview

An incident is a recorded, time-stamped disruption to a service, tracked from when it started through acknowledgement to resolution, and classified by severity.

An incident record carries a start time, an optional acknowledgement time, an optional resolution time, a severity, and the services and sites it touches. MTTA and MTTR are both computed directly from these timestamps. An incident is a narrower object than a situation: a situation can correlate evidence and a recommended action before any incident has formally been declared.

Common mistakeUsing incident and situation interchangeably, when a situation can span or precede the incidents it is later shown to explain.

See alsosituation, MTTA, MTTR, postmortem

SourcePagerDuty: AIOps documentation

A situation is a correlated, ranked case that gathers the evidence, impacted services, and a recommended action for an emerging problem, whether or not an incident has yet been declared against it.

A situation carries a state of decision-ready, investigating, or monitoring, a count of the evidence items behind it, and a count of any known source gaps in that evidence. It sits above the incident: several incidents can later be explained by one situation, or a situation can resolve before an incident is ever opened. Splunk's AI Canvas opens a comparable object, an ITSI episode, pre-loaded with services, KPIs, entities, and similar past episodes.

Common mistakeAssuming a situation always follows an incident, when the platform's situation record can exist before any incident has been opened.

See alsoincident, event correlation, evidence receipt

SourceSplunk: agentic operations at Cisco Live

MTTA, mean time to acknowledge, is the average elapsed time from an incident starting to a responder taking ownership of it.

It is computed only across incidents that carry an acknowledgement timestamp; an incident nobody has yet acknowledged cannot contribute a value to the average. A short MTTA says a responder noticed and claimed the incident quickly, and says nothing on its own about how long the fix then took.

Formulamean of acknowledgedAt − startedAt over incidents with an acknowledgement

Common mistakeAveraging every incident including ones never acknowledged, which either breaks the calculation or silently drags the reported average toward zero.

See alsoMTTR, MTTD, incident, on-call

SourcePagerDuty: Spring 2026 release

MTTR, mean time to resolve, is the average elapsed time from an incident starting to its resolution, measured only over incidents that have actually resolved.

Because MTTR excludes incidents still open, a period with several long-running unresolved incidents can show a falsely improving MTTR simply because the slow cases have not yet finished. Launch material that quotes a single case going from hours to minutes is not an MTTR claim; a defensible MTTR claim states the population it was measured over, not one example. HELM prints the same formula beside every MTTR figure it shows.

Formulamean of resolvedAt − startedAt over resolved incidents

Common mistakeQuoting an MTTR improvement without saying whether it covers every severity or only the incidents convenient to the claim.

See alsoMTTA, MTTD, error budget, postmortem

MTTD, mean time to detect, is the average elapsed time from when a fault actually begins to when monitoring or a person first notices it.

MTTD requires a detection timestamp distinct from the moment an incident record is opened, since a fault can run silently before anyone notices it. A platform that only stores when a record was created, not when the underlying fault began, cannot honestly compute MTTD and should say so rather than substitute the incident's start time.

Common mistakeTreating an incident's started timestamp as its detection time, when the two differ whenever a fault runs silently before anyone opens a record for it.

See alsoMTTA, MTTR, observability

SourceDatadog: Bits AI SRE deeper reasoning

An error budget is the amount of allowed unreliability still available under a service level objective before that objective is breached, expressed as a percentage of the target not yet spent.

It is derived from the gap between an objective's target and its current attainment. A shrinking error budget is a leading warning, not itself an incident: the objective is only actually breached once the budget reaches zero. Reporting the worst remaining budget across a set of services, rather than an average, is what keeps the figure meaningful as a warning.

Formulamin of serviceHealth.slos[].errorBudgetRemainingPercent

Common mistakeTreating a shrinking error budget as itself an incident, when it is a leading warning that only becomes an incident once the objective is actually breached.

See alsoSLO, burn rate, SLI

Burn rate is the speed at which a service is consuming its error budget, expressed as a multiple of the rate that would exhaust the budget exactly at the end of the measurement window.

A burn rate of one times means the budget is on pace to run out precisely at the window's end; higher multiples mean it will run out sooner. The HELM alert policy treats one times as a watch threshold, four times as attention, and eight times as critical. The peak burn rate across a set of services, not the average, is what a reader should watch, since averaging hides the single service closest to breach.

Formulamax of serviceHealth.slos[].burnRate

Common mistakeReading a burn rate above one as an active incident, when it means the budget is depleting faster than sustainable, not that the objective has already been missed.

See alsoerror budget, SLO

An SLO, service level objective, is the target level of a measured service level indicator that a service commits to over a defined window.

A service typically registers several SLOs, each naming its own indicator, target, and window, together with the current attainment against that target. HELM reports overall attainment as the mean across every registered objective, so one badly missed objective can be masked by several comfortably met ones unless the reader also checks the tightest one directly.

Formulamean of serviceHealth.slos[].attainmentPercent

Common mistakeConfusing an SLO with an SLA, when the objective is an internal engineering target and the agreement is the external, often contractual, commitment built on top of it.

See alsoSLI, error budget, burn rate

An SLI, service level indicator, is the specific measured quantity, such as availability or latency, that a service level objective sets a target for.

The indicator is the raw measurement; the objective is the target drawn against it. Choosing the wrong indicator, one that is easy to measure but does not reflect what a user experiences, produces an objective that can be met while users are still unhappy.

Common mistakePicking an SLI that is easy to measure rather than one that reflects what a user actually experiences, such as server-side success rate instead of completed user requests.

See alsoSLO, error budget

Change-failure rate is the share of production changes that cause a degradation, an incident, or a rollback, measured against every change deployed in the same period.

The metric originates in DORA's software delivery research and depends entirely on a consistent definition of failure. The HELM change record currently tracks approval state and rollback readiness per change rather than computing a change-failure percentage, and that gap is stated here rather than filled with an invented number.

Common mistakeQuoting a change-failure rate without defining what counts as a failure, since a rollback, a hotfix, and a customer-visible incident are not the same event.

See alsoblast radius, runbook

Blast radius is the extent of a system, measured in affected services, sites, or users, that a single failure or change can reach before it is contained.

A change's stated blast radius should widen with any shared infrastructure or hidden dependency it touches, not just the service it was intended to affect. A high-risk change with a large blast radius is exactly the case an approval gate and a rollback plan exist for.

Common mistakeEstimating blast radius from a service's architecture diagram alone, when shared infrastructure and hidden dependencies routinely widen it beyond the diagram.

See alsochange-failure rate, authority boundary

A runbook is a documented, repeatable procedure for diagnosing or resolving a specific class of operational problem, written so a responder or an agent can follow it under pressure.

An agent that reads telemetry and cross-references it against prior incidents and a knowledge base before a privileged command stops for a human to approve is running a runbook, rather than a person reading one. A runbook that is never revised drifts out of step with a system that has since changed underneath it.

Common mistakeWriting a runbook once and never revising it, so it drifts out of step with a system that has since changed underneath it.

See alsoon-call, postmortem, governed action

On-call is the rotation of responders, human or agent, who carry responsibility for acknowledging and responding to incidents during a scheduled shift.

PagerDuty's Spring 2026 release puts an SRE agent directly on the on-call roster alongside human responders, with per-agent permissions governing what it may do without waiting for approval. Adding an agent to a roster only works if its escalation path is defined as clearly as a human responder's.

Common mistakeAdding an agent to a roster without also defining its escalation path, so an incident an agent cannot resolve waits for a human who was never notified.

See alsoMTTA, runbook, specialist agent

SourcePagerDuty: Spring 2026 release

A postmortem is the written record produced after an incident closes that reconstructs its timeline, root cause, and the follow-up actions the team commits to.

The convention of a blameless postmortem, one that names causes and contributing factors rather than the person who happened to be on shift, exists because honest reporting is what a postmortem depends on to find the real cause. A postmortem is also where a comparable-incidents record earns its value, by showing whether the same failure has happened before.

Common mistakeWriting a postmortem that assigns blame to a person, which discourages the honest reporting a postmortem depends on to find the real cause.

See alsoincident, runbook, MTTR

SourceTraversal: state of the field in AI incident response

Agentic AI is a system built from one or more AI agents that pursue a goal across multiple steps, calling tools and observing the results, rather than returning a single response to a single prompt.

The defining behavior is the loop: an agent plans a next step, calls a tool, observes what came back, and decides what to do next, repeating until the goal is met or it abstains. Gartner's own framing pairs the category's growth with a warning that over forty percent of agentic AI projects will be cancelled by the end of 2027 for cost, unclear value, or inadequate risk controls.

Common mistakeCalling a chatbot agentic because it can hold a conversation, when nothing in it plans multiple steps or calls a tool against a live system.

See alsospecialist agent, tool call, agentic operations

SourceGartner: agentic AI cancellations forecast

A specialist agent is an AI agent scoped to one operational domain or task, such as a filesystem-capacity investigator or a change-risk advisor, rather than a single general-purpose assistant covering everything.

ServiceNow's Autonomous Workforce ships role-scoped AIOps Specialist and SRE Specialist agents under an AI Control Tower; BMC's HelixGPT similarly names a Situation Analyzer, a Best Action Recommender, and a Change Risk Advisor as separate agents. The scoping is what lets a specific tool set, context, and authority boundary be assigned per domain instead of one broad grant covering everything.

Common mistakeDeploying one broad agent for every domain and calling each invocation a specialist, when nothing scopes its authority, tools, or context to that domain.

See alsoagentic AI, autonomy gradation, on-call

SourceServiceNow: Autonomous Workforce announcement

Autonomy gradation is the practice of assigning an AI agent one of several defined levels of independence, from observe-only through propose, act-with-approval, and act, rather than a single all-or-nothing switch.

The field norm names four rough levels: observe, suggest, act with approval, and act. Dynatrace argues for determinism first, calling its own posture supervised autonomy, while the stated posture of HELM is recommend-and-propose. A gradation is only real if it shows up as a visible, per-workflow setting a person can inspect and change, not a description in marketing copy.

Common mistakeDescribing a system as having graduated autonomy when it exposes no visible, per-workflow setting a person can actually inspect or change.

See alsohuman-in-the-loop, graduated trust, governed action

SourceDynatrace: third-generation platform announcement

Human-in-the-loop is a design in which an AI agent's proposed output must be reviewed or approved by a person before it takes effect on a live system.

A 2026 survey of 696 respondents found sixty percent cite a lack of trust as the top blocker to autonomous operations, and sixty-two percent prefer a co-pilot over full autonomy, which is exactly the posture human-in-the-loop describes. The design only holds if the action genuinely waits on the review; a notification the person can ignore while the action proceeds anyway is not the same control.

Common mistakeCalling a system human-in-the-loop when the review step is a notification the person can ignore rather than an approval the action actually waits on.

See alsoautonomy gradation, governed action, graduated trust

SourceThe Register: survey of SREs on AI agents in production

Graduated trust is the earned expansion of an agent's authority over time, based on its demonstrated track record, rather than an authority level fixed permanently at deployment.

Cleric describes exactly this pattern: read-only by default, escalating to write access only when a team judges it ready. The same mechanism has to run in reverse, revoking authority if an agent's record changes, or the trust was never actually graduated, only granted once.

Common mistakeGranting an agent broad authority immediately because an early pilot went well, without a defined path for that authority to be revoked if its record later changes.

See alsoautonomy gradation, abstention, human-in-the-loop

SourceCleric: AI SRE

Abstention is an agent declining to propose or take an action when its confidence in the available evidence falls below a defined threshold, rather than guessing.

PagerDuty's SRE Agent can act on its recommended remediation or wait for approval; waiting is a form of abstention built into the product rather than an agent silently failing. An abstention that correctly flags insufficient evidence is the system working as intended, not a defect to be tuned away.

Common mistakeTreating every abstention as a failure of the agent, when an abstention that correctly flags insufficient evidence is the system working as designed.

See alsohallucination in operations, graduated trust, human-in-the-loop

SourcePagerDuty: Spring 2026 release

Hallucination in operations is an AI agent stating a fact, root cause, or fix as established when the operational record does not actually support the claim.

The failure is not limited to an invented citation or a fabricated fact; a plausible but unsupported root cause written into an incident record carries the same failure at higher stakes, since a responder may act on it. Grounding a prompt in the actual evidence record, and letting the agent abstain when the evidence is thin, are the two controls that address it directly.

Common mistakeAssuming hallucination only means an invented citation, when a plausible but unsupported root cause in an incident write-up is the same failure with higher stakes.

See alsogrounded prompt, abstention, evidence receipt

Agent observability is the ability to inspect what an AI agent believed, planned, and did at each step of a task, not only the final answer it returned.

Datadog's Bits Investigation renders a hypothesis tree alongside an agent trace listing every tool call the agent made. Logging only the prompt and the final response is not agent observability; the useful record also needs the intermediate tool calls, the evidence each call returned, and the reasoning that connected them.

Common mistakeEquating agent observability with logging every prompt and response, when the useful record also needs the tool calls, evidence, and reasoning that connected them.

See alsoagent trace, tool call, observability

SourceDatadog: Bits AI SRE deeper reasoning

An agent trace is the ordered record of an AI agent's reasoning steps, tool calls, and observations for a single task, replayable end to end.

Datadog names this object directly: an agent trace listing every tool call, shown beside the hypothesis it supports. A trace that shows only the agent's final explanation, without the intermediate tool calls that produced it, is a narration of the work rather than a trace of it.

Common mistakePublishing a trace that shows the agent's final explanation without the intermediate tool calls, which is a narration of the work rather than a trace of it.

See alsoagent observability, tool call, agentic AI

SourceDatadog: Bits AI SRE deeper reasoning

A tool call is a single, structured invocation an AI agent makes to an external function, API, or system, together with the arguments it passed and the result it received.

Every step in an agent trace corresponds to one tool call and its result. A tool call that returns without an error is not automatically a successful one; a call that returns the wrong data still returns a status code that looks fine.

Common mistakeCounting a tool call as successful because it returned without an error, when returning the wrong data is a silent failure a status code will not reveal.

See alsoagent trace, MCP, model gateway

SourceDatadog: Bits AI SRE deeper reasoning

MCP, the Model Context Protocol, is an open standard that lets an AI agent discover and call external tools and data sources through one consistent interface instead of a bespoke integration per source.

Anthropic introduced MCP and open-sourced it in November 2024. Standardizing how a tool is called says nothing about what authority that tool is allowed to exercise once called; that boundary has to be enforced separately.

Common mistakeTreating MCP as a guarantee of safety or scope, when the protocol standardizes how a tool is called and says nothing about what authority that tool may exercise.

See alsotool call, agent-to-agent protocol, model gateway

SourceAnthropic: Model Context Protocol announcement

An agent-to-agent protocol is a standard by which AI agents built on different frameworks or by different vendors can exchange tasks, context, and results with each other.

MCP and agent-to-agent interoperability both appear on the field's list of what wins a 2026 demonstration, alongside a model gateway that keeps a platform provider-neutral. Two agents both being described as agentic does not mean they can already cooperate; without a shared protocol, neither can hand the other a task.

Common mistakeAssuming agents from different vendors can already cooperate because both are described as agentic, when without a shared protocol neither can hand the other a task.

See alsoMCP, model gateway, specialist agent

SourceAgent2Agent protocol documentation

A model gateway is the layer that routes an application's requests to one of several interchangeable AI model providers, so the application is not locked to a single vendor's model.

A platform that describes itself as model-open, able to run Anthropic, OpenAI, Google or a fine-tuned model behind one default, depends on a model gateway to make that substitution possible. Routing to a different provider does not make every prompt and tool schema interchangeable in practice; each still needs to be verified against the new provider.

Common mistakeAssuming a model gateway makes every model interchangeable in practice, when prompts, tool schemas, and evaluation still need to be checked against each provider.

See alsoMCP, grounded prompt, agentic AI

A grounded prompt is an instruction to an AI model that is assembled from, and constrained to, verified data drawn from the operational record rather than the model's own unverified recall.

Grounding is the primary defense against hallucination in operations: a prompt built from an incident's actual fields is far less likely to produce an unsupported claim than one relying on the model's general training. A prompt that mentions real field names is not automatically grounded if the values inserted into it were never checked against the record those names describe.

Common mistakeCalling a prompt grounded because it references real field names, when the values inserted into it were never checked against the record the names claim to describe.

See alsohallucination in operations, evidence receipt, model gateway

Separation of duties is a control that requires two different principals to complete a sensitive action, so that no single identity can both request and approve the same change.

ServiceNow's AI Control Tower publishes role-scoped agents with full audit trails as one implementation of this idea. HELM states the rule directly: a principal never approves an action they proposed, whatever role either identity holds, and the control plane rejects an approval that fails the check rather than relying on a policy document alone.

Common mistakeWriting separation of duties as a policy statement without an enforcement point, so nothing actually stops one identity from proposing and approving the same action.

See alsofour-eyes principle, authority boundary, role-based access control

SourceServiceNow: Autonomous Workforce announcement

The four-eyes principle is the requirement that at least two people review and agree to an action before it takes effect, named for the two sets of eyes involved in the review.

It is one common implementation of separation of duties, distinguished by also requiring both reviewers to be independently qualified to judge the action, not merely a different login. A second approval from someone acting on the same incomplete information as the first is not an independent review.

Common mistakeSatisfying a four-eyes requirement with two approvals from the same team acting on the same incomplete information, rather than an independent second review.

See alsoseparation of duties, governed action

An authority boundary is the explicit limit on what an identity, human or agent, is permitted to decide or execute, enforced at the point an action is requested rather than assumed from a role title alone.

HELM enforces authority boundaries at the API-scope level, mapping each permission to a concrete scope a request must carry. An authority boundary written into a policy document has no force if the system carrying out the action never actually checks a request against it.

Common mistakeDefining an authority boundary in a policy document that the system carrying out the action never actually checks against.

See alsogoverned action, least privilege, effect permission

A governed action is a proposed change to a live system that only takes effect after it clears a named authority boundary, and that leaves a record of who proposed it, who approved it, and when it ran.

One published launch demonstration in this category stops for a human at exactly this point, with a privileged command approved in two clicks. The platform's own posture, recommend-and-propose, means an effect stays proposal-only until a named approver acts; calling an action governed only means something if the system would actually have refused to run it without that approval.

Common mistakeCalling an action governed because a person clicked a button, when nothing in the system would have stopped the action from running without that click.

See alsoauthority boundary, separation of duties, evidence receipt

An evidence receipt is a durable record attached to a decision or action that names the data it drew on, the reasoning applied, and who or what took the resulting step.

A receipt is what makes a claim like every step visible checkable rather than narrated: it points a reader to the actual source field or formula behind a figure, the way the platform's own scorecards do for every indicator they show. A narrative summary of a decision is not a receipt unless it names the actual source fields a reader can go check.

Common mistakeProducing a narrative summary of a decision and calling it a receipt, when a receipt must name the actual source fields a reader can go check.

See alsocustody, hash-linked ledger, audit trail

Custody is the unbroken record of who or what held responsibility for a piece of evidence or an action from its creation to the present, so its provenance can be verified rather than assumed.

A custody record differs from a plain access log by also capturing the state of the record at each handoff, not only that a handoff happened. Knowing who accessed a record is not the same as knowing what, if anything, changed while they held it.

Common mistakeKeeping a log of who touched a record without also keeping its state at each handoff, which proves access happened but not what changed.

See alsoevidence receipt, hash-linked ledger, immutability

A hash-linked ledger is a sequence of records in which each entry's hash is computed from its own content plus the previous entry's hash, so altering or removing any past entry breaks every hash that follows it.

The chain starts from a fixed genesis hash and ends at a head hash that summarizes the entire sequence up to that point; recomputing the chain and comparing it to the stored head hash is how tampering is detected. A created-at timestamp on a row proves nothing about whether that row was later edited, which is exactly the property a hash-linked ledger is built to rule out.

Common mistakeCalling a database with a created-at timestamp a ledger, when nothing about it would reveal a row that was edited after the fact.

See alsoimmutability, custody, attestation

Immutability is the property that a recorded entry cannot be altered after it is written, so any later correction must appear as a new entry rather than a change to the old one.

An append-only design is the usual way to enforce it: corrections are added as new rows that reference the one they supersede, and the original stays exactly as it was written. A missing edit button in the interface says nothing about whether the underlying rows can still be updated directly.

Common mistakeAssuming a database is immutable because the application's interface has no edit button, when the underlying rows can still be updated directly.

See alsohash-linked ledger, custody, continuous control monitoring

An attestation is a signed statement by an identified party, human or system, confirming that a specific record, release, or control was in the stated condition at a stated time.

A signed release passport or a completed SARIF scan tied to a deploy commit are both attestations in this sense: identified, dated, and checkable by a third party. A vendor's self-reported outcome percentage is not an attestation on its own, since nothing about it is signed, dated, or independently checkable.

Common mistakeAccepting a vendor's self-reported outcome percentage as an attestation, when nothing about it is signed, dated, or checkable by a third party.

See alsoevidence receipt, continuous control monitoring, audit trail

Continuous control monitoring is the automated, ongoing verification that a required control, such as an approval gate or an access boundary, is actually operating as designed, rather than a periodic manual check.

Where an annual audit samples a control at one point in time, continuous monitoring checks it on every relevant event, which is what catches a control that silently stops enforcing between audits. A control that passed last year's audit is not thereby proven to still be enforcing today.

Common mistakeTreating a passed annual audit as evidence a control is working today, when continuous monitoring exists precisely because a control can silently fail between audits.

See alsoaudit trail, attestation, authority boundary

An audit trail is the complete, ordered record of the actions taken on a system, including who or what took each one and when, sufficient to reconstruct events after the fact.

ServiceNow's own governance layer is described as carrying full audit trails alongside role-scoped permissions and enterprise context. An investigation into a near-miss usually needs the record of what was denied or attempted and failed just as much as the record of what succeeded, which an audit trail that logs only successful actions cannot supply.

Common mistakeKeeping an audit trail of successful actions only, when the record of a denied or failed attempt is often what an investigation actually needs.

See alsoevidence receipt, continuous control monitoring, role-based access control

SourceServiceNow: Autonomous Workforce announcement

Data residency is the requirement that specified data be stored, and sometimes processed, only within a named geographic or jurisdictional boundary.

Keeping data home is named directly among what wins a 2026 buyer's demonstration, alongside agent governance and MCP interoperability. Satisfying residency for storage alone is not enough if the same data is still routed through a processing or model endpoint located outside the required boundary.

Common mistakeSatisfying data residency for storage while still routing the same data through a processing or model endpoint located outside the required boundary.

See alsoleast privilege, authority boundary

Least privilege is the principle that an identity, human or agent, should hold only the permissions its current task requires, and no broader access kept in reserve for convenience.

The principle applies as much to an AI agent's tool access as to a human's login: an agent that only needs to read telemetry should not also hold a permission to execute a change. A broad role granted once during setup, because narrower roles were inconvenient to configure, tends to stay broad long after the task that justified it has narrowed.

Common mistakeGranting a broad role once during setup because narrower roles are inconvenient to configure, then never revisiting it as the actual task narrows.

See alsorole-based access control, authority boundary, effect permission

Role-based access control is an access model that grants permissions to a named role rather than to an individual identity, so a person or an agent's access follows the role they are assigned.

The HELM reference deployment defines seven interactive roles carrying twenty-four permissions between them, each mapped to a concrete API scope. Two people can hold the same job title while carrying differently scoped roles in the system, so a role label alone does not describe what either can actually do.

Common mistakeConfusing a role label with the actual permission set behind it, when two people can carry the same job title while holding differently scoped roles in the system.

See alsoleast privilege, separation of duties, effect permission

SourceServiceNow: Autonomous Workforce announcement

An effect permission is a granted capability that can change something outside the reader's own screen, such as approving a decision or executing an action, as distinct from a permission that only grants visibility.

HELM marks each permission definition with an explicit effect flag so the role table itself states which grants are read-only and which can change the record. An audit of a role's permission list is incomplete unless it also separates which permissions carry an effect, since that split is what actually determines blast radius.

Common mistakeAuditing only which permissions exist for a role without separating which of them carry an effect, which is the distinction that actually determines blast radius.

See alsoleast privilege, authority boundary, role-based access control

Avoidable spend is the portion of a monthly run rate that a specific, named opportunity, such as an idle compute reservation, could eliminate if it were acted on.

The figure is always paired with the run rate it is drawn against and a list of the named opportunities behind it, ranked by effort to realise. Avoidable spend is a modeled opportunity, not a saving already booked; the two are only the same once the recommended action has actually been taken and its effect confirmed.

FormulacostCapacity.monthlyRunRateUsd; avoidable value is modeled

Common mistakePresenting avoidable spend as savings already achieved, when the figure is a modeled opportunity that has not yet been realised.

See alsomodeled versus measured, realised outcome

Modeled versus measured is the distinction between a figure calculated from an assumption or a simulation and a figure read directly from an observed system, and it must be labelled every time either kind of number is shown.

Self-reported launch metrics in this category, such as a diagnostic-accuracy percentage or a single case going from hours to minutes, carry no published methodology, which is exactly the case this distinction exists to flag. The platform's own convention keeps a synthetic reference estate labelled as synthetic and a modeled figure labelled modeled everywhere it appears, rather than letting the label drop once a number has circulated for a while.

Common mistakeDropping the modeled label once a number has circulated for a while, so a reader later treats an estimate as an observed result.

See alsoavoidable spend, realised outcome, source gap

A realised outcome is a result confirmed to have actually occurred, such as a cost reduction that appeared on a subsequent bill, as distinct from a modeled projection of what acting on a recommendation would produce.

The gap between a recommendation and a realised outcome is exactly where an unverified claim can quietly become a verified one without anyone checking. Approving a recommended action is the moment the outcome becomes possible, not the moment it is realised; that only happens once the approved action's effect is later confirmed.

Common mistakeCounting a recommendation as an outcome the moment it is approved, when nothing has been realised until the approved action's effect is later confirmed.

See alsomodeled versus measured, avoidable spend

A source gap is a known area of the operating estate that no connected telemetry source currently covers, tracked explicitly rather than left to appear as false good health.

A gap that is never counted reads, wrongly, as a healthy area with nothing to report; naming and counting it instead is what keeps a coverage figure honest. Every situation record also carries its own source-gap count, so a reader can see exactly how much of the evidence behind a specific recommendation is missing.

Formulatelemetry.sourceGapCount

Common mistakeLetting an uncovered area of the estate read as healthy by default, when the honest state behind a source gap is unknown, not good.

See alsocoverage, modeled versus measured

Coverage is the share of an operating estate's registered telemetry sources that are actively connected and reporting fresh data, measured against every source registered for that estate.

The figure is built from source status counts: fresh, stale, and awaiting activation, alongside any known source gap. A source that connected once and then went stale should not keep counting toward coverage as though it were still reporting.

Formulatelemetry.coveragePercent and source status counts

Common mistakeReporting coverage as a share of sources with any historical connection, rather than sources currently fresh, so a source that went stale months ago still counts toward the total.

See alsosource gap, observability