All Products
Search
Document Center

STAROps:Core concepts

Last Updated:Sep 30, 2026

This topic lists the common STAROps terms and their English names for reference when you read other documentation. The terms are grouped into six conceptual layers. Each entry states the relevant quantity constraints and status definitions.

Execution actors and capabilities

  • Digital Employee: An intelligent execution entity in STAROps that can answer questions immediately and take on long-running tasks. Digital Employees include system-provided Digital Employees and custom Digital Employees.

  • System-provided Digital Employee: A restricted Digital Employee provided by STAROps. It is also referred to as a system employee, built-in employee, or default employee, and corresponds to Ops Agent (apsara-ops). It does not bind to a RAM role and inherits the user's permissions at runtime. It does not support Skill management or Connector configuration, but it can create Missions.

  • Custom Digital Employee: A Digital Employee that you create. It is also referred to as a self-built Digital Employee or custom employee. It binds to a RAM role, and that role's access policy configuration determines the resources that it can access at runtime. You can configure Skills, MCP services, Connectors, and the Alibaba Cloud command-line interface (CLI) for a custom Digital Employee.

  • Default Rule: A Markdown-based behavioral constraint for a Digital Employee. It consists of role definition, data source focus, analysis logic constraints, and output requirements. Changes take effect only for Threads created afterward.

  • Skill: A reusable capability module that you configure for a Digital Employee and define in SKILL.md. Skills use progressive loading, so their complete instructions load only when a task matches them. A Default Rule constrains how work is performed, whereas a Skill extends specific capabilities.

  • MCP service: A service that follows the Model Context Protocol (MCP) and provides a Digital Employee with a set of callable tools. After adding an MCP service, configure an execution mode for each tool. For write operations, configure the tool to ask every time.

Data access and modeling

  • Connector: A configuration module that connects external systems, such as Cloud Monitor 2.0 and Simple Log Service, to a Digital Employee. Each Connector uses its own access identity; it neither supports automatic creation of roles nor grants data permissions. Connectors include system Connectors for observability, resources, pipelines, and code access, as well as custom Connectors for MCP services and environment agents.

  • Fabric: The process of creating data models for Connector targets. When Agentic modeling is enabled, the system models data automatically. You can also model data through a conversation, review the result, and then apply it. Saving a Connector successfully does not mean that modeling is complete.

  • UModel: A model that describes system topology and entity relationships, such as ownership between services and instances and call relationships between services. O&M objects in a UModel are called entities. You can enter @ in a Thread to reference an entity.

  • Region: The region where data is stored. Dual-center deployment supports China North 2 (Beijing) and Singapore, which you select when creating a Digital Employee. Cross-border data transfers can occur when the Region and the resources being operated are in different legal jurisdictions.

Conversations and long-running tasks

  • Intelligent conversation: A natural language interaction capability that uses multi-turn conversations to query data, analyze alerts, interpret metrics, analyze logs, and diagnose faults. Its corresponding console module is Intelligent Assistant. You can start an intelligent conversation from STAROps, Cloud Monitor 2.0, or Simple Log Service.

  • Thread: The record unit of an intelligent conversation. You can continue, rename, or delete a Thread. Deleting a Thread permanently removes its historical messages and analysis results.

  • Model: A large language model (LLM) used to generate responses and analysis conclusions. Select a Model before sending the first message or creating a Mission. If you do not select one, STAROps uses Auto, the default Model configured on the server.

  • Mission: A long-running, asynchronous O&M goal that can plan Tasks across days or months. Missions run on a schedule or in response to events, and Tasks can also be triggered manually.

  • Blueprint: The execution plan for a Mission. The AI generates the Blueprint, which starts after you confirm it. It defines the content, trigger method, execution order, and notification method for each Task. Updates added in a conversation also require your confirmation and apply only to subsequent Tasks.

  • Task: A specific execution unit in a Mission that can be triggered on a schedule, manually, or by an event. A Task generates a Task Report when it is complete. A Task and an action item under a Finding use the same English name, but they refer to different concepts.

  • Artifact: An output generated by a Task, including a Task Report and a process snapshot.

  • Notification channel: A channel through which a Mission sends messages externally. It shares a framework with Cloud Monitor 2.0 notification recipients. Notification types include AI assistance requests, report generation, and Task exceptions.

Issues and closed-loop management

  • Finding: A stable problem determination that a Digital Employee derives from a set of observations. A Finding includes affected objects, evidence, action items, and validation conditions. STAROps updates the existing Finding for the same problem instead of creating duplicates. Findings are enabled by default and can be disabled in Digital Employee settings. The capability name is Findings.

  • Action item (Task): The smallest unit used to close a Finding. It includes an action to execute, an owner, validation conditions, and a risk level. Low-risk action items can run automatically, whereas high-risk action items require Human-in-the-Loop (HIL).

Security and permissions

  • User permissions: Determine whether you can use and manage Digital Employees, Threads, Missions, Artifacts, Skills, and MCP services. They do not determine the data that a Digital Employee can access.

  • Digital Employee runtime permissions: Determine the data and resources that a Digital Employee can access at runtime. They are independent of user permissions and must be granted separately. System-provided Digital Employees are an exception because they inherit user permissions.

  • Human-in-the-Loop (HIL): A mechanism in which the AI pauses and asks for your confirmation before continuing when it encounters a risky operation, insufficient information, multiple remediation options, or an unexpected situation. Pending requests are delivered as AI assistance messages. If you do not respond for an extended period, that execution fails.

  • Execution policy: The confirmation mechanism for tools called by a Digital Employee. It applies four layers of validation in order: reject policies, automatic allow policies, Human-in-the-Loop (HIL), and RAM role permissions. A matching reject policy rejects the operation directly. A matching automatic allow policy, or a built-in read-only rule, executes the operation directly. All other operations require Human-in-the-Loop (HIL).

Metering and quotas

  • AI_Credit: The unified metering and settlement unit for STAROps. It offsets model resource consumption for scenarios such as intelligent conversations and Missions and cannot be redeemed for cash. One question and answer consumes approximately 30 AI_Credits, and one root cause analysis consumes approximately 200 AI_Credits. These values are estimates.

  • Agent_Day: The billing item for a custom Digital Employee that remains on duty continuously, 24 hours a day and 7 days a week. It is measured per Digital Employee per calendar day and applies only to custom Digital Employees; system-provided Digital Employees are not billed. It takes effect on October 10, 2026. For unit prices and deduction rules, see Billing overview.