Privacy Policy

This privacy policy applies to all applications, services, and websites offered by The Resonance Labs LLC, a Washington limited liability company (referred to as “us,” “we,” “our”), which applications, services, and websites will be collectively referred to as “#Let's Data” in this privacy policy. By using #Let's Data, you agree to be bound by the terms of this privacy policy.

You can withdraw from this agreement by sending an email with a request to terminate your agreement with us at

#Let's Data is a cloud infrastructure product that simplifies how you process, analyze and transform data. To make this happen, we collect certain information from you and your devices, use the information in providing data processing services, allowing users to manage data artifacts on #Let's Data, to provide secure and relevant experiences to the users and to charge the customers for the services rendered.

Your privacy is important to us. We recognize your right to confidentiality and are committed to protecting your privacy. We use the information that we collect to provide you with the best experience possible in offering an end to end data processing software as a service offering and to communicate with you about our products and services.

The data collected by #Let's Data varies depending on how you use #Let's Data. Let's look at the different data collection usecases as follows:

1. Information We Collect for Analytics

1.1 Analytics Data

We collect the device, environment and usage information from the HTTP requests to our service - including but not limited to: the Internet address from which you access #Let's Data, date and time, the Internet address of the website from which you linked to #Let's Data, the search texts, buttons pressed, links clicked and the page's screen time and the browser and operating system used (“Analytics Data”). This information is used to better design the customer experience, diagnose and debug technical issues, secure the systems against abuse and to be in compliant with the rules and regulations.
In most cases, this information is anonymized and not associated to the individual users. However, in some cases, data such as ip address may be used for the signed-up user and may be shared with third parties for the purposes of customer experience and compliance. For example, IP Address at signup are shared with our external billing system for taxation. You can learn about our external billing system, Stripe's privacy policy.

2. User Accounts

2.1 Signup Data

When setting up an account with #Let's Data, a user will share their full name, their email address, their phone number, the name and the address of the company that they work for, and their credit card details ("Signup Data"). "Signup Data" (with the exception of credit card details), is recorded in a database and is used to personalize a user’s experience on the #Let's Data services.

#Let's Data never stores / processes a customer's credit card details. Our signup web page communicates securely with our external billing system, Stripe, to securely store the credit card details in Stripe systems. This generates a unique payment identifier in Stripe for the credit card and billing details which is then stored and used by #Let's Data systems for payment processing. You can learn about our external billing system, Stripe's privacy policy. We also describe the details about the data we share with Stripe in a later section.

"Signup Data" also contains the user's login name and password. A password is initially generated by Let's Data authentication provider (AWS Cognito) and communicated to the user in an email. The user is required to change their password on first login. During this and after this, the login page is managed by AWS Cognito and #Let's Data does not handle user passwords in this scenario. When logging in using the CLI, #Let's Data CLI will get the user's password to call AWS Cognito for login credentials. We do not store a user's password. You can read about AWS's Data Privacy

2.2 Dataset Data

A logged-in user can create, update and delete datasets for processing on #Let's Data. This generates a number of auxilliary types of data (collectively called "Dataset Data") that are discussed as follows:

Dataset Configuration Data: When a user creates a dataset for processing on #Let's Data, they define a configuration that tells #Let's Data the read, write and error details on how to process the data. In addition, they share code that Let's Data executes to process the data on behalf of the user. The user's code and configuration details collectively are called "Dataset Configuration Data".
User's Read Connector Data: When #Let's Data executes a dataset task (i.e. processes user data), it reads the data that needs to be processed from the read connector. Any bytes / data read from the read connector as part of the dataset's processing is "User's Read Connector Data" - this is essentially customer data and it is not any configuration or #Let's Data related data. Ideally #Let's Data would want to be opaque to this data, process it using the user code and not store any data in its systems. However, a small amount of the read connector data does get into document identifiers, exceptions and logs - (these could primarily be from the user code). We take utmost care to make sure that any user data does not get stored unnecessarily in #Let's Data systems.
User's Write Connector Data: When #Let's Data executes user code, the user's code returns a write document that needs to be written to the write destination and is called "User's Write Connector Data". This is essentially customer data and it is not any configuration or #Let's Data related data. Ideally, #Let's Data would want to be opaque to this data, write it to the write destination and not store any data in its systems. However, a small amount of the write connector data does get into document identifiers, exceptions and logs - (these could primarily be from the user code). We take utmost care to make sure that any user data does not get stored unnecessarily in #Let's Data systems.
User's Error Connector Data: When #Let's Data executes user code, record errors can occur. #Let's Data creates error documents for these error records and are called "User's Error Connector Data". The error records can have metadata about the data (such as file names, file data offsets etc) and some data about the error - such as subset data from the read connector data. This is essentially a write document constructed from a combination of the user's code and #Let's Data code. Ideally, #Let's Data would want to be opaque to this data, write it to the error destination and not store any data in its systems. However, a small amount of the error connector data does get into document identifiers, exceptions and logs - (these could primarily be from the user code). We take utmost care to make sure that any user data does not get stored unnecessarily in #Let's Data systems.
Dataset's Task Data: When #Let's Data initializes and processes a user's dataset, it will generate internal objects such as tasks that represent a fixed amount of work that needs to be done. It then executes that fixed amount of work and monitors it through its execution. This generated metadata for a fixed amount of work and its execution is called Dataset's Task Data. This metadata does contain identifiers from the Read/Write/Error user data, but beyond that, it should not reference any user data.
Dataset's Log Data: #Let's Data and user code both log the execution details using the #Let's Data Log interfaces. This generates "Dataset's Log Data". #Let's Data Logs try not to log any user data in its logs and we expect the same from the user code. This log data is stored in #Let's Data systems and is available for troubleshooting and diagnosis to #Let's Data team and the customer.
Dataset's Metrics Data: #Let's Data and user code both emit execution metrics using the #Let's Data metrics interfaces. This generates "Dataset's Metrics Data". #Let's Data metrics do not have any user data (Read/Write/Error) they do have the user and dataset identifiers for metrics lookup. This metric data is stored in #Let's Data systems and is available for troubleshooting and diagnosis to #Let's Data team and the customer.
Dataset's Metering and Usage Data: #Let's data uses different resources to process a user's dataset. Some of these resources are user specified, others are created internally by the #Let's Data infrastructure. #Let's Data records the usage of each of these resources into what we call "Dataset's Metering and Usage Data". This data is used in billing to determine the charges accrued by a dataset's processing and would ultimately be billed to the customer in the next invoice. This data is available to the customers for transparency around costing and is also shared with external billing systems (Stripe) that would be generating the customer's billing invoice and charging the customer's credit card.
#Let's Data Internal Data: In addition to the different types of data mentioned above that are accessible by the users, #Let's Data generates a number of internal databases, queues, storage, compute processes, code artifacts etc. that have their own set of data and metadata that may reference the different data types mentioned above. This is collectively called "#Let's Data Internal Data". We make sure that there is a transparency around this and that the details are shared with the customer (as much as possible without compromising intellectual property). We also make sure that this data has a defined lifecycle which is known to the customers so that the customers know when this data is created and how it is destroyed.

2.3 Company Users Data

Logged-in users on #Let's Data can belong to one of the following security profiles: TenantAdmin, TenantUser. A user that belongs to the TenantAdmin security profile can additionally create, delete, update users in their company / organization. This generates "Company Users Data" which includes data for each user in the Company including the user's "Signup Data" and "Dataset Data".

3. Personal Information from Minors

We do not offer our services to, or target, persons under the age of 13. In compliance with the Children’s Online Privacy Protection Act, we will remove any information we receive from people we believe to be under the age of 13 from our database and cancel any corresponding accounts.

4. Data Usage

Collectively, the different types of data discussed above, including “Analytics Data”, “Signup Data”, “Dataset Data”, “Dataset Configuration Data”, “User's Read Connector Data”, “User's Write Connector Data”, “User's Error Connector Data”, “Dataset's Task Data”, "Dataset's Log Data" "Dataset's Metrics Data", "Dataset's Metering and Usage Data", "#Let's Data Internal Data" and “Company Users Data” are referred to as “User Data”.
We use User Data to create your account, provide our services to you, communicate with you about our services, offer additional third-party products and services, and to enforce our terms of service. Representative use cases include but are not limited to the following:

Ephemeral and anonymized “Analytics Data” is used to better design the customer experience, diagnose and debug technical issues, secure the systems against abuse and to be in compliant with the rules and regulations.
"Signup Data" is used to deliver a personalized experience for the user. It is also used as a security boundary for the different data artifacts that are consumed and produced by #Let's Data. It is also shared with external billing systems such as Stripe to create per user billing and usage information for #Let's Data that is in compliance with financial regulations.
"Dataset Data" is used by the service to process the user's dataset jobs and provide an end to end experience expected of a secure, reliable and customer friendly SAAS data service.
"Dataset Configuration Data" is used by the service to create and manage dataset jobs as defined by the user. It serves as a configuration of how the user wants the data to be processed and retained. It also contains user data handler code that the user shares with #Let's Data. This data is visible to the creating user and the TenantAdmins in the Company.
"User's Read Connector Data" is used by the system to process the data using the user's code. This data is visible only to the user's data code and not shared with anyone. The exceptions to these are the ones already mentioned above. (document identifier, exceptions, logs, error documents, write documents)
"User's Write Connector Data" is generated by the system using the user's code and written to the write destination. This data is visible only to the user's data code and stored in the specified write destination. It may also be shown in artifacts such as document identifiers, exceptions, logs and error documents
"User's Error Connector Data" is generated by the system using the user's code and #Let's Data code and is written to the error destination. This data is visible to the creating user and the TenantAdmins in the Company.
"Dataset's Task Data" is used to manage a task's execution in the system and has data structures for a task's progress and checkpointing. This is generated by #Lets Data using the manifest from Dataset Configuration. This data is visible to the creating user and the TenantAdmins in the Company.
"Dataset's Log Data" is log data used to diagnose and troubleshoot issues in the task's / dataset's execution. This is generated by user and #Lets Data code. This data is visible to the creating user and the TenantAdmins in the Company.
"Dataset's Metrics Data" is metrics data used to diagnose and troubleshoot issues in the task's / dataset's execution. This is generated by user and #Lets Data code. This data is visible to the creating user and the TenantAdmins in the Company.
"Dataset's Metering and Usage Data" is generated by the system to track the resource usage for different resources and is sent to the external billing systems such as Stripe which will consolidate it into a user's invoice. This data is visible to the creating user and the TenantAdmins in the Company.
"#Let's Data Internal Data" is generated by the system to successfully process the dataset. These are visible at a high level to the creating user and TenantAdmins in the company - primarily for cost transparency and resource allocation / deallocation status.
"Company Users Data" is the directory of users in the company and is used to manage user access and privileges in #Let's Data. These are visible to TenantAdmins.

5. Sharing User Data

5.1 Disclosure of User Data

We will take reasonable steps to protect all User Data against unauthorized access or disclosure. We may share User Data: (i) with our third-party service providers in order to maintain and support #Let's Data; (ii) with another company if such company acquires our company, business, or assets; and (iii) as required by law and when we believe disclosure is reasonably necessary to comply with a judicial proceeding, court order, or legal process served on us, to protect our rights and the rights of our users, or to enforce or apply our terms of service or other policies or user agreements.
The "Signup Data" is shared with external billing systems such as Stripe to manage per user billing.
The "Dataset's Metering and Usage Data" is also shared with external billing systems such as Stripe to enable per user billing based on resource usage.

5.2 Notice and Consent for Other Disclosure

Except as detailed above, we will provide reasonable notice and obtain your consent before sharing your User Data with any third parties.

6. Security of User Data

6.1 Reviews and Updates to Security Measures

We take commercially reasonable security measures to protect against unauthorized access to or unauthorized alteration, disclosure, or deletion of User Data. This may include undertaking internal reviews of our data collection, storage, processing practices, and security measures, including secure communications, appropriate encryption and physical security measures to guard against unauthorized access to the systems where we store User Data. In addition, we will restrict access to User Data to our employees, contractors, and agents who need to know certain information in order to process it on our behalf. These individuals and entities are bound by strict confidentiality obligations and may be subject to discipline, including termination and criminal prosecution, if they fail to meet these obligations.

6.2 Security Breach

If User Data is compromised as a result of a security breach, we will promptly notify you that your personal information may have been compromised via email, by posting a notice on our website, or as otherwise required by applicable law.

7. Third Parties and Linked Sites

Information collected outside of #Let's Data by a third-party service provider is governed by the third-party’s privacy policies and their terms and conditions. #Let's Data may contain links to and from third-party sites and applications. We provide these links solely for your convenience and information. We assume no responsibility for your use of such third-party websites or applications.

8. Conditions of Use, Notices, and Revisions

By using #Let's Data, you consent to the collection, use, and disclosure of information according to the terms of this privacy policy. We reserve the right to modify this privacy policy at any time. If we make material changes to this privacy policy, we will notify you by providing the updated privacy policy on our website, sending an email notifying users of a change in our privacy policy. We will take reasonable steps to ensure that you are always aware of the information that we collect, how we use it, and under what circumstances we disclose it. Unless we clearly state otherwise, changes to our privacy policy will affect only the information we collect after the effective date of the change.

9. Data Rights

To request access to the User Data we collected for #Let's Data, correct or complete incorrect User Data in #Let's Data, terminate your account and delete the User Data in #Let's Data, or process other User Data related requests, contact us at . We reserve the right to decline the processing of other User Data related requests without assigning a reason. We also reserve the right, if we deem fit, to withhold, obfuscate, omit a part of or complete data for access, correction, and deletion requests for any reason including but not limiting to, protecting the business and its intellectual property.

If you have any questions or concerns regarding any of the terms of this privacy policy, please feel free to contact us at .

    #Let's Data
    c/o The Resonance Labs LLC
    P.O. Box 3223
    Redmond, WA 98073

Last updated: 01/01/2023