Discovery · Trust Addendum

This document supplements the flowscope Security and Trust Overview with the controls specific to flowscope Discovery: a time-boxed engagement during which a small, opted-in cohort of customer employees runs flowscope capture software on their workstations so that flowscope can map how work actually flows through the business and propose candidate workflows for automation. Discovery is the observation phase: the capture software reads how work happens and takes no action on the participant's machine. Automation, where a customer proceeds to it, is governed separately by the Workflow Execution Addendum.

Engagement scope

Discovery runs against a named cohort of employees agreed in advance with the customer, for a contractually bounded period typically days or weeks. The cohort, the period, and the goal of the engagement are documented before any capture software is installed. Capture stops when the engagement ends, and the capture software is designed to be removed by the employee at any time without administrator intervention.

Restricted Data

Certain categories of regulated data are excluded from Discovery scope by contract under MSA §6.4 and cannot be processed by the capture software without a separate written addendum signed by both parties before deployment: protected health information governed by HIPAA, payment card data subject to PCI-DSS, Social Security numbers and other government-issued identification numbers (beyond the high-confidence numeric patterns the on-device redaction layer masks at the point of capture), financial account numbers, and biometric data of any kind. The customer is responsible for implementing the technical controls necessary to prevent the capture software from surfacing any of these categories during the engagement. Where an engagement is likely to touch protected health information, a HIPAA Business Associate Agreement is executed before deployment; for other regulated categories the parties execute the corresponding addendum during onboarding so that the right scope, retention, and processing terms are in place before capture begins. Engagements likely to touch any of these categories should be raised at the first call to legal@flowscope.com.

Capture surfaces

Two surfaces operate on the participant's machine: a native desktop application for Windows, and a browser extension for Chromium browsers such as Microsoft Edge and Google Chrome. Depending on how the customer manages its fleet, each is either deployed centrally through the customer's device and browser management or installed directly, with the extension also published on the Chrome Web Store, and both are signed by flowscope. Both authenticate to the customer's Discovery tenant with a per-device credential that is established only when the participant pairs the surface, after signing in with the work account their admin invited, and that the customer can revoke at any time, and both apply the same capture boundary described below. Neither surface records audio, video, or webcam input; the capture model is based on accessibility-tree and page-interaction events, together with the technical metadata of the web requests in-scope applications make (method, address, and response status, never the contents).

Still screenshots are off by default. They are enabled only by contract, for a named narrow set of applications where other capture methods are not available, and only where the customer authorizes them. Text derived from an authorized screenshot passes through the same server-side redaction layer as all other captured content.

Scope controls

Five controls operate together to bound what the capture software records and what subsequently leaves the participant's device: a customer-controlled allowlist of applications and domains, a categorical denylist that overrides the allowlist in regulated contexts, authentication-token stripping applied to captured URLs at the point of capture, a per-file decline window that lets the participant mark any file detected inside an allowlisted application personal before its contents leave the device, and a participant-accessible start/stop control surfaced through a persistent system-tray indicator. The participant start/stop control ships enabled by default; its availability is a customer configuration decision. The five together form the live technical posture through which flowscope minimizes the capture of personal data, operating alongside the contractual redaction obligations of MSA §6.7; each is described in detail in the sections below.

Capture boundary

What leaves the participant's machine is bounded at source by two mechanisms applied before any event is transmitted.

• The first is a customer-controlled allowlist of applications and web domains, configured per organization by the customer's admin in the Discovery dashboard. Activity outside the allowlist produces no event content of any kind: no application identity, no window titles, no keystrokes, and no values. While a participant is actively working outside the allowlist, the capture software records a content-free presence marker carrying the span of time covered and one fact of shape: whether the foreground software was a web browser. The customer can see how long someone was active outside the captured scope, and whether that time was in a browser, but never which application, site, or page it was or what it involved. Separately, when the capture software encounters an application or domain the admin has not listed, it reports only the bare identifier of that application back to the dashboard's review queue, carrying no usage timing, no duration, and no captured content, so that the admin can decide whether to bring it into scope.
• The second is a categorical denylist that overrides the allowlist regardless of how the customer admin configures it. It blocks capture from seven categories: banking, brokerage, and consumer payments; healthcare portals, electronic-health-record vendors, insurers, and hospital systems; password managers; encrypted messengers; consumer and personal email; legal research, court filing, and case-management portals; and government services portals. In addition, content-level drops apply regardless of the allowlist: they exclude private and incognito browser windows and strip authentication token parameters from URLs. The customer's admin can extend the denylist with categories specific to their business, but neither the admin nor flowscope can shrink it below the default.

What never leaves the device

The capture software is designed so that certain inputs cannot be transmitted at all, regardless of allowlist configuration. Password fields are dropped at the input layer on both surfaces. Token-bearing URL parameters are stripped before any URL is sent.

Per-file decline window

Documents opened inside an allowlisted business application are captured by default on detection of a file open or document interaction. At detection the capture software shows a notification on that device and lists every detected file, with the time each has left, so the participant can mark a file personal before its contents leave the device. A file marked personal leaves no record of any kind, neither its contents nor any metadata. For a file that settles as work, the capture software records file-open metadata: a salted file identifier and a salted identifier of the parent folder, the file name, file type, and file size, the application in which the file was opened, and the work classification the file reached, with file names redacted by the server-side layer described below. While a file is still within its window, that metadata is held on the device and is sent only if the file settles as work. Applications and domains on the categorical denylist never reach this detection step at all.

On-device PII redaction

Before any captured content leaves the workstation, it passes through an on-device redaction layer that masks standard PII categories (such as payment-card numbers, bank account identifiers, and government-issued identifiers) using format and checksum validation. The same redaction rules run on both the desktop application and the browser extension, so comparable content captured through either surface is redacted to the same standard. Only content that has passed the on-device layer leaves the device, and flowscope does not reconstruct redacted values on the server.

The on-device layer is rule-based and is not designed to cover free-form personal data such as personal names or postal addresses; those entities are handled by the server-side layer described below. Customers whose workflows surface large volumes of such fields are also advised in onboarding to weigh the allowlist accordingly.

Server-side PII redaction

Before any captured content is persisted, it passes through a server-side redaction layer using Microsoft Azure AI Language (PII detection). This layer is always on and is applied to every Discovery deployment under MSA §6.7(b); it covers a broader set of named entities than the on-device pass, including personal names, organization names, postal addresses, dates of birth, and the other entity categories Azure AI Language is configured to detect. Identified entities are replaced with type-tagged placeholders before the content is written to durable storage and before it is transmitted to any third-party AI API provider. The set of entity categories Azure AI Language can detect is documented publicly at learn.microsoft.com; the subset flowscope has enabled in the server-side layer for a given engagement is maintained by flowscope and is made available to the customer in writing on request. flowscope does not perform a reconstruction step from placeholders back to the original text.

Where Captured Personal Data cannot be isolated for redaction without deleting the surrounding record, the affected record is deleted in its entirety rather than retained. Both the on-device and the server-side layer are rule-based or model-based and therefore probabilistic; complete elimination of personal data is technically infeasible given the nature of the capture, a limitation both parties acknowledge under MSA §6.7(g), and the posture flowscope maintains against it is the combined operation of these two redaction layers together with the five live scope controls described above (the customer allowlist, the hardcoded denylist, authentication-token stripping, the per-file decline window, and the employee start/stop control).

Logic extracted from work files

When a work file is ingested, flowscope reads its bytes once during processing, runs an automatic redaction pass that removes detected personal-data entities before anything is stored, and does not retain the original file. Where the same file is encountered more than once across the engagement, flowscope may retain successive versions of the extracted logic so that changes to a process over time can be analyzed. The extracted logic is Customer Data owned by the customer under MSA §4.11, is processed only to deliver the engagement, and is deleted or returned on the terms in the Retention section below.

No training use of captured data

Captured Workflow Data, including any Captured Personal Data that survives the redaction pipeline, is never used to train, fine-tune, or otherwise develop any AI or machine-learning model, and is never incorporated into any general-purpose or third-party AI training dataset. flowscope contracts with each AI API provider under terms that disallow retention of prompts or outputs for the provider's own training; the OpenAI account flowscope uses for Discovery analysis runs on Zero Data Retention. This obligation is set out in MSA §6.7(d) and survives termination of the engagement.

Pseudonymization of participant identifiers

Each in-scope employee is identified within Customer Data by a pseudonymous User Id, and each in-scope device by a pseudonymous Device Id. The User Id is derived under a per-organization salt held by the customer. flowscope holds a copy of that salt only during setup, while devices are being added and paired and before any capture has begun, and destroys its copy the moment the engagement admin starts capture for the organization. Capture does not begin on any device before that point. flowscope therefore never holds the salt and captured activity at the same time: every item of Customer Data it receives is recorded after its copy of the salt is gone, so it cannot reconstruct the relationship between any User Id and the corresponding employee identity without the customer-held salt.

Participant transparency

On the participant's own machine, the capture software shows the current capture state, the allowlist and denylist that apply to them, and a recent record of what has been captured. The capture state is shown through a persistent Windows system-tray indicator, visible whenever the agent is running, so the participant always knows whether capture is on or off without opening the application. A participant start/stop control is reachable from that indicator; it ships enabled by default, and its availability is a customer configuration decision. Where the control is enabled, the participant can pause and resume capture at any time. Uninstalling the software stops all transmission permanently. Capture begins on a device only once the engagement admin has started capture for the organization, the same point at which flowscope discards its copy of the per-organization salt. A further per-device gate applies first: on first launch the capture software presents a click-to-accept End-User License Agreement, and capture does not begin on a device until the participant on that device has accepted it. Acceptance cannot be bypassed or pre-accepted on the participant's behalf. flowscope provides the EULA text and the click-to-accept tooling; legal responsibility for workplace-monitoring disclosure and any employer-side consents remains with the customer. flowscope maintains a log of acceptances available to the customer on request, and the customer remains responsible for informing the cohort that capture is taking place and for providing whatever workplace-monitoring notice or consent applies in the participant's jurisdiction before installation.

Tenant separation

The Discovery dashboard and the Automation control panel are operated as separate deployments. A grant to operate Discovery for a customer does not extend to that customer's Automation tenant, and vice versa; the two products are integrated commercially but not through a shared session.

Retention

The captured event stream and the derived process model follow the platform retention policy described in the overview. The customer may at any time request deletion of an individual participant's contribution; on request, flowscope removes that participant's raw event records, any derived structures attributable to them, and the corresponding entries from backups within their next rotation cycle. Aggregate process models that no longer identify the participant are not affected by such a request, unless the model itself is the customer's deletion target.

Legal review

The controls described above represent flowscope's designed posture for Discovery. The specific category lists, redaction tiers, retention defaults, and consent text are subject to legal review per customer and per jurisdiction before an engagement begins, and the contractual data-processing agreement governs in case of conflict with this document.