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.

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, 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 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.