Module 2 — Projects and Tasks · Lesson 2.3
Anatomy of a Task
Every field on the card, and what each one drives elsewhere in Kavanah
~14 min
What you'll learn
- Name what each task field is read by elsewhere in the product
- Write a task title and description the agent and your teammates can both use
- Decide which fields are worth filling at capture time and which at triage
- Use the task's own KVN charter for work with a specific boundary
Most task fields in most tools are metadata: they describe the task and nothing reads them. In Kavanah, nearly every field is an input to something. Knowing which is which changes how you fill them in — you stop filling fields out of diligence and start filling the ones that make a downstream surface work.
Title and description
The title is the thing every other surface shows: the card, the list row, the report, the digest email, the agent's answer when you ask what is open. Write it as an outcome, not a topic. 'Website' is a topic. 'Publish the new pricing page' is an outcome, and it has the property that you can tell whether it is done.
The description is where the detail goes, and it is read by more than humans. When the agent is asked about the task, reasoning about who should own it, or estimating it, the description is most of what it has. A description that states what done looks like and what constraints apply is worth several rounds of clarification later.
The practical rule: title at capture, description at triage. Do not let a missing description stop you writing the task down.
Status, assignee and due date
Status is which column the task sits in, and it is the input to cycle time, burndown, velocity and the WIP limits. Statuses are configurable per workspace, and Lesson 2.5 covers customizing them.
Assignee is who owns it. Exactly one person — the field is singular deliberately, because work owned by two people is work owned by nobody. Assignee drives My Work, the daily digest, workload views, capacity, and the notification that tells someone they now have this.
Due date drives the calendar view, overdue detection, automation triggers, the digest, and escalation. It is also the field most often set optimistically, which is worth naming: a due date is a commitment, and a board where half the dates are in the past has stopped meaning anything. If a date is not real, leaving it empty is more honest and more useful than setting a fictional one.
Priority, labels and custom properties
Priority orders work within a status. Its value comes entirely from being used sparingly — a board where everything is high priority carries exactly as much information as a board with no priorities at all.
Labels are free-form tags for cross-cutting concerns: 'blocked-on-client', 'tech-debt', 'q3-launch'. They are what you filter and group by when the thing you care about does not map to a project or a status.
Custom properties are workspace-defined fields with real types — dropdowns, numbers, dates, text — configured in Settings. Use them when you need to filter or report on something structured. The test is whether you would ever want to answer a question by that field; if not, it belongs in the description.
Estimate, and the loop behind it
The estimate field is the input to planning, capacity and the calibration loop. Kavanah can produce estimates automatically, and the estimate-versus-actual comparison feeds a per-workspace calibration that improves the forecasts over time.
One thing worth knowing now and properly in Module 5: the stored estimate stays as it was written. Kavanah does not overwrite your estimate with a corrected one, because a stored value that has already been adjusted makes the next comparison measure the adjustment rather than the error, and the correction quietly unwinds itself. Uplift happens at the planning layer, as a forecast, and never gets written back onto the task.
What that means for you: put down your honest estimate, and let the system learn the gap. Padding it defeats the mechanism designed to handle the padding.
Subtasks, comments, files and activity
Subtasks break a task into checkable pieces. They are first-class — they have their own status and can be assigned — and they are covered in the next lesson along with dependencies.
Comments are the conversation attached to the work. Mentioning someone notifies them, and the thread stays with the task rather than scrolling away in chat, which is the whole point.
Files attach to the task. The agent can read attached documents, which makes 'here is the brief, break it into tasks' a real workflow rather than a copy-paste exercise.
Activity is the audit trail — what changed, when, and who did it, including changes the agent made. When something on a board is not what you expected, this is where you look first.
The task's own KVN
A task can carry its own Know-how, Vision and Negation, set from the task drawer. This is the smallest scope of the charter system, and it is for work where the boundary is specific to this task rather than to the whole workspace.
The common good use: a task whose Negation says 'do not touch the production database' or 'do not contact the client directly'. The agent checks the charter before acting on work, so a task-level Negation is how you fence a specific piece of work without constraining everything else.
Most tasks do not need one, and adding one to every task devalues them all. Reach for it when this particular piece of work has a boundary that the project's does not already cover.
Fill in one task properly
- 1
Rewrite a task title as an outcome
Find one on your board phrased as a topic and rewrite it so you could tell whether it is done. Notice how much easier it is to estimate afterwards.
- 2
Write a description that states done and constraints
This is the text the agent has when it is asked about the task, so it pays twice.
- 3
Any date in the past that nobody intends to hit. Empty is more honest than fictional, and it stops overdue reporting being noise.
- 4
Define one custom property you would actually filter by
Settings → Custom Properties. If you would never answer a question by that field, it belongs in the description instead.
What to watch
- Description coverage
- Share of active tasks that have more than a title.
- Healthy signal: Our suggested target is most in-progress work. A task entering progress with no description is one somebody is about to ask three questions about.
- Stale due dates
- Count of open tasks with a due date in the past.
- Healthy signal: Small and shrinking. A large number means the field has stopped meaning commitment, and every overdue-triggered automation is now noise.
- Priority spread
- Distribution of priority values across open tasks.
- Healthy signal: Genuinely spread. If most of the board is high, the field is carrying no information.
Key takeaways
- ·Nearly every task field is an input to another system, not decoration.
- ·Title as an outcome, description at triage — the description is most of what the agent has to work with.
- ·One assignee, deliberately: work owned by two people is owned by nobody.
- ·Put down an honest estimate; the calibration loop exists to handle the gap, and padding defeats it.
- ·Task-level KVN fences one specific piece of work — use it rarely so it keeps meaning something.
Next: the structure between tasks — subtasks, dependencies, and the recurring work you should never be typing twice.