Autopilot

Autopilot is the fourth way to run Stabiso, beside the app, MCP and REST: the system keeps business outcomes true by itself, the way an outsourced back office would, and leaves a person only the steps that are theirs (ADR-0094; the sales outcomes: ADR-0095).

Outcomes

An outcome is a test the system checks from its own records. Switched on for a company, Autopilot keeps it true.

Outcome	True when	The rules	The AI	Only a person
`leads_followed_up`: new leads are followed up	Every open lead has an owner and a first step on it (a task, call, meeting, e-mail or note).	A lead nobody owns gets the owner of its website form, else of a contact with its e-mail address, else the person Autopilot acts for.	Each owned lead without a first step, with the contacts and earlier leads of its e-mail address: it plans the owner's first step as a task due the next working day and sets the lead to working, or disqualifies a lead that is plainly no possible customer. It never contacts anyone or converts a lead.	Do the first steps; follow up the leads it left.
`won_deals_billed`: won deals are billed	Every deal won in the last 90 days has its quote, order or subscription (a renewal deal: the subscription it renews).	None: what was sold is the AI's to read.	Each won deal nothing bills, with its customer, its timeline and its lead: it drafts a subscription for a recurring service, else a quote, for the deal, or asks.	Send the quotes; ask for the subscriptions' approval and approve them (a second person); bill the deals it left.
`invoiced`: customers are invoiced	Everything delivered and every recurring invoice or subscription period due up to today is invoiced.	The invoice of each posted delivery note with something left to invoice, at its order's prices, as a draft; the invoice of each checked-out hotel stay whose invoice was rejected, again as a draft; the recurring invoices due through today (a draft, or submitted where the template says so).	Not asked: nothing here needs judgement.	Bill the subscription periods (a run that can post invoices is a person's); invoice a delivery or a hotel stay or mend a recurring invoice the rules could not; check and issue the drafts; approve what waits; send the invoices of the last 30 days nobody sent.
`paid_on_time`: customers pay on time	Every overdue invoice has its reminder at the right level, and every invoice due under a direct debit mandate is collected.	The direct debits the collection proposal says are due, one receipt per mandate (an invoice being collected is not reminded).	Before a customer is reminded, their overdue invoices with the unmatched receipts that could be their payment (amount, payer or an invoice number agree): it matches one that clearly is, or asks. A customer with no such receipt is not given to it.	Make and send the reminder letters; withdraw those out of date; approve the collections that wait and release them to the bank.
`bank_matched`: the bank is matched	Every bank line up to today is matched, booked or set aside.	The bank matcher: a released payment's end-to-end id, or the one document a line settles without doubt.	Each line the matcher leaves, with its candidate documents: it matches one the records leave no doubt about, books a fee or interest, or asks.	Approve what waits for a second person; link lines that execute or return a booked payment; match what is left; mark each account reconciled.
`month_closed`: the month is closed on time	Every ended month is closed by the working day the close calendar sets, once its close checklist passes (the latest three ended months still open, from the month of the company's first posted entry on).	The runs of the close plan: recurring journals and invoices due, depreciation, FX revaluation, deferred tax, revenue recognition, leases, the allowance for doubtful receivables, the bank matcher.	Each close check still failing that is not only a person's, with the close plan's guidance (`month_end_close`) and reading tools: it finds what holds the check, or asks.	Approve what holds the close; finish the checks that are theirs; close the month (by the close calendar's working day).
`vat_ready`: the VAT return is ready	Every ended VAT period that is not filed has its return prepared from the books as they are now, with no error that blocks finalising it.	Prepare the return of a period that has none; recompute a draft after a posting into its period.	Each draft with an error: it asks for an amount only the person knows and recomputes with it, or names the booking to correct.	Finalise, approve the settlement, submit and record the submission, finish a correction.
`group_reports`: group and reports are ready	For the month that ended last, intercompany agrees, each group the company heads passes its close checks, and the month's report pack (the close memo) is written.	A new consolidation run of a group whose latest run at the month end is missing or older than the books.	Each intercompany relationship with an unexplained difference (it finds the documents, or asks); the report pack, written with the close review once the checklist passes or its close calendar day has come.	Resolve intercompany differences; finish what holds a group; read a report pack that names blockers.
`bills_coded`: bills are in and coded	Every bill that came in as a file is coded, matched to its order and posted or waiting for approval (no draft left).	Each draft whose vendor is active now and whose reading was sure is submitted, as bill capture would have (submitting matches it to its order).	Each draft left, with why it is still one, the vendor's usual accounts and open orders: it codes the lines and names the order with `code_bill`, or asks. It never changes amounts, dates or VAT.	Activate new vendors; approve the bills and the differences against their orders; finish the drafts left.
`vendors_paid`: vendors are paid on time	Every posted bill due in the next days (setting `days_before_due`, default 2, 0 to 30), or whose cash discount ends by then, is in a payment ready to release.	The payment proposal and its run, vendor by vendor: only bills without a warning or a problem, while the bank account stays above zero, and never again a bill whose payment a person rejected or reversed.	Not asked.	Approve the payments; release them to the bank; pay the bills it left.
`recurring_bookings`: recurring bookings are made	Every recurring journal due by today is booked.	The recurring journal run, one journal at a time; not a journal whose entry a person rejected.	Not asked.	Approve the entries; book what it could not.
`depreciation`: assets are depreciated	Every month that has ended and is still open has its depreciation booked.	The month's depreciation run, oldest month first, stopping at the first that cannot run or that a person rejected.	Not asked.	Run the oldest month it left; approve the runs only under four eyes (the AI reviewer posts a run's entry when its checks pass).

A pass

Check: what is not yet true.
Rules: code settles what it can, without the AI.
The AI: each item left, one at a time, with its own records, a short brief and a few MCP tools. It may ask the person one question about an item instead of guessing.
Check again: an item counts as settled only if the outcome's check finds it so.
The person's steps, each a link into the app.

A pass starts when something happens (a statement imported; a delivery note posted; a bill that came in stays a draft; a vendor is activated; a bill posted; a recurring journal activated; an asset registered; a lead arrives; a deal is won; a month closed, for the VAT and group outcomes), once a day (the daily job) and when a person presses Run now. Every pass is recorded: what started it, for whom it acted, what the rules and the AI settled, the tools the AI called for each item, what it asked and what it left a person.

Rules it keeps

A person switches an outcome on; its passes act for them, so a second person approves what they book (four eyes).
It never approves, closes or reopens a period, sends documents, releases payments or files returns.
Its postings go through the approval policy and the posting limit like anyone's.
The approve step of an outcome counts only its own bookings that wait (the bank's: what it booked from a bank line; vendors paid: its payments; and so on).
A company's outcomes give the AI at most 50 items a day; the rest waits for the next day or a person.

In the app

Processes (beside Analytics in the sidebar) is Autopilot's page. At the top, what waits for you: the steps passes left a person, each a link to where you do it, and the AI's questions, which you answer in place (the next pass hears the answer). Then each outcome with its state (off, true, open items, waits for you, problem), how many items are open, its last pass, the switch and Run now, which shows each step as it happens. Last, what every pass did; a pass opens with its steps, the tools the AI used on each item and whether the check found the item settled after.

API


`GET /v1/entities/{entity}/autopilot`	Each outcome's state, the person's steps, the open questions, the AI budget used
`PUT /v1/entities/{entity}/autopilot/{outcome}`	Switch an outcome on or off (a person)
`POST /v1/entities/{entity}/autopilot/{outcome}/passes`	Run now (`/stream`: with each step)
`GET /v1/entities/{entity}/autopilot/passes`	The passes, newest first
`GET /v1/autopilot/passes/{pass_id}`	One pass, step by step
`POST /v1/autopilot/questions/{question_id}/answer`	Answer a question; the next pass uses it

MCP: autopilot_status, autopilot_passes (reading only).