05Documentation
Turn a finding into shipped work
From a finding, to a decision, to merged code, to proof it worked.
Turn an investigation into an initiative
One click turns a finished investigation into tracked work. The evidence, the hypotheses and the success metric come with it — you type none of it.
Make the initiative
Every initiative starts as a question in chat. Ask a why question, wait for the answer, then promote it.
- 1Run the investigation
Ask your question in chat. A run takes a few minutes. Wait for the cited answer to finish.
- 2Click
Generate initiativeThe button sits in the action bar under the answer, alongside Copy.
- 3Read the toast
It names the new initiative and the product it filed under. The app jumps to the Initiatives section.
- 4Open the top row
The list is ordered by most recently touched, so your new initiative is at the top. The problem statement, the evidence, the hypotheses and the metric are already filled in.
Promote an investigation you trust. Everything in the initiative is derived from that one answer, so a thin investigation makes a thin initiative.
What carries over
Nothing is typed by hand. The whole initiative is built from the investigation result at the moment you click.
| What lands | Where it comes from | What you do with it |
|---|---|---|
| Problem statement | Written from the findings: who, what, when, impact | Read it in the Identify tab |
| Signals | The real records the investigation cited, grouped into named clusters | Click a cluster to page through the actual rows |
| Hypotheses | The investigation's own competing explanations, leading one first | Anchor the one that holds up |
| Solutions | Candidate fixes built from the root cause and the hypotheses | Make one current |
| Tracking metric | The success metric the investigation derived, with its formula and its value | Lock it as your baseline |
| Report | Built the moment the initiative is created | Read it or download the PDF |
The hypotheses are the investigation's own reasoning, rewritten for readability. Each confidence number is anchored to the verdict's measured confidence, then scaled by that hypothesis's evidence. A low number means the evidence is weak or split. It does not mean the hypothesis is wrong.
The product picker at the start of an investigation is a tag, not a filter. It does not narrow what the investigation reads. It decides which product the resulting initiative files under, and you can change that later from the row menu in the list.
One investigation, one initiative
Clicking the button twice never gives you two initiatives. Vernais checks the chat thread first.
Generate initiative again and it either refreshes the existing initiative's evidence from the re-posted result, or tells you one already exists and takes you to itA refresh rewrites the signals, the clusters and the correlation graph. It keeps your solutions, your hypotheses, the phase, the problem statement and the owner.
Reporter and owner
There are two people fields. One is fixed and one moves. There is no assignee.
Whoever created the initiative. Stamped once at creation and never changes. Your authorship survives every handoff.
The person on the hook today. Starts as the reporter. Hand it to any teammate.
To hand it over, open the initiative and pick a new member on the Owner · change chip in the header, then confirm. The Reporter chip sits beside it and cannot be edited. The current owner, the reporter, or a platform admin can reassign. Nobody else can.
Editing needs a permission, not membership. initiative.edit_own is a baseline permission, so a new member has it, but your workspace owner can switch it off for a specific person. Without it you can read an initiative and not change it, and the buttons do not appear. See Permissions and seats.
The five phases
The phases say where the team is working. Two of them advance on their own. You move the rest yourself from the row menu in the list.
| Phase | The question it answers | How it advances |
|---|---|---|
| Identify | What is the problem, and what evidence says so? | Where every initiative starts |
| Validate | Which explanation holds up? | Anchor a hypothesis and it advances on its own |
| Decide | Which fix are we doing? | Make a solution current and it advances on its own |
| Act | Who is building it, and how far along? | Move it yourself: row menu, then Advance to Act |
| Measure | Did the number actually move? | Move it yourself, then lock the baseline |
The two automatic advances are guarded. Anchoring a hypothesis or making a solution current can only carry an initiative forward, so a late click or a retry cannot pull back a team that has already moved on. The row-menu move writes whatever phase you pick, so treat that one as a deliberate edit.
Reaching Measure is not a claim that you shipped. The outcome state stays in progress until you lock the metric, which starts tracking. Marking the work shipped or rolled back is a separate action in the Measure tab.
Start without an investigation
You can create an initiative from a title alone. Go to Initiatives, click New initiative, choose Without AI, then name it and pick type, impact and product.
Do this when you already know the problem and have nothing to diagnose — a known bug, a committed roadmap item. The test: if you cannot say which records back the problem, run the investigation instead.
no derivable metric to lockIt starts with no clusters and no hypotheses for the same reason. There is no investigation behind it.
Related resources
Work out what is really causing it
Sort the evidence that matters from the noise, then weigh the explanations against each other. It is one decision, asked twice.
One constraint shapes most of what follows: when Vernais answers from your connected data, every claim has to trace back to a record it can point at. It will not invent a cause. A question it cannot ground in your data returns nothing rather than a guess. Questions about the outside world, or about general knowledge, it answers like any good assistant — and tells you which world the answer came from.
Two questions, one decision
This page merges two jobs on purpose. Reviewing signals and weighing explanations are not two tabs to tour. They are one decision, asked twice.
Every piece of evidence raises two questions. Does this belong to my problem? And which explanation does it back? Get the first one wrong and the second one inherits the error.
Settle belonging first. An explanation built on the wrong evidence is wrong however confident it looks.
Read the two signal buckets
Open your initiative and go to the Identify tab. Under Signal clusters, switch to Post-initiative creation. That is everything captured after the initiative existed: chat tags, meeting transcripts, tagged pages and uploaded files.
Each one lands in Related signal clusters or Non-related signal clusters. One AI pass decides. It judges two things in the same breath, so the two can never contradict each other.
The signal concerns the same problem, feature, funnel, error, service or area.
A real signal, but about a different subject. It stays visible and does not feed the explanations.
It proposes a concrete fix or action aimed at this problem. A solution must also be related.
An observation, finding or complaint about this problem, with no action proposed.
Content-free chatter. A greeting, a thanks, an empty page behind a promising title.
A related signal carries a relation score from 0 to 10 and a written reason. An unrelated one scores 0. The Solutions & tasks and Statements toggles split the same signals by kind.
The verdict is cached against the signal's text and this initiative. The same message always lands in the same bucket. It will not flip between refreshes.
Solutions & tasks / Statements counts, are computed from the full list and stay exactcapped at 40 when there are moreJudge relatedness against the problem, not the root cause
The root cause is one explanation, not the boundary of your problem.
This is the rule the AI follows. Follow it yourself when you disagree with the AI. A signal is judged against the initiative's problem, feature, funnel or area. It is not judged against the narrow cause the investigation landed on.
So a note that blames a different cause is still related. A note proposing a different fix for the same checkout failures is still related. A note about a different subject is unrelated, even when it proposes an action.
Weigh the explanations
Go to the Validate tab. It lists the competing explanations, highest confidence first. Each card shows a statement, a status, a confidence gauge and its evidence counts. They come from the investigation's own reasoning, rewritten for readability. Nothing is invented.
| Status | What it means |
|---|---|
| Leading | The investigation's chosen root cause, or one it rated likely. |
| Plausible | A real alternative it rated possible. |
| Provisional | An AI draft from a new signal. It needs your anchor before it counts, and its confidence is held under 50. |
| Ruled out | The investigation found against it. Its confidence is pushed near the floor. |
Open one. You get the proposed mechanism, the causal chain, and the evidence split into supporting and counter. Each related signal shows the explanation it maps to and its relation score. That mapping is your evidence trail: the record, what it backs, and which way it pulls.
Read the confidence number correctly
This is the most misread number in the product. It is not an independent opinion about that explanation.
Each percentage starts from the investigation's own measured confidence in its verdict. Alternatives are scaled down from there by their relative strength — their rating, and the balance of records the investigation cited for and against them. Evidence you capture later moves the number again.
- The verdict sets the starting point. A weakly grounded investigation cannot hand any explanation a strong opening number.
- Later evidence adjusts it, within bounds. Supporting records nudge it up; counter records push it down harder, per record. Only receipt-carrying, de-duplicated records count, so a repeated opinion cannot run the number upward.
- A low number means weak or split evidence. It does not mean the explanation is wrong.
Two hard caps sit on top. A ruled-out explanation is held near the floor, at roughly a third of the verdict. A provisional one is held at 49 until you anchor it. Nothing reads above 95.
If two explanations sit close together, the number will not break the tie for you. Open both and compare their counter-evidence. The test: can you name a record that would have to be wrong for this one to hold?
Disagree with it and move a signal
You will find signals the AI filed as unrelated that you know matter. Move them.
- 1Find the signal
At the bottom of the
Validatelist, openUnrelated signals. Each row shows its source and label. Open a row for the reason it landed there. - 2Mark it as evidence
Click
Mark as evidence. It counts as related from then on, and it is routed into hypothesis scoring as it scores. - 3Know that it sticks
The button then reads
Evidenceand is disabled. This view has no un-mark, so mark a signal you mean to keep.
Marking does not create or run an explanation. You are flagging a signal to keep, not asserting a cause. The Mark as evidence and Anchor hypothesis buttons appear when you own or report the initiative, or hold the initiative.edit_any permission. Everyone else reads the same view without them.
Deleting a signal is a different act, done from the cluster records table, and it cannot be undone. The signal drops out of the clusters and stops contributing to every explanation. Only the initiative's owner or reporter can do it.
Commit to an explanation
When one explanation holds up, open it and click Anchor hypothesis. The initiative advances to the Validate stage. You can anchor more than one, and click the button again to un-anchor.
Anchoring a provisional explanation is the human review it was waiting for. Stage only ever moves forward, so a late action, a retry or an un-anchor cannot pull a team backwards to an earlier phase.
Develop your intuition
These are starting points, not rules. When a bucket or a number looks wrong, ask yourself:
- Am I judging this signal against my problem, or against the cause I already believe?
- Is this about a different subject, or about the same funnel with a different theory?
- Am I reading a low percentage as "wrong" when it means "thin evidence"?
- Do I want to keep this signal, or commit to what it implies? Those are different actions.
- Would deleting this signal change the numbers for a teammate who was counting on it?
Related resources
Pick a fix and ship it
Choose the solution you believe in, turn it into tasks, and run them to merged — one decision, not two tabs.
Pick the fix you believe in
Deciding and delivering are one move here — the solution you make current is the one Act builds.
Open the initiative and go to the Decide tab. Vernais drafts three to five candidate fixes, strongest first. Each one is written from the investigation's own root cause and hypotheses. It does not invent a fix from nothing.
Each drafted solution carries a link to the hypothesis it addresses. That link is stamped when the solution is written, not guessed afterwards. If the AI names a hypothesis that does not exist, the link is thrown out and falls back to the leading one. Open a solution and the Hypothesis alignment panel marks which explanation it is aimed at.
- 1Read the candidates
Each card shows the fix and the detail behind it. Open one for the hypothesis alignment.
- 2Make current
In the open solution, click
Make currentin the ACTIONS rail. The initiative moves to the Decide stage. - 3Send it to Act
The same rail now offers
Move to Act. The fix is copied onto Act and you land on the Act tab. No task is created yet.
Switching to a different current solution deletes the Act tasks built from the old one, along with the cached AI plan. The board starts clean for the new fix. Vernais confirms first, and only when there is work to lose — but the delete cannot be undone.
Turn the decision into tasks
Nothing is created until you press the button — the AI proposes, you approve.
With no tasks yet, the Act tab shows a launcher and the fix you chose. Click Plan this solution. The AI reads the investigation's evidence — the root cause, the event mix per tool, the hypotheses, the signal clusters — plus your solution, and proposes a small set of typed tasks.
- 1Review each row
Every proposed task has a type (
Tech/Non-tech/Design), an editable title, the AI's reason, and an hours estimate. - 2Edit it
Change a title, switch a type, bin a row you don't want, or add your own with
Add task. - 3Create them
Click
Create N tasks. They are written at once and the board opens.
- Plan the whole solution — the wizard above. This is the normal path.
- One signal, one task — in Decide, open a solution and click
Add to Acton an attached signal. Clicking twice returns the task you already made. - By hand —
New taskorNew bugin the Act header. A bug is created as a sub-bug; parent it under a task and it lives inside that ticket instead of on the board.
A technical task needs an approved repository first. Pick one in Settings → Codebase. Without it, creating any tech task fails with "Choose a GitHub repository in Settings → Codebase before creating technical tasks." There is no fallback, by design — Act will never read its own server's code.
The board follows your product's workflow
The columns on your board are yours — they come from the product this initiative belongs to.
Vernais looks up the initiative's product and uses that product's workflows. An initiative with no product falls back to the workspace's product. A workflow's states become the board columns. Its arrows are the only legal moves. Every product opens with this starter set.
| Workflow | States | Editable |
|---|---|---|
| Engineering | To Do → In Progress → In Review → Merged → Verifying → Done | No — locked |
| Design | To Do → In Progress → In Review → Approved → Done | Yes |
| Content | To Do → In Progress → Done | Yes |
| Bug triage | Triage → Investigating → Fixing → Verifying → Closed | Yes |
| Custom workflow | Intake → Review or Fast-track → Done | Yes |
A Tech task lands on the Engineering board, Design on Design, Non-tech on Content. Edit the unlocked workflows, or add your own, in Settings → Workflows — see Set up a product. Every Act board for that product changes with them.
Engineering is the exception. It carries a Locked badge and cannot be edited or swapped. The git and Sentry machinery in the next two sections is wired to its exact state names, so a rename would strand your tickets. A custom workflow tagged tech is allowed but never governs engineering tasks. On the Engineering board, In Review, Merged and Verifying are also locked to dragging — they advance from git.
Plan the dates before you assign
Set hours and blockers first — every date the engine gives you is computed from those two, plus who owns the task.
Pressing Create N tasks opens the Plan view, not the board. Plan is a grid, one row per task, with five columns: Task, Flow, Hours, Blocked by, Assignee. Only top-level tasks appear — sub-bugs stay out. The Compute schedule button sits at the top right. The total estimate sits under the grid.
- 1Set the hours
Type into the Hours cell. It saves when you click away. This is the only number the engine sizes a task from.
- 2Mark what blocks what
Open the
+ blockpicker and name the tasks that must finish first. Each one becomes a chip you can remove. - 3Pick owners
The Assignee column opens a people picker. An owner is optional here. It still changes the dates.
- 4Press Compute schedule
The engine writes a start and an end date onto every task. It returns one state for the whole initiative.
No AI runs here. The engine is a plain calculation. The same hours, blockers, owners and calendar give the same dates every time. Re-run it as often as you like. The dates move only when an input moves.
Laid out across working time only: 09:00 to 17:00, Monday to Friday. Eight hours fills one day.
A task cannot start before its last blocker ends. One blocker or ten, the latest end wins.
One person's tasks run back to back. Nobody is scheduled on two tasks at once.
Out-of-office days and holidays push the remaining hours forward, into the next working day.
Read the hours basis
| Marker | Where the number came from |
|---|---|
you | You typed it. The engine takes it as given. Typing over the estimate flips the marker, including from the ticket. |
n=0 | Nobody typed it. Act guessed from the task type. |
The guess is arithmetic, not learning. A tech task starts at 8 hours, design at 6, other work at 4. If the investigation behind the initiative touched two or more integrations, every estimate starts 50% higher. The n counts the similar past tasks used. It is always 0 — nothing in Act learns from past tasks yet. Hover the marker and it tells you: “Estimate — no similar past tasks yet”.
Compute before you assign anyone. You get the shape of the plan while the hours are still cheap to change. The counter-case: every unassigned task shares one queue. The engine runs them back to back, as if one person did all of them. That makes the end date pessimistic. The test: count the rows that still say Unassigned. More than one, and treat the date as a ceiling — not a date to promise.
Read the rollup
| State | What the engine found |
|---|---|
on_track | Neither of the states below. |
at_risk | The planned span runs longer than the timebox. The timebox is 14 working days by default. |
red | The last task finishes after the target date. You also get the overrun in days and the critical chain — the sequence that broke the date. With no target date set, a plan can never go red. |
A task's first computed start is kept as its floor. Re-assigning it later will not slide it earlier than that date. Its hours still move the end date.
Assign it, and read the fit score
The fit score reads profiles, not people — treat it as a hint you can overrule.
Open a task and use the Assignee dropdown in the Details rail. Each teammate shows a bar, an N/10 score and a one-line reason, best fit first.
An AI judge compares that person's own written profile — role, title and bio — against this task's title and description, and scores it 0 to 10. Each verdict is cached on that exact pairing, so the same profile and task give the same score every time. A teammate with no title or bio gets a plain role-fit score on the same scale instead, and so does everyone when the task carries no real text. A note above the list tells you which basis was used.
A 4/10 is not a rejection. It means adjacent — a PM or founder on an engineering task, say: real product context, not the core skill. A thin profile is scored around the middle rather than at zero, so a low number is a claim about the task match, not about the person. The test: if the reason line says something you know is wrong about them, ignore the number and assign them anyway.
Ship the code from the ticket
Do the git work in the Development panel — that panel is what drives the locked columns.
- 1Create branch
Click
Create branch. Pick the repository, edit the name (it pre-fillsfeat/act-xxxxx-<slug>), pick the base. The branch is created on GitHub and linked to the task. If it already exists, it is linked instead of erroring. The task leaves To Do. - 2Let the panel pull
Open the ticket and it pulls the branch's real commits, pull requests and CI builds once.
Refreshforces it again. A failed GitHub call keeps the data you already had rather than wiping it. - 3Merge
Click
Merge → main. Vernais prefers a pull request: it merges an open one, or opens one first and merges that. A direct branch merge is the fallback. The merge SHA is stamped on the task and it advances to Verifying.
Put the task's short id — act-4f9a2 — in the branch name, the PR title or a commit message. That string is how a later production error gets matched back to your change with confidence instead of a guess.
What GitHub has to be for any of this to be real: connected, with push access to the repository. Without it, Create branch records a demo branch locally and tells you so, and Merge refuses outright. A demo branch has no real commits, pull requests or builds. Creating a new branch also clears the old branch's commits, PRs, builds and merged state, so you never read stale data.
Merged is not done
On the Engineering flow, a merge moves the task to Verifying, not Done. A watch window opens — 24 hours by default. While it runs, Vernais reads the Sentry errors already ingested into this workspace and checks whether any belong to your change. Stay clean for the whole window and the task marks itself Done. A strong match files a sub-bug under the task and bounces the task back into active work. Nothing can close while a child bug is open.
Errors are judged against the real deploy time, not the moment you clicked: the matching Sentry release's date if there is one, otherwise the merge. That is why an error that already existed before your deploy is not blamed on you, and why backfilled data still matches.
This gate exists only on the Engineering flow, and only when Sentry is connected and synced into this workspace. Design, Content and custom manual boards have no gate, no watch window and no auto-filed bug.
Ship the initiative
When every ticket is closed and no bug is open, Ship it in the Act header turns on. It moves the initiative to the Measure phase. If anything is still open, the server refuses and tells you how many tasks and bugs remain. Act also hands off to Measure on its own once the last surviving task closes. Reaching Measure is not a claim that you shipped — see Prove it worked for locking a baseline and taking readings.
Changing anything in Act needs permission to manage product work, which the workspace owner grants per person. Without it the board is read-only: some controls are hidden, and the rest return an error when you click them. Choosing the repository in Settings → Codebase is a separate permission again. See Permissions and seats.
Related resources
Prove the fix worked
Lock the number you set out to move, then watch it. And let the merged code prove itself in production before anyone calls it done.
Two things prove a fix. A metric that moves, and production that stays quiet. Vernais handles both. It derives a success metric while it investigates, and you lock that number as your baseline. Separately, a merged engineering task waits in a watch window while Vernais checks new production errors against it.
What has to be in place
The tracking metric only exists if an investigation created it.
- An investigation — the metric is derived from the investigation's own findings. It rides onto the initiative when you press
Generate initiative. - The Measure tab — Initiative → Measure. The metric sits there as a candidate until you lock it.
- The Measure permission — locking, readings and outcomes all need
launch.take_reading. It is an elevated permission, off by default, and the workspace owner turns it on per person. The owner always holds it. See Permissions and seats. - Sentry in this workspace — only for regression detection. The metric works without it.
No tracking metric yet when the findings had no clean event funnel to ground oneRead the math before you lock it
Read the receipts first — a locked baseline is the number you will argue about for weeks.
Vernais derives the metric after the investigation ships its answer, not while it reasons. It reads the frozen findings, then asks one question: which real events measure this problem? The AI picks from a closed menu. The menu holds only event values Vernais actually found in your data. It cannot name an event you do not have.
The counts are not the AI's work either. Vernais sums the real events and writes down the filter it used. Same investigation, same metric, every time — the result is cached against the question, the graph and the diagnosed root cause.
The math card on the Measure tab shows all of it:
- The formula — the metric written out, such as
checkout_failed / (checkout_failed + conversion). - Numerator and denominator — the count on each side, the exact events summed into it, and a receipt you can open to see the filter recipe behind that number.
- Why this metric — the reasoning for picking it over the alternatives.
- Chips — how well the data supports it (
Suitable,SuggestiveorNot measurable), the sample sizeN, the source tools and the window it was counted over.
An investigation can derive a set: a north-star metric plus supporting ones, and sometimes an external one. The header tells you how many. Locking locks the whole set together.
The metric is best-effort. If Vernais cannot ground one, the investigation still ships its answer — you just get no Measure card.
Lock the baseline
Locking freezes the value the investigation already computed. Nothing is recounted.
- 1Open Measure
Initiative → Measure. The header reads
Tracking metrics · derived at investigationand the metric carries aCandidatechip. - 2Check the math card
Read the formula, both counts and their receipts. If it measures the wrong funnel, do not lock it.
- 3Press Lock as baseline
The bar spells out what will be frozen, including the north-star value.
- 4Watch the state change
The initiative's lifecycle moves from in progress to tracking. The title becomes
Outcome graphs.
What gets frozen: the value and how it displays, the numerator and denominator counts, the window, and the time it was derived. Vernais never re-reads the answer's prose and never recounts to build it. That is why the before number cannot drift under you.
Locking before the fix ships is fine — the baseline is the investigation's number, not today's. But do not lock a metric you cannot explain and hope it works out. Unlock clears every reading you have taken. The test: can you say in one sentence what would make this number move?
Unlock clears the baseline and all readings and returns the initiative to in progress. The derived metric definition stays, so you can lock again when you are ready.
Take a reading and read the trend
Every reading replays the baseline's exact recipe, so the two numbers are genuinely comparable.
Press Update the baseline. Vernais re-runs the metric's stored recipe over a recent window. Each side of the formula carries that recipe: the tool, the field and the values to count. A separate process replays it with plain database queries. No AI runs. No model rewrites the definition. Same inputs, same number.
The button says Update the baseline, but it does not move the baseline. It adds a reading to the trend and leaves the frozen starting number alone.
The reading joins the growth series. The outcome graph draws baseline to current and tags the metric improving or regressing. Hover any point to see that reading's value, the metric name and the formula behind it.
Readings de-duplicate by the hour. Press the button twice in one hour and the second reading replaces the first, so a retry cannot corrupt the chart.
Record the outcome
The outcome is a portfolio label. Measurement carries on either way.
Measure → Resolution. Three chips:
| Chip | What it records | What else happens |
|---|---|---|
| Shipped | the fix went out | the initiative's remaining calendar blocks are cleared; task history stays |
| Rolled back | you pulled it back | the same calendar clean-up |
| Tracking | the default after locking | nothing else |
Reaching the Measure phase is not a claim that you shipped. The lifecycle stays in progress until you lock, then tracking, until you pick an outcome. Portfolio views read that lifecycle, not the phase.
The Verifying gate: what soak means
Merging is not done. A merged engineering task waits in Verifying while Vernais watches production.
Press the merge button on the task's Development panel — it reads Merge → main, or whatever base branch the branch targets. The branch merges on GitHub and the task advances to Verifying. That opens a soak window: 24 hours by default, with a live countdown and a progress bar on the ticket.
The window is measured from the real deploy, not from your click. Vernais anchors it to the matching Sentry release's release date. With no release it uses the merge time. With neither it uses the moment the gate opened. That is why an error that existed before your deploy is not blamed on you, and why imported error data still lines up.
- Clean and elapsed — no attributed error, CI not failing, no open child bug. The task marks itself Done. You do not come back and click anything.
- Scan Sentry now — the ▾ menu beside the master button runs the check on demand. A background clock runs the same scan every few minutes anyway.
- Mark clear → Done — sign it off yourself. It still refuses while a child bug is open.
- Report a bug — records a QA failure, files a sub-bug and bounces the task back to In Progress.
How an error gets pinned to your task
Put the task id, like act-4f9a2, in your branch name, PR title and commit messages.
Vernais reads the Sentry issues already ingested into this workspace and scores each one against your change. Every signal it finds adds weight.
| Signal | What it proves | Weight |
|---|---|---|
| Your task id in the error text | your reference is literally there | 0.50 |
| One of your commit SHAs | the exact code that changed | 0.45 |
| The release matches your version | the deploy this task shipped | 0.35 |
| Your version named in the text | the error names the deploy | 0.30 |
| First seen inside the window | it appeared right after the change | 0.20 |
| Same service | the same subsystem — this ranks, it does not prove | 0.15 |
| Unhandled, or high volume | real users hit it, and not once | 0.10 / 0.05 |
Score 0.60 and up files a bug on its own — but only when a strong anchor is present: your task id, a commit, the release or your version. Severity and timing alone never file. Score 0.35 and up appears as a card for you to judge. Score 0.15 and up shows as possibly related.
Each matched-error card carries the error title, the culprit code path, and the event, user and occurrence counts. A pill reads the score and the tier. A why: line names the exact signals that scored. Links open the issue in Sentry, or the underlying records in your data.
A red File as bug button sits on the review cards. A card whose bug already exists reads Bug filed instead.
Read the tie before you trust a card. Commit-confirmed means one of your commits is named in the error. Time-correlated means it only turned up in your window. That is a correlation, not proof.
When a regression is caught
Nothing to click. A sub-bug appears under the task and the board card turns red.
- 1The bug is filed
It is a full engineering task, inheriting the parent's assignee, pre-filled with the Sentry evidence: culprit, event and user counts, the attribution signals and the Sentry link. It is pulled into In Progress.
- 2The parent bounces
It leaves Verifying. Its rollup line reads
Regression — fix bug act-xxxxx, then it re-verifies automatically, and a system comment names the bug. - 3You fix the child and close it
A parent can never be closed while a child bug is open. Every path is blocked, including the skip override.
- 4The parent re-verifies
Closing the last child returns the parent to Verifying with a fresh window. It never jumps straight to Done.
Vernais recognises the same logical error by its title and code path, and records that fingerprint on the task once a bug is filed. The same issue then reads Bug filed instead of filing a duplicate — including after the parent re-enters the gate.
What Sentry needs
The gate reads Sentry data already inside this workspace, not Sentry's API.
- Connected — Sentry is connected as a tool. See Connect a tool.
- Synced into this workspace — the gate reads ingested Sentry issues from this workspace's own graph. Build the graph here so the data lands here. See Build the graph.
- GitHub, for commit-confirmed matches — the commit check reads the task's synced commits. Without a refresh on the Development panel, attribution falls back to release, version, service and timing.
- No Sentry rows — the panel says
Sentry not connectedand nothing is ever auto-filed. It does not guess.
With no Sentry in this workspace the gate is not useless — CI still reports and you can sign off by hand. But do not read a quiet soak as evidence. The window will elapse and close the task whether or not anything was watching it. The test: does the panel show a countdown, or does it say Sentry not connected?
Related resources
Watch what you shipped
One screen for every metric you locked — which shipped fixes are moving their number, and which are quietly going the wrong way.
Launches is the portfolio view of everything you measured. An initiative's Measure tab watches one fix. This page puts every locked metric on one screen. It answers the question no single initiative can: is the stuff we shipped working? Metrics that got worse sort to the top, so the trouble finds you first.
What has to be on this page
Nothing reaches Launches on its own — an investigation derives the metric, and a person locks it.
- An investigation — the metric is derived from an investigation's findings. It rides onto the initiative you generate from that answer.
- A lock — the metric stays a candidate until someone locks it as a baseline. The math card and the lock live on the initiative's Measure tab. See Prove the fix worked.
- A reading — a locked metric with no reading yet draws one flat point and reads
awaiting reading. It still counts as tracked. - The permission —
launch.take_readingis elevated and off by default. Without it you see every card and every number. Both buttons are gone.
Tracked and candidate
Tracked means locked — that is the whole difference.
The metric is locked. It carries a frozen baseline and a growth series, so it can draw a green or red outcome graph. This is the only tier the header counts and the rail breakdowns count. A locked metric with no reading yet still sits here, tagged awaiting reading.
An investigation derived the metric, but nobody locked it. It has one point and no baseline, so there is no trend to draw. It waits in the Ready to track strip under the grid, with a Lock & track button. It exists so the page is not blank on day one.
Read a card
Every number on a card was computed on the server, not rebuilt in your browser.
| Part of the card | What it tells you | Where the number comes from |
|---|---|---|
| Metric name | the number this launch is judged on | the frozen metric definition, derived during the investigation |
| Initiative name | the fix behind the metric | the initiative — click the card to open its Measure tab |
| Delta | the move from baseline to latest reading | the two end values of the series, compared |
| Spark chart | the baseline, then every reading in order | the frozen baseline plus each reading taken — hover a point for its value |
| baseline → current | the start and the latest value, as text | the server's stored display strings for those two points |
| The tag | improving, regressing, awaiting reading or candidate | the metric's own direction, checked against the baseline |
| Status chip | Tracking, Shipped, Rolled back or Paused | the outcome set on the Measure tab — this page shows it, it cannot set it |
| Readings and window | how many readings exist, and the window the metric counts over | the locked measure |
Units follow the metric type. A rate or percentage moves in percentage points, like −12.0pp. A count or ratio moves in relative percent, like +25.0%. A baseline of zero has no meaningful percent, so the card shows the absolute move instead. Direction decides which way is good. Most metrics carry their own; a count with none set is read as lower is better.
+0.0pp, which is not a real dropNarrow it by owner, impact or product
Who owns the initiative behind each tracked metric. Avatars resolve to the person's current one at read time, so a stale face never sticks. Use it to ask whether one person's launches are all drifting.
High, Medium or Low, taken from the initiative. Use it to check whether the work you called high-impact actually paid off. That is the honest test of a roadmap.
The initiative's product. Use it when one product is the story and the rest is noise. See Set up a product.
Every number in the rail counts tracked metrics only. Candidates are never in them. The filters still narrow the candidate strip, so a rail count of 3 can sit above 3 cards plus a candidate.
The header switches All, Improving and Regressing. Awaiting reading and Ready to track appear in the rail only, and only once at least one exists.
Lock a candidate, then take a reading
Read the math on the Measure tab before you lock — Launches never shows you the formula.
- 1Find the candidate
Scroll to the
Ready to trackstrip, or pickReady to trackin the rail. The strip hides while an outcome filter is on. - 2Open the math first
Click the card. It deep-links to that initiative's Measure tab, where the formula, both counts and their receipts live.
- 3Press Lock & track
This freezes the value the investigation already computed as the baseline. Nothing is recounted. The card moves up into the tracked grid and reads
awaiting reading. - 4Press Take a reading
The metric's stored recipe replays over the last 14 days using plain database queries. No AI runs. The new point joins the series and the graph turns green or red.
Locking from Launches is one click, and that is the risk — the button sits on the card, the formula does not. A baseline is the number you will argue about for weeks, so a wrong one is worse than none at all. Lock from here only when you already read the math. The test: can you name the events on both sides of the formula? If not, open the Measure tab first.
Related resources
Find the work assigned to you
Every task assigned to you sits in one queue, and your inbox holds what happened while you were away. Your status dot quietly decides which of it reaches you.
Open your queue in My tasks
Click My tasks in the sidebar. It gathers every Act task assigned to you across every initiative in the workspace, in one place. You do not have to open each initiative to find your work.
My tasks reads your queue. You create and assign tasks on an initiative's Act board.
It matches tasks to you by your user id or your email address, so a task assigned to either still finds you. Two kinds of task never show up here: ones marked cancelled, and ones whose initiative was deleted. A deleted initiative leaves nowhere to open the task, so it is left out rather than shown as a dead link.
The page reloads itself when you come back to the browser tab. Assign yourself something on an Act board, switch back, and it is there. The header keeps a running count — how many tasks, across how many initiatives.
Work the queue the way you think
Three views sit at the top of the page. They show the same tasks.
| View | What you get | Reach for it when |
|---|---|---|
| Board | Kanban columns with a count per column | You want to see shape and flow |
| List | Grouped rows with a done-count per group | You are checking off a batch |
| Table | A dense grid: ID, Task, Initiative, Type, Priority, Stage, Est, Due | You are scanning dates across many tasks |
The Group menu re-columns the board by Stage, Initiative, Type or Priority. Grouping by Initiative gives each one its own coloured column, labelled with its code and name. Act runs seven real states, and the board folds them into four readable columns — merged, verifying and approved all sit under In Review. The card keeps showing its true status, so a card reading Verifying in the In Review column is correct, not a glitch.
The filter bar narrows what you see: Initiative, Type, Priority and Status each open a menu, and Status carries the useful cut — Open bugs. Once anything is on, a Clear button appears to reset the lot. The search box matches a task's title, its human id, or its task ref. The left rail lists every initiative you have work in, each with its own count.
Start on the Board — but if you are hunting a date across forty tasks, columns hide what you came for. Switch to Table. The test: are you reading flow, or reading a column of values?
What lands in your inbox
Inbox in the sidebar is the durable list of things that happened to you. It carries an unread badge and keeps items until you archive or delete them.
The inbox is a record. The pop-ups are a separate live layer, and your status governs those, not this.
Real things that arrive here today:
- Meeting invitations — the meeting card with its time and guest list, plus a
Join nowbutton once the call is live. You answer Yes, No or Maybe from the Calendar, not from here - RSVPs — someone answered an event you organise
- Out-of-office declines — an invite that clashed with your out-of-office was declined for you, and you are told so you can accept anyway
- Meeting is ready, has started, and a nudge when the scheduled time is up
- Proposed times from a guest, a heads-up when a time changes, and word if your own proposal was not taken
- Meeting captured — the recording and transcript were written up after the call ended
- @mentions from live chat, with a reply box you can type straight into
Clear it down to zero
Opening an item marks it read and drops the badge. Each row has quick buttons for Archive and Delete, and the detail header adds Mark unread and Copy link. On a row you can swipe left to archive and right to delete. Archived items live in the Archived view, where you can restore them. There is a Mark all read button when you want the badge gone in one go.
Delete removes an inbox item for good. Archive is the reversible one — it keeps the item and you can restore it later.
Your status decides what reaches you
This is the part people miss. Click your avatar at the bottom of the sidebar and pick a status. That choice overrides every notification toggle in Settings — it is checked first, and it wins.
| Status | What still reaches you |
|---|---|
| Online | Every type you left switched on |
| Away | @mentions and direct messages only — channel messages go quiet |
| Do Not Disturb | Nothing at all |
| In a call | Urgent alerts only, and no chat alert counts as urgent — so this is silent too |
| Invisible | Every type you left switched on. You only appear offline to other people |
Do Not Disturb silences the live layer only. Items keep arriving in your inbox and the unread badge keeps counting. Nothing is lost while you are quiet — you are not interrupted until you look.
Away is the better default for heads-down work, because a direct message still gets through. Reach for Do Not Disturb when you can afford to answer nobody for an hour. The test: if one person could not reach you for the next hour, would that be a problem?
Change what you're alerted about
- 1Open Settings, then Notifications
You'll see three cards: Delivery, Notify me about, and a card that lists what each status does.
- 2Set your delivery channels
Sound plays a soft chime and is on by default. Desktop notifications are off by default; switching them on asks your browser for permission. If you have blocked notifications for the site, the toggle is disabled and says so.
- 3Pick your types
@mentions & repliesandDirect & group messagesare on.All channel messagesis off, because it is noisy in a busy workspace. - 4Read the status card last
It spells out the policy for each status. That policy sits above every toggle on this page.
One detail worth knowing: a desktop notification only fires when the tab is in the background. If you are looking at Vernais, you get the in-app toast instead of a system pop-up.
See it all from the Dashboard
If you would rather start your morning in one place, the Dashboard carries a My tasks card and an Inbox card side by side. My tasks shows up to six open tasks, sorted active-first, then by priority, then by due date. Inbox shows up to eight notifications with unread dots. Each card links through to the full section.