Aestus-native

The check-in is already written

Reads the work connected to each goal, grades the goal from those records, and asks the owner only for the number nothing can measure.

Join the waitlist See what it produces

Goal cadence

Write the goal check-in

Who it is for: Heads of operations and chiefs of staff who own the goal cadence and chase updates that arrive late and vague.
What starts it: Every Friday at 07:00 in your workspace's time zone, or by hand from the use-case catalog; On a schedule

Turn it on in Aestus

The goal check-in is the one document in a company where the writer has a motive. "On track" is cheaper to type than the truth, it is written by the person accountable for the number, and nobody can check it until the period ends — by which time the check-in that would have been useful is three months old. So every goal tool asks for that sentence in a dropdown, and gets back a quarter of them that were true when they were typed and a few that never were.

This one does not ask for it. Before any prose exists, the run reads what is connected to each goal and decides the goal's reading in code: what rolls up into its number, and what reached a terminal column since that goal's own last check-in. The step that writes the document has no tools at all. It cannot reach a record, cannot recompute a figure, and cannot use a word for how a goal is doing that the records did not produce — and the checking step in front of filing rejects the whole draft if it did.

The number always travels with where it came from. Sixty-eight per cent is a figure; sixty-eight per cent rolled up from four connected projects is a figure you can argue with, and a figure with nothing connected behind it is one you know to ignore. The rollup is the product's own — the same one the Goals canvas renders — so the check-in and the goal page can never disagree about the same goal in the same minute.

The distinction the whole thing is built around is between a goal with nothing connected to it and a goal whose work has stopped. Both show a number that did not move, which is why every status field collapses them, and they are not the same problem at all. The first is about the goal's wiring: nothing has ever been attached to it, so its number is a dead seed that will read the same every week until somebody connects work, and calling it behind would be an accusation nobody can substantiate. The second is about the work: the goal is wired correctly and nothing has closed. One conversation is five minutes with whoever owns the goal; the other is a conversation about delivery. Collapsing them costs a team a quarter of explaining work that was never attached to the goal in the first place.

Then there is the number the check-in genuinely cannot know. A key result measuring a median time, a satisfaction score or a revenue figure has no record behind it in Aestus, and a document that filled that in would be doing exactly what this one exists to replace. So it names the value, says in one sentence why no ticket, project or run records it, and asks. That single question is the whole of what the owner is asked to supply, and it is the reason the rest of the check-in can be trusted.

It writes nothing to your goals, and that limit is stated in the document rather than worked around. No workflow-reachable tool in Aestus can change a goal today, so instead of a step that quietly does less than it claims, each goal gets a short note built only from figures the run derived, for its owner to post. A workflow that says it updated a goal and did not is worse than one that never said it, because it fails at the moment somebody trusts it.

And it says what it could not see, under its own heading: how many closed tickets belong to a team this run cannot look at, so every closed count in the document is stated as a minimum, and which goals a per-run cap left undrafted, by name. A cap that silently decided which of a company's goals got asked about would be the quietest failure of all.

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

Goal check-in — 2026-W37

Produced by: Run EXAMPLE-GC-01 · read-only · document on AES-4120 · no goal changed · demo values

Where each goal stands: One table over all 4 goals, and one chart of each goal's progress against how much of its period has gone. Every row says where its number came from before it says what the number is: G-12 reads 68% rolled up from 4 connected projects, and G-9 reads 35% with nothing connected. The reading in each row is derived from those records — "behind pace" for G-12 — and not from the status its owner last typed, which for both of those goals is "on-track".
What moved: 2 tickets reached a terminal column on the work connected to these goals since each goal's own last check-in — for G-12, AES-1841 and AES-1855, each named so a reader can open it. G-21 closed nothing in its window, which is why it reads "no progress" rather than behind pace: the work has stopped, and that is a different conversation from missing a date.
What has no evidence: 1 of the 4 goals has no project and no child goal connected to it at all. G-9 has shown 35% every week since it was created and will keep showing it, because there is nothing behind that number to move it. It is reported here rather than graded — "no evidence" and "no progress" are different facts, and only one of them is about the work.
What only you can answer: 2 values no record in the workspace can produce, each named with one sentence on why. G-14 measures "median minutes to first workflow run", and no ticket, project or run records it — so the check-in asks for that one number instead of producing one. Nothing in this document estimates it.
Notes to post: One short note per goal, built only from the figures above, for the owner to paste onto the goal. Aestus does not write it there: no workflow-reachable tool can change a goal today, and the check-in says so rather than implying the goal was updated.
Not asked about: 1 active goal was left alone, by name. It is fresh, it is rolling up on its own, and nothing about it needs a person — so the check-in asks nothing about it and says that it did. A reminder that asks for work that does not exist teaches people to ignore the next one.
What this check-in could not see: 3 tickets were withheld because they belong to a team this run cannot see, so every closed count above is stated as a minimum. This section also names any goal the per-run cap left undrafted and says plainly that no goal was changed by this run.
Sources: 5 sources, numbered, each with the instant it was read: one per goal carrying that goal's progress and its basis, plus the board read behind every closed count. Every marker in the document resolves to a row here, or the check-in is refused before it is filed.

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 picks the goals that actually need somebody
Every active goal whose period has ended, whose update cadence has lapsed, that its owner has marked at risk, or that rolls up from work nobody ever connected. A goal that is fresh and rolling up on its own is left alone and named as left alone, because a reminder that asks for work which does not exist teaches people to ignore the next one.
02The progress number comes from the product, not from a new sum
Each goal's progress is read through the same rollup the Goals canvas uses, so the check-in and the goal page can never disagree. It arrives with its basis attached — rolled up from four connected projects, rolled up from two child goals, or typed by the owner — and the document prints the basis every time it prints the number.
03Code grades the goal, before any sentence exists
The reading for each goal is decided from records: what is connected to it, and what reached a terminal column since that goal's own last check-in. The step that writes the prose has no tools, cannot reach a record and cannot produce a figure. The words it may use for how a goal is doing are fixed, and none of them is a status.
04Nothing connected is reported as nothing connected
A goal that rolls up from work and has none is reported as having no evidence, and it is never called behind, stalled or at risk, because nobody can tell whether it is. A goal with connected work and nothing closed is reported as having no progress. Those are different facts, and they start different conversations.
05It checks its own draft, then files it
Every number has to trace to the read, every sentence with a number has to carry a source, no goal may be described with a word the records did not produce, and the chart block has to be unchanged. One repair attempt; if it still fails, the run fails and nothing is filed. You get a document, one note per goal, and no change to any goal until you post it.

By hand, and on Aestus

The same job, on either side.

By hand
Somebody opens the board on Thursday and counts.
On Aestus
Rolled up from the work already connected, with the count printed beside the number.
By hand
You trust whoever typed it, and find out at the end of the quarter.
On Aestus
Each line carries the ticket or the project it came from, and every ticket is one you can open.
By hand
A goal nobody wired up shows a number that never moves, and nobody notices for a quarter.
On Aestus
It gets its own heading, by name, and is never graded as though somebody could tell.
By hand
What moved is written from memory, over whatever window the writer had in mind.
On Aestus
Read from the work that reached a terminal column since that goal's own last check-in.
By hand
The value nobody records is left blank, or guessed.
On Aestus
Named, with one sentence on why no record holds it, and no number offered for it.
By hand
Everyone gets the same reminder, including the people with nothing to answer.
On Aestus
A healthy goal is listed as not asked about, and nothing is asked.

What Aestus records

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

The run
What it read, what it drafted, how long it took, what it cost, and when it fails, why — on the same ledger as every other run in the workspace.
The cycle
One ticket per cycle, carrying that cycle's check-in as a document with its own revisions. Move it to its last column once the notes are posted and the cycle is recorded as one somebody used.
What it could not see
How many closed tickets were withheld because they belong to a team the run cannot see, which goals a per-run cap left undrafted, and a plain sentence saying that the run changed nothing on any goal.

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 goals?

No, and it says so in the document. Nothing a workflow can reach today is able to write a goal in Aestus, so instead of implying otherwise it hands you one short note per goal, built only from the figures above it, for you to post on the Goals canvas.

Can it close or grade a goal?

No. Closing a goal is a person's act. The only words this workflow can use for how a goal is doing are the ones derived from records, and none of them is a grade or a status.

What if a goal's progress is rolled up from projects?

Then it reports the rollup, with the number of projects it rolled up from, and never a figure of its own. Where the progress is a number somebody types by hand, it says that too, and asks the owner for the value rather than producing one.

What does it read?

Your goals, the projects and child goals connected to them, and the tickets on that work. Nothing else, and no outside system. Every figure in the check-in can therefore be recomputed from a record this workspace already holds.

All use cases How access is governed

Sources

docs/runbooks/use-case-workflows.md

Hand over Write the goal check-in.

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

Talk to us

Goal check-in — 2026-W37

Produced by: Run EXAMPLE-GC-01 · read-only · document on AES-4120 · no goal changed · demo values

Where each goal stands: One table over all 4 goals, and one chart of each goal's progress against how much of its period has gone. Every row says where its number came from before it says what the number is: G-12 reads 68% rolled up from 4 connected projects, and G-9 reads 35% with nothing connected. The reading in each row is derived from those records — "behind pace" for G-12 — and not from the status its owner last typed, which for both of those goals is "on-track".
What moved: 2 tickets reached a terminal column on the work connected to these goals since each goal's own last check-in — for G-12, AES-1841 and AES-1855, each named so a reader can open it. G-21 closed nothing in its window, which is why it reads "no progress" rather than behind pace: the work has stopped, and that is a different conversation from missing a date.
What has no evidence: 1 of the 4 goals has no project and no child goal connected to it at all. G-9 has shown 35% every week since it was created and will keep showing it, because there is nothing behind that number to move it. It is reported here rather than graded — "no evidence" and "no progress" are different facts, and only one of them is about the work.
What only you can answer: 2 values no record in the workspace can produce, each named with one sentence on why. G-14 measures "median minutes to first workflow run", and no ticket, project or run records it — so the check-in asks for that one number instead of producing one. Nothing in this document estimates it.
Notes to post: One short note per goal, built only from the figures above, for the owner to paste onto the goal. Aestus does not write it there: no workflow-reachable tool can change a goal today, and the check-in says so rather than implying the goal was updated.
Not asked about: 1 active goal was left alone, by name. It is fresh, it is rolling up on its own, and nothing about it needs a person — so the check-in asks nothing about it and says that it did. A reminder that asks for work that does not exist teaches people to ignore the next one.
What this check-in could not see: 3 tickets were withheld because they belong to a team this run cannot see, so every closed count above is stated as a minimum. This section also names any goal the per-run cap left undrafted and says plainly that no goal was changed by this run.
Sources: 5 sources, numbered, each with the instant it was read: one per goal carrying that goal's progress and its basis, plus the board read behind every closed count. Every marker in the document resolves to a row here, or the check-in is refused before it is filed.

Questions teams ask

Does it change my goals?

Can it close or grade a goal?

No. Closing a goal is a person's act. The only words this workflow can use for how a goal is doing are the ones derived from records, and none of them is a grade or a status.

What if a goal's progress is rolled up from projects?

What does it read?

Sources

docs/runbooks/use-case-workflows.md

The check-in is already written

Write the goal check-in

What you get

Goal check-in — 2026-W37

How it runs

By hand, and on Aestus

What Aestus records

The run

The cycle

What it could not see

What it connects to

Questions teams ask

Other use cases

Hand over Write the goal check-in.

The check-in is already written

Write the goal check-in

What you get

Goal check-in — 2026-W37

How it runs

By hand, and on Aestus

What Aestus records

The run

The cycle

What it could not see

What it connects to

Questions teams ask

Other use cases

Hand over Write the goal check-in.