Objectives
A goal with a metric and a budget, per project — what tasks get measured against
An objective is the target a signal or a task gets measured against: a goal, the metric that represents it, and a budget for pursuing it — set per project.
Why it matters
Without objectives, the loop can tell you a task shipped. It cannot tell you whether it worked.
That's the gap. Today a task closes when the change is merged and validated — which confirms the work happened, not that it was worth doing. An objective is what turns "we shipped 20 changes this month" into "conversion on the PLP moved 1.4 points, and here are the four changes that did it."
It's also what makes prioritization possible. When the agent can weigh a candidate task against a number you're trying to move, the board stops being first-in-first-out.
What it will look like
Per project, you declare what you're trying to move — a metric, a target, a window. Signals get weighed against it instead of being ranked by severity alone. Tasks carry the objective they serve. After post-deploy validation, the outcome reports back against the number.
This is the next thing after the monitoring consolidation, not a parallel effort — objectives are only meaningful once signals arrive continuously.
What to do in the meantime
State the target in the task itself. Acceptance criteria written as a number ("LCP under 2.5s on mobile PLP") give the agent and the reviewer something checkable, and they're the same information an objective would carry. See Writing a task.