Skill: TraceMem Intent and Automation Modes

Purpose

This skill explains how to choose the correct intent and automation_mode for a Decision Envelope. Correct classification is critical for potential policy checks and audit clarity.

⚠️ VALID AUTOMATION MODES - ONLY THESE 4 VALUES

When calling decision_create, the automation_mode parameter MUST be one of these exact values:

Mode	Description	Use When
propose	Agent suggests, human decides	You're gathering info or proposing actions
approve	Agent executes after approval	You need human confirmation before acting
override	Human overrides policy	Breaking rules with explicit permission
autonomous	Agent acts independently	Fully automated within policy bounds

INVALID values (these will cause errors):

• ❌ manual, auto, full_auto, automated
• ❌ assisted, interactive, human_required
• ❌ semi_auto, supervised, monitored

When to Use

• When calling decision_create and you need to populate the arguments.
• When determining if a task requires human-in-the-loop (propose) or can be done automatically (autonomous).

When NOT to Use

• Do not invent new automation modes. Stick to the strict list.

Core Rules

• Intent is Hierarchical: Intents must be dot-separated strings ordered from general to specific (Category -> Entity -> Action). Example: customer.order.refund.
• Automation Mode is Binding: The mode you select declares your authority level.
  • propose: You will only read data and suggest actions. You will NOT write/execute.
  • approve: You will execute, but only after explicit human approval (often enforced by policy).
  • override: You are explicitly breaking a rule (requires high permission).
  • autonomous: You will execute immediately without human intervention.

Correct Usage Pattern

Choosing an Intent

Structure: <Domain>.<Entity>.<Action>

• Good: security.access_log.scan, billing.invoice.void, support.ticket.reply.
• Bad: scan_logs, fix_thing, decision_1.

Choosing Automation Mode - Decision Tree

START: What kind of operation?
│
├─ Read-only (no state changes)
│  ├─ Just gathering information → `propose`
│  └─ Pre-approved read operation → `autonomous`
│
├─ Write/Update/Delete (state changes)
│  ├─ Need human approval first → `approve`
│  ├─ Just suggesting changes → `propose`
│  └─ Fully automated operation → `autonomous`
│
└─ Breaking a policy rule
   └─ Human override required → `override`

1. Are you just looking?
   • Mode: autonomous (if read-only duties are pre-approved) or propose (if you are just gathering info for a human).
2. Are you planning to change state (write/delete)?
   • If you need permission first: Mode propose (stop after planning).
   • If you have permission but need confirmation: Mode approve (TraceMem might force this anyway).
   • If you are fully trusted logic: Mode autonomous.

Example

{
  "intent": "network.firewall.block_ip",
  "automation_mode": "autonomous",
  "actor": "security-agent-v2"
}

Common Mistakes

• Using invalid automation_mode values: Using values like manual, auto, full_auto, assisted, or interactive will cause errors. ONLY use: propose, approve, override, or autonomous.
• Mismatched Mode: interacting as propose but then trying to decision_write (TraceMem may block this or flag it as a violation).
• Inconsistent Intents: Using user.create in one decision and create.user in another. Be consistent.
• Inventing automation modes: The 4 valid modes are fixed. You cannot create custom modes.

Safety Notes

• Policy Triggers: Policies are often attached to specific intents. Using the wrong intent might bypass safety checks or trigger unnecessary alarms.
• Escalation: If you start as autonomous but policy returns requires_exception, you effectively switch to an approval flow. The initial mode was your desired mode.