Aestus-native

Your plan stopped describing the work three weeks ago

Every week, a cited list of the places your plan document and the tickets filed under it no longer agree — with the ticket ids and the headings from the plan.

Join the waitlist See what it produces

Plan drift watch

Watch for plan drift

Who it is for: Anyone who keeps a written plan other people read and act on.
What starts it: Weekly on Monday in your workspace's time zone, and on demand from the plan itself; On a schedule

Turn it on in Aestus

A plan is written once and then everything else moves. Tickets get promoted out of it, new work arrives that nobody adds back, a wave slips, a dependency turns out to point the other way. None of that is visible in the document, because the document is exactly as correct as it was on the day it was written. So the plan and the board drift apart quietly, and the gap is usually discovered in a meeting, by somebody reading the plan out loud while other people say "that moved".

This use case reads both halves, because Aestus already holds both. Once a week it compares the plan document with the tickets filed under that plan and reports the places the two no longer agree: work on the board the plan never mentions, ticket blocks in the plan that were never filed, a dependency that contradicts the order the waves are written in, a loop in the dependencies, work whose last blocker finished weeks ago and has not moved since, and a target date that has passed with work still open.

The important word is "disagree". Drift is not slowness. A plan whose work is going slowly is not drifting — the board already shows that, and two other Aestus reports already say it. Drift is the plan's own text no longer describing what is happening, which is a different thing and has a different fix. So every line is a contradiction between two records, and each one carries the ticket id, the heading quoted from your plan, or the recorded date it came from.

It is equally careful about what it does not know, and prints that in every report. It does not read the plan document's earlier versions, so it can tell you the two records disagree today and it can never tell you when they started to — it says that rather than implying the stronger claim. It reads no dates written in prose under a heading, because guessing which date in a paragraph was meant as a deadline would invent the structure it then cited. It projects no finish date from the rate work is closing, because a forecast from a handful of tickets is a statistic with an invented confidence.

The tenancy rule does real work here. A ticket owned by a team you are not in is left out and counted, never named — and that matters more in a drift report than anywhere else, because a row the check cannot see looks exactly like a row that was deleted. So when anything is hidden, the counts are stated as minimums and the one check that could mistake a hidden ticket for a missing one is switched off, and the report says which check and why. A watch that cannot see all of a plan does not get to announce that a piece of the plan is missing.

Everything the report states was computed before the model was asked to write a sentence. The findings, the counts and the staleness judgement are arithmetic; a review step then checks the written report back against them, and a value the model produced on its own fails the run rather than reaching the person who is about to re-plan a quarter around it.

What you get

The artifact this use case produces, in the product view you would read it in.

Example — fictional team and data. Not a live run or customer result.

Worked example

document

Plan drift — NW-PLAN-56 Earned Autonomy · 11 September 2026

Produced by: Run NW-RUN-4417 · read-only · document artifact · demo values

What was checked: At least 7 tickets across 4 waves and 6 ticket blocks, against the plan document as it was last written on 14 August. "At least", because 1 ticket on this plan is owned by a team this reader is not in: it is counted here and named nowhere.
Findings: 6 disagreements, each citing what it came from. 2 tickets (NW-1802, NW-1803) are filed under this plan and appear in no block in the document, with the day each was opened. NW-1781 is written under "Wave 1 — Signals" but waits on NW-1784 under "Wave 2 — Trust surfaces", so the written order contradicts the recorded dependency. NW-1787 has had every blocker finished since 2026-08-21 and has not moved. One block, tk_9f2c41, was never turned into a ticket. The plan's target date of 2026-08-31 has passed with work still open.
What this check could not see: 1 check was switched off for this run and says why: with 1 row hidden, a ticket the plan names would look identical to one this reader cannot see, so the report does not claim work is missing. Beside it, the 5 things this check never sees, printed in every report. This compares the plan as it is now with the board as it is now. It does not read the document's earlier revisions, so it can say the two disagree today and can never say when they started to.
Checked and clean: The checks that ran and found nothing, named one by one: dependency_cycle. A check that was switched off is never listed here — it was not looked at, and calling it clean would claim a check the run skipped.
Sources: One numbered row per ticket, block and heading behind the lines above. Every count in the report was computed before the model was asked to write anything, and a review step checks the written report back against them.

How it runs

Each step is one node in the workflow graph the interpreter runs. Nothing here is a prompt chain hidden in a route handler.

Workflow steps

01It reads the plan the way you wrote it
The plan document is structured, not prose. Aestus reads your wave headings and the ticket blocks inside them, then loads every ticket filed under that plan with its column, when it entered it, and what it depends on.
02It compares the two records in code
The comparison is arithmetic, not judgement: which tickets the document never mentions, which blocks were never turned into tickets, which dependency contradicts the order the waves are written in, and whether the plan's own target date has passed with work still open.
03It says what it could not see
Every report lists what the check is blind to: it does not read the document's earlier versions, so it reports that the two disagree today and never claims to know when they started to. It reads no dates written in prose and projects no finish date.
04A checker reads the report before you do
A review step rejects the report if a ticket id, a heading, a date or a count is not in what the check was given, or if a line asserts a cause. It names the exact value that failed, and the writing runs again.
05It changes nothing
The model that writes the report has no tools. Nothing is moved, closed, filed or edited — not a ticket, and not the plan document. The output is one document and one notification.

By hand, and on Aestus

The same job, on either side.

By hand
Someone reads the plan with the board open beside it, before the planning meeting.
On Aestus
Runs weekly on a schedule, or on demand from the plan page.
By hand
You notice work that was never in the plan when a ticket you do not recognise turns up in a review.
On Aestus
Listed with its id, its title, its column, and the day it was opened.
By hand
Somebody has to remember which blocks in the plan were actually turned into tickets.
On Aestus
Each block that was never filed is listed under the heading it sits below.
By hand
A dependency that lands after the thing waiting on it is found when the work stops.
On Aestus
Reported as soon as the recorded dependency contradicts the order the waves are written in.
By hand
Work whose last blocker finished weeks ago sits untouched because nothing surfaces it.
On Aestus
Reported with the day the last blocker finished and how long the ticket has waited since.
By hand
You never learn whether a quiet week means agreement or a check that stopped running.
On Aestus
A clean week still publishes the report, with what was checked and what was clean.

What Aestus records

Every run is auditable after the fact, which is what makes handing the job over survivable.

The run
Cost, tokens, duration and whether the review step passed, on the same ledger as every other run in the workspace.
The report
Each week's report is a document on the plan's own watch ticket, with its own revision history, so last month's can still be reopened.
What it counted
The run records the counts the check computed before the model was called, so the document can be compared against them rather than believed.

What it connects to

This use case reaches no system outside Aestus. It reads governed evidence and writes a document, so there is nothing to connect and no approval to wait on.

Questions teams ask

Does it change my plan or my tickets?

No. The model that writes the report has no tools at all, so it cannot move, close, file or edit anything. It produces one document and one notification, and the document says so on every run.

What happens when the plan is fine?

It still publishes the report, listing what was checked and what was clean, with no findings section. A watch that went quiet when it found nothing would look exactly like a watch that had stopped running.

Can it see work my team cannot?

No. A ticket owned by a team you are not in is left out entirely and counted in a number the report prints. When any row is hidden, the counts are stated as minimums and the check that could mistake a hidden ticket for a missing one is switched off and says so.

Does it tell me why the plan drifted?

No, and it is not allowed to. It reports that two records disagree, with the ids and headings behind each one. It records no reason, so it does not guess at one and it never names anyone at fault.

What stops it inventing a ticket id or a date?

Every finding, count and date is computed before the model is called, and a review step checks the report against them afterwards. A value that is not in what the check was given fails the run rather than reaching you.

All use cases How access is governed

Sources

Hand over Watch for plan drift.

Tell us how your team does this today and we will set it up with you.

Talk to us

Questions teams ask

Does it change my plan or my tickets?

No. The model that writes the report has no tools at all, so it cannot move, close, file or edit anything. It produces one document and one notification, and the document says so on every run.

What happens when the plan is fine?

Can it see work my team cannot?

Does it tell me why the plan drifted?

No, and it is not allowed to. It reports that two records disagree, with the ids and headings behind each one. It records no reason, so it does not guess at one and it never names anyone at fault.

What stops it inventing a ticket id or a date?

Sources

Your plan stopped describing the work three weeks ago

Watch for plan drift

What you get

Plan drift — NW-PLAN-56 Earned Autonomy · 11 September 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The report

What it counted

What it connects to

Questions teams ask

Other use cases

Hand over Watch for plan drift.

Your plan stopped describing the work three weeks ago

Watch for plan drift

What you get

Plan drift — NW-PLAN-56 Earned Autonomy · 11 September 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The report

What it counted

What it connects to

Questions teams ask

Other use cases

Hand over Watch for plan drift.