Skip to content

Advisor looking further: what it does, what it costs, how it is checked

When the model you connected can call tools, Advisor does not only answer from the records it reads in advance. It may ask the product, as the person asking, to list, count and add up records, look one up, or search, within a fixed budget, before it writes its answer. The product does the counting; the model only composes. Everything it asks for is limited to what that person can open, and where records are out of reach the answer says only how many records the person can see in their role, never how many there are beyond that, and never which.

Under each answer that looked further, a How Advisor found this button opens the steps: what was asked, in the product’s own words, and how many records came back. The list is kept with the question in the interaction log (arguments and counts, never record text).

  • Admin > Advisor: the switch Let Advisor look further, and Most lookups for one question (1 to 10, default 6).
  • Admin > AI models: each connection says whether it can look further. A connection is tested once when you save it and again when you press Test. A model that answered in words instead of calling the test tool shows Cannot look further: Advisor then answers from the records it finds in advance, exactly as before. There is no pretend tool calling for such models.
  • Admin > Advisor quality > Looking further: how many questions reached the lookup step, how each ended (finished, hit a limit, failed, model cannot, switched off), the mean number of calls, and a filterable list of recent questions with calls used, tools, tokens and cost. It holds counts and tool names only.

It sees what the person asking can see, and no more: archived work packages and workstreams are left out of every lookup, exactly as the plan tree leaves them out (this is intended, not a gap). A record that names plan items (a RAID item’s “Affects” line, a change sitting’s entries) shows only the ones the person reaches, with no count and no mention of the rest. A change sitting’s free-text justification and decision note are left out of what Advisor reads when any of its changes are out of that person’s reach, without saying so.

One thing it cannot do: scrub what people typed. Records are filtered by reach, but the words in a record’s own description, note or comment are read as written. If someone writes “blocked until Beta’s payroll cut-over lands” in a risk you can see, Advisor can read that sentence when it reads that risk, even if you cannot see Beta’s work. This is accepted: Works does not try to find and remove names from free text, because it would get it wrong in both directions. The sentence is only ever shown to people who can already open the record that holds it, and it reaches the model as quoted data, never as an instruction. If a sentence should not be read by Advisor, rewrite or delete it.

When Let Advisor propose changes is on (Admin > Advisor, off by default), a person who asks for a change gets a review, not an edit: Advisor prepares each change as a before and after, and the person accepts, rejects or skips each one. Nothing is changed until they accept, and Advisor never claims it has changed anything.

The button says what will happen. Before the person clicks, the review shows Save where the change will be made straight away, and Send for approval where your programme holds changes and it will wait for an approver. The product asks the same function the write itself uses (the active baseline’s review mode), so the label cannot disagree with what then happens. If the instance has no active baseline the button says Accept this change and the write is refused with its own reason.

Switching AI off stops the proposal routes too. Every proposal route (list, read, accept check, result report and reject) answers ai_off while AI is off, not only the ones that call a model. The plain side effect, which is intended:

  • A change accepted just before AI was switched off still happened. Its audit entry is written by the ordinary write, with “Suggested by Advisor, accepted by ”, and it stays in the history and the change register as normal.
  • What is not available once AI is off is Advisor’s own report of the result (the proposal’s status moving to accepted, held or refused) and the review itself. A person who accepted and lost the connection to Advisor at that instant sees no confirmation from Advisor; the change is in the register and the audit history, and the proposal stays “pending” until AI is back (it is then reconciled from that audit entry the next time they try to accept it, and never marked done without one).
  • Pending proposals cannot be accepted while AI is off, and expire after 7 days as usual.

Looking further adds model calls: one or more steps in which the model chooses lookups, then the answer. The bounds are enforced by the server: at most the call budget (default 6) per question, three rounds, 8,000 characters per result and 40,000 in all, 45 seconds, and the instance’s own token and cost caps, which count the loop. A question that needs no lookup costs one extra short step.

Measured offline on the leftfield question set (74 hand-written questions, 104 persona runs; the model is a script, so call choices are the ideal ones): about 1.0 lookup per question, and about twice the prompt, roughly 4,200 against 2,100 estimated prompt tokens (characters divided by four; the loop’s own step prompts are included). Treat this as the shape, not the price: a real model asks more questions and wordier ones, and your provider’s token counts are the figure that matters. The Admin screen above shows your own spend per question.

Before each release, OTB asks Advisor a fixed set of questions as people with different reach: full reach, one workstream and no access. An answer that shows something the asker could not see stops the release. Proposed changes are checked the same way: a change Advisor must never propose, or one the person cannot make, also stops the release.

Partial approval and what a restricted approver is told

Section titled “Partial approval and what a restricted approver is told”

An approver who reaches only some of a sitting’s changes sees and decides only those, with buttons worded as their own action (“Approve your 2 changes”). Once they have decided everything they can see, the sitting may still be open because others have yet to decide; they are told “Waiting on other approvers”, with no count and no detail. That the sitting stays open is intrinsic to partial approval and is accepted: it is the one thing a restricted approver can infer, and the product does not try to disguise sitting state. The sitting’s justification and decision note are not shown to them, and nothing says they have been left out.

  • Advisor reads only what a person sees in full. It is never given the neutral summary lines a limited role sees in place of a record, so it cannot count what is withheld. For a person limited to their own workstreams, risk, issue and benefit counts and totals come from the records they can see and are described as “your reach”.
  • A plan record the person is not shown answers “not found”. Advisor and Suggest answer exactly as for a record that does not exist, where 1.0.4 answered “forbidden” or named it. A client that told the two apart will see only “not found”.
  • Source documents and transcripts. Advisor no longer finds them for a person who has no work of their own, because such a person sits in the programme ring, which a limited role does not read in full. Settings that decide what a role reads are in how a role’s visibility works.
  • Change sittings. Answers about changes use sitting text that is the same for every reader. The index keeps only a sitting’s header (who, when, mode, decision); the changes, justification and decision note are matched to the person asking at the moment they ask. Change sittings are used as source material only for a question about changes.
  • Rebuild the index after upgrading. Open Admin > Advisor > Index and select Rebuild index (unavailable while AI is switched off). Nothing rebuilds it at upgrade, and the index page shows no out-of-date state. An index built on 1.0.4 cannot show a person more than they may see, because every hit is checked against the asker’s visibility and rendered from live data when it is served. Change sittings already in the index keep their full text there, used for ranking and full-text statistics, until the sitting next changes or you rebuild.

Where a figure is limited to what the person can see, Advisor says “In your role you can see N” before it. It should not call that figure a total, and it should not say the programme has no more. The model still sometimes writes “in total” or “that is all” beside such a figure, and a figure that says so when it is wrong is a defect.

  • A guard on the answer. Before an answer is shown, Works looks for a sentence that calls a reach-limited figure a total (“in total”, “a total of”, “that is all”, “that is everything” and similar) and rewrites the phrase to name what the figure covers (“in the part of the programme you can see”). A sentence that also states a whole-programme figure is left alone. What cannot be rewritten safely is not guessed at: a fixed note is added, “This figure covers only the part of the programme you can see.”
  • Ordering. A record whose whole label appears in the question is placed first among the records the model reads, then records of the kind the question asks for, then the index’s own order. Records are only moved; none is added or removed.
  • What is still possible. A model may produce an overclaim in words outside the guard’s list. It is counted and the list grows when it does. Answers are not wrong about what a person can see; the wording may overclaim scope.