<!-- Reviewed 2026-09-07, later (the mode can be chosen before the first message): the
covered chatHost.tsx and conversations.ts changed — the host now holds a mode picked
before a chat exists and carries it into the row the first message mints. NOTHING ON
THIS PAGE MOVES, and that is a finding rather than an omission: this page is about
rating an answer and about the workspace data-control switch. Neither reads the
permission mode, neither is affected by a chat being created with one, and the
refusal-to-send on a failed create is described where the setting itself is —
intelligence/ai-review.md. Two pages covering one file is why this note exists. -->
<!-- Reviewed 2026-09-07 (the mode moved into the composer): the covered chatHost
gained a permission-mode port and conversations.ts a permission_mode column, both
serving the new control beside the message box. Neither touches rating, the
dissatisfaction signal or the consent-gated share offer this page describes —
unchanged, including that consent is still never inferred from wording. -->
<!-- Reviewed 2026-09-05 (the language follows the account, and background AI
work gets a workspace language): the covered GeneralPanel gained a
workspace Language select beside the clock, documented on
administration/workspaces.md. The Data controls consent switch this page
describes is unchanged. -->
<!-- Reviewed 2026-09-05 (permission mode, docs/ASSISTANT-LOOPS.md §2): nothing
this page describes changed. The covered `chatHost.tsx` gained the seam
that decides a held change (Apply / Dismiss) — ratings, sharing and the
consent flow this page describes are untouched. The setting itself is
documented on AI review and assistance. -->
<!-- Reviewed 2026-09-04 (the Build button — docs/design/build-button/README.md):
the covered src/components/chat/chatHost.tsx changed;
the chat host gained the build-flow seams (Templates → "Building a document together"); ratings, sharing and the consent flow this page describes are unchanged. -->
<!-- Reviewed 2026-08-25 (archived-chats filter): nothing on THIS page changed.
The chat host it covers gained two store pass-throughs (a status filter on the
conversation list and a restore-from-archive call) for the rail's new
Chats/Archived filter, documented on the AI assistant page; rating and data
controls are untouched. -->
<!-- Reviewed 2026-08-25 (canonical-keys migration): no user-visible change —
receipts render and survive reloads exactly as this page describes. What
changed underneath: a backfill folded pre-2026 rows onto the one canonical
payload shape, so the legacy-format fallbacks this page never mentioned are
gone from the code paths it documents. -->
<!-- Reviewed 2026-08-25 (residue sweep): no user-visible behavior changed on
this page's surfaces. The one functional fix RESTORES what this page already
documents — the host's apply.run wrapper had been dropping the kit's run
context, so the server-side receipt record on a persisted message (seam 3)
never engaged; receipts now persist exactly as described. Everything else was
deletion of unreachable code and strings. -->
<!-- Reviewed 2026-08-24 (receipt persistence): chatHost's write seam became
one call to the server apply route (the per-kind switch, receipt words
and proof links moved server-side). Ratings, the share-with-Alchex
consent flow and the data-controls switch — what THIS page documents —
are untouched. -->
<!-- Reviewed 2026-08-24 (confirm-kind retirement + dead-weight sweep):
chatHost lost its five confirm-era branches (audits, publish, push-version,
submit) — actions chat could no longer propose since their tools left the
catalog on 2026-08-07 — plus the receipt-detail tier flag and the unused
renderDocDiff port. Ratings, the share-with-Alchex consent flow and the
data-controls switch — what THIS page documents — are untouched. -->
<!-- Reviewed 2026-08-24 (chat approval retirement / auto-apply): chatHost lost
the ports that only served the approval cards — the template preview, the
guardian decision telemetry, the teams picker and the register-binding
reads — and proposals now execute on arrival, with audits/publishing
waiting for a typed go-ahead. Ratings, the share-with-Alchex consent flow
and the data-controls switch — what THIS page documents — are untouched:
a reply still takes one rating, and consent still gates the share. The
new behavior is documented in AI review & assistance. -->
<!-- Reviewed 2026-08-26 (the Governance Automations feature deleted, owner
directive): chatHost LOST that runApply case again, and the
create_automation tool left the chat catalog with the feature it wrote
into. Ratings, the share-with-Alchex consent flow and the data-controls
switch — what THIS page documents — are untouched: a reply still takes one
rating and consent still gates the share. The note below records when that
card arrived; it is history now. -->
<!-- Reviewed 2026-08-18 (create_automation approve-card): chatHost gained one
more runApply case (proposing an automation posts its definition on
Approve). Ratings and data controls — what this page documents — are
untouched; a reply carrying the new card still takes one rating and the
card keeps its own decision, exactly as written. The card itself is
documented in AI review & assistance and Automations. -->
<!-- Reviewed 2026-08-18 (Documents becomes its own settings section): the
covered GeneralPanel lost the document style sheet, which moved to
Settings → Documents. This page documents conversation-sharing consent,
which is untouched; the sheet is documented under Administration →
Workspaces. -->
<!-- Reviewed 2026-08-17 (organization document style): the covered
workspace/settings code gained the org-style cascade — documents render
`override ?? organization style ?? app default`, and Settings → General
gained a Document style section. Nothing THIS page documents changed
behavior; the feature itself is documented under Administration →
Workspaces → "The organization's document style" and Authoring →
The editor → "The document font". -->
<!-- Reviewed 2026-08-24 (prompt cleanup after the approval retirement): the
covered chatHost's follow-up prompt wording changed (typed answers instead
of tapped options). Ratings and data controls — what this page documents —
are untouched. -->
Every answer the assistant gives can be rated, and a conversation that went wrong can — if your workspace allows it — be shared with the Alchex team. This page explains both, and exactly what leaves your workspace in each case: for the feedback signal, no content at all; for a share, only what you explicitly agree to send.
Telling the assistant an answer was wrong
There is nothing to click. Say it — "that's wrong", "that's not what I asked", "you misunderstood" — and Alchex records that the reply missed. There are no thumbs to hover for and no control to find: you were going to type that sentence anyway.
It only hears you complaining about the answer. Correcting the subject — "no, use the other supplier", "change it to quarterly" — is ordinary work, not a complaint, and is never recorded as one. Nor is talking about things going wrong in your own organisation: "if a change goes wrong we revert it" is your procedure, not a verdict on the reply.
What gets recorded is a content-free signal: which answer and that it missed — never what was said, and never which records the answer cited (see References for how citations render and where their chips lead). It is what tells Alchex where the assistant underperforms without exposing what you were talking about.
There is no "that was good" to record, because nothing would read it. Say it if you like — the assistant is listening — but only the misses are kept.
What happens after you say an answer was wrong
The signal is saved. Then, only if your workspace admin has turned on conversation sharing, a small offer appears under the message: Share this conversation with Alchex to improve the product, next to a Dismiss button.
- The offer is just an offer. Nothing opens on its own, and dismissing it leaves only the saved rating.
- If sharing is off for your workspace — the default — no offer appears at all.
Sharing a conversation
Choosing the offer opens a dialog that lists, before you confirm, exactly what sharing sends:
- the messages in this conversation so far;
- the note you add in the dialog (optional).
Nothing else is shared — no other conversations, no documents, no records. Share and No thanks are equal choices, and closing the dialog any other way sends nothing. Once shared, the copy the Alchex team receives expires automatically after 90 days.
If the admin switches sharing off between the offer appearing and you confirming, the share is refused and the dialog says so plainly — nothing is sent. Sharing covers the conversation only: a document the assistant edited during it is never sent with it, whatever state that document is in.
The workspace switch
Sharing is governed by one switch in Settings → General → Data controls, visible to workspace admins: Allow members to share individual conversations with Alchex to improve the product.
- It is off by default for every workspace. Nobody is opted in.
- While it is off, members never see the share offer, and the server refuses any share request outright.
- Turning it off later stops all future sharing immediately; it is enforced on the server, not just hidden in the interface.
Where your conversations live
Assistant conversations stay in your workspace, and each one is private to the member who had it — other members cannot open your chats, and neither can Alchex.
Some cards in a conversation show your own records — the card that asks where you keep something lists your registers so you can pick one, each with the same status the library shows: whether anyone has confirmed a record in it. That list is read by the app on your behalf at the moment the card is drawn, from the records your teams can already reach. The assistant is not handed it; it learns which register you meant when you choose one, the same as any other answer you give it.
What Alchex learns from is aggregated and anonymised: counts, categories and trends of where answers fall short, computed across many workspaces, with any pattern specific to a small group of users or organisations suppressed entirely. No one at Alchex reads customer conversations to produce these patterns.
The single exception is the explicit share described above — a deliberate action by the member who owns the conversation, available only in workspaces whose admin has enabled it. If you never share a conversation, no person at Alchex ever sees one.
Records the assistant names in an answer
When the assistant refers to one of your records it links to it, and the link carries the record's name. Two rules decide whether you see that name.
In your own conversation, you see the names of records you could open anyway. Owning a conversation is not the same as having access to everything it mentions: the assistant can answer about a record on a team you are not on. Where that happens the link is replaced by a restricted record — no name, no identifier, and nothing to follow. The sentence around it is left exactly as written, so you can still see what was said.
A public share link never shows a name. A conversation you publish by link is readable by anyone who has the link, with no sign-in, so there is no way to tell what that reader is entitled to. Every record reference in a shared conversation becomes a restricted record, whoever opens it — including you. If a link needs to show what a record is, describe it in the conversation rather than relying on the reference.
In both cases a hidden record looks identical to one that no longer exists. That is deliberate: telling the two apart would itself say that the record is real.
- AI review and assistance — what the assistant can do, and the actions on each reply.
- Permissions — who counts as a workspace admin.
<!-- Reviewed 2026-09-08 (a record link opens the preview dock): the covered
chatHost.tsx changed at `renderLink` only — a link to one of your own
records now opens a read-only panel beside the conversation instead of
navigating. That is described on the AI review page, under "Reading a
record beside the conversation"; nothing on THIS page changes, because
what a reference shows a reader — and what a shared link withholds — is
decided by the resolver, not by where the record is rendered. -->