Actspan Product data and pilot boundaries
This page explains where data can go on the documented Actspan paths. It is separate from the public website privacy notice. Before a design-partner trial, agree on the exact deployment, participants, sample data and records to retain. Use synthetic data until that agreement is in place.
Before you begin
Identify the provider, tool endpoints, local workspace and optional portal that will receive records. Expected result: the workflow owner can explain each data destination and the controls that still need deployment-specific verification. The release matrix identifies the qualified paths; this page does not add a security certification.
Where workflow data goes
| Destination | Data that can reach it | What to decide before a trial |
|---|---|---|
| Model provider or configured gateway | The mediated request, including selected messages, context, tool definitions and tool results used in follow-up requests | Provider account, endpoint, permitted data and applicable provider retention/settings. Local evidence settings do not change the provider's own handling. |
| Your tools, services and MCP servers | Tool arguments, authenticated context and requests sent on their selected paths | Endpoint owner, authorization, permitted records and independent service logs. An external tool may send data to another service. |
| Local machine | Workspace/state files, execution records, checkpoints, tool receipts and available inputs/outputs | Device access, filesystem permissions, disposable ledgers and which files may be shared. Local records can contain sensitive workflow data. |
| Optional portal/control API | Run identity, source/configuration context, decisions, usage and event/input/output records according to reporting mode | Hosting location, workspace access, reporting configuration and records actually received. Inspect a synthetic run before sending customer data. |
| Shared evidence export | The files selected for that export, with missing records reported | Review the archive contents separately. An export is not a complete description of everything previously sent to the portal or provider. |
Portal reporting is explicit
--no-portal on the native CLI path avoids portal requests for that run; the
provider and configured tools can still be contacted. Required portal reporting
fails if shared evidence cannot be accepted. Best-effort reporting can leave a
local outbox record for a later actspan portal sync. Review queued records
before syncing them.
The native reporter's ACTSPAN_CLOUD_SYNC_MODE selects metadata, redacted
(the default) or full. Metadata mode summarizes request/output content while
retaining operational context such as source, target and identity metadata.
Redacted mode masks recognized sensitive keys and selected text patterns; it
does not guarantee removal of every secret or personal detail. Full mode can
send complete supplied content. These settings govern that reporter, not all
portal APIs, browser uploads, provider traffic or local files. Confirm the
installed runtime and actual received payload before relying on a setting.
Credentials and people
Keep provider keys and service credentials out of example YAML, committed files and support messages. Local provider access uses the configured secret references; a native CLI installation does not create a hosted account. Hosted execution can use the deployment's runtime secret store and requires its own configuration.
Portal access uses the selected deployment's authentication and workspace roles. Agree on who can run, review, administer and inspect records, and test denied access as well as an allowed review. Local CLI reviewer names are audit labels. The published browser approval recording is historical core 0.1.2 evidence; production OIDC, reviewer roles and support access require qualification for the delivered deployment. See portal setup.
Retention, deletion and support access
There is no universal pilot retention period or hosted-region commitment on this page. Before onboarding, record the responsible operator, storage region, retention period, backup handling, deletion process and who can access records for support. A local file deletion does not delete records already held by a provider, tool service, portal, outbox copy or backup. Verify each destination's deletion behavior separately; do not promise automatic end-to-end erasure.
Send an initial enquiry to info@actspan.com with a workflow description and synthetic examples. Arrange any support access and data transfer explicitly. The first session should produce an agreed data-flow checklist alongside the trial outcomes; unresolved items remain visible before a longer pilot or production rollout.