Task Taxonomy

Wishfleet uses a composable grammar for real-world task requests. Instead of picking from a fixed catalog of task types, you describe four things: the action (what to do), the resource (what to act on), the subject (the property or object of focus that matters), and the result (what structured shape to return). Wishfleet resolves the combination, routes it, and returns validated evidence.

The grammar is intentionally narrow enough to be implementable but generic enough to absorb fuzzy input at the boundary and normalize it into a strict internal representation.

Display form

action / resource.sub_resource [subject] => result

Example:

inspect / building.room [water intrusion] => inspection report

Read it as an imperative sentence: inspect a building room for water intrusion, and return an inspection report.

Every task has all four slots. When the verb+resource has no meaningful subject (rare), the subject is the sentinel - and the display form drops the brackets.

Actions

The action vocabulary is small and closed. Two categories frame the set — they are used in docs and product grouping, but they are not part of the identifier.

Observe — produces a structured record; the world is unchanged.

Act — something physical is added, removed, or moved.

New verbs are added only when a genuinely new action shape appears — not to encode domain flavor (that belongs in the subject).

Resources

Resources are dotted type.sub_type identifiers drawn from a small top-level set:

Sub-resources observed today include room, unit, door, store, exterior, roof, lockbox, and address. Each sub-resource has its own attribute schema (a building.room has a room_name; a fixture.lockbox has an expected_position).

Subject

Subject is a first-class slot with its own type vocabulary. subject.type selects a concrete subject schema that carries the acceptance criteria for that subject.

A subject: water_intrusion payload defines the checklist, a subject: damage payload defines the categorization schema, a subject: dimensions payload defines the measurements list. The same subject schema can be consumed by multiple verbs — e.g. inspect / property.exterior [damage] and capture / property.exterior [damage] share one damage schema.

Because domain specificity lives in the subject, the verb set stays small. inspect can look for water intrusion, mold, storm damage, or code violations — each is a distinct subject, not a distinct verb.

Sentinel. When a verb+resource has no meaningful subject, submit subject: { "type": "-" }. Canonical IDs use the literal - segment. This preserves the shape of every task: four peer slots in the envelope, five segments in the canonical ID.

Results

The result profile determines the shape of what you receive back. Profiles are reused across verbs where sensible.

A complete example

A property manager needs a laundry room measured for appliance fit.

{
  "action": {
    "type": "measure",
    "instructions": "Measure the laundry room for appliance fit."
  },
  "resource": {
    "type": "building.room",
    "location": {
      "address": "123 Main St, Unit 4, Los Angeles, CA",
      "access_contact": "onsite manager",
      "access_notes": "Call on arrival"
    },
    "attributes": {
      "room_name": "laundry room"
    }
  },
  "subject": {
    "type": "dimensions",
    "measurements": ["length", "width", "height", "doorway_width"]
  },
  "result": {
    "profile": "detailed-measurements",
    "evidence": ["overview_photos", "detail_photos"],
    "notes": { "required": true }
  },
  "constraints": {
    "schedule_window": "2026-04-24T09:00:00-07:00/2026-04-24T13:00:00-07:00",
    "budget_policy": { "max_amount_usd": 85 }
  }
}

Wishfleet validates each part, checks the combination is supported, and resolves it to a canonical task identity:

{
  "resolution": {
    "status": "supported",
    "canonical_task_id": "measure/building.room/dimensions/detailed-measurements/v1.0",
    "confidence": "high"
  }
}

Canonical identifiers

Fixed five segments. Form: action/resource.sub_resource/subject-type/result-profile/version.

The subject segment is always present. When none applies, it's the literal -.

Compatibility

Not every combination is valid. The resolver enforces compatibility along four axes: action × resource, action × subject, subject × resource, and action × result.

action × resource

action × result

Lifecycle

A task moves through these states from creation to completion:

LLM callers

The API boundary is permissive about phrasing but strict about normalization. If your agent or LLM constructs task requests, it can use synonyms or slightly off-taxonomy terms. Wishfleet resolves them to canonical form when the meaning is preserved.

Safe normalizations:

• measure-room → action: measure with subject: dimensions — lexical simplification, same semantics.
• photo-proof → result: attestation-with-media — when evidence semantics match.
• document water damage → action: inspect with subject: water_intrusion — when observational scope is preserved.

Unsafe normalizations (rejected):

• assess-cause-of-leak does not normalize to inspect [water intrusion] — it crosses from observation into diagnosis and changes provider skill, liability, and pricing.
• Arbitrary combinations that would change validation burden or provider requirements.

For the most reliable results, use canonical action, resource, subject, and result values directly. The composable form (separate action, resource, subject, result objects) is always more reliable than passing a pre-composed canonical ID string.