OPAL reference

OPAL (Operator Permission and Access Layer) is the structured command interface every operator uses to drive OctoMY™ — you, an automation rule, or a connected language model. This page is the per-domain catalogue of registered OPAL Tasks.

For the architectural overview (why OPAL exists, the three operator types, permissions, audit), see OPAL architecture.

Security Consideration

OPAL Tasks are validated against operator permissions before execution. An LLM can only perform tasks the user has explicitly granted scope for — and those permissions can be revoked at any time. Every execution lands in the OPAL History database, so you can always see exactly what was done, by whom, against which Sentient and Node.

Task domains

Every subsystem registers its tasks into the central registry under a domain prefix. Click through for per-task parameter schemas, permissions, and examples.

Rotation via OPAL is Euler-angle based and gizmo-independent. construct.item_set_transform sets rotation with rx/ry/rz (degrees) written directly to the item's transform — it does not go through the interactive rotation gizmo, so OPAL plans set orientation the same way regardless of gizmo behaviour.

An SDF item stores its rotation in one of eight representations. By default rx/ry/rz are degrees in the item's current mode. The optional rotationMode argument (EulerZYX, EulerXYZ, EulerXZY, EulerYXZ, EulerYZX, EulerZXY, AxisAngle, Quaternion) sets the rotation in that mode; for AxisAngle, rx/ry/rz are the axis and angle is the degrees. Given alone, rotationMode converts the item's current rotation without moving it, which is also what construct.item_set_rotation_mode (itemId, mode) does.

A transform under an expression is set through the parameter task. translate, rotate and scale are parameters, so an expression covers a whole channel: construct.sdf.set_all_parameters with {"rotate": "=vec3(0, anim.progress * 360, 0)"}. The scalars on construct.item_set_transform carry literal numbers only. It refuses a channel an expression already owns, because the expression is re-evaluated every frame and would discard the write.

Detail pages

Operator types

Every task invocation is made by one of three operator types. The task is the same; the permission gate differs:

See OPAL architecture for the rationale and Trust Levels for how permissions are graduated.

TaskPlans

A single task does one thing. A TaskPlan is a JSON document chaining tasks, with each step able to reference earlier outputs:

{
  "steps": [
    {"task": "catalog.list_by_tag", "tag": "trust"},
    {"task": "catalog.capture",     "id": "$1.results[0].id"},
    {"task": "filesystem.copy",     "from": "$2.image_path", "to": "/exports/"}
  ]
}

The same shape underlies LLM-composed plans, batch jobs, and trigger directives. See Plans for authoring tools.

Where you see OPAL in the UI