Pipeline sources

The ticket pipeline can read more than the ticket. For each ticket it can also look up records in the systems you already keep: your IT documentation, any MCP source, and the connectors of a StackJack connection such as IT Glue or Hudu. You choose which of these sources each stage of the pipeline reads. This page explains the choices, what the pipeline reads and never reads, and where the records show up.

Before you start: you need the Administrator role to change a source on MCP Sources. The Administrator or Q-Director Configuration role can use the Pipeline sources table on the Research & Docs tab of Q-Director Settings. A source that signs in as each person cannot be read by the pipeline, because nobody is signed in when it runs; Set up a service connection shows what to use instead.

What a pipeline source is

The pipeline only reads. It never changes a record in any of these systems.

The stages

A stage is a step of the pipeline. Each source has one switch per stage. A new source starts with every stage off, so nothing is read until you turn a stage on.

For a documentation row, the Qubit chat cell now decides whether Qubit chat searches your documentation (Enable documentation search in RAG pipeline must be on too), and it started with the value Include in chat responses had when the table was created. If Qubit chat stopped citing your documentation after that change, the cell is off: check Qubit chat on a documentation row and save.

Turning on Autopilot decisions carries a warning: an unattended decision can be steered by text that comes from another system, so the source feeds that stage titles only. Records never count as evidence for a decision.

A stage that has no AI model to call tools (Analysis, Q-Director and Autopilot decisions) can only use a recipe. The switch stays gray, with the reason, until the source has one.

Set up a service connection

The pipeline runs without a person, so it reads a source with one shared key, not with each person's own sign-in. A source is eligible when it is a tenant source that uses no sign-in, an API key, a client ID and secret, or OAuth client credentials. A per-user source, the StackJack per-user preset and any source that needs a browser sign-in are never read by the pipeline. The source's card says so: "It signs in as each person, so the unattended pipeline cannot use it. Add a service connection." For a source that needs a browser sign-in it says "It needs a browser sign-in, which an unattended run cannot complete. Add a service connection."

To add one, open MCP Sources, edit the source and choose Add a service connection. The New MCP source card opens ready for a tenant source with an API key. Paste the key, save, and then turn on the stages. A service connection is for the pipeline only: it does not appear in any chat, channel or picker list.

You can also use the connection Ticket Autopilot already has, the StackJack (Autopilot) source set up on Autopilot settings. Its card shows the warning This connection can also change records, because the key may be allowed to write. The pipeline still only reads: QuantumOps never calls a tool that changes a record, and never reads passwords, credentials, secrets, one-time passwords or API keys, whatever the key allows. The key's own tool selection in StackJack decides which records the pipeline can see, and everyone who works a ticket sees the same records (see Who sees the records).

Choose the stages for a source

There are two places, and they edit the same settings.

On MCP Sources

1. Open MCP Sources and edit the source with the pencil. A card called Use in the ticket pipeline is below Tool policy.
2. Under Stages that read it, check the stages. Qubit chat is listed separately, under People. A gray box carries its reason in the information icon beside it.
3. Fill in Use when. It is one line, up to 300 characters, and the AI sees it, for example "Configurations and runbooks for the client's servers and firewalls". A good line helps the AI choose the source.
4. Choose How it is read: Tools: the model calls read-only tools, Recipe: a fixed fetch built from the ticket, or Both.
5. Under Applies to, limit the source to some clients, categories or ticket types, or exclude some. The default is all of them.
6. Choose Save.

In the sources list, each source shows a badge: "Used by: Research · Autopilot plan", or "Not used by the pipeline".

Advanced: budgets holds the limits that keep a slow source from slowing a ticket down: Recipe calls per ticket, Agent calls per run, Call timeout (seconds) (1 to 30), Records in a prompt, Characters per record, Cache (minutes) (0 means no cache) and Calls in flight. Allowed tools and Denied tools can only narrow what the source and the built-in rules already allow.

In Q-Director settings

On the Research & Docs tab, the Pipeline sources table lists every source in one grid: your documentation first, then MCP sources, then StackJack connectors under their connection. Each row has a switch for the source (On), a switch for every stage, and a Health column. A link on the row opens the source on MCP Sources or in the Documentation Hub. Below 640 pixels wide, each source becomes its own card.

A switch saves nothing by itself. The page says "Unsaved changes to the pipeline sources" and Save Changes writes them together with the rest of the tab. If someone changed the same source on MCP Sources since you opened the tab, the table reloads and tells you, so you never overwrite their edit unseen.

Connect StackJack connectors

On MCP Sources, a StackJack source that uses an API key has a Connectors button. It opens Connectors for the ticket pipeline, a table with one row per connector: the Connector, its tool Prefix, the Connection, the Recipe and a box for every stage.

• Read from StackJack lists the connectors your StackJack account holds, and the connections of each. A connector that has several connections (one per customer, for example) can be pinned to one of them; otherwise the connector's default connection is read. If the key cannot see this list, the page says so and you enter the connector by hand under Add by prefix, with its Connector name and Tool prefix (for example itg_).
• A connector's row shows how many calls it has used in its billing cycle, and Configure shows the allowance and when the cycle resets. That is a call allowance, which StackJack counts for each connector. When a connector's allowance is used up, calls to it pause until the cycle resets, and Health says so.
• Configure opens the same Use in the ticket pipeline card for that connector. Save connectors saves the table.
• The recipe column reads ITGlue v1, Hudu v1, Custom or Tools only. Hudu v1 shows not checked yet until you have run Check recipe on a workspace that has the Hudu connector.

Recipes

A recipe is a fixed set of up to five read-only calls built from the ticket: for IT Glue, find the client's organization, list its documents that match words from the ticket, and read the top two. The two shipped recipes make at most five calls. IT Glue has no full-text search, so a document is found by a word in its name.

The Recipe card shows each step and the worst case: "Worst case: 5 calls for one ticket (limit 6)". A recipe whose worst case is above the limit cannot be saved.

• Check recipe asks the connector. Every tool must exist, be marked read-only by the connector, count as a read in QuantumOps and not be a credential tool, and every argument must be one the connector accepts.
• Test on ticket # runs the saved recipe for one ticket, ignoring the caches, and shows the records, the calls, the time and how much was cleaned. Save the source first.

Match clients to organizations

A recipe that looks up an organization needs to know which organization is which client. Under Client mapping, the pipeline uses the first of these that applies:

1. A mapping you confirmed here. A client can also be excluded, so the source is never read for it.
2. The IT Glue ID on the HaloPSA client (IT Glue only). Autotask and ConnectWise keep no IT Glue ID on a company, so on those PSAs the pipeline goes straight to a mapping you confirmed or to the exact name.
3. An exact name match: the organization's name must equal the client's name, ignoring capital letters. "Contoso" never matches "Contoso Holdings", and two organizations with the same name match nothing. When the connector holds more matching organizations than fit on the first page it returns, nothing is matched either, because a second organization with the same name could be on a later page. Confirm a mapping for that client instead.

Suggest exact-name matches asks the source about each client without a mapping and lists the exact matches; Confirm keeps one. Mappings from the Documentation Hub are shown as suggestions only, because your documentation and your connector can be different accounts. Copilot never uses a name match: a reply a person may send is built only from a mapping you confirmed or an ID.

What the pipeline never reads

Three rules apply to every source and cannot be switched off:

• Credential tools are never called. The pipeline never calls a tool whose name or description says it reads a password, credential, secret, one-time password, MFA code, API key or token. A tool that is reached through StackJack's read-only dispatcher is judged by the description its connection gives for it, and if that description cannot be read the tool is not called. One dispatcher cannot be called through another. That holds even when a rule allows the tool and even when the connector marks it read-only. Tool Governance lists these as Built-in rules. Ticket Autopilot refuses a tool that reads such a value too, but a step a person approved that changes one, such as a password or MFA reset, is not blocked there.
• Credential values are cleaned from what comes back. A field that holds a password or similar value is replaced by a mask, and a record that is a password or one-time-password record is dropped, before any AI, note or panel sees the result. A table that holds a credential word anywhere in it (a password, passphrase, PIN, secret, token, recovery key, Wi-Fi key, API key or a similar word, in the plural too), whether it is an HTML table or a Markdown table written with pipes, has every cell masked except the labels in its first column. The rule reads the table as it is written (Markdown rows with a break or a list in a cell, a quoted reply, rows in paragraphs, an HTML table), and it errs toward masking: it also masks the headings and notes of such a table, the lines of text directly under it, the labels under the first credential label of a label and value table, and, in an HTML message, the sentences just above and below any line that has a pipe in it, such as a status line or a signature, when one of them holds a password word; that is deliberate. A table drawn with other characters than pipes, a cell of dozens of lines in a row the rule cannot join (a first cell of more than 32 lines after a row that ends at a newline), or a second table close under a first one whose header's first cell is broken over several lines, can still leave a value behind, and the key and token patterns and the field and record rules below apply to it as to any text. Text is also stripped of anything shaped like a key or token.
• Excluded clients and ticket types are never read. A client or ticket type that AI Processing excludes (see Q-Director: AI Processing) gets no records from any source, from any stage, including a re-run with chosen sources. If the exclusion list cannot be read, nothing is read.

Everything that is read reaches the AI as reference data, not instructions, in a fenced block, and web addresses are kept only when they begin with http or https. A result too large to return is cut to its preview. No usage cap applies: the per-source limits above only keep a ticket from waiting on a slow system.

Who sees the records

A ticket's records are read once, with the shared key, and everyone who works the ticket sees the same ones. If your StackJack key can reach a record, a technician sees it in the research note and the panels even when their own StackJack account could not. Set the key's tool selection in StackJack to what every technician may see.

The records appear in these places:

• The research note on the ticket in your PSA (HaloPSA, Autotask or ConnectWise), as Related records, when the research output profile includes that section. It is on by default and added to profiles that already include related documentation. A new record alone never causes a new note. See Q-Director: research and documentation.
• The Ticket tab of the browser extension, as Related records, with a link to each record. See The browser extension.
• The Autopilot plan, as a Related record chip that links to the record. See Ticket Autopilot.
• Reply drafts, guides and response templates, which cite up to three.

Run research again with chosen sources

On a ticket's Sherlock Findings card, and on the Sherlock card of the Ticket tab in the browser extension, Re-run research with sources… lists the pipeline sources that are switched on, read with a shared key and apply to this ticket, whatever stages they feed. Documentation follows the Research settings. Check the ones to use for this run only and start the investigation. The chosen sources replace the default set, and the caches are ignored so you see current records. Leave all unchecked to use the defaults. See Sherlock research and live context.

Health and pauses

The Health column and the card show one of Working, Failing, Paused or No calls yet, with the last error in plain words. After three failures in a row a source pauses for five minutes and then tries once; a used-up allowance pauses it until the cycle resets. A slow or cold source never holds up a ticket: the stage goes on without it and the next stage uses it once it is ready. The card also shows the calls in the last 24 hours and 7 days, the errors and the typical time.

Messages you may see

Related pages

• MCP sources: add and manage the sources.
• StackJack: the connection the connectors belong to.
• Tool Governance: the rules, the built-in rules and the audit list.
• Q-Director: research and documentation: the Pipeline sources table and the research note.
• Documentation sources: the documentation the pipeline searches.
• Sherlock research and live context: the research the records feed.