The in-app AI assistant

Every engagement has a chat assistant. Ask it about the engagement’s model, the gaps, the standards in play, or what a recommendation is based on.

What it’s grounded in

The assistant answers from the engagement’s own model and the standards library — retrieved semantically for your question, not the whole graph. It’s a reasoning aid over what’s in the engagement, not a general chatbot.

It suggests, it doesn’t write

The assistant can propose things — a maturity score, a clarification, a draft — but nothing it produces is written to the model automatically. Proposals go through the same review as any candidate. Maturity scores in particular are always applied by a person.

It’s logged separately

Every exchange with the assistant is written to a separate, immutable chat audit log — distinct from the main model audit trail. This is deliberate: a client asking “what did the AI touch?” gets an answer that includes what was asked of the assistant, not just what changed in the model.

What reaches the language model

Your messages, and the earlier messages in the conversation, are sent to your deployment’s language-model provider to generate the reply. Before content goes out, personal names in the retrieved evidence and in stakeholder records are pseudonymised — replaced with stable placeholders and restored in the answer. This is best-effort (a pattern heuristic, not a named-entity model), not a guarantee. A few high-level capability names are sent as-is.

What to keep out of it

Don’t paste confidential material or personal data into the assistant that isn’t already in the engagement — it’s a reasoning tool, and your text leaves to the model provider. If your engagement data can’t be shared with a third-party model provider at all, that’s a deployment-level constraint to raise before the engagement, not something to work around in chat.