Privacy

This page is for the developer installing Docent, and it describes what the code does. The customer-facing statement is at usedocent.com/privacy, and the vendors are listed at usedocent.com/subprocessors.

Two kinds of people

Docent is installed by a company into its own app. That company is the customer and signs in to the Console. The people using that app are end users. End users never create a Docent account and never give Docent a password, and nothing about them is shared between customers.

What the guide sees

The accessibility tree of the page the user is on: the roles, names and states of controls, their positions, the current route and the scroll position. It does not take screenshots. Changes to that tree are sent so the guide can answer about the page in front of the user.

What is masked before anything leaves the browser

Before a snapshot is sent:

• Input values are never captured. The snapshot carries roles, accessible names, states, rectangles and the route, and no field contents.
• Every data-guide-mask subtree is removed, its accessible names replaced with a placeholder. The mask travels through labels, so an element that draws its name from inside a mask is masked too. data-guide-readable re-exposes one element inside a mask, and nothing is readable by default.
• Email addresses, card numbers and phone numbers are replaced wherever they appear, including in the route and its query string.

All of this happens in the browser, before egress. It fails closed. If the masking step throws, the capture returns nothing and nothing is sent.

The microphone

The guide never opens a microphone until the end user agrees to it in a prompt that says what will happen, and the prompt comes before anything that leads to a microphone rather than after the browser's own permission sheet. After each turn the microphone closes. A visible indicator is shown while it is open. Declining leaves the guide fully usable by typing, because text mode is a full peer of voice mode.

Consent is recorded per app and per user, so it is asked once rather than on every reload.

What is stored, and for how long

Docent stores the masked text of each turn, which tools the guide used, how long the turn took, the routes a session visited, and a small set of named events such as whether the guide was opened, muted or dismissed. Event names come from a closed list and carry no content; a route is already redacted, and an anchor is a data-guide token you wrote.

For a crawl, Docent stores the job's URL and its page counts alongside the chunks it extracted, and nothing else about the site.

Each environment has its own retention period, a whole number of days from 0 to 90. Zero keeps nothing once the session ends. Automatic deletion at that boundary is not yet running; until it is, deletion happens on request.

Audio

Docent stores no raw audio. Voice is processed by the vendor named on the sub-processor list under that vendor's API terms, and where the vendor offers a retention control it is switched off. Docent's own store is the system of record. Perception snapshots never go through the voice vendor; they go to Docent's own service over its own connection.

What is never done

• No customer data is used to train models.
• No end-user data is shared between customers.
• End users are identified only by the id your app passes to the guide. A host may additionally sign that id so the session is marked verified, which is what cross-session memory and handoff attachments require.

The overlay in your app

The guide overlay sets no cookies. It renders inside a Shadow DOM root, so your CSS cannot leak into it and its styles cannot leak out. The one thing it keeps in the browser is per-user convenience state under the docent: prefix in local and session storage: where the mascot was dragged to, whether microphone consent was given, whether the guide has been seen, and the session's dismissal and nudge counts.

What you control