Task properties

A task property is one structured field on a task: its status, its due date, its priority, its parent. This page explains what a property is as a unit, so the syntax in Inline task syntax and the renaming in Key mappings make sense together. The same properties power an inline task and a file task; only where they are written differs.

Four traits of every property

Each property is defined by four things:

  • Canonical key: the stable internal name Operon uses everywhere, such as status or dateDue. This never changes, so the meaning is constant across every surface.
  • Visible name: the property name written in a file task's frontmatter, and the field's label in Operon's UI. It can be renamed without changing the canonical key, which is what Key mappings does. For example, a vault can show priority as Tier. Inline tasks still write the canonical key in {{key:: value}}.
  • Type: how the value is stored and edited. There are six: Text, Number, Date, Date & time, List, and Checkbox. The type decides which picker the Task Editor shows and how the value is validated.
  • Sync policy: whether the value carries across forms and occurrences. yes fields are shared task data; no fields belong to one instance and are not copied (for example datetimeCreated); auto fields are recomputed by Operon.

System and custom properties

Properties come from two places:

  • System properties are built in. They cover the whole task model: identity, status, priority, dates, scheduling, parent and dependency links, recurrence, time tracking, and the automatic rollup counts. You use and rename them, but you do not create or delete them.
  • Custom properties are ones you define when the built-in set is not enough. A custom property is a real canonical key with its own type and behavior, not just a loose YAML field. See Custom keys.

Three built-in user-managed properties describe the task rather than its lifecycle: Task Type is a free Text classification, Task Image is one Text media reference, and Task Gallery is an ordered List of media references. Task Type might hold values such as Milestone, Bug, or Meeting; Operon does not impose an enum. See Task images and galleries for the visual fields.

Do not confuse user-managed Task Type with Task Data Type. Task Data Type is a read-only Table helper that reports whether the task is inline or file; it is not a property you write to Markdown.

A third case sits outside this model entirely: a frontmatter property on a file task that is neither of the above, no canonical key, no sync policy. Operon still discovers it and offers it as a typed Table column or filter condition, but only there; it has none of the four traits above, and none of the Task Editor, Task Creator, chip, or swimlane reach a real property gets. See File task property columns.

Set fields versus managed fields

Not every property is yours to fill. Two groups behave very differently:

  • Fields you set: status, priority, dates, contexts, assignees, parent, recurrence, reminders, icon, color, note, and your custom keys. You edit these directly or through the Task Editor.
  • Fields Operon manages: identity, timestamps, progress, subtask counts, totals, dependency links, and tracker bookkeeping. You can read them, but you should not hand-edit them. The full split is listed in Inline task syntax.

One idea can be carried by more than one property. Reminders are the clearest example: there is no single reminder field, but two, reminderDatetimes for reminders at a fixed moment and reminderRules for reminders at an offset from one of the task's own dates. They are separate canonical keys with separate values, and a task can use either or both. See Reminders.

One model, two surfaces

The point of the property model is that an inline task and a file task are the same record underneath. An inline task writes its properties as {{key:: value}} on the line; a file task writes them as frontmatter. Because both resolve to the same canonical keys, a task keeps its full meaning when it converts from one form to the other. See Converting inline and file tasks.

The same four properties, status, priority, dateDue, and contexts, written each way:

- [ ] Prepare the board meeting {{operonId:: {{operonId}}}} {{status:: Project.Planned}} {{priority:: A}} {{dateDue:: 2026-07-01}} {{contexts:: [[Office]]}}

---
operonId: {{operonId}}
Status: Project.Planned
Priority: A
dateDue: 2026-07-01
contexts:
  - "[[Office]]"
---

The canonical keys are the same on both; only the container differs. In the file task the visible property names can be renamed through Key mappings, while the inline line keeps the canonical keys.

Settings

Operon settings for this live in two places under Settings → Operon → Core: Keymapping sets each property's visible name and type, and Custom Keys creates and manages your own canonical fields.