Task KVN — When to Demand All Three Axes

The three patterns that benefit from task KVN

High-stakes delegation. A task whose mistake would be expensive to undo benefits from explicit task KVN. The K names the specific context the doer needs; the V names the specific outcome; the N names the specific things not to do. The cost of writing it is small relative to the cost of the mistake.

Unusual scope. A task that does not fit neatly within the project's normal patterns benefits from explicit task KVN, because the project charter's inheritance does not quite cover it. The V especially needs to be written explicitly so the doer (human or AI) does not default to the project's standard outcome.

Cross-functional handoff. A task that passes between two parts of the team (engineering → design, support → product, sales → CS) benefits from explicit task KVN, because the two sides have different inherited context. The K is the bridge; the V is the shared outcome; the N is the boundary that neither side gets to assume.

For every other task — routine work that fits the project's pattern, well-understood scope, single owner — the inherited K, V, N is enough. Save the task-level KVN for the cases that earn it.

Using generate_task_kvn

The AI agent's generate_task_kvn tool drafts task-level K, V, or N from the task's title, description, and the inherited workspace + project charters. It does not save the result; it returns the draft for the human to review and (if they want) persist.

The practical flow: when you create a task that warrants explicit KVN, write the title and description, then ask the agent to generate the three axes. The agent's K usually inherits cleanly; its V is the most useful new content (it surfaces the task's specific outcome); its N often surfaces a constraint you would have forgotten.

The drafts are starting points, not commitments. Edit them. The point is that the agent does the heavy lift of stating the obvious; you do the lift of stating the non-obvious.

The KVN theater failure mode

The opposite failure of skipping KVN is demanding it on everything. A team that fills out K, V, and N for every routine task is producing paperwork, not management. Within a sprint or two, the team starts writing the same generic K, V, and N on every task to make the form pass — and the entire signal is lost. KVN becomes theater.

The heuristic to avoid theater: KVN exists when it changes a decision. If filling in the K for a routine task does not change which assignee is picked, the description that is written, or the trade-offs that are made, the K is decoration. Skip it. The inherited charters are enough.

Kavanah does not enforce mandatory task-level KVN, by design. The kvn_complete flag on tasks is a stored generated boolean — it's a measurable signal, not a gate. You can ship tasks without it. The metric exists so you can see, at the workspace level, what fraction of tasks chose to populate it — which is a useful proxy for how much explicit alignment the team is doing.

Reading task KVN at the right moment

Task KVN, when written, should be read by the doer at the start of the work and again at the moment of any ambiguity. Most teams write it and never re-read. The discipline is to make re-reading easy.

Kavanah surfaces the task's K, V, N in the task detail view, and the AI agent surfaces them when you ask for help on the task. 'I'm stuck on this task' should produce, among other things, a reminder of the task's V and N. Doers who use the agent as their first line of help end up reading the KVN by default; doers who do not need a manual cue.

The coaching pattern: when a contributor asks for guidance mid-task, your first question should be 'what does the V say?' If they can't recall, walk them through reading it together once. Within a few cycles, they internalize the pattern and start with the V on their own.