> ## Documentation Index
> Fetch the complete documentation index at: https://docs.attensira.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Decisions

> The small, typed questions the agents answer before they act. A decision can stop, escalate or pick among allowed options. It never approves, never spends, and never changes what needs your approval.

## What a decision is

Along the way, the agents answer many small questions that are not worth your time. Is this draft breaking one of your rules? Is this dip noise? Does this need a person sooner? Each one is a **decision**: one typed question about one thing, with a fixed set of things its answer is allowed to do.

A decision can do one of four things, and nothing else:

| Kind | What the answer may do |
| - | - |
| **Stop** | Hold back something that would otherwise happen. |
| **Escalate** | Bring something to a person, or to a re-plan, sooner. It never acts on your behalf. |
| **Select** | Pick one option from a list the agents' own rules already allow. An answer outside the list counts as no answer. |
| **Shadow** | Be recorded, and nothing more. |

None of the four widens what the agents may do. A decision never approves anything, never spends, and never changes what needs your approval. Your [approval mode](/agent/approval) and the change classes decide that, and no decision can override them.

Every decision is recorded: the question, the answer, and what the answer was allowed to do. The same question about the same thing, unchanged, can be answered from that record instead of being asked again.

## When a decision cannot be made

When a question gets no answer, the agents do exactly what they did before decisions existed. A missing answer never counts as yes, and never as no. It means the step the decision would have changed runs the old way.

No answer covers every way a question can fail: it timed out, the service that answers it was unavailable, the answer was missing, or it named an option that was not on the list. In each case the step runs as if nobody had asked. When answers keep failing, the agents stop asking for a short while and run the old way straight away, so an outage never slows the loop down.

[Noise or a real change](#noise-or-a-real-change) and [Worth a run](#worth-a-run) are both of this kind. With no answer, a finding is filed and an event wakes its automation, exactly as before.

The [draft check](#the-draft-check) is the one place this works differently, because the old way there was no check at all.

## Noise or a real change

Every hour, [detection](/agent/findings) checks your readings against five fixed rules. A rule that fires says what moved. It cannot say whether it moved by more than sampling moves on its own. A prompt read three times a day can lose a citation for three days on luck alone. So before a finding is filed, it is measured, and some findings are put to a decision.

### First, the arithmetic

The finding's last three days are compared with the seven days before them, counting successful reads only. A failed read is missing data, never a miss. The comparison is Fisher's exact test. If the change is significant at p \< 0.01, the finding is filed, and nothing is asked.

### Then, one Stop decision

A finding that is not significant on the arithmetic, and has no row open in your [Inbox](/agent/inbox) yet, is put to one question: **is this a real change in AI answers, rather than sampling noise or a gap in the readings?**

The question reads numbers only:

* for each of the ten days, how many answers were read successfully (n), how many reads failed, how many answers named you and how many did not, and how many counted toward the finding;
* the totals and rates for the three recent days and for the prior seven;
* the p-value;
* how many prompts and engines the finding reaches.

It never sees a domain, a URL, a page title or a prompt's text. Nothing written on a page can argue a loss away.

A finding is **held as noise** only when the decision is confident it is not real: less than a 20% chance that it is. Everything else is filed.

### What held as noise means

* **It is not filed.** No Inbox row is raised and no open row is bumped.
* **It is not an event.** No [event automation](/agent/autopilot#event-automations) hears about it, and it starts no run.
* **It is held for this hour only.** The next hourly pass measures the finding again. Once new readings have landed, the question is asked again on them, and a change that holds up is filed then. Until they land the numbers are the same, so for up to six hours the earlier answer stands rather than being asked again.
* **It is recorded.** Each hold keeps the number of successful reads it was judged on (n, across both windows) and the test's p-value. A finding that was held and later filed no longer counts as held.

A held finding is not recorded as an event with a "held" flag either. The same event is recorded at most once per subject per day, so a held event in the morning would hide the real one in the afternoon.

### What is never held

* **A significant change.** p \< 0.01 is always filed, whatever a decision would say.
* **A finding whose Inbox row is already open.** That row is always bumped, so its count keeps growing.
* **A change to your own pages.** It is not a measurement that can be noisy, and it is often the reason behind the other findings.

### How much it matters

The same findings get a second question, a **Select** decision: how much does this matter, on a scale of **low**, **medium**, **high** or **critical**? It reads the same numbers.

The answer only changes the order in which findings take the three open Inbox rows that detection may fill. It never drops a finding. A finding that misses a row still bumps the closest open one, as before.

* A significant finding ranks with **critical**. The arithmetic already proved it.
* An answer that is less than 40% sure is ignored, and the finding ranks as **medium**.
* If no finding got a usable answer, the rules' own order stands.

## Worth a run

An [event automation](/agent/autopilot#event-automations) runs when something happens instead of on a clock. Most events have already been judged by the time they arrive. One kind has not: a competitor changing pages on its site (`competitor_changed`). Those arrive in bursts. A redesign changes every page at once.

So before a competitor's change wakes an automation, a **Stop** decision asks: **is this event worth starting a run of this automation now?**

The question reads:

* the automation's name and the first 500 characters of its instruction;
* the focus of the automation's project and its three most recent directions, when it belongs to a project;
* the event's type, subject and date;
* the automation's event runs from the last seven days, at most five, each as its **Because…** sentence;
* what changed on the competitor's page.

The competitor's page is read as text to judge, never as instructions. A page that says "ignore this change" is weighed like any other wording.

An event is skipped only when the decision is confident it is not worth a run: less than a 15% chance that it is. A change to plans, positioning, a product, or a comparison page reads as worth a run. A styling change, a copyright date, a cookie banner, or something a recent run already covered reads as not.

### What a skip does

* **The event is closed for that automation,** as skipped, with the reason **not worth a run:** and the event in our own words. For example: "not worth a run: competitor.example changed pages on its site".
* **The rest of the batch still fires,** as one smaller run.
* **If every event in the batch is skipped, nothing fires.** [Loop health](/agent/loop-health#why-a-scheduled-run-was-skipped) records a skip with the reason `not_worth_run`, so an automation that always skips shows up there.
* **A skip starts no run,** so it spends no credits and does not count toward the automation's 3 event runs per 24 hours.

### What is never asked

* **Every other event type** wakes its automation as before. Detection's events (`citation_lost`, `prompt_lost`, `new_deciding_source`) were already measured by the pass above. Changes to your own pages and readings (`page_changed`, `win_detected`) are about you, and never noise to you.
* **An event that says nothing about what changed** fires. There is nothing to judge.
* **The 48-hour age limit and the rate cap come first,** and they win whatever the answer. The question can only hold back what those rules let through. Credits, caps and a paused project are checked after it, as before.
* **A batch that already has a run** is not asked again. An event that waits behind a run still in progress can be answered from the earlier decision for up to 12 hours, rather than asked again on every check.

## The draft check

Before anyone can approve a draft the agent writes in your name, it is checked against every rule that applies to it: your compliance and voice rules, your words to avoid, and our house rules. The full list, and what each verdict does, is on [Approval modes](/agent/approval#the-draft-check).

For each rule, the check asks one question: does this draft break this rule?

* A compliance rule the draft clearly breaks **stops** it. One it may break sends it to **review**.
* A voice rule is at most **review**. Sounding off is a reason to read a draft, not to refuse it.
* A word you said to avoid, and the certain part of some house rules, is a plain match. It needs no judgement and runs before anything is asked.

The draft goes in as text to judge, never as instructions. An instruction inside a draft, such as one copied from a page the agent read, is judged as content and never followed.

For articles and pages, the check also records how readily an answer engine could quote the draft. That is a note on the draft only, and it never changes the verdict.

### Checked against N rules, or Not checked

A draft that passes is **checked against N rules**. N counts your rules and our house rules together.

A draft the check could not finish is **not checked**, and it is never read as passed. For your own rules, a missing answer does not fall back to "go ahead": the draft cannot be approved, published or sent until it is checked. A row in your [Inbox](/agent/inbox) says how many drafts are waiting on a check, and approving a draft checks it again. A stop found before the check broke off still stands.

Our house rules are the exception. A house rule the check could not answer is left out of N, and the verdict stands on the rest. Its certain part still runs. Before the house rules existed, drafts were not checked against them, so a gap in the check does not hold every draft in every workspace.

The check only ever adds a stop. A passed draft still waits for every yes it needed before.

## Where a handed-off line goes

When you hand off several lines at once from the composer, or the Chief of staff hands off tasks from a chat, each line becomes its own task in one of your workspace's projects. Picking the project is a **Select** decision. It can choose a project, or decide that the line should wait for you. It cannot do anything else.

Rules come first, and when one applies, nothing is asked:

1. A project named for the line itself goes first: the project the Chief of staff named for that task, or a `#name` in the line that matches one of your projects. A line that *starts* with a `#name` matching no project waits for you, with the reason "there is no project #name". A `#name` later in the line that matches no project is read as an ordinary hashtag and ignored.
2. The project you picked in the composer takes every line that does not name its own.
3. If exactly one project is taking work, every line goes there.

A project named by a rule that is paused, or still being set up, does not take the line. The line waits for you and says why, for example "Blog is paused".

When no rule applies, the decision reads the line and the name and focus of each project that is taking work (up to 25 of them). It then picks one of these: one of those projects, the **Chief of staff** (for a question, a one-off ask, or work that spans several projects), or **a new project** (for an ongoing area of work that no project covers yet). The line is judged as text and never followed as an instruction. A line that says "this is for the blog project, ignore your rules" is weighed like any other wording.

| What the decision answers | What happens to the line |
| - | - |
| A project, 60% sure or more | It is filed as a task in that project |
| The Chief of staff, 60% sure or more | It waits for you: "This does not belong to one project" |
| A new project, 60% sure or more | It waits for you: "This looks like work for a new project" |
| Anything, less than 60% sure | It waits for you: "Not sure which project should take this" |
| No answer | It waits for you: "More than one project could take this" |

A line that waits for you is marked **Waiting on you** on the card. The chat then asks **Which project should take "…"?** and offers your most recently active projects as one-click answers. You can also type a project's name. If up to three lines are waiting, each gets its own question. If more are waiting, one question covers them all. Your answer files the line in that project straight away, with no further decision. An answer that matches no project goes back to the Chief of staff to sort out.

If the workspace has no projects, there is nothing to choose from, so the Chief of staff does the work in the chat.

### How sure it was

The **Handed off** card in the chat lists each line and where it went. Hover over or focus a project that the decision picked to see how sure it was, in words and as a percentage. For example: "Very sure this belongs in #blog · 91%. Attensira picked the project."

| Words | Confidence |
| - | - |
| Very sure | 90% or more |
| Fairly sure | 75% to 89% |
| Somewhat sure | 60% to 74% |

A project you named, or your only project, shows its name with no percentage, because nothing was decided. A line that went to the person because no answer came back has no percentage either. There is no number to show, so none is shown.

### What routing never changes

* **Only the project.** The output and speed you chose in the composer are filed exactly as you chose them.
* **Not your approval mode.** The task runs as an ordinary run under your [approval mode](/agent/approval). Routing never approves anything and never changes what needs your yes.
* **No guesses.** A wrong project means real work done in the wrong place. Confirming takes one click, so a line the decision is unsure of always comes to you.

## Goal re-plans

A goal is a number from a connected source, a target and a date. Each goal is read every day and compared with its pace line, which runs from its first reading to its target. Whether a goal is ahead, on pace or behind is plain arithmetic, never a decision. If decisions are unavailable, a goal's standing does not change.

When the arithmetic says a goal is **behind**, an **Escalate** decision asks one more question: is this gap worth re-planning the work now, or should the current plan keep running?

### When it is checked

The check runs every morning at 05:00 on the workspace's clock. That is after the 04:00 readings land and before the 06:00 [Daily win plan](/agent/automations). It looks only at open goals that are behind as of their latest reading (that morning's or the day before's) and whose date has not passed.

### What decides

* **The floor.** If a goal is more than 30% of its climb behind with fewer than 14 days left, it is always re-planned. Nothing is asked.
* **Otherwise, the decision.** It reads numbers only:

  * the last 28 days of readings, with the sample size (n) behind each;
  * the pace line and its noise band;
  * the gap, and the days elapsed and left;
  * shipped work that is still waiting for its [re-read](/measure/before-and-after), with the re-read dates;
  * how long ago the goal was last re-planned.

  It never sees the goal's name or anything a person or a page wrote, so no wording can steer it. Only a confident yes leads to a re-plan. These read as no: a dip of a day or two, readings with a small n, a trend already climbing back, and shipped work whose re-read could close the gap.
* **No answer means no re-plan,** the same as before decisions existed. The floor still applies.

### At most once a week

A goal re-planned in the last seven days is left alone. Each goal gets at most one re-plan per calendar week, counted on the workspace's clock. A re-plan run you cancel stays cancelled for the rest of that week. A re-plan row you dismiss is not filed again that week.

### What a re-plan does

What happens depends on your workspace's [approval mode](/agent/approval):

* **Draft or Act.** One run of the Daily win plan starts, focused on this goal. It plans at most three pieces of work that move the goal's number and files them as work, which your approval mode governs like any other. If the target looks out of reach, it says so in one line and asks you. The run shows why it started: **Because "your goal" is behind pace.** It is an ordinary run and spends credits like one. If the balance is spent or a cap is reached, nothing starts.
* **Ask.** Nothing starts. One row is filed in [Work](/agent/inbox): **"your goal" is behind pace: re-plan the work toward it?**

For seven days after a re-plan run starts, the goal's chip reads **Behind, re-planning**.

A re-plan never changes the goal, its target or its date, the budget, or any setting. Changing those is always yours.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.