Aestus-native

Know what is blocking the release before the meeting

Aestus reads the milestone and writes the go/no-go, with the exact blockers and where each one came from.

Release decisions

Release readiness check

Who it is for: Release managers and engineering leads who spend the afternoon before a release opening tickets one at a time.
What starts it: On demand from the milestone, or on a schedule during the release week; On demand

The question before every release is the same, and answering it takes an afternoon. Is this safe to cut? Somebody opens each ticket in the milestone and decides whether its column really means done. Then each ticket's pull request, to see whether it merged. Then the reviews, to see which were actually accepted. By the time the meeting starts, half of it has already scrolled out of memory.

Aestus holds every one of those records, so it reads them in one pass and writes the answer down. The result is one document: the verdict, the exact blockers with the ticket and pull-request ids they came from, the risks that do not block, a score for each of eight checks, and an honest list of what Aestus holds no record of at all.

Two things make it worth acting on. The counts are computed by the server before the model is called, so no number in the document was written by a model — and any answer that echoes a number the facts do not state is thrown away rather than published. And the verdict itself is computed in code from the eight results, so a confident answer cannot talk a release into going out.

The sharpest case is migrations. Applying one is a manual step somebody performs by hand, and merging the pull request that adds the file is not the same event. So this check never passes on a merged pull request alone: without an operator writing down that the migration ran, it reads unknown, and unknown never reads as GO. A check that quietly passed there would be the most expensive thing this document could get wrong.

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

Go / no-go — R7 · Billing v2

Produced by: PROJ-41 · milestone R7 · Billing v2 · 14 tickets · demo data

Verdict: NO-GO — 3 blockers, 2 risks. Migration 0299 shipped in a merged pull request and has no record of being applied to production. The verdict is computed from the eight results below, not written by the model: one failed blocking check is a NO-GO however the rest of the document reads.
Blockers: 1. Migration 0299 has not been applied to production — evidence PR #812, AES-1841 — filed as AES-1902, owner Lior Heber. 2. AES-1846 was reviewed and rejected and has not been reworked — evidence AES-1846, AES-RUN-4479 — filed as AES-1903, owner Dana Katz. 3. AES-1850 is blocked by AES-1799, which is outside this release — evidence AES-1850, AES-1799 — filed as AES-1904, unassigned.
Risks: Two pull requests merged in the window are linked to no ticket, so nobody owns them and no acceptance was recorded against them (PR #803, PR #818). Four tickets carry no acceptance criteria, so "done" was never written down and review had nothing to check against (AES-1837, AES-1844, AES-1848, AES-1850).
Readiness by check: tickets_terminal fail 11/14 · pull_request_merged fail 12/14 · pull_request_linked fail 15/17 · review_accepted fail 13/14 · acceptance_criteria_present fail 10/14 · migrations_applied unknown · dependencies_clear fail 13/14 · runs_clean pass 14/14. Every count was computed by the server before the model was called; an answer echoing a number the facts do not state is refused.
Not checked: Staging soak and load test results. Customer and support communications for this release. Feature-flag state in production. On-call cover for the release window. Aestus holds no record of any of these, and says so every time rather than letting their absence read as a pass.
Sources: Board: PROJ-41, milestone R7 · Billing v2, 14 tickets. Pull requests: 17 merged in the last 21 days. Runs: 14 across those tickets, 13 with an accepted verdict. Anchor ticket AES-1841, read for a "MIGRATIONS APPLIED" attestation and finding none.

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

01You pick the release
The milestone or plan wave, and the release ticket it hangs on. The document is filed there afterwards.
02Aestus assembles the facts
From its own records: board columns, acceptance criteria, pull-request state, review outcomes, run failures, dependency links, and the pull requests merged in your window.
03One model call scores the eight checks
It names the blockers and may only cite ids that are in the facts. It does not count: every count was computed by the server before the call.
04A second model call checks it
Every id must appear in the facts and every count must match. Two strikes and the run stops rather than shipping a guess.
05The verdict is computed in code
Not written by the model. A failed blocking check is a NO-GO however the answer reads, and an unknown one never reads as GO.
06You approve, and the blockers become tickets
Each one is filed so the release depends on it. The document lands on the release ticket, and goes to your channel if you asked for it.

By hand, and on Aestus

The same job, on either side.

By hand
Open every ticket and remember which column means done.
On Aestus
Terminal is read from the board itself, never from a column's name.
By hand
Check each ticket for a pull request, then each one for a merge.
On Aestus
Pull-request state per ticket, plus the merged ones linked to nothing.
By hand
Trust that somebody ran the migration.
On Aestus
It says there is no record of it being applied, instead of assuming.
By hand
Rewrite the blockers into tickets after the meeting.
On Aestus
Each blocker becomes a ticket the release depends on, once you approve.
By hand
Nobody can tell later why the call was made.
On Aestus
The document lists every id it read, and the run keeps its inputs and cost.
By hand
Do all of it again for the next release.
On Aestus
The same check, the next milestone, on a schedule if you want one.

What Aestus records

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

The run
Cost, tokens, latency and outcome, on the same ledger and in the same reports as every other run in the workspace.
The document
The go/no-go is kept as an artifact on the release ticket, so the call you made this month can be reread next quarter.
A ticket per blocker
Filed at high priority and linked so the release depends on it, and never filed twice when you run the check again.
What keeps recurring
When a blocker class repeats, one cited candidate is proposed to Workspace Memory, where a person reviews it before it counts.

What it connects to

Only the tools this workflow actually uses. Each one has a setup guide.

Questions teams ask

Can it decide to release?

No. It reports and it files. It never merges, deploys, reverts or tags, and nothing advances on its own.

What if a check has no evidence?

It says unknown. An unknown blocking check never reads as GO, so silence can never be mistaken for a pass.

What about things Aestus does not hold?

Staging soak, customer communications and feature-flag state are listed under "Not checked" every time, so nobody mistakes their absence for a clean result.

Does it work without GitHub?

Yes. The check on pull requests being linked to a ticket reports unknown instead of passing, and the other seven still run.

Can it file duplicates if we run it twice?

No. A blocker that already has an open ticket is reported with that ticket's id, not filed again.

All use cases How access is governed

Sources

docs/runbooks/local-ci-gate.md
docs/agent-ticket-workflow.md

Hand over Release readiness check.

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

Talk to us

Go / no-go — R7 · Billing v2

Produced by: PROJ-41 · milestone R7 · Billing v2 · 14 tickets · demo data

Verdict: NO-GO — 3 blockers, 2 risks. Migration 0299 shipped in a merged pull request and has no record of being applied to production. The verdict is computed from the eight results below, not written by the model: one failed blocking check is a NO-GO however the rest of the document reads.
Blockers: 1. Migration 0299 has not been applied to production — evidence PR #812, AES-1841 — filed as AES-1902, owner Lior Heber. 2. AES-1846 was reviewed and rejected and has not been reworked — evidence AES-1846, AES-RUN-4479 — filed as AES-1903, owner Dana Katz. 3. AES-1850 is blocked by AES-1799, which is outside this release — evidence AES-1850, AES-1799 — filed as AES-1904, unassigned.
Risks: Two pull requests merged in the window are linked to no ticket, so nobody owns them and no acceptance was recorded against them (PR #803, PR #818). Four tickets carry no acceptance criteria, so "done" was never written down and review had nothing to check against (AES-1837, AES-1844, AES-1848, AES-1850).
Readiness by check: tickets_terminal fail 11/14 · pull_request_merged fail 12/14 · pull_request_linked fail 15/17 · review_accepted fail 13/14 · acceptance_criteria_present fail 10/14 · migrations_applied unknown · dependencies_clear fail 13/14 · runs_clean pass 14/14. Every count was computed by the server before the model was called; an answer echoing a number the facts do not state is refused.
Not checked: Staging soak and load test results. Customer and support communications for this release. Feature-flag state in production. On-call cover for the release window. Aestus holds no record of any of these, and says so every time rather than letting their absence read as a pass.
Sources: Board: PROJ-41, milestone R7 · Billing v2, 14 tickets. Pull requests: 17 merged in the last 21 days. Runs: 14 across those tickets, 13 with an accepted verdict. Anchor ticket AES-1841, read for a "MIGRATIONS APPLIED" attestation and finding none.

Questions teams ask

Can it decide to release?

No. It reports and it files. It never merges, deploys, reverts or tags, and nothing advances on its own.

What if a check has no evidence?

It says unknown. An unknown blocking check never reads as GO, so silence can never be mistaken for a pass.

What about things Aestus does not hold?

Staging soak, customer communications and feature-flag state are listed under "Not checked" every time, so nobody mistakes their absence for a clean result.

Does it work without GitHub?

Yes. The check on pull requests being linked to a ticket reports unknown instead of passing, and the other seven still run.

Can it file duplicates if we run it twice?

No. A blocker that already has an open ticket is reported with that ticket's id, not filed again.

Sources

docs/runbooks/local-ci-gate.md

docs/agent-ticket-workflow.md

Know what is blocking the release before the meeting

Release readiness check

What you get

Go / no-go — R7 · Billing v2

How it runs

By hand, and on Aestus

What Aestus records

The run

The document

A ticket per blocker

What keeps recurring

What it connects to

Questions teams ask

Hand over Release readiness check.

Know what is blocking the release before the meeting

Release readiness check

What you get

Go / no-go — R7 · Billing v2

How it runs

By hand, and on Aestus

What Aestus records

The run

The document

A ticket per blocker

What keeps recurring

What it connects to

Questions teams ask

Hand over Release readiness check.