Intent-Task Catalog

The Intent-Task Catalog is the routing layer of the Decision plane: it maps every supported intent to a versioned task template, a v1 risk-class compatibility projection, and the Decision Specs that template produces. Native risk remains capability- and call-specific.

Intent and TaskTemplate below describe a deployment catalog protocol, not additional exported base wire types. The reference compiler accepts a declared intent or uses its small deterministic keyword fallback; it does not implement this catalog service or select task templates. The runtime must validate supported intent, template and authority before acting. A declared intent is a routing input, not authorization.

Definition

A versioned, governed registry of Intent entries (canonical intent name with metadata) and TaskTemplate entries (parameterized plan blueprints bound to one or more Decision Specs). Each intent declares its risk class, accepted channels, locale support, and the task templates eligible to handle it.

Why it exists

Intents are how the runtime understands what the user wants. If different teams classify “refund” differently or build different workflows for it, decisions become incomparable across teams, audit becomes impossible, and improvement loops stall. The catalog gives intents a single name, single risk classification, single set of approved templates.

How it works

1. Author an Intent with name, description, risk class, accepted channels.
2. Author one or more TaskTemplate entries that handle that intent.
3. Bind each task template to its Decision Specs (e.g., support.refund.eligibility and support.refund.execute).
4. Resolve at runtime — the admission/router resolves one supported intent and an eligible pinned template under current Run Context, policy and risk, then supplies the selected intent to compilation.
5. Emit decisions — this catalog profile requires the otherwise optional intent_ref on each Decision Record for evaluation and improvement.

Intent

{
  "intent_id": "support.refund",
  "version": "3.0.0",
  "owner_role": "support_ops",
  "description": "Customer requests a refund on a prior order.",
  "risk_class": "destructive",
  "accepted_channels": ["app_chat", "email", "voice"],
  "locale_support": ["en-IN", "en-US", "hi-IN"],
  "eligible_task_templates": ["task_refund_with_eligibility", "task_refund_self_serve"]
}

Intent fields are tightly governed because they decide which workflow runs and establish a coarse v1 safety ceiling. They do not replace native per-capability risk evaluation.

TaskTemplate

{
  "task_template_id": "task_refund_with_eligibility",
  "version": "2.1.0",
  "intent_id": "support.refund",
  "owner_role": "support_ops",
  "decision_bindings": [
    { "decision_key": "support.refund.eligibility", "checkpoint_after_step": "s2" },
    { "decision_key": "support.refund.execute",     "checkpoint_after_step": "s2" }
  ],
  "default_plan": {
    "steps": [
      { "id": "s1", "tool": "adp_orders.lookup", "params_schema": "schema://adp_orders.lookup.in" },
      { "id": "s2", "tool": "adp_policy.eval",   "depends_on": ["s1"] },
      { "id": "s3", "tool": "adp_payments.issue_refund","depends_on": ["s2"], "approval_mode": "destructive" }
    ]
  },
  "eligibility_rules": {
    "and": [
      { "==": [{ "var": "request.channel" }, "app_chat"] },
      { ">=": [{ "var": "user.tenure_days" }, 30] }
    ]
  }
}

Task templates are not scripts. They are versioned, owned, schema-validated blueprints the Planner expands into a concrete Plan.

Risk classification

Every v1 intent declares one of the approval-mode compatibility values as its risk_class; 2026-native capabilities additionally carry independent ActionRisk dimensions. Effects:

• the runtime validates the intent/template classification and supplies the run’s authorized safety_mode; the reference Compiler filters tools using that Run Context ceiling,
• the Compiler and Tool Gateway evaluate every declared native risk dimension against action_risk_policy,
• the Critic verifies plan steps respect both native policy and the v1 projection,
• the Trust plane can stratify sampling by native dimensions while retaining v1 historical slices.

Routing

For an inbound invokeAgent request:

1. Intent classification produces one canonical intent.
2. Eligibility rules are evaluated against verified Run Context using the deployment’s pinned resolver. A routing expression error is an explicit non-success, never silently false. Define and test the full tie order (for example configured priority, semantic version, then stable template ID); do not depend on iteration order or ambient time.
3. The selected template is the Planner’s blueprint.
4. Preserve the selected intent and immutable template reference in declared routing lineage (or RunContext.metadata under the deployment protocol). Do not invent required top-level intent_id / task_template_id fields on the base RunContext.

Admit the template’s actual features and exact required control profiles. A template cannot lower mandatory controls, expand a standing personal mandate, merge employer/personal trust domains, or obtain fresh budget by creating child work. Bind the concrete action at dispatch and retain the routing/template pins through recovery.

Interfaces

Inputs

• Raw user input (message, channel, locale, attachments)
• Run Context (user, agent, tenant, claims)

Outputs

• intent_id, task_template_id
• Decision-binding map for the planner
• Risk class for downstream sampling and release gates

Failure modes

• Multiple intents/templates match — use the documented deterministic resolver or return an explicit ambiguous/unsupported result.
• Selected template binds to a non-existent decision spec — reject catalog admission; the compiler also rejects an active policy’s unknown decision binding.
• Task template plan references a tool not in the pack’s tooling_layer — caught by the Critic’s verify pass.
• Intent risk class lower than the tool’s v1 projection — deny unless an explicit, governed policy path permits the higher ceiling; do not silently rewrite the intent.
• Capability lacks native risk while action_risk_policy governs the pack — fail closed and repair the adapter declaration.

Operational concerns

• Owner role accountable for every intent and template; orphans flagged.
• Versioned changes; deprecation windows for breaking changes.
• Per-tenant routing overlays cannot grant new tools, only constrain.
• Routing latency budget folded into the planner timeout.

Evaluation metrics

• Intent-classification precision/recall on golden requests.
• Template-selection consistency across replays.
• Risk-class drift detection (intent changing risk class across versions).
• Mean templates per intent (target: low).

Example

Two templates handling the same intent in different amount bands. Both may invoke the registered destructive refund capability; a smaller amount cannot relabel that capability as delegated. Any per-action approval difference comes from explicit policy, with domain currency/amount rules pinned by the workflow:

{
  "intent_id": "support.refund",
  "templates": [
    { "task_template_id": "task_refund_self_serve",
      "decision_bindings": [{ "decision_key": "support.refund.execute" }],
      "eligibility_rules": { "<=": [{ "var": "request.context.refund_amount" }, 200] },
      "highest_approval_mode": "destructive" },
    { "task_template_id": "task_refund_with_eligibility",
      "decision_bindings": [{ "decision_key": "support.refund.eligibility" }, { "decision_key": "support.refund.execute" }],
      "eligibility_rules": { ">": [{ "var": "request.context.refund_amount" }, 200] },
      "highest_approval_mode": "destructive" }
  ]
}

Common misconceptions

• Intents are not user phrases. They are canonical, governed names; classification maps phrases to intents.
• Task templates are not scripts. They are blueprints; the Planner expands them into a Plan.
• V1 risk class is not the whole risk model. It remains required for compatibility; ActionRisk independently describes effect, authority, reversibility, interaction, data scope, and optional decision TTL.