netorca_ai_processor_info - Query NetOrca Pack AI processors¶

Part of the netautomate.netorca collection (version 2.0.0). Added in version 2.0.0.

Synopsis¶

Retrieve the AI processors configured on your services in NetOrca Pack.
An AI processor is the per-service AI agent of the Pack framework. It binds a service to an LLM model with a prompt and an action_type - the pipeline stages config, verify and execution, the optimiser, or the change_instance_validator that reviews consumers' PENDING changes as they arrive.
Each service can carry at most one processor per action_type; together they form the service's pack pipeline. Approving a change instance (or calling netautomate.netorca.netorca_pack_trigger) starts a pipeline run through the active processors, recorded as a pack pipeline you can poll with netautomate.netorca.netorca_pack_pipeline_info.
The processor's extra_data holds its behaviour switches - context enrichment flags, scheduling, and for validators allow_auto_approval/allow_auto_rejection.

Requirements¶

The below requirements are needed on the host that executes this module.

netorca-sdk >= 1.0.9, < 2.0.0

Parameters¶

Parameter	Comments
action_type `list` / elements=`str`	Filter by processor type. Choices: `config`, `verify`, `execution`, `optimiser`, `change_instance_validator`
active `bool`	Filter by whether the processor is enabled. Inactive processors are skipped by pipeline runs.
id `int`	Return only the AI processor with this ID. When set, all other filters are ignored. If the ID does not exist, an empty list is returned.
include_history `bool`	Also return the configuration history of the processor selected by `id` - the versioned audit trail of every edit, with actor and timestamp. Useful to answer "who changed this prompt, and when". Default: `false`
llm_model_id `list` / elements=`int`	Filter by ID of the LLM model the processor uses (see netautomate.netorca.netorca_llm_model_info).
service_id `list` / elements=`int`	Filter by ID of the service the processor belongs to.

Common parameters¶

Connection and query parameters shared by every module in the collection. See Authentication for the environment-variable pattern.

Parameter	Comments
context `str`	Point of view for the request. The same query returns different data depending on which side of the service relationship your team is on. `serviceowner` operates on the services your team offers - the requests made against them, their service items and deployed items. This is the side that validates, approves, deploys and completes changes. `consumer` operates on what your team consumes - the service items your applications declared and the change instances tracking your own requests. If not set, the value of the `NETORCA_CONTEXT` environment variable is used. Choices: `serviceowner`, `consumer` Default: `serviceowner`
limit `int`	Maximum number of results to return. Results are auto-paginated, so by default all matching records are returned regardless of the API's page size.
ordering `str`	Server-side field to order results by, for example `created` or `modified`. Prefix with `-` for descending order - `-modified` returns the most recently changed records first.
api_url `str` required	Base URL of the NetOrca API, for example `https://api.example.netorca.io`. The URL is normalised to end in a single `/v1`, so passing it with or without the suffix both work. If not set, the value of the `NETORCA_API_URL` environment variable is used.
api_key `str` required	API key of your NetOrca team. The NetOrca API supports API-key authentication only - there is no username/password mode. Treat the key like a password - supply it via the `NETORCA_API_KEY` environment variable (for example from a CI/CD secret) or from Ansible Vault, never as a literal in a playbook. If not set, the value of the `NETORCA_API_KEY` environment variable is used.
validate_certs `bool`	Whether to validate TLS certificates when talking to the API. Only disable this for lab instances with self-signed certificates. If not set, the value of the `NETORCA_VALIDATE_CERTS` environment variable is used. Default: `true`

Attributes¶

Attribute	Support	Description
check_mode	full	This module is read-only and runs identically with and without check mode.
diff_mode	N/A	This module never changes anything, so there is nothing to diff.

Notes¶

All modules talk to the NetOrca REST API and are typically executed on the controller (hosts=localhost with gather_facts=false, or delegate_to=localhost).
Module parameters take precedence over their NETORCA_* environment variable fallbacks.
Info modules never change anything and always return changed=false.
When nothing matches - including a lookup by ID that does not exist - info modules return an empty list rather than failing.
Filter options that accept a list match records with any of the given values (an OR filter, the platform's in lookup).

Examples¶

- name: All AI processors my team owns
  netautomate.netorca.netorca_ai_processor_info:
  register: processors

- name: The change validators that auto-review incoming requests
  netautomate.netorca.netorca_ai_processor_info:
    action_type: [change_instance_validator]
    active: true
  register: validators

- name: Pipeline stages configured for one service
  netautomate.netorca.netorca_ai_processor_info:
    service_id: [49]
    action_type: [config, verify, execution]
  register: stages

- name: One processor with its configuration audit trail
  netautomate.netorca.netorca_ai_processor_info:
    id: 65
    include_history: true
  register: processor

Return values¶

ai_processors¶

List of matching AI processors as returned by the NetOrca API. service and llm_model are returned as nested {id, name} objects.

Returned: always
Type: list / elements=dict
Sample:

[
  {
    "action_type": "config",
    "active": true,
    "extra_data": {
      "allow_auto_approval": false,
      "enable_pack_context": true
    },
    "id": 65,
    "llm_model": {
      "id": 8,
      "name": "Claude 4.6"
    },
    "name": "vip_config",
    "service": {
      "id": 49,
      "name": "VIRTUAL_SERVER"
    }
  }
]

count¶

Number of returned AI processors.

Returned: always
Type: int
Sample:

history¶

Configuration history of the processor, newest first, when include_history=true. Each entry is a full snapshot plus history_id, history_date, history_user and history_type.

Returned: when id and include_history are set
Type: list / elements=dict

Authors¶

NetAutomate (@netautomate)