Plans and Skeptron

How OctoMY™ defines robot behavior through Plans and manages authority through the Skeptron.

Did You Know?

The name "Skeptron" is derived from "scepter" - the ceremonial staff that represents royal authority. In OctoMY™, the Skeptron represents authority over a Plan, ensuring that only authorized operators can make a robot execute certain behaviors. This naming reflects OctoMY™'s philosophy that robots should remain under human control.

What is a Plan?

A Plan is a declarative document that describes all aspects of a node's behavior. Written in a JSON-based schema, it tells the node how to configure itself and respond to events.

Note: Plans were formerly called "Dogma" in earlier versions. Documentation using "Dogma" is outdated.

What plans configure

Plans cover many aspects of node operation:

Behavior

• Triggers and Actions - "When X happens, do Y"
• Directives - Standing orders for the node
• Event responses - How to react to sensor input

Resources

• Locations and areas - Map coordinates and regions
• Node references - Other nodes by ID
• Web services - External service URLs
• Shared secrets - Authentication tokens

Hardware

• Actuator configuration - Motor settings, limits
• Sensor configuration - Which sensors to use
• Lobe configuration - Locomotion type settings

Organization

• Grouping tags - Categories for nodes
• Node selectors - Dynamic groupings

Plan structure

A Plan contains:

The main directive

The main directive must contain the node's ID, which must match the key-pair in the node's keystore. If this doesn't match, the robot enters a vegetative safety state and won't respond to commands.

References and inlining

Detail sections can be used two ways:

Inlined

{
  "directive": {
    "name": "patrol",
    "secret": {"text": "patrol-auth-token"}
  }
}

Referenced

{
  "secret": {
    "name": "patrol-secret",
    "text": "patrol-auth-token"
  },
  "directive": {
    "name": "patrol",
    "secret": "#patrol-secret"
  }
}

References (using #name) allow multiple directives to share the same detail section, reducing duplication and errors.

What is the Skeptron?

The Skeptron is a virtual "baton" or "scepter" designating authority to execute a Plan. It answers the question: "Who has the authority to make this Plan take effect?"

Key properties

• Held by operators, not nodes - The human user holds authority
• Transferable - Can be delegated to others
• Required for execution - Plans don't execute without Skeptron authority
• Auditable - Authority transfers are logged

Authority model

Trust requirement

For a Plan to become effective:

1. The Skeptron holder initiates execution
2. Each participating node checks if it trusts the holder
3. Only nodes that trust the holder accept the Plan
4. Untrusted Plans are rejected

Operator vs node authority

A critical distinction:

Operators can:

• Move between Remotes while retaining authority
• Transfer Skeptron to other operators
• Define chain-of-command for network splits

Network split handling

Plans can define what happens when network connectivity is lost:

Safety guarantees

The Plan/Skeptron system provides safety:

• No unauthorized execution - Plans require proper authority
• Explicit trust - Nodes choose what authority to accept
• Audit trail - All authority changes logged
• Fail-safe - Invalid Plans trigger safe mode