Skip to content

Change Instance Validator

When a Consumer submits a declaration and change instances enter a pending state, the Service Owner must approve or reject them — a step known as validation. This can be done manually, through scripting, or by using an AI Processor as a Change Instance Validator.

The Change Instance Validator passes the consumer's requested declaration and the service's configuration to an LLM, which evaluates whether the request should be approved or rejected. This is useful for enforcing validation rules that go beyond what JSON Schema or regex validation can express — such as business logic, policy constraints, or cross-field dependencies that require a deeper level of assessment.

The Change Instance Validator acts as an automated validation layer between the consumer's submission and the actual processing of their intent on the Service Owner's infrastructure.

How it works

When a consumer submits a declaration and a change instance enters the pending state, the Change Instance Validator is triggered automatically. The LLM receives the consumer's declaration along with the service context and returns a decision to approve or reject the change instance.

NetOrca expects a specific internal response format from the validator — custom Response JSON Schemas are not supported for this AI Processor type.

Setting Up

Each service can have one Change Instance Validator. Service Owners can configure auto-approval and auto-rejection, and optionally include additional service context in the prompt payload.

POST /v1/external/serviceowner/ai_processors/ HTTP/1.1
Content-Type: application/json
Authorization: Token <YOUR_TOKEN>
{
  "name": "Firewall Policy Validator",
  "service": <service_id>,
  "llm_model": <llm_model_id>,
  "action_type": "change_instance_validator",
  "prompt": "Validate the consumer's declaration against our security policies and naming conventions.",
  "extra_data": {
    "allow_auto_approval": true,
    "allow_auto_rejection": false,
    "send_service_info": true,
    "send_existing_service_items": false
  }
}

Options

  • Allow auto-approval — When enabled, the validator can automatically approve change instances without Service Owner intervention if the LLM determines the declaration is valid.
  • Allow auto-rejection — When enabled, the validator can automatically reject change instances if the LLM determines the declaration is invalid.
  • Send service info — Includes service metadata (name, schema, description) in the payload, giving the LLM more context about the service being validated.
  • Send existing service items — Includes existing service items in the payload, useful for detecting conflicts or duplicates across declarations.

Prompt

Define the prompt that customizes the LLM's behavior for this validation. This prompt provides the instructions that guide how the AI evaluates the consumer's declaration.

Example: 

Review the following consumer declaration for compliance with our firewall policy.
Reject if any rule allows unrestricted inbound access (0.0.0.0/0) to production zones.
Reject if naming conventions do not follow the pattern: <env>-<zone>-<direction>-<port>.
Approve if all rules comply with the above policies.

Final Prompt Generation

The final payload sent to the LLM combines the system prompt, the Service Owner's validator prompt, and the relevant service and declaration data:

{
  "netorca_prompt": "<system prompt provided by LLM Model>",
  "serviceowner_prompt": "<AI Validator prompt provided by the Service Owner>",
  "declaration": {"... service item declaration"},
  "change_instance_id": "<change_instance_id>"
}