Data Policy

We think a data policy should describe reality, not hide it. Run is designed around collecting as little as we reasonably can while still making the product useful, supportable, and secure.

If we need more data for a specific workflow, we want that choice to be explicit. The goal is operational clarity, not surprise collection.

This is the practical list of data types most likely to touch the system.

• Website and infrastructure logs such as page requests, browser metadata, device information, and security signals.
• Waitlist, contact, or sales information that you submit directly, including your email address and any context you provide.
• Scheduling and meeting metadata when you book time with the Run team through embedded or linked calendar tooling.
• Prompts, tasks, files, links, and notes that you intentionally send into the product or share during setup, demos, and support.
• Operational telemetry that helps us understand failures, latency, feature usage, and abuse prevention.

• Into the infrastructure required to host the site and service.
• Into internal admin or support tools used by the Run team to respond, debug, and improve the experience.
• Into third-party processors that help with things like scheduling, email delivery, analytics, storage, or model access.

We try to keep the chain short and only use providers that serve a clear operational purpose. Our current subprocessors are listed below.

• To make Run work as requested by the user.
• To maintain product reliability, investigate incidents, and keep systems secure.
• To understand aggregate product usage and decide what to improve next.
• To communicate with interested teams, coordinate onboarding, and provide support.

We do not want Run to become an ad-tech machine. We are not building hidden behavioral profiles for resale, and we do not sell personal information to data brokers.

We also avoid collecting sensitive personal information unless the workflow truly requires it and there is a clear reason to process it.

• Contact and sales data stays around while we have an active relationship or a reasonable business need to keep it.
• Logs and telemetry are usually retained for shorter operational and security windows.
• Workspace or workflow data is retained according to the needs of the service, the contract in place, and any deletion request you make.
• Some information may be retained longer if required for legal compliance, dispute handling, fraud prevention, or security investigations.

People at Run may access data when that is necessary to support you, investigate an issue, maintain the service, or review system quality and safety. Access is intended to be limited and purposeful.

If you are planning a workflow with confidential or regulated information, talk to us before rollout so we can confirm whether the workflow is appropriate and what controls are needed.

We work with a small number of carefully chosen partners to deliver Run. Here is who they are and what they do for us.

We believe transparency builds trust. That is why this page is written to describe the data path plainly, including where data may move and which partners help us operate Run.

We are also committed to open sourcing the native tool sets we build. Over time, we want to replace more provider-dependent integration layers with open, native tool sets that we can maintain in public.

Longer term, we hope to explore open sourcing more of the core system as it matures. For now, the native tool sets are the first step in that direction.