Privacy Policy

Privacy Policy

Effective Date: October 14, 2026 Version: 1.23

Synergy In Construction, LLC ("SynC™," "we," "us," or "our"), a Florida limited liability company, is committed to protecting your privacy and ensuring transparency about how we collect, use, disclose, and safeguard your personal information. This Privacy Policy describes our practices regarding the information we collect through our platform, website, and related services (collectively, the "Services"). You can reach us about anything in this Policy at privacy@synergyinconstruction.com; our full contact details are in Section 14.

By accessing or using the Services, you agree to this Privacy Policy. If you do not agree, please do not use the Services.

The Services are offered to customers in the United States, and personal information is processed and stored in the United States. We do not direct the Services to any other country. If you use the Services, or contact us, from outside the United States, you do so on that basis, and your information is transferred to and processed in the United States as Section 7 describes. The rights in Section 8.1 are open to you wherever you are.

1. Information We Collect

We collect information in several ways when you use our Services:

1.1 Information You Provide Directly

Account Registration Information:

• Full name (first and last name)
• Email address
• A recovery address, where the Services offer one: one of the verified email addresses on your account that you designate as an address a password reset or a sign-in code may be sent to when you type it, and our record of which of your addresses it is (Sections 1.2 and 8.1)
• Password (hashed; see Section 6.1), unless you sign in with Microsoft or Google and have not set one (Section 1.3)
• Phone number (optional)
• Job title and role
• Company name and information
• Profile information

The history of your name. We keep a history of the names your account has used: each name, and the period during which it was the name on your account. When you change your name in your profile (Section 8.1), the history gains the new name from that moment, and the earlier name stays with the period it covered. Each entry also records the category of evidence we held at the time that the account belonged to a real person: none, a verified email address, or a verified email address at a domain that a company you held a seat or a role in had registered as its own. The category is kept, not the evidence: no address, domain or sign-in identifier is written to the history, and the category is not shown on any record. We do not edit this history, and deleting your account does not change it (Section 5.1).

Passkeys (where the Services offer them). You may add one or more passkeys to your account and sign in with them instead of a password. A passkey is a pair of keys made by your device or your password manager; the private key stays there, and what we receive and keep is the rest:

• the public key, which can check a signature made with the private key and cannot make one, and the credential identifier that goes with it;
• a usage counter, where your authenticator reports one;
• how the passkey connects to a browser (for example built in to the device, or over USB or Bluetooth);
• whether the passkey is of a kind that is backed up or synced between your devices, and whether it currently is;
• an identifier of the make and model of the authenticator that holds it, which is shared by every authenticator of that model and identifies none of them individually;
• a name for it, which starts as a description of the browser that added it (for example "Chrome on Windows") and which you can change, and when it was added and last used.

We never receive the private key, and we never receive a fingerprint, a face or a device PIN. Unlocking a passkey is done on your device, by your device, and the result of that check is not sent to anyone; what reaches us is a signature we can verify. A passkey sign-in asks you for no email address: your browser says which passkey it used, and we find your account by that passkey's credential identifier. Where a passkey syncs between your devices, the syncing is done by the provider of your device or password manager under its own terms, and we are not party to it. Section 5.1 states how long a passkey record is kept, Section 6.1 what we hold and do not hold, and Section 8.1 how you see and remove your passkeys. If the Services do not show you an "Add a passkey" control, passkeys are not switched on, and nothing in this paragraph applies to you until you add one.

User Content and Project Data:

• Construction project specifications and documents
• Equipment datasheets and technical information
• Project files, drawings, and attachments
• Comments, annotations, and collaboration messages
• AI chat interactions and queries
• Custom templates and saved preferences
• SynC Standards wiki contributions

Conversations with the AI assistant. Your conversations with the AI assistant are stored on our servers rather than only in your browser, so that a conversation survives a page reload and remains available to you afterwards. What we store for each conversation is:

• the messages you send;
• the assistant's replies; and
• a plain-language record of the actions the assistant took in the course of the conversation — for example that it read a particular standard, or that it made a change you approved — together with the outcome of any change you approved; and
• the statement about you that was sent with the conversation's requests (Section 4.1A), as it stood when the conversation started; and
• where the conversation has grown long, a written summary of its earlier part (Section 4.1A), with which part of the conversation it stands in for, when it was made, and the model that wrote it.

Where an action produced a machine payload, that payload is reduced to identifying information before the conversation is stored. We keep what identifies the thing the assistant acted on, not the raw data it returned. This is the same form the conversation is displayed in: the assistant's actions are shown to you as that plain-language record, never as raw payloads.

We also record which inference provider and model served each exchange, so that the record of what happened is complete.

A summary is made for the assistant's use and is not shown to you. The Services show only a line in the conversation where one was made, and your own transcript is unchanged and complete (Section 4.1A).

A conversation carries the context it was started in — for example the project you were working in — and, when you reopen the assistant in that same context shortly after using it, we restore your most recent conversation there. The Services show you that this has happened and let you start a new conversation instead. Section 5.1 states how long a conversation is kept, Section 4.2A states who can see it, and Section 8.1 states what you can do with it.

Billing Information:

• Billing contact details — the name and email address of the person who makes a purchase for your company, the billing address they enter, and the name of the company being billed — which the purchaser enters on our payment processor's page and the processor reports back to us, or which you give us when we agree seat or credit fees with you in writing
• Purchase and subscription records — what your company has bought, in what quantity and for which period, the status of its subscription, the date it renews or ends and the count it renews at, any credit packs bought, the amounts charged and whether they were paid, and which user of your company started each purchase
• The processor's identifier for your company's billing account, and the event records the processor sends us about your company's purchases and subscription (see Section 4.1)
• Payment method details are not collected by us. You provide your payment card details directly to our payment processor, on a payment page it hosts; they do not pass through the Services and we never receive them. The records the processor sends us may state the kind of payment method used (for example, a card), never its number (see Section 4.1)

Communications:

• Email correspondence with our support team
• Feedback, surveys, and reviews
• Contact form submissions
• Where our website offers a booking page, the details you give when you book a call with us: your name, your work email address, your company's name, anything you choose to write about what you would like to see, and, if you choose to invite colleagues to the call, the email address you enter for each of them, all of which you enter on a scheduling page hosted by our scheduling processor (Section 4.1)
• If a colleague entered your email address when booking a call with us, we hold that address with the booking, and the calendar invitation you receive is how you learn of it (Sections 4.1, 8.1 and 11)
• Where everyone on a call booked with us agrees to it at the start of the call, the recording of the call, and any transcript or meeting notes we make from it (Sections 2.5, 3, 4.1, 5.1 and 11)

1.2 Information Collected Automatically

When you access or use the Services, we automatically collect:

Usage Information:

• Pages viewed and features accessed
• Time spent on pages and in the application
• Click patterns and navigation paths
• Search queries and AI interaction history
• Feature utilization and engagement metrics
• Files uploaded, downloaded, and shared

Wiki search. When you search the public SynC wiki without signing in, we record what you searched for and which result you opened, so that we can see which standards are missing or hard to find. These records include no IP address, device or browser identifier, and no link to any account; they are never used to build a profile of you, and they are deleted after 90 days. Searches you run while signed in are ordinary account activity, are associated with your account as described under Usage Information above, and are deleted on the same 90-day schedule.

Email we send you. We send email through a third-party delivery service (Section 4.1), and that service applies tracking to the messages it sends on our behalf.

• Every link in an email we send is rewritten before the message goes out. A link you follow resolves first through our email-delivery processor's tracking domain, awstrack.me, which records the click and then redirects you to the real destination. This is why a link in one of our emails shows an awstrack.me address when you hover over it rather than a synergyinconstruction.com one. What is recorded is that a link in a particular message was followed, which link it was, and the technical details accompanying that request, including your IP address and the date and time.
• Where open tracking is enabled on our email-delivery account, opening a message is also recorded. That feature works by including a small invisible image in the HTML version of a message; your email program requests that image when it displays the message, and the request records that the message was opened, when, and the same kind of technical detail. Configuring your email program not to load remote images prevents it. The link rewriting described above is part of the message itself and is not affected by that setting.

These records are held by our email-delivery processor. No email interaction record is written to your SynC account or to our application database. Section 4.1 describes that processor and what it receives, Section 5.1 states what we can and cannot say about how long it keeps this data, Section 8.1 states what you can do about it, Section 10.1 explains why none of it is a browser cookie, and Section 12.3 explains that it applies to transactional email and not only to marketing email.

Sign-in security records. The Services keep four short-lived records to protect accounts against guessed and stolen passwords and codes. Section 5.1 states how long each lasts and Section 6.1 what each protects.

• Failed sign-ins, counted per address. When a password sign-in fails, we record a count against the email address that was typed, whether or not an account exists for it, together with the time of the last failure and, after repeated failures, the time until which further attempts are held. The record holds a hash of the address rather than the address itself, and it is used for nothing but the hold. Wrong verification codes and wrong sign-in codes (below) are counted in the same way, separately from passwords. A wrong password typed when the Services ask you to confirm it is you (Section 6.1) is counted as a failed sign-in.
• The 6-digit code in our verification email. When we send you an email to verify an address, the email carries a code as well as a link, and either one verifies. We store the code only in a form that cannot be read back, never the code itself, beside the link token stored the same way, with the time it expires and a count of the attempts made against it.
• The 6-digit code in a sign-in email (where the sign-in page offers it). When you ask for a sign-in code instead of entering your password, we email one to the address you typed when that address is your account's primary email address or the recovery address you have designated (Section 1.1), and otherwise to your primary address, as a password reset is sent, and entering it signs you in without your password. We also email one, with a notice, to the owner of an address when someone tries to create an account with it, so that the person who owns the address can sign in from the page they were on and anyone else learns nothing; the notice goes to the primary address too, says that an attempt was made and that nothing about the account has changed, and carries nothing about who made the attempt. For each code we store, against your account, the code in a form that cannot be read back, never the code itself, why it was sent, when it was sent and when it expires, a count of the attempts made against it, and when it was used or replaced by a newer code. No address, network address or browser is stored on that record; our audit record notes that a code was sent and why, and that a signup named your address, each with the time and the network address and browser of the request that caused it. If the sign-in page does not show "Email me a sign-in code instead", sign-in codes are not switched on, and the notice to the owner of an address goes out without a code.
• Which provider you signed in with. When you sign in with Microsoft or Google (Section 1.3), our audit record notes that a sign-in, a linking or an unlinking happened, when, and which provider was involved. It does not carry the provider's identifier for you.

Where you are signed in. Each browser session on your account records when it signed in, how (by password, by an emailed code, by the code or link in a verification email, by an invitation or a share link, or with Microsoft or Google), when the browser last used it, and the browser's own description of itself, which is the user-agent string your browser sends with every request. These facts are written on the session itself rather than in a separate record, so they last exactly as long as the session does (Section 5.1), and they are shown to you, and to no one else, in Profile → Security, where you can end a session you do not recognize (Section 8.1). When you end a session there, our audit record notes that you did, and how many. Once you have confirmed it is you before a sensitive change to your account (Section 6.1), the session also records when you last did and how (by password, by passkey, with Microsoft or with Google), written on the session in the same way and for the same life, and our audit record notes that you confirmed, how, when, and the network address and browser of the request. A request made with an API key creates no browser session and is not listed. Nothing here is new information about your device: the Device and Technical Information list below already names your browser and operating system. What is new is that it is kept on the session, for the session's life, so that you can see where your account is signed in.

API keys, the apps and tools you connect with them, and the record of their use. You can create an API key and use it from an outside app or tool: a developer tool, a script of your own, or an AI app such as a general-purpose assistant (Section 4.10). The Services keep these records about a key and its use.

• Each API key: its name, the permissions you gave it, when it was created, rotated and last used, the network address it was last used from, whether and when it was revoked, and the key itself only in a form that cannot be read back (Section 6.1).
• Every request made with a key is logged: which key made it, the method and the address of the request, including any search term or identifier the address carries, the result, the network address and the software description the request came from, and the time. Where an AI app makes the request, the network address and software description are usually those of a server run by the app's provider, not of your device. The log does not hold the body of a request or of a response: not the content read, and not the text an app wrote into a draft. Section 5.1 states how long the log is kept, and Section 8.1 states how you see it and what your company's administrators can see.

Company records of what you did, and the name on them. When you act in a company's project or library, the record of the act names you: that you published a revision, started a draft, uploaded a file, wrote or resolved a comment, changed, adopted or archived a standard, saved a datasheet, created a share link, accepted one, or received access (see Project Sharing and Distribution Analytics below). Each record stores our identifier for your account and the time of the act, and no name; the name it shows is looked up, each time the record is shown, from the history described in Section 1.1 as it stood at the time of the act. A record therefore shows the name you had when you made it. Changing your name afterwards does not change it, and neither does deleting your account (Sections 5.1 and 5.2). A revision of a company library standard records who published it and when. A notification we send you about something another person did names that person as they were when the notification was sent, from the same history.

Made through an integration. Where a record is made with an API key rather than from a signed-in session, which the Services allow for uploading a file, posting a comment, publishing a project or standard revision, and saving a datasheet revision, the record also stores which key made it, and the name on it is shown with "via API" after it.

Acts on a name. A name is shown differently from how it was recorded only through an act that we record. There are three. A name may be withheld: on the instruction of the company that holds the record, for that company's records only; by SynC under the Terms of Service, for impersonation, an abusive name, someone's safety, or an identity that was not confirmed; or where the law requires it. The record then shows "Name withheld", with the reason and the date, in place of the name, wherever the record is shown, including in a notification. You cannot withhold your own name; Section 8.1 states what you can ask for instead. A name may be annotated: while SynC looks into a report that an account is not who it says it is, the name is shown as recorded with "(identity disputed, under review)" after it. Only SynC annotates a name, and a finding becomes a withholding or a release. A name may be superseded, which is your own election to show your current name on the records you made under an earlier name (Section 8.1); a withholding takes precedence over it, and an annotation is shown alongside either. Each act records whose name it governs, whether it covers all of that person's records or one company's, which act it is, a reason from a fixed list, who instructed it, who carried it out, and when. An act ends by a release, which records who released it, when and why; an act is not edited or deleted, and a released act stays as the record that it was released. Each act and each release is noted in our audit record by identifiers and categories only, and so is each change to your name. No act changes a record, the history, or the content check on a published revision: names are not part of what a revision's fingerprint covers, and the verification page says so. Where a name is withheld on a project revision that has already been sent to recipients, the withholding, and any later release, is written as an event on that revision's distribution record (Section 5.1), and the revision as served to a recipient says that the name was withheld after the revision was sent to them, with the reason and the date. We do not send you a notice when a name of yours is withheld or annotated; the act is shown on the record itself.

Project Sharing and Distribution Analytics:

• Share link creation, acceptance, and forwarding activity
• Access records tracking which users have accepted shared project access
• Records of the removal of a recipient's access, and of the deletion of a distributed project and of its restoration
• Sharing chain data (how access has been forwarded through delegation)
• Records that a name on a revision already sent to recipients was withheld, or shown again (see Acts on a name above, and Section 5.1)

Device and Technical Information:

• IP address and geolocation (city/region level)
• Browser type and version
• Operating system and device type
• Screen resolution and display settings
• Unique device identifiers
• Referring URLs and exit pages

Cookies and Similar Technologies: We use cookies, browser storage, web beacons, pixels, and similar tracking technologies to:

• Maintain your session and keep you logged in
• Remember your preferences and settings
• Analyze usage patterns and improve Services
• Prevent fraud and enhance security
• Deliver personalized content and recommendations

For more information, see Section 10 (Cookies and Tracking Technologies).

1.3 Information from Third Parties

Sign-in with Microsoft or Google (where the Services offer it). You may choose to sign in to SynC with a Microsoft or Google account instead of, or as well as, a password. If you do, this is what happens with your information.

• What we ask the provider for. We request only the standard sign-in scopes: openid, email and profile. We do not request access to your contacts, your files, your mail, your calendar or anything else in that account, and the consent screen the provider shows you names what we ask for.
• What we receive. Your name; your email address; whether the provider has verified that address; and a stable identifier for the account. For Google, the identifier is the account's subject identifier. For Microsoft, it is the identifier of the directory the account belongs to (for a work account, your employer's directory) together with your identifier within it, so the same person in two organizations is two sign-in identities. We also record which provider you used. When the Services ask you to sign in to Microsoft again to confirm it is you (Section 6.1), we receive the same information and nothing more, and we read from it the time Microsoft reports for that sign-in.
• What we do not receive. Your password at the provider, any second factor you use there, your contacts, files, mail or calendar, and no ongoing access to the account: we keep no access token and cannot act in that account. The identifier the provider gives us signs you in to SynC and does nothing else.
• What we use it for. To sign you in, and to keep your account: when you first sign in this way, to create your SynC account with the name and address prefilled, both of which you can change before you finish; when you already have an account, to link the provider to it once you have confirmed the link with that account's password, with a code emailed to it, or with one of its passkeys (Sections 1.1 and 1.2); and afterwards, to recognize you at your next sign-in. We use the verification the provider gives us in place of our own email verification when the provider vouches for the address, and we send our own verification email when it does not. We do not use information received from Microsoft or Google for advertising, for profiling, or to train any model, and we do not sell it or share it with anyone.
• Google's requirements. SynC's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
• The provider is not our processor. When you sign in with Microsoft or Google, the provider acts for you, and for a work account also for the organization whose directory it is. It does not process your information on our behalf and we give it no instructions; what it does with your account, including keeping its own record that you signed in to SynC, is governed by its privacy policy and, for a work account, by your organization's settings. Section 4.1 states what the provider learns from us, which is that you asked to sign in to SynC; Section 11 describes the page you are sent to.
• You can disconnect at any time, in Profile → Security → Sign-in methods. Section 8.1 states what that does and does not do.

Sign-in with a provider is described here so that it is disclosed before it is offered. If the Services do not show you a "Continue with Microsoft" or "Continue with Google" control, it is not switched on, and nothing above applies to you until you use it.

What an app or tool you connect sends us. When you use an API key from an outside app or tool (Section 4.10), we receive each request it makes on your behalf: which action it asks for and the parameters it sends, which can include text the app has composed, for example a requirement it proposes to add to a draft you asked it to work on. We treat what the app sends as sent by you, within the permissions on the key, and the Services check every request against what your account can do at that moment (Section 6.1). We do not receive your conversation with the app, your prompts to it, or anything the app holds about you beyond the request it makes.

Business Partners:

• Information from companies that collaborate with you on projects
• Referral information from partners

Public Sources:

• Publicly available business information
• Industry data and construction standards

2. How We Use Your Information

We use the information we collect for the following purposes:

2.1 Service Delivery and Operations

• Provide, maintain, and improve the Services
• Create and manage your account
• Sign you in with Microsoft or Google when you choose to, and keep the link between that account and your SynC account so that your next sign-in is recognized (Section 1.3)
• Sign you in with a code emailed to you when you ask for one, or with a passkey you have added, and keep the records those require (Sections 1.1 and 1.2)
• Keep the recovery address you designate, and send a password reset or a sign-in code to it when you type it (Sections 1.1 and 8.1)
• Serve the requests of an API key you created, from whatever app or tool presents it, within the permissions you gave the key and what your account can do, and mark each change made with a key as made through the API (Sections 1.2 and 4.10)
• Sell seats and AI credits to your company, keep the record of what it holds and has paid for, apply what our payment processor reports about its purchases and subscription, and notify your company of a failed payment or a coming lapse (see Section 4.1)
• Store and organize your project data and User Content
• Store your conversations with the AI assistant so that they survive a page reload and remain available to you, and restore a recent conversation when you reopen the assistant in the context it belongs to, and keep with a conversation that has grown long a summary of its earlier part (see Sections 1.1, 4.1A and 5.1)
• Keep the history of the names your account has used, and show on each company record the name you had when you made it (Sections 1.1 and 1.2)
• Show on a record that a name was withheld, annotated or superseded where an act we record says so, tell the recipients of a sent revision when a name on it was withheld after it was sent, and show the current name of a person who has chosen to show it on their earlier records (Sections 1.2 and 8.1)
• Enable collaboration features with team members
• Provide customer support and respond to inquiries
• Send transactional emails (account notifications, password resets, etc.)

2.2 AI and Machine Learning

We use artificial intelligence and machine learning to deliver certain features of the Services:

AI Feature Delivery:

• Process your queries and requests through AI services
• Generate AI-assisted content and recommendations
• Analyze specifications and documents using natural language processing
• Provide predictive analytics and intelligent suggestions
• Make content searchable by meaning as well as by keyword (semantic search)
• Continue a stored conversation where you left it, which requires transmitting that conversation to the inference provider again (see Section 4.1A)
• Generate a short title for each stored conversation, so that a list of your conversations is navigable. The title is produced by a separate, small inference request over the conversation's own content (see Section 4.1A)
• Condense the earlier part of a conversation that has grown long into a written summary, so that continuing the conversation does not require transmitting the whole of it again. The summary is produced by a separate inference request over that part of the stored conversation and is stored with the conversation (see Sections 1.1 and 4.1A)
• Tell the assistant what your role on the current project lets you do, so that it does not propose actions you cannot take (see Section 4.1A)
• Pitch the assistant's answers to who you are (your first name, your professional role and discipline, the type and name of the company you are with, and how the project you are working in records that company among its participants), which requires transmitting those facts to the inference provider with your request (see Section 4.1A). You can see exactly what is sent and switch this off (Section 8.1)

We Do Not Train Models on Your Content:

• We do not use User Content to train, fine-tune or improve any generative AI model, or any general-purpose or foundation model, whether ours or a third party's, and whether or not it has been anonymized or aggregated. The scope of that commitment, its conditions, and its limited exceptions are set out in Terms of Service §5.3.1 — which governs if this summary and it ever differ
• We may build models inside the Services that classify, score, match, rank or flag content — for example identifying what kind of value a datasheet field holds. Terms of Service §5.3.1 states the conditions such a model must meet: it produces structured outputs rather than text, it is never distributed outside the Services, and neither it nor its outputs reproduce your content to anyone not already authorized to see it
• The principal exceptions are content you deliberately submit for inclusion in the public SynC Standards library, which is a Contribution under our Contributor License Agreement, and feedback you direct to SynC about the Services or about a published Standard, which is governed by Terms of Service §8.5
• We do measure how the Services are used, and structural facts derived from content, in ways that cannot reconstruct your content — see Terms of Service §5.3.2
• Your messages to the AI assistant are User Content, and the commitment above applies to them. Storing a conversation does not create a training use: a stored conversation is transmitted to an inference provider only in order to continue that conversation, to generate its title or to summarize its earlier part (Section 4.1A), under the same constraints as any other request
• There is no opt-out from training generative or foundation models to request, because that is a use we do not make. We may use what you upload, and what the Services produce from it, to evaluate and improve the Services: to find out why a result was wrong and put it right, to make the Services read documents and answer questions better, and to measure how well they do. Your content stays your confidential information; we do not sell or license it; we do not use it to train, fine-tune or improve a generative, general-purpose or foundation model; and nothing we build from it reproduces, or discloses the substance of, your content to anyone not already permitted to see it. Terms of Service §5.3.1 states these limits, which govern. Section 5.1 states how long we keep what we make for this purpose, and Section 8.1 states how a project is opted out
• The Terms of Service also set a rule for you and every other user: the Services may not be used to collect other people's content, content shared with you, or information about other users, in order to train or evaluate a model (Terms of Service §9.2A). Your own content remains yours to export and use

Third-Party AI and Embedding Services:

• Delivering AI-assisted features and semantic search requires transmitting the content you are working with to service providers that perform inference and text-embedding on our behalf
• We send requests only to inference providers named on our published subprocessor list, whose terms do not permit them to retain your content for their own purposes or to train on it. Some of those providers we contract with directly; others serve requests as suppliers of a routing service we contract with, under configuration that excludes hosts that log or train. Section 4.1A describes the controls we apply on each path, and Terms of Service §5.3.3 states the commitment, which governs
• The providers we use or may use are published at synergyinconstruction.com/legal/subprocessors, with links to each provider's own documents, which state where it processes content and how long it keeps it. That list names every provider a request may reach, without stating which of them serves at a given time, and does not restate what a provider's documents say. It changes from time to time; our obligations under Terms of Service §5.3.3 do not
• An AI app you connect to your account yourself is not one of these providers, and none of this applies to it. What you send to such an app, and what it reads from your account on your behalf with an API key (Section 4.10), goes to a company you chose, under terms you agreed with it. We do not send your content to any AI provider except as this Section and Section 4.1A describe; an app you connect is you sending it

2.3 Analytics and Service Improvement

• Monitor and analyze usage patterns and trends
• Conduct research and development for new and existing features, using the usage data and structural statistics described in Terms of Service §5.3.2 and, for projects that have not been opted out, the content and results described in Section 2.2, within the limits Terms of Service §5.3.1 states
• Perform statistical analysis and create aggregated reports
• Measure effectiveness of features and user experience
• Identify and fix technical issues and bugs
• Optimize performance, speed, and reliability
• Identify gaps in the SynC Standards library — which standards are missing, or present but hard to find — from what visitors search for and which results they open (see Section 1.2)
• Maintain a citation index derived from published documents — which published document cites which SynC Standard, and at which clause — used to resolve citations for readers of the citing document, to warn Wiki editors about the impact of an edit on documents that cite the edited clause, and to produce the aggregate citation counts described in Section 4.5

2.4 Personalization

• Customize your experience based on preferences and usage
• Provide relevant recommendations and content
• Remember your settings and preferences
• Display personalized dashboards and workflows

2.5 Communication

• Send important service announcements and updates
• Notify you of new features and improvements
• Request feedback and conduct surveys
• Provide educational content and best practices
• Send marketing communications (with your consent, where required)
• Schedule a call you have asked for, send its calendar invitation and any reminder or change to you and to each colleague you invite, and hold the call on a video-meeting service (Sections 4.1 and 11). Booking a call is not consent to marketing email, and neither is attending one; Section 12 governs that separately
• Follow up with you after a call you booked, and with a colleague you invited who attended it: send what we said on the call we would send, answer what was asked, and propose a next step if there is one (Sections 4.1 and 11). This is correspondence about the call, not marketing email, and it stops when you tell us to (Section 8.1)
• Record a call booked with us, where everyone on the call agrees to it at the start, and keep the recording, and any transcript or meeting notes we make from it, for our own reference and for following up on that call (Sections 4.1 and 11). We do not publish a recording, transcript or note, use it for marketing, use it to train, fine-tune or evaluate a model, or use it to evaluate or improve the Services under Section 2.2

2.6 Security and Fraud Prevention

• Detect, prevent, and investigate fraud and security incidents
• Protect against unauthorized access and malicious activity
• Monitor for violations of our Terms of Service
• Ensure platform integrity and user safety
• Comply with legal obligations and enforce our policies
• Slow down repeated failed sign-ins and wrong codes against an address, verify an email address by a short-lived code or link, and check a password against a public list of passwords exposed in data breaches when it is set and when it is used to sign in (Sections 1.2, 4.1 and 6.1)
• Tell the owner of an email address, by email, when someone tries to create an account with it, so that the person who owns the address learns of the attempt and anyone else learns nothing (Section 1.2)
• Tell you, at every verified email address on your account and not only the primary, when your password is changed, when your primary address is changed, when an address is added to or removed from your account, when your recovery address is set, changed or cleared, and when a passkey is added or removed, so that a change you did not make is noticed at an address the change did not touch (Sections 8.1 and 12.3)
• Show you where your account is signed in, and let you end a session you do not recognize (Sections 1.2 and 8.1)
• Ask you to confirm it is you before a change that would give a way into your account that outlives the browser session you are using, or that would take the account, or the ways back into it, away from you, and keep on that session when and how you did (Sections 1.2, 6.1 and 8.1)
• Keep an audit record of sign-ins, of the linking and unlinking of a sign-in method, of the adding and removal of a passkey, of a sign-in code being sent, of a signup that named your address, of your confirming it is you before such a change, and of your ending a session, so that you and we can see what happened to your account (Section 1.2)
• Annotate a name while we look into a report that an account is not who it says it is, and withhold a name under the Terms of Service on a finding, on a company's instruction for its own records, or where the law requires it (Section 1.2)
• Note in our audit record each change to your name, and each act on a name and its release (Section 1.2)
• Log every request made with an API key, so that you and we can see what a key, and the app or tool using it, did with your account, and so that a key that is misused can be found and stopped (Sections 1.2 and 5.1)
• Refuse a request made with a key when the key has been revoked, when your company has switched access by API keys and connected apps off, when a share link's export setting does not allow it, or when your own access has narrowed, and limit how often your keys may ask (Sections 4.10, 6.1 and 8.1)

2.7 Legal Compliance

• Comply with applicable laws, regulations, and legal processes
• Respond to lawful requests from public authorities
• Protect our rights, privacy, safety, and property
• Resolve disputes and enforce agreements

3. Legal Basis for Processing

This Section states the ground on which we process each category of personal information. It is written in the terms the General Data Protection Regulation (GDPR) uses, so that a reader in the European Economic Area (EEA), the United Kingdom or Switzerland can see the basis we rely on. It is a description of our practices; it does not make the Services an offer to any country other than the United States (Section 7). We process your personal information on the following grounds:

Contract Performance:

• Processing necessary to provide the Services you've requested
• Account creation and management
• Signing you in with Microsoft or Google when you choose to, which requires receiving your name, your email address, its verification status and the provider's identifier for your account from the provider, and keeping that identifier linked to your account for as long as you keep the link (Section 1.3)
• Signing you in with a code emailed to you when you ask for one, which requires keeping a hash of the code for at most a day, and with a passkey you have added, which requires keeping its public key and the record described in Section 1.1 for as long as you keep the passkey (Sections 1.1, 1.2 and 5.1)
• Serving the requests of an API key you created, which you asked us to do when you created it, and sending the app or tool that presents it what it asks for on your behalf within the permissions you gave the key (Sections 1.3 and 4.10)
• Selling seats and AI credits to your company and operating its subscription, which includes disclosing your company's name and billing contact details to our payment processor so that a purchase can be made and charged, and receiving from the processor the status of the purchase and of the subscription (see Section 4.1)
• Transmitting the content in scope for your request to an inference provider in order to answer a question you have asked of the AI assistant, and transmitting a search query to a text-embedding provider in order to run a search you have asked for (see Section 4.1A)
• Transmitting, with a request to the AI assistant, our internal identifiers for your account and your company and a statement of what your role on the current project lets you do, so that the assistant acts within your permissions and does not propose actions you cannot take (see Section 4.1A)
• Storing your conversations with the AI assistant so that they remain available to you, restoring a recent conversation when you reopen the assistant in the context it belongs to, and transmitting a stored conversation, or the summary and recent part of it that Section 4.1A describes, to an inference provider when you continue it — each of which is what the conversation-history feature you are using consists of (see Sections 1.1, 4.1A and 5.1)
• Retaining a project you have deleted so that it can be restored for 30 days, and restoring it within that period when a user with authority over it asks (see Section 5.1)
• Keeping the history of the names your account has used, and showing on each record you make in a company's project or library the name you had when you made it, which is what a company's record of its work consists of (Sections 1.1, 1.2 and 5.1)
• Showing your current name on your earlier records where you have elected to, and withdrawing the election when you ask (Section 8.1)
• Scheduling and holding a call you have booked with us, and following up with you about it afterwards, which are steps taken at your request before any contract, and which require disclosing the details you give when booking to our scheduling processor and holding them in our calendar (see Sections 4.1 and 11)

Legitimate Interests:

• Improving and optimizing our Services
• Evaluating and improving the Services using what a person uploads and what the Services produce from it, within the limits Terms of Service §5.3.1 states, for projects that have not been opted out (see Sections 2.2, 5.1 and 8.1). What we use may name people who are not users, such as a contractor's staff on a transmittal; we process those names only because they are in the content, and we add them to no record about those people
• Fraud prevention and security
• Keeping the log of every request made with an API key, so that what was done with an account can be seen and a misused key stopped (Sections 1.2 and 5.1)
• Letting a company's administrators see which members hold a key and how it has been used, and switch access by API keys and connected apps off for the company, in the company's interest in deciding where its own project records go; and serving a member's key while the company has not switched access off, as the company's standing instruction about its records and the member's own authority to read them (Sections 4.10 and 8.1). What an app reads with a key can name people who are not you, such as a colleague on a company's record or a supplier's staff on a transmittal; we send those names only because they are in the record you could read yourself, on the same footing as an export would carry them
• Letting an app or tool a recipient has connected read a project shared with that recipient where the sender's share link allows export, on the same basis on which the recipient may export it (Sections 4.2 and 4.10)
• Protecting accounts against guessed and stolen passwords: holding an address after repeated failed sign-ins or wrong codes, verifying an address by a short-lived code, telling the owner of an address when someone tries to create an account with it, telling every verified address on your account when your password, your addresses, your recovery address or your passkeys are changed, keeping on each browser session when and how it signed in, when it was last used and the browser's description of itself so that you can see where your account is signed in and end a session, asking you to confirm it is you before a sensitive change to your account and keeping on that session when and how you did, and checking a password, by a hash prefix that identifies no one, against a public list of passwords exposed in data breaches (Sections 1.2, 4.1, 6.1 and 8.1)
• Analytics and business intelligence
• Direct marketing to existing customers
• Sending the calendar invitation for a call, and any reminder or change to it, to a colleague whose email address the person booking the call entered, holding that address with the booking in our calendar and at our scheduling processor, and following up with a colleague who attended the call, in our interest in holding the call the person who booked it arranged with the people they chose to bring. The colleague made no request of us; the invitation is where they learn of this, and asking us to remove their address is how they object (see Sections 4.1, 8.1 and 11)
• Detecting, diagnosing, and remediating errors and service-impacting incidents through our error-monitoring processor (see Section 4.1)
• Measuring how visitors and signed-in users move through the application, the public SynC Standards library and our legal pages, and which features are used, through our product-analytics processor (see Section 4.1). We ask for no consent to the cookie and browser storage that processor uses and we show no consent banner; in a browser whose time zone places it in the European Economic Area, the United Kingdom or Switzerland, the processor is not loaded at all (Sections 4.1 and 10). The events our own server sends to that processor about what a signed-in user did (Section 4.1) rest on this same basis and are sent wherever the user is. Asking us is how anyone objects (Section 8.1)
• Understanding which construction standards our public wiki fails to answer, from search-and-click records that carry no identifier and are deleted after 90 days (see Section 1.2)
• Maintaining durable records of project distribution events (share-link creation, acceptance, forwarding, access removal, and deletion of a distributed project), including where the recipient is not a SynC user, as reasonably necessary for the establishment, exercise, or defense of legal claims arising from the distribution of project content (see Sections 5.1 and 5.2)
• Keeping a company's records of who published, uploaded, commented, adopted and changed what in its projects and libraries, with the name the person had at the time, after that person's account is deleted, together with the name history those records are read from, as the company's record of its own work and as reasonably necessary for the establishment, exercise or defense of legal claims by the parties who rely on a published revision (see Sections 5.1 and 5.2)
• Withholding a name from a company's records on that company's instruction, withholding a name under the Terms of Service, annotating a name while a report of impersonation is looked into, and recording each act and its release so that any difference between a name as recorded and a name as shown is visible on the record (see Section 1.2)
• Publishing a register of our own moderation actions on SynC Standards, which carries no identifier of any person, so that what SynC has done is open to the public; and keeping the record that a required notice of a moderation hold was given, the record of a copyright notice we received and of its outcome, the record of a suspension of wiki contribution privileges under the repeat-infringer policy and of its lifting, the record of a decision to terminate an account under that policy or not to, and a non-public copy of material we have withheld, in each case as reasonably necessary for the establishment, exercise, or defense of legal claims arising from the action or the notice, and, for the notice, suspension and termination records, to operate the repeat-infringer policy that Terms of Service §5B.5 describes (see Sections 5.1 and 5.2)
• Sending the author of material identified in a copyright notice a copy of that notice, with the sender's contact details removed, so that the author can decide whether to send a counter-notification, and keeping the notice as correspondence for as long as a claim arising from it could reasonably be brought (see Sections 4.9 and 5.1)
• Building and maintaining the search index, including converting content into numeric vectors when it is created or changed rather than only when a search is run, so that content is searchable by meaning as well as by keyword (see Section 4.1A)
• Maintaining the citation index and displaying the aggregate citation counts described in Section 4.5, so that the maintainers and readers of a cited standard can see that citations of it exist — disclosed, where the viewer cannot read the citing documents, only as a bare count of citation occurrences (see Sections 4.5 and 5.1)
• Measuring whether the email we send is delivered and acted on, through the delivery reporting and link tracking applied by our email-delivery processor to the messages it sends for us (see Sections 1.2 and 4.1)
• Generating a short title for each stored conversation so that a list of conversations is navigable, and enforcing the limits described in Section 5.1 on how many conversations we store for you and how long each may run, so that the volume of conversation content we hold stays bounded
• Condensing the earlier part of a conversation that has grown long into a written summary, by a separate request to the inference provider over that part of the stored conversation, and keeping the summary with the conversation, so that continuing a long conversation does not require transmitting the whole of it again (see Sections 1.1, 4.1A and 5.1)
• Pitching the assistant's answers to your professional role, discipline, company type and company name, and to how the project you are working in records your company among its participants, and letting it address you by your first name, by transmitting those facts to the inference provider with your request, where you have not switched this off (see Sections 4.1A and 8.1). Switching it off is how you object to this processing, and it takes effect from your next conversation

Consent:

• Marketing communications to prospects (you may withdraw consent)
• Recording a call booked with us, and making a transcript or meeting notes from the recording, which we do only where everyone on the call agrees at its start; anyone on the call may decline, and the call goes ahead unrecorded (Sections 2.5, 4.1 and 11). Asking us to delete the recording is how you withdraw that consent (Section 8.1)

We do not rely on consent for the cookie and browser storage our product-analytics processor uses, because we ask for none. Where that processor runs, it runs on the legitimate interest stated above; in a browser whose time zone places it in the European Economic Area, the United Kingdom or Switzerland, it does not run at all (Sections 4.1 and 10).

Legal Obligation:

• Compliance with applicable laws and regulations
• Responding to legal requests
• Withholding a name from a record where the law requires it (Section 1.2)

You have the right to object to processing based on legitimate interests. See Section 8 for more information about your rights.

4. How We Share Your Information

We do not sell your personal information to third parties. We share your information only in the following limited circumstances:

4.1 Service Providers and Processors

We engage trusted third-party service providers to perform functions on our behalf, including:

Our processors change over time. The processors described in this Section are those we use as of the Effective Date of this Policy. We may add, replace, or discontinue processors from time to time; where we do, the categories of data, purposes, and safeguards described in this Section continue to apply to any processor performing the same function. The processors described here reflect our current arrangements and are not an exhaustive or permanent list. A list of our third-party subprocessors is published at synergyinconstruction.com/legal/subprocessors and is also available on request at privacy@synergyinconstruction.com, and we will update this Policy in accordance with Section 13 when changes are material. Where more than one provider may perform a function, that list names each of them without stating which one serves at a given time; a provider is named there before any content or personal data is sent to it. Section 8.1 states how to ask which provider actually received your personal data.

Infrastructure and Hosting:

• Cloud hosting and compute providers
• Content delivery networks (CDNs) and DNS providers
• Object storage, data storage, and backup services

AI and Machine Learning:

• Inference providers, reached either directly on our own account or through an inference router which selects a downstream inference host per request from a set we control (see Section 4.1A)
• Text-embedding providers, which power semantic search (see Section 4.1A)

Business Operations:

• Payment processors (see Payments below for our current payment processor)
• Transactional email delivery services (see Email Delivery below for our current email processor)
• Customer support platforms
• Analytics services (see Web Analytics, Product Analytics, and Error Monitoring below for our current analytics and observability processors)
• Scheduling and video-meeting services, where you book a call with us or a colleague invites you to one (see Scheduling below for our current scheduling processor)

Web Analytics — our current web-analytics processor (Cloudflare Web Analytics):

• Processor: Cloudflare, Inc., based in the United States, with global processing infrastructure
• Purpose: Aggregate, privacy-respecting measurement of site traffic and performance for our public website and wiki (e.g., page views, referrers, country-level visitor distribution, page load timing)
• Categories of data received: URL of the page visited, referring URL, anonymized browser and operating system family, country (no precise geolocation), and basic connection performance metrics
• What is NOT received: Cloudflare states that Web Analytics is cookieless — that it does not set cookies, does not assign visitor identifiers, and does not perform cross-site tracking. On that basis, no persistent identifier is created in your browser by this processor.
• Where deployed: The analytics beacon is loaded only on the production hostname (synergyinconstruction.com). It is not loaded in local development or on staging environments.
• Consent banner: Because the beacon is cookieless and does not create or read any persistent identifier on your device, it does not require consent under the ePrivacy Directive's cookie rule. No consent banner is required for this processor.
• Cloudflare privacy commitments: https://www.cloudflare.com/web-analytics-privacy/

Product Analytics — our current product-analytics processor (PostHog):

• Processor: PostHog, Inc., based in the United States. SynC uses PostHog's US cloud (us.i.posthog.com), so product-analytics event data, and any session recording, are transferred to and processed in the United States.
• Purpose: See how visitors and signed-in users move through the application, the public SynC Standards library and our legal pages: which pages are opened, in what order and for how long, which links, buttons and forms are used, and where a path from a standard in the library to a created project is abandoned; and, where session replay is switched on, diagnose a user-experience problem from a masked recording of the session
• Where it runs, and where it does not:
  • In the application, the processor's script runs on every page and sends the page views, clicks, form submissions and named events described below.
  • On the public SynC Standards library and our legal pages, which are served without the application, a short script of our own sends one page view per page you open, under the visitor identifier described below. On a standard that offers the "Use in a project" control, it also sends an event that the control was shown and, when you reach the control by pointing at it, moving keyboard focus to it or using it, an event that you did. Reaching the control is the one thing that loads the processor's own script on those pages, and the script is configured there to send that one event and nothing else: no page view, no clicks, no recording, and no text from the page. Our script stays silent for a browser that identifies itself as a crawler or an automated browser.
  • Not in the European Economic Area, the United Kingdom or Switzerland, by time zone. We do not ask you to consent to this processor's cookie or browser storage and we show no consent banner. Instead, if your browser's time zone places it in those places, neither the processor's script nor ours runs: no cookie or browser storage is set, nothing is fetched from the processor, and no event is sent from your browser. The time zone is read in your browser and is not sent anywhere. The list of time zones we exclude is wider than those places, taking in every European time zone and the European island territories; if the time zone cannot be read, the processor stays off. It is a heuristic and not a statement of where you are: a browser set to another time zone, a VPN or a travelling laptop can fall either side of it. The rule governs what your browser sends. It does not govern the events our own server sends, described below, which are sent wherever the user is. Anyone, anywhere, can ask us not to capture their activity (Section 8.1).
• Categories of data received:
  • Page views and time on page, in the application: Each page you open as you move through the application, with its URL and path, the page you came from, and the time you leave it
  • Clicks and form submissions, in the application: When you click a link or a button, or submit a form, the event records what kind of element it was, its style classes, its place in the page's structure, the address a link points to, and the page you were on. The text shown on the element and its labels are not sent: a button or link in the application is often labelled with the name of a project, standard or datasheet, and the event says which control was used without saying what it was about. The address a link points to can contain our identifiers for a project, revision or document, which are codes and not names. Nothing else you do is captured: typing, scrolling and mouse movement are not sent as events, and neither is the content of a specification, datasheet, comment or conversation
  • Named events, in the application: That you started or completed signing up, and that you changed a datasheet field, each with how you arrived at the Services (from the library or directly) and no content
  • One page view per page, on the public SynC Standards library and our legal pages: The URL and path of the page, its title, the page you came from, and the visitor identifier; and on a standard with the "Use in a project" control, the two events described above. Nothing else you do on those pages is sent
  • With every event from your browser: browser and operating system family, screen size, the time, the per-browser identifier described under Cookie and browser storage below, and your IP address, which the processor receives with each event your browser sends and keeps with the event, and from which it derives a location to city or region level (Sections 1.2 and 15.3). The location is derived from a network address, not from your device, and can be wrong
  • Addresses, with any share-link token removed: The address of a share link contains the token that opens it. Before any event leaves your browser, that token is replaced with [redacted] in every address the event carries, so the processor never receives it
  • Events sent by our own server: When a signed-in user creates a project, imports a standard from the library, saves a datasheet revision, publishes, exports or distributes a project revision, starts a trial or has one end, takes or releases a seat, or asks for or is granted a sponsored seat, our server sends the processor an event naming what happened, with our identifiers for the user and for the project, revision or company concerned, and the facts the event is about (for example the revision code, or the number of seats in use and the limit). No content is sent. These events come from our server rather than your browser; no cookie is involved, and the time-zone rule above does not apply to them
  • A profile for each browser, signed in or not: The processor keeps the events sent under one per-browser identifier together, as a profile of that browser, with properties it derives from them, such as the location derived from the IP address, the browser and operating system family, and the page and referring site with which the browser first arrived. Every browser the processor hears from has one, including a browser that has never signed in and a browser reading the public SynC Standards library or our legal pages. Nothing is collected for the profile that is not already listed above; it is the same events, kept in one place. For a visitor who has not signed in, the profile carries no name, email address or account. When you sign in, the next item applies
  • Identification: When you sign in or create an account, we tell the processor that the per-browser identifier belongs to your user ID, and we attach your email address, your name and our identifier for your company, so that what you did before and after signing up can be read as one person's path and so that a person in the processor's records can be recognized. When you sign out, the link is broken and the browser starts a new anonymous identifier
  • Session replay, switched off as of the Effective Date: The processor can record what a session looked like: mouse movement, clicks, navigation, scrolling and the structure of the page, so that a user-experience problem can be diagnosed by watching it. Recording is switched off in our account with the processor as of the Effective Date, and no recording is made. We may switch it on. If we do, the masking in the next item applies from the first recording
• What is NOT received / how sensitive data is protected:
  • If session replay is switched on, all inputs and all text are masked. The recording is configured so that every input field, including every password field, and all text on every page are replaced with placeholder characters before the recording leaves your browser. A specification, a datasheet, a comment and a conversation with the AI assistant are rendered as text, so none of their content would appear in a recording; what would appear is the shape of the page and where you clicked. An element we mark with the ph-no-capture class is left out of a recording entirely; as of the Effective Date we rely on masking all inputs and all text rather than on marking surfaces, and no surface carries that class. Recording is also stopped for the whole of a page whose address is a share link, because the address is visible in a recording and masking does not reach it
  • No payment data: No payment details are entered anywhere on our surfaces. Payment card and bank account details are entered on a payment page hosted by our payment processor, outside the Services (see Payments below), so they are never present in the DOM available to PostHog.
• Where processed: United States (PostHog US cloud at us.i.posthog.com)
• Cookie and browser storage: Where the processor is loaded, it keeps the per-browser identifier in a first-party cookie and in your browser's local storage, both named ph_<project key>_posthog, so that the identifier survives between visits. On the public SynC Standards library and our legal pages, our own script uses that identifier if the browser has one and otherwise makes a random one and stores it in local storage under the name ph_wiki_did; when you later open the application in the same browser, the processor adopts it, so that a reader of the library who then signs up is counted as one person rather than two. None of these is essential to the Services, and clearing your browser's cookies and site data removes them (Section 10). We do not ask for consent to them, and in a browser the time-zone rule above excludes they are not set at all
• Right to object: You may ask at any time that your activity not be captured by this processor, including by session replay if it is switched on, by contacting privacy@synergyinconstruction.com (see Section 8.1)
• PostHog privacy policy: https://posthog.com/privacy
• PostHog Data Processing Addendum: https://posthog.com/dpa

Error Monitoring — our current error-monitoring processor (Sentry):

• Processor: Functional Software, Inc. d/b/a Sentry, based in the United States. SynC uses Sentry's US-region ingestion endpoint, so error data is transferred to and processed in the United States.
• Purpose: Detect, diagnose, and remediate frontend (JavaScript) and backend (server) errors and service-impacting incidents
• Categories of data received: Error message and stack trace, the URL and HTTP method of the request that triggered the error, browser and operating system information, and a breadcrumb trail of recent user actions in the application leading up to the error
• What is NOT received:
  • We configure Sentry with sendDefaultPii: false, so Sentry does not receive your IP address or your browser cookies by default
  • Sensitive HTTP headers are automatically scrubbed before transmission, including Authorization, Cookie, and Set-Cookie
  • Request and response body fields with sensitive names — including password, secret, token, api_key, access_token, and refresh_token — are automatically scrubbed before transmission
  • Routine 4xx client errors (e.g., validation failures, "not found," "unauthorized") are filtered server-side before transmission and are not sent to Sentry; only 5xx server errors and uncaught exceptions are reported
• Where processed: United States (US-region ingest at ingest.us.sentry.io)
• Sentry privacy policy: https://sentry.io/privacy/
• Sentry Data Processing Addendum: https://sentry.io/legal/dpa/

Email Delivery — our current transactional-email processor (Amazon SES):

• Processor: Amazon Web Services, Inc., based in the United States. SynC sends email through Amazon Simple Email Service ("Amazon SES") in a US region, so the messages we send you and the delivery and interaction data described below are processed in the United States.
• Purpose: Deliver the email the Services send — account verification, invitations, share-link notices, notifications, and required legal notices — and see whether that mail is delivered, bounces, is reported as spam, or is acted on
• Categories of data received: Your email address and the content of the message we are sending you; the delivery outcome of that message (delivered, bounced, or complained-of); and the email interaction data described in Section 1.2 — that a link in a message was followed and which link it was, together with the IP address, date and time, and client information accompanying that request. Where open tracking is enabled on our account, that a message was opened, with the same accompanying details
• Link rewriting, and what you will see: Links in the email we send are rewritten so that they resolve through this processor's tracking domain, awstrack.me, which records the click and then redirects you to the destination on our site. The address shown when you hover over a link in our email is therefore an awstrack.me address rather than a synergyinconstruction.com one. We state this plainly because it is visible to you and an unfamiliar address in an email is a reasonable thing to want explained.
• What is NOT received: Nothing you enter into the Services is transmitted to this processor other than the content of the message being sent to you. Your specifications, datasheets, project content, and conversations with the AI assistant are not sent to it, except to the extent a notification we send you quotes the item it is notifying you about. Email interaction data is not written to your SynC account or to our application database.
• Where processed: United States
• Tracking is configured at the processor, not in the Services. Link rewriting and open tracking are settings on our email-delivery account rather than features built into the application, so they apply to mail we send regardless of which part of the Services generated it. Section 8.1 states what this means for objecting to them.
• AWS privacy notice: https://aws.amazon.com/privacy/
• AWS GDPR Center (including the AWS Data Processing Addendum): https://aws.amazon.com/compliance/gdpr-center/

Payments — our current payment processor (Stripe):

• Processor: Stripe, LLC, based in the United States — the Stripe entity that contracts with businesses located in the Americas.
• Purpose: Sell seats and AI credit packs to companies, charge and renew seat subscriptions, host the billing portal on which a company changes or cancels its subscription, and issue invoices and receipts.
• How it is used. The Services are connected to this processor. When a person authorized by your company buys seats or credits, the Services send the processor what it needs to take the payment and open the purchase page, the purchaser completes the purchase on a page the processor hosts, and the processor then reports back to the Services what happened, so that the Services can grant what was bought and keep its record current. A seat subscription renews automatically through the processor, which charges the payment method your company gave it; the Terms of Service §10 state when and on what authority. Where seat or credit fees have been agreed with your company in writing instead, we raise an invoice in our account with the processor and your company pays it on a page the processor hosts.
• Categories of data sent by us to the processor: Your company's name, its contact email address if one is on file, our identifier for your company and for the purchase attempt, the item and quantity being bought, and, for a purchase made during your company's trial, the date the trial ends. For a company we invoice against a written agreement, the billing contact details described in Section 1.1 and the content of the invoice.
• Categories of data you give the processor directly: The payment card details, the purchaser's name and email address, the billing address, and any promotion code you enter on its hosted page, and any change of payment method or billing email or address you make on its billing portal. Card details go to the processor, not to us. We never receive, see, or store a card number or bank account number.
• Categories of data received by us from the processor: For each purchase and each change to your company's subscription, the processor sends the Services an event record stating the status of the subscription, the items and quantities it covers, the dates of the current period, any change booked to take effect at renewal, the amounts charged and whether they were paid, a link to the hosted invoice, and the billing name, email address and address the purchaser entered on the processor's page. The record may state the kind of payment method used; it never contains its number. We store these records (Section 5.1).
• What is NOT sent or received: Your account credentials, your specifications, datasheets, and project content, your conversations with the AI assistant, and your usage data. None of this reaches the processor. Section 15.3 states what the exchange above means for the categories of information we disclose.
• Where processed: As the processor's Data Processing Agreement, linked below and on our subprocessor list, states; we do not restate it here.
• The processor's own role: Stripe's Data Processing Agreement states that Stripe processes some personal data as a data processor on our behalf, and other personal data as an independent data controller. When you enter payment details on its hosted page, Stripe collects them directly, and Stripe's own privacy policy governs that processing (see Section 11).
• Stripe privacy policy: https://stripe.com/privacy
• Stripe Data Processing Agreement: https://stripe.com/legal/dpa

Scheduling (Cal.com), where our website offers a booking page:

• Processor: Cal.com, Inc., based in the United States, which hosts the page on which you book a call with us. Its name is shown in the address of that page and on the page itself.
• Where this applies: Only where our website offers a booking page. Until it does, nothing is sent to this processor; it is named here so that the disclosure precedes the practice.
• Purpose: Let you pick an open time for a call with us, receive a calendar invitation with a video link, and receive any reminder or change; send the same invitation, reminder or change to each colleague you choose to invite; and place the booking in our calendar.
• Categories of data you give the processor directly: Your name, work email address, company name, the optional line you write, the time you chose, and, if you choose to invite colleagues, the email address of each colleague you enter. You enter these on a page the processor hosts, and the processor's own privacy policy, linked on that page and on our subprocessor list, applies to what you enter there. A colleague you invite enters nothing and has not seen that page: the processor sends them the invitation at the address you entered, and the invitation says so (see A colleague you invite below).
• Categories of data received by us from the processor: The booking, meaning those same details, the time and the address of each colleague you invited, placed in our calendar, which is held with our workspace provider (Google Workspace, named on the subprocessor list) together with the video-meeting link for the call.
• What is NOT received: Nothing else. The scheduling processor receives no account credentials, no content, no conversations and no usage data, and a booking is not linked to a SynC account; if you later create one, the two are not joined.
• A colleague you invite: Has not seen the booking page and has asked us for nothing. What we hold about them is the email address you entered, with the booking, and nothing else. The invitation they receive from the processor, which names SynC as the organizer, is how they learn of it, and it carries a line from us saying that their address was entered by the person who booked, that we hold the booking to run the call and to follow up about it and for nothing else, and where this Policy is. A colleague can ask us to remove their address from the booking (Section 8.1). Section 3 states the basis on which we hold it.
• After the call: We may email you, and a colleague who attended, about the call: to send what we said we would send, to answer what was asked, or to propose a next step. It is correspondence about the call and is not marketing email; Section 12 governs that separately, and nothing in booking or attending a call subscribes anyone to it.
• Recording the call: At the start of a call we may ask everyone on it whether we may record it. If anyone declines, the call goes ahead unrecorded. Where everyone agrees, we record the call ourselves, on our own equipment, capturing what is shown and said on it, and we hold the recording in our own storage; neither the scheduling processor nor the video-meeting service makes or receives it. We may later make a transcript or meeting notes from the recording. If we use a service to do so, that service is named on our subprocessor list before we send it anything, as the list states for every provider; as of the Effective Date none is named for this purpose. We ask on the call, not on the booking page, and nothing on the booking page is consent to recording. No one outside SynC sees a recording, transcript or note. We keep them for our own reference and for following up on that call; we do not publish them, use them for marketing, use them to train, fine-tune or evaluate a model, or use them to evaluate or improve the Services under Section 2.2. Section 5.1 states how long they are kept and Section 8.1 how anyone who was on the call has them deleted.
• Where processed: As the processor's privacy policy and subprocessor list, linked below and on our subprocessor list, state; we do not restate them here.
• Cal.com privacy policy: https://cal.com/privacy
• Cal.com subprocessor list: https://trust.cal.com/subprocessors

Search telemetry is first-party. The wiki-search records described in Section 1.2 are stored in our own database and are not disclosed to any of the processors named above, nor to any other third party.

Microsoft and Google, when you sign in with them, are not our processors, and are not on our subprocessor list. A provider you sign in with acts for you and, for a work account, for the organization whose directory it is; it does not process your information on our behalf. Information flows from the provider to us (Section 1.3), not the other way. What the provider learns from us is that you asked to sign in to SynC, and when; we send it nothing else about you, and it holds nothing of yours from the Services. What it does with its own record of that sign-in is governed by its privacy policy.

An app or tool you connect to your account with an API key, and the company that makes it, are not our processors, and are not on our subprocessor list. Such an app acts for you, under the terms you agreed with its maker (Section 4.10). It does not process your information on our behalf, we give it no instructions, and we have no agreement with its maker about what it does with what it receives. Information flows from us to the app because you gave it your key, within the permissions you put on that key. What the app's maker learns from us is what the app asks for on your behalf and what we answer; what it does with that is governed by its own privacy policy.

The breached-password check sends no personal information anywhere. When you set a password, and when you use a password to sign in, our server computes a one-way hash of it and sends the first five characters of that hash to a public breached-password lookup service, which answers with the list of exposed hashes that begin the same way; the comparison against the rest of your hash is made on our server. The password never leaves our servers, the full hash never leaves our servers, and the five characters go with nothing that identifies you: no account, no email address, no name, no cookie, and our server's address rather than yours. A five-character prefix matches many hundreds of unrelated hashes and cannot be turned back into a password, so we do not treat it as personal information, and this lookup service is not a processor of your personal information. If the service does not answer within two seconds, the check is skipped rather than blocking you. Section 6.1 states what the check is for and what happens when it finds a match.

These service providers have access to personal information only to perform services on our behalf, under contractual terms that limit their use of it to providing the service to us. For the downstream AI inference and embedding hosts, the controls we apply are described in Section 4.1A.

4.1A AI Inference and Embedding — What Leaves Our Servers

Two features transmit content to a third party.

AI assistant (inference). Your prompt and the project or standards content relevant to your request are transmitted to an inference provider, together with our internal identifiers for your account and your company, which the assistant uses to address its requests to our own systems and is instructed not to display. The assistant operates under your own permissions and can read only what your account is entitled to read.

Continuing a stored conversation transmits that conversation to an inference provider again, because the provider holds no memory of it between requests. What is transmitted is the stored form described in Section 1.1 — the prose of the exchange, with machine payloads already reduced. Generating a conversation's title is a separate, small request over that same content. Opening the assistant to read a conversation you already had transmits nothing: displaying stored history is a read from our own database, not a request to a provider.

Summarizing a long conversation. When a conversation grows long, the earlier part of it is condensed into a written summary. The summary is produced by a separate request to the inference provider over that earlier part, in the stored form described above, and is stored with the conversation (Sections 1.1 and 5.1). From then on, continuing the conversation transmits the summary, the stored record of each change the assistant made or proposed in that earlier part, the last note of where in the Services you were working, and the recent part of the conversation, in place of the whole of the earlier part. A conversation that goes on growing may be summarized again, from the earlier summary and the part of the conversation since it. None of this changes what you see: your transcript stays complete, the summary is not shown in the Services, and the conversation shows only a line where a summary was made. A summary is built from your own conversation alone.

What the assistant is told about you. Each request to the assistant also carries a short statement of who it is working for, in two parts.

The first part states what you may do: whether your account may create projects and may use the assistant to make changes, and, where you are working in a project, what your role on that project lets you do, for example that you can edit the draft but cannot add standards, publish or distribute, and whether you belong to the company that owns the project or are an outside party to it. These lines are sent with every request. They stop the assistant proposing actions you cannot take; they describe your rights and do not change them, and the Services enforce every action regardless of what the assistant was told.

The second part is about you, and you can switch it off (Section 8.1): your first name; your professional role, your discipline and the type of company you are with, each sent as a label from a fixed list rather than as text you typed; the name of your company, sent as it is recorded on SynC, which is the one value in this part sent as text rather than as a label; and, where you are working in a project, how that project records your company among its participants, as one or more of the four roles a project can record, Development Owner, Engineer of Record, Prime Contractor or Subcontractor, each sent as a label and marked where your company has not confirmed it. A role your company has declined is not sent, and where the project does not name your company at all, which is the usual case, nothing is sent about it. Where you are associated with more than one employer, the one relevant to the project you are working in is used, or otherwise your primary employer; the assistant is not told about the others. A field you have not filled in is left out rather than sent as unknown. The whole statement is capped in length.

Not sent: your surname, your email address and phone number, any other employer you are associated with, your seniority, anything you wrote in a free-text field other than your company's name, the names of the other companies on a project, including the company whose project it is where that company is not yours, your billing details, and your location. Nothing in the statement is an instruction to the assistant, and the assistant is told so.

The statement is fixed when a conversation starts and stored with it (Sections 1.1 and 5.1), so a change to your profile, or to the switch, reaches the assistant in your next conversation rather than the one under way. It is not sent with the separate request that generates a conversation's title. The Services show you the exact lines sent, from the assistant's own panel (Section 8.1).

Semantic search (text embedding). To make content searchable by meaning rather than only by keyword, text is converted into numeric vectors by a third-party embedding service. The vectors are stored in our database. Our configuration excludes embedding endpoints that retain submitted text for their own purposes or use it for training; the current hosts, and the specific controls applied to them, are published on the subprocessor list. This covers public SynC Standards content and your own standards and project specifications, so search works the same way over private content. Search queries you type are embedded the same way.

How we constrain the processing. A request reaches a provider in one of two ways, and the subprocessor list states which providers we may use on each.

• Directly, on our own account with the provider. We rely on the provider's terms with us, which do not permit it to use submitted content to train its models or to retain it for its own purposes, and on its published data-handling terms, which the subprocessor list links. We do not ask the provider to store completions on our behalf.
• Through a routing service, which selects a host from a set we specify. On that path our configuration is designed to prohibit logging and training at the host, by excluding hosts the router classifies as logging on or training on submitted content; to restrict processing to hosts we have vetted, with automatic failover disabled, so that an outage produces a failed request rather than a reroute to a host we have not vetted; and to fail closed, so that if no host satisfies our constraints the request fails, search falls back to keyword matching, and AI features return an error, rather than the constraint being relaxed to complete the request.

On either path, content goes only to a provider named on the subprocessor list, and a provider is named there before any request is sent to it. The constraints above apply to the request as a whole, including the statement about you described above. This Section describes the AI assistant and semantic search, which are features of the Services. It does not describe an app or tool you connect to your account yourself with an API key, which Section 4.10 describes: content such an app reads goes to that app's maker at your direction, and the controls above do not reach it.

These are the categories of control we apply. The specific mechanisms, and the hosts they apply to, are published on the subprocessor list and may change; Terms of Service §5.3.3 states what we will do if a change materially reduces the level of protection. Where an engagement requires zero-data-retention processing or a restricted set of processing jurisdictions, contact privacy@synergyinconstruction.com.

What a request carries. A request carries the content in scope for that request and the statement about you described above, and nothing else about you: never your credentials or your payment details, and never your whole account. Where you are working in a project shared with you, the request carries that project's content, which you are authorized to read. Where we use your content to evaluate or improve the Services (Section 2.2), a request that sends it to a provider for that purpose is subject to the same controls as the requests described above and goes only to a provider named on the subprocessor list; no provider is used for that purpose that is not used for the Services themselves.

Retention on our side. Embedding vectors, and a cache of query vectors, are stored in our own database under the "Derived Search Data" retention rules in Section 5.1. Vectors are derived data: deleting the underlying content removes it from the search index. Stored conversations, and the summaries made of them, are retained under the "AI Assistant Conversations" rules in the same Section.

4.2 Collaboration and Sharing Features

When you use collaboration features, we share information with:

• Team members and colleagues you invite to projects
• Companies and organizations you collaborate with
• Users you grant access to specific documents or projects through share links

You control what information is shared through your permission settings and project configurations. A record you make in a company's project or library shows your name, as Section 1.2 describes, to everyone who can see that record, including the recipients of a revision distributed from it.

Apps and tools a recipient connects. A person you share a project with may connect an app or tool of their own, for example an AI assistant they use, to their SynC account with an API key (Section 4.10). Where your share link's export setting allows it, that app can read the project you shared, through our API, acting for that person and within the access you gave them. Content the app reads goes to that app's maker under the maker's terms, not ours: the maker is not one of our service providers, is not on our subprocessor list, and the constraints in Section 4.1A do not apply to it. You control this with the same setting that controls export, and a link whose export setting is off is not readable through a recipient's app. An administrator of your company can also switch off access by API keys and connected apps for all of your company's projects (Section 8.1). Each read is in our request log, as Section 1.2 describes.

Your conversations with the AI assistant are not part of this. They are not shared with anyone through the collaboration features, and they are not affected by your permission settings or project configuration. Section 4.2A states the rule that applies to them instead.

4.2A Conversations with the AI Assistant Are Private to You

A conversation is private to the person who had it, and stays that way. The Services provide no means by which anyone other than you can view one of your conversations: there is no sharing control, no copy of it visible to your team, your company, a project owner, or another participant in a project you both work on, and no administrative view of your conversations inside the product. Conversation content is never included in a published document, in a revision record, or in any export of project content. We do not intend to add a sharing surface for conversations; if that ever changed, it would be a material change to this Policy and Sections 13.1–13.3 would apply.

This is a statement about what the Services do, not a claim that the stored records are beyond our reach. Like every other category of information described in this Policy, stored conversations sit in our database, and our personnel may access them where it is necessary to operate, secure, or repair the Services, to answer your own request under Section 8, or in the circumstances described in Section 4.7. Access of that kind is limited on a need-to-know basis under Section 6.1.

Your own past conversations are retained as your record. A conversation is kept for you, and keeping it does not depend on your still having access to the material it discusses. If your access to a project or a document ends — because a share link was removed, because your role changed, because you left a company, or because the content itself was deleted — the conversations you had before that remain in your account until they are deleted under Section 5.1 or you delete them yourself.

We do not tell you that a stored conversation contains no project content, because that would not be true. Reducing machine payloads (Section 1.1) removes the raw data an action returned; it does not remove the assistant's prose, and prose written about a specification necessarily restates parts of it. What this Policy gives you instead is specific and checkable: a bounded retention period, a record that is visible to no other user of the Services, and the ability to delete any conversation yourself at any time, immediately (Sections 5.1 and 8.1).

4.3 Company Profile Visibility

When your company creates a profile on the Services, the following information is visible to other authenticated users through the company search and discovery features:

• Company name
• Company type(s)
• Company description
• City, state, and country (no street address is disclosed)
• Website URL

This visibility enables essential platform functionality, including allowing users to join their company, discover collaborators, and invite companies to bid on or participate in projects. Individual user information (names, emails, phone numbers) is not exposed through company search.

4.4 SynC Standards Attribution

When you contribute to SynC Standards, your contributor attribution — which may include your display name, account identifier, and the name of your affiliated organization at the time of contribution — is displayed on adopted revisions in accordance with the CC-BY-SA 4.0 license attribution requirements. The treatment of contributor attribution is governed by our separate Contributor License Agreement ("CLA"), Section 2A.

This Section describes the public SynC Standards library only. A company's record of your work in its own projects and libraries follows a different rule, stated in Sections 1.2, 5.1 and 5.2: it keeps the name you had when you made the record, including after your account is deleted, and it is not pseudonymized.

If you delete your account, your public-facing contributor attribution is removed from the SynC Standards Wiki and from any project that has imported your contribution by reference, so that a member of the public can no longer identify you as the contributor (CLA §2A.3). Your contribution itself remains in the public repository under CC-BY-SA 4.0 (see Section 5.1). Separately, SynC retains a limited, non-public, access-restricted record linking each contribution to the contributor who made it, kept only as reasonably necessary to establish, exercise, or defend legal claims and to maintain the integrity of the attribution and licensing chain required by CC-BY-SA 4.0 (CLA §2A.4). Because that retained record makes it possible, in principle, to re-associate an otherwise public-anonymized contribution with you, the overall treatment of your contributor-attribution data is pseudonymization rather than anonymization for the purposes of data-protection law. The retained record remains personal data, and this Privacy Policy and applicable data-protection law continue to apply to it.

How your attribution appears is your choice. You may elect to have your public-facing attribution shown under a pseudonym instead of your name: for a single contribution, for all of your contributions to one standard including future ones, or for all of your contributions. You may make that election at any time and reverse it at any time (CLA §2A.5). We record each election and each change to it privately, as a record of your account. No election or change is published, in the moderation log or anywhere else. The election replaces your display name with a stable pseudonym and removes the name of your affiliated organization from the public-facing attribution; your Affiliation Type, Primary Specialty and Professional Role are preserved, for the reasons stated in CLA §2B. The election does not affect the limited non-public record described above, and it does not affect the anonymization applied on account deletion, which applies whether or not an election is in force.

One consequence, stated plainly. Where SynC withholds material from a standard under Terms of Service §5A.6, the public notice in its place states the adopted revision in which the withheld material first appeared. The notice names no person. But an adopted revision has a public contributor byline, so a reader of the notice can reach the byline of the revision it names in one step. We state the originating revision because a notice that did not would implicate every later contributor who merely carried the material forward. We state this consequence because you should know it exists, and because the election described above is what answers it. We will not ask you to use it, and we do not treat using it as a response to any notice.

Where the moderation record can be found. The public moderation log is readable without signing in, and its main register is reachable from search engines. Individual entries have addresses of their own, which withheld-material statements and notices cite. Those entry pages ask search engines not to index them.

4.5 Aggregated Statistics

We may share aggregated statistics about how the Services are used, of the kind described in Terms of Service §5.3.2, with research partners and academic institutions, industry organizations and standards bodies, business partners, and the public, including in industry reports and benchmarks. A statistic we share outside the Services never names or identifies a customer, a project or a person, is never derived from the content or usage of a single customer, and is aggregated across enough customers that no customer's contribution to it can be worked out from it. Where a figure would not meet that test, we do not share it. We do not name a customer as a source of a statistic without its written agreement.

We do not share your content, or any adaptation or excerpt of it, with those recipients, whether or not identifying details have been removed. De-identifying content does not make it shareable. See Terms of Service §5.3.1.

Citation counts shown inside the Services. Separate from the third-party sharing above, the Services display one aggregate statistic to other users. When you publish a document on the main site — a standard in your company, project, or personal library — each citation it makes to a SynC Standard is recorded in a citation index at the moment of publication (Section 5.1 states the retention rule). On a SynC Standard's page, and through the corresponding API, the Services may show how many citations point at that standard or at a clause of it, including citations made in documents the viewer has no right to read. Where the viewer cannot read the citing documents, the disclosure is a single number of citation occurrences and nothing else: no titles, no authors, no organizations, and no other detail of the response varies with those documents. The number counts occurrences rather than documents, so it does not reveal whether one document cites a standard nine times or nine documents cite it once. A citing document is named, linked, or excerpted only to viewers who are already authorized to read that document. Because SynC Standards pages are public, the number itself is public: an observer who watches it change over time can infer that some published document citing the standard was published, revised, or deleted, but not whose document, which document, or what it says. Drafts and unpublished content are never counted.

4.6 Business Transfers

If SynC is involved in a merger, acquisition, asset sale, bankruptcy, or other business transaction, your information may be transferred as part of that transaction. We will notify you via email and/or prominent notice on our Services before your personal information is transferred and becomes subject to a different privacy policy, or, where the transaction does not allow notice before the transfer, as soon as the law and the transaction allow.

4.7 Legal Requirements and Protection

We may disclose your information if required to do so by law or in good faith belief that such action is necessary to:

• Comply with legal obligations, court orders, or subpoenas
• Protect and defend the rights or property of SynC
• Prevent or investigate possible wrongdoing in connection with the Services
• Protect the personal safety of users or the public
• Protect against legal liability

4.8 With Your Consent

We may share your information for other purposes with your explicit consent or at your direction. Giving an app or tool your API key, and asking it to read content, is a direction of this kind for the content it reads (Section 4.10).

4.9 Copyright Notices We Receive

If you send SynC a copyright notice (Terms of Service §5B.3), this Section states what we do with the information in it. A notice reaches our Designated Copyright Agent by email, by post or by another channel, and it carries what the statute requires of it: your name or your organization's name, your postal address, telephone number and email address, the work you say was copied, the material you say copies it, and your sworn statements.

What goes to the author. When we act on a notice against material in the SynC Standards library, we email the author of the identified revision a copy of the notice as we received it, with your postal address, telephone number and email address removed. Your name or your organization's name, the work identified, the material identified, your statements and the date stay in the copy. It goes with fixed cover text stating that the notice is your statement and not ours, and that SynC has made no finding about the author or about what they wrote. The copy goes by email only: the notification the author sees in the Services says that a copy has been emailed and carries none of the notice's text. Where we have no email address for the author, no copy is sent, and we record that. We send it so that the author can decide, knowing what was claimed and by whom, whether to send a counter-notification, which the law requires us to forward to you in full (Terms of Service §5B.4). A notice about material stored in a project is not copied to anyone. Terms of Service §5B.3 and §5B.4 state this to senders and to authors; this Section discloses it.

What does not go anywhere. Your contact details are used to correspond with you. They are not given to the author, to the administrators of any project, or to any other user, except where the law requires it or a court orders it (Section 4.7). The public moderation log names no complaining party (Section 5.1), and the internal record we keep of a notice holds neither your name nor the notice's text.

Where the notice lives. The notice itself is kept as correspondence in the Designated Copyright Agent's mailbox, not in the Services' database. Section 5.1 states how long it is kept, and what we record about the copy sent to the author.

4.10 API Keys, and the Apps and Tools You Connect With Them

You can create an API key for your account and use it from an outside app or tool: a developer tool, a script of your own, or an AI app such as a general-purpose assistant, which can reach our API directly or at the address the Services publish for AI apps. This Section states what such an app receives, what it cannot receive, who is responsible for what, and what we can and cannot control. A key is the credential the Services issue for this as of the Effective Date; where the Services issue a credential of another kind for the same purpose, this Section applies to it in the same way. An app or tool that presents your key is a "connected app" in this Policy, and Terms of Service Section 4A states what you and SynC each owe in respect of one.

You create the key, and you choose what it may do. A key is created by you, signed in to SynC, after you confirm it is you (Section 6.1). You pick the permissions it carries from among your own, and you can give it less than you can do yourself, down to reading only. Publishing a project revision, saving a standard revision, sharing or distributing a project, deleting anything, and moderation start unticked; a key has them only where you ticked each one. Nothing acts as you until you give a key to an app or tool.

What a connected app receives. An app or tool with your key can ask for what you could read yourself in the Services, within the permissions on the key: your projects, specifications, datasheets, files, comments, your company's library, the SynC Standards library, search results, and your own account details as the Services show them to you. Each answer carries what the record carries, including the names of the people on it, as Section 1.2 describes, and for a revision, which revision it is. If the key carries permission to make changes, the app can make the changes you could make yourself, except those no key can make. The app receives an answer only when it asks; we send nothing to it on our own, and we send it nothing about you that it did not ask for.

What a connected app cannot receive or do. No key can read or change your sign-in methods, your passkeys, your sessions or your other keys, act on your company's billing, seats, membership or roles, bring a person into a project or appoint who leads it, or do anything the Services ask you to confirm it is you for. Those are done by signing in to SynC, whatever permissions a key carries. A key can never do more than you can: every request is checked against what your account can do at that moment, so if you lose a seat, leave a company or lose access to a project, every app using your key loses the same reach on its next request, with no step for you to take.

The app is yours, not ours. The app you connect, and the company that makes it, are not our processors and are not on our subprocessor list (Section 4.1). They act for you under the terms you agreed with them. We have no agreement with the app's maker, give it no instructions, and do not know what you ask it. We control what leaves: what a key may read and change, revocation, the record of every request, and the limits on how often it may ask. We do not control what happens after. We cannot control what the app's maker stores, keeps or trains on; whether the app asks you before it makes a change the Services would allow; or whether the app is misled by text inside the content it reads. The commitments in Sections 2.2 and 4.1A about the providers we use for our own AI features, including that they may not retain your content or train on it, are commitments about those providers, and they do not reach an app you connect. Whether the app's maker keeps what it reads, and whether it trains on it, is a matter of that maker's terms, which you should read before you connect.

Other people's information. What a connected app reads can name people other than you: a colleague on a company's record, a recipient who commented, a supplier's staff on a transmittal. We send those names only because they are on the record you could read yourself, on the same footing as an export of that record would carry them. The companies whose records you can read keep their own authority over them: an administrator of your company can see which members hold a key and how it has been used, and can switch off access by API keys and connected apps for the whole company; and a company that shares a project with you decides, through its share link's export setting, whether an app you connect may read what it shared (Section 4.2). Where a setting of that kind stops a request, the app is told so in plain words, so that you can ask the sender or your administrator.

Seeing and ending a key. Your keys are listed in your account, each with its name, what it may do, when it was created and when it was last used, and the recent requests made with it. You can revoke or rotate any of them at any time; revoking takes effect on the next request, and rotating stops the old secret working. Revoking a key does not remove SynC from any list the app keeps of the services you connected, and does not remove what the app already received; that is done at the app, under its terms. Section 8.1 states these controls.

Limits. We limit how often your keys may ask, per person across all of your keys and connected apps together, and the limit follows whether you hold a seat. A request over the limit is refused with a plain answer the app can repeat to you.

5. Data Retention

5.1 Retention Periods

We retain your information for as long as necessary to fulfill the purposes outlined in this Privacy Policy, unless a longer retention period is required or permitted by law.

Account Information:

• Retained while your account exists, including while it is suspended (Terms of Service §16.2)
• Retained for 30 days after account deletion, which is the period in which the account can still be restored, and then deleted or anonymized as Section 5.2 states; a copy may persist in database backups for the period stated under Backups below
• Our record of which of your addresses is your recovery address (Section 1.1) is part of your account information. It is kept until you change or clear the designation or remove that address from your account, and it is deleted with your account
• The history of the names your account has used (Section 1.1) is not deleted or anonymized with your account. It is kept for as long as any record that is read from it, under User Content and Project Data below, and we do not edit it
• Where two of your accounts are merged into one, by an administrator or at your own request, the record of the merge is kept as the statement that the two accounts were the same person, and the records each account made keep that account's own name
• Certain information may be retained longer to comply with legal obligations

Sign-In Methods and Sign-In Security Records (Sections 1.2, 1.3 and 6.1):

• A linked Microsoft or Google identity (the provider, its identifier for your account, the address it asserted when the link was made and whether it had verified that address, when the link was made, and when it was last used) is kept for as long as the link exists. Removing the method in Profile → Security deletes the record at once. It is also deleted when your account is permanently deleted, and it moves with your account if an administrator merges two of your accounts into one. The audit entry that a method of that provider was linked or unlinked, and when, is kept with your account and does not carry the identifier
• Removing a sign-in method changes nothing at the provider. The provider may continue to list SynC among the applications you have signed in to, under its own controls; removing SynC there is done at the provider, not here
• A passkey (its public key and credential identifier, its usage counter, how it connects, whether it is of a kind that syncs and whether it does, the model identifier of its authenticator, its name, and when it was added and last used; Section 1.1) is kept for as long as it is on your account. Removing it in Profile → Security deletes the record at once, and we email you that it was removed, naming the passkey. It is also deleted when your account is permanently deleted. The audit entry that a passkey was added or removed, and when, is kept with your account
• Removing a passkey here does not remove it from your device or from the password manager that holds it; that is done there, and until it is, the device will still offer a passkey that no longer works
• Failed sign-in records are kept only while they are doing their job: a successful sign-in with the method that failed, or a password reset, deletes the record for that address, and a record untouched for seven days is deleted. Because the record holds a hash of the address rather than the address, we can find the record for an address we are given, and no one reading the store can recover the addresses in it. Records of wrong codes are kept in the same way
• The 6-digit email code is single-use and short-lived: it stops working when it is used, shortly after it was sent, after repeated wrong attempts, or when a newer verification email replaces it, whichever comes first, and the stored form of it is cleared when it is used. The link in the same email is short-lived too. The record that the address was verified is part of your account information above
• The 6-digit sign-in code is single-use and short-lived in the same way: it stops working when it is used, shortly after it was sent, after repeated wrong attempts, or when a newer code replaces it, and the stored form of it is cleared when it is used or replaced. The record is deleted within a day of the code being sent, whether or not the code was used. A code sent with the notice that a signup named your address is the same kind of record and lives the same life

Signed-In Sessions (Sections 1.2 and 8.1):

• A browser session, with the sign-in time, the sign-in method, the last-use time, the browser's description of itself and, once you have confirmed it is you before a sensitive change (Section 6.1), the time and method of that confirmation written on it, is kept until the session ends, and the facts written on it go with it. There is no separate record of them
• A session ends when you sign out of it, when you end it from Profile → Security, when it is ended for you (a change of your password ends your other sessions, a reset of your password or a disabling of your account ends all of them), or seven days after the browser last used it. A session that is signed out or ended is deleted at once; one that has expired is deleted shortly after
• The audit entry that you ended one or all of your other sessions, and how many, is kept with your account, and so is the audit entry that you confirmed it is you, how and when, with the network address and browser of that request (Section 1.2)

API Keys and the Request Log (Sections 1.2, 4.10 and 6.1):

• An API key (its name, permissions, creation, rotation and last-use times, the network address it was last used from, and the key in a form that cannot be read back) is kept while the key exists. Revoking a key ends its use at once; the record of the key is kept, marked as revoked, so that the requests logged against it can still be read for as long as they are. Keys are revoked when your account is terminated (Terms of Service §16.3), and the key records go with your account on the schedule stated under Account Information above
• The request log (Section 1.2) is kept for 90 days from each request and is then deleted by an automated nightly job. Rows made with your keys are deleted on that schedule whether or not your account still exists, and a deletion request does not shorten it

User Content and Project Data:

• Retained while your account exists, including while it is suspended (Terms of Service §16.2)

• Content that belongs to your account alone is retained for 30 days after account deletion so that it can be exported under Terms of Service §16.4, and may be deleted after that

• Content stored in a company's project, including files you uploaded to it, is that company's project record, not content that belongs to your account alone. It is not deleted when your account is deleted; it remains with the company, as Terms of Service §16.2 states. Where a file is part of a published revision, it cannot be removed or replaced: the revision is fixed once published, every copy distributed from it is checked against it, and the Services refuse the change. When your account is permanently deleted, the file, its description, its place in the project and the company's record of who uploaded it remain

• A company's record of who did what in its projects and libraries keeps the name you had when you made the record, after your account is deleted. The record stores our identifier for your account and the time of the act; the name it shows is read from the history described in Section 1.1, which account deletion does not change. So a revision you published, a draft you started, a file you uploaded, a comment you wrote, a standard you adopted, changed or archived, a datasheet you saved, and the records that you created or accepted a share link, show the name you had at the time, to the company and to the recipients of what it distributed, for the life of the record; the distribution records among them follow the fifteen-year rule below. A company's projects are not deleted by any process we run (below), and we apply no clock of our own to these records. Everything else that identified you is removed on the schedule stated under Account Information above. Deleting your account is not a way to remove your name from these records; Section 5.2 states who can ask for a name to be withheld, and what a withholding does. The same rule applies to a person named on a company's records who was not a member of that company, such as a recipient who commented on a revision or forwarded one

• A company's projects are not deleted by any process we run, whether the company's account is open, suspended or ended. A project with no activity for the period the company has set, 24 months unless it changes it, is archived, and after the company's retention period it is flagged for administrator review; removing it is a decision someone takes, not a process that runs. We do not promise that a project is deleted at any point

• Uploaded files are backed up each night. A file you upload is held in our object storage and copied each night into a separate backup, as Backups below states. A file that leaves the Services persists in that backup for the period stated there

• A copy of content in the database may persist in database backups for the period stated under Backups below

Backups (Sections 5.2 and 6.1):

• Database backups are taken daily and kept on a fixed schedule. On our own server we keep the seven most recent daily copies, the four most recent weekly copies and the three most recent monthly copies, together with the five most recent copies taken immediately before a deployment of the Services. In our cloud storage (Cloudflare R2), daily copies are kept for up to 30 days, weekly copies for up to 84 days and monthly copies for up to 365 days. A second weekly copy is kept in a separate cloud storage account (Google Drive) for up to 120 days. Both providers are named on our subprocessor list
• A database backup holds the database as it stood when it was taken, including personal information that has since been deleted or anonymized in the live Services. Information removed from the live Services therefore persists in backups until the last copy that holds it ages out, which can be up to 365 days after the removal. We do not edit backups, and a deletion request (Section 5.2) does not reach them
• A backup is used to restore the Services after data loss, and for nothing else. Restoring a database backup returns the database to the state it was in when the backup was taken. We do not restore a backup in order to recover information that has been deleted
• Database backups are encrypted before they leave our server, so every copy, on our server, in Cloudflare R2 and in Google Drive, is encrypted
• Uploaded project files are backed up each night. Each night, the files uploaded to projects are copied from our object storage into a separate backup bucket at the same provider (Cloudflare R2). That bucket has its own write credentials, and a lock at the provider stops early deletion. The backup is a mirror of what the Services hold: a file the Services hold is in it, and a file uploaded since the last nightly copy is not yet in it, so the backup can be up to about a day behind. The Services remove a stored file only when no revision of the project uses it any more: removing a file from a draft does not remove it while a published revision uses it, and reverting a draft removes only uploads that nothing else uses. When a file leaves the Services, its copy in the backup is moved to a removed area and deleted 365 days later, by the backup process and by a rule at the provider; nothing is kept beyond that. A removed file therefore persists in backup for up to 365 days after it leaves the Services. That period is chosen to match the longest a database copy is kept, so that the files a database copy refers to are kept for as long as it is. The file copies are not encrypted by us, unlike the database backups. Our storage provider encrypts every stored file, in the live storage and in the backup, at rest with AES-256, using keys the provider manages. Files are not copied to the second cloud storage account; only the weekly database copy goes there
• This is the schedule we run as of the Effective Date. If it changes, we will state the new schedule here under Section 13

Content Used to Improve the Services (Sections 2.2 and 8.1):

• What we keep for this purpose is a copy of content a feature processed, what the feature produced, and a record of what the right result was. It is kept while it is useful for evaluating and improving the Services, and no longer. We state a criterion rather than a period because the use is to measure and improve a feature, and that need ends when the feature has changed or the measurement is done; we do not run a job that deletes these copies on a clock, and we will not describe one we do not run
• It is deleted when the project it came from is opted out (Section 8.1); when the content it was made from is deleted from the Services under the rules above, including a deletion request under Section 5.2 that reaches that content; and when the account or company it belongs to is deleted on the schedule stated under Account Information and User Content and Project Data above. A copy may persist in database backups, and in the backup of uploaded files where the content was a file, for the periods stated under Backups above
• What is learned is not a copy, and deleting the copies does not remove it. A change to how the Services read a document or answer a question, made with the help of your content, stays made after the copies are deleted; it reproduces nothing of your content and discloses none of its substance, as Terms of Service §5.3.1 requires. We say this plainly because an opt-out deletes copies and does not undo what was already improved
• A copy may name people who are not users, such as a contractor's or supplier's staff on a transmittal. We process those names only because they are in the content, and they are added to no record about those people

SynC Standards Contributions:

• Contributions licensed under CC-BY-SA 4.0 are retained as part of the public standards repository even after account deletion, as they are licensed to the public
• Following account deletion, your public-facing contributor attribution is removed (pseudonymized as described in Section 4.4); SynC retains a limited, non-public, access-restricted record linking each contribution to you only as reasonably necessary for legal-claims and licensing-integrity purposes (CLA §2A.4). The retention rule for that linking record is stated below under Contributor Attribution Records

Several categories of records below carry retention rules of different kinds, and the differences are deliberate. A record of a distribution event documents that something happened on a date; its evidentiary value runs out with the limitation periods for claims about that event, so it carries a time period. A record of contribution provenance answers who authored content that is still published; its justification does not decay with time but ends when the content is no longer public, so it carries a condition tied to the content's lifecycle, with a fixed tail. A public record of our own moderation conduct is kept for the public rather than for us, and is not deleted; a record that we gave a required notice carries a time period of its own, because its value is in what it proves.

Project Distribution and Access Records:

Records of project distribution events — the creation of a share link, a recipient's acceptance, forwarding of access, the removal of a recipient's access, and the deletion of a distributed project (Section 1.2) — are durable evidence, for every party to a distribution, of what project content was shared, with whom, and when. They are the platform's equivalent of the construction industry's transmittal record.

• Each record is retained for up to fifteen (15) years from the date of the event it documents. The period runs separately for each record and is not extended, restarted, or shortened by later activity in the same project.
• These records are not deleted when a project is deleted or when an account is closed. They are maintained append-only precisely so that no party to a distribution — including the project owner — can later alter or erase the evidence of what was distributed. Deleting a distributed project removes it from the owner's workspace and ends recipients' access; the distribution records survive the deletion.
• A withholding of a name on a revision that had already been sent to recipients, and any release of it (Section 1.2), is recorded as an event against that revision's distribution record under this same rule: kept for up to fifteen (15) years from the event, append-only, and surviving project deletion and account closure. The event records the act, the revision and the date; it does not carry the name.
• At the end of the retention period, we redact the personal identifiers from the record rather than delete the record: the fact that a distribution event occurred is retained, and the identity of the persons involved in it is removed. Under this Policy's Effective Date, the earliest records reach the end of their retention period in 2041. Deleting your account does not shorten this period. The redaction reaches the distribution record; it does not reach the company's project records described under User Content and Project Data above, which carry no clock.
• This retention period is SynC's chosen policy, not a statutory retention requirement imposed on SynC. It is calibrated to the statutes of repose for construction-defect claims in U.S. jurisdictions — which run as long as roughly fifteen years, and in some states without limit — so that the record remains available for the period in which a dispute about a distributed specification could plausibly arise. Record-retention obligations imposed by licensing boards on design professionals are obligations of those professionals, not of SynC; these records can help our customers meet them, but that is not their legal basis.

These records frequently include the personal information of a person who is not a SynC customer — a share-link recipient need have no other relationship with SynC. Section 5.2 describes how deletion requests interact with these records.

Deleted Projects (Sections 1.1 and 5.2):

• When a user with authority over a project deletes it, the project is removed from your company's workspace immediately, and every recipient's access to it ends at that moment.
• The project is retained so that it can be restored for 30 days from the deletion. Restoring it within that period returns the project, and returns the access its recipients held before it was deleted. The 30 days are fixed at the moment of deletion and are not extended or restarted by anything.
• After 30 days the project can no longer be restored through the Services. It is not erased at that point. We do not operate a process that permanently removes deleted projects, and we will not describe one we do not run. What the 30 days bounds is the ability to recover the project through the Services — not the life of the data. If we begin operating such a process we will state its period here, under Section 13.
• A deletion request under Section 5.2 reaches a deleted project's content in the ordinary way, and the restore window does not delay it. If you want a project's content erased rather than only removed from your workspace, ask under Section 8. Removing a project from your workspace and erasing its contents are different acts, and the Services' Delete control performs the first.
• Records of distribution events are not affected by either the deletion or the restoration. They survive both, under the Project Distribution and Access Records rule above, and a restoration is recorded in the same way a deletion is.

Contributor Attribution Records:

The limited, non-public record linking each SynC Standards contribution to its contributor (Section 4.4, CLA §2A.4) is retained under a condition tied to the contribution's public availability, not a fixed period:

• The linking record for a contribution is retained for as long as that contribution remains available in the public SynC Standards corpus, plus six (6) years thereafter.
• A contribution remains available in the public corpus while any adopted revision containing it remains publicly accessible through the Services — including in public revision history and in superseded or retired standards, which remain publicly accessible as historical records. Because adopted revisions are permanent public records (Terms of Service §5A.6.1), a contribution leaves the public corpus only if every publicly accessible revision containing it is revoked or otherwise permanently removed from public availability (Terms of Service §5A.6.3), or if the public corpus itself is discontinued. Material that is withheld from public view under a hold has not left the public corpus: the adopted revision containing it remains published, the attribution and licensing chain for it is still owed, and this record continues to be retained on the condition stated above. See Standards Contributors and Moderation Records below. In practice, therefore, this record is retained for as long as the contribution remains published.
• While the contribution is public, this record is what enables SynC to maintain the attribution and licensing chain that CC-BY-SA 4.0 requires and to establish, exercise, or defend legal claims relating to the contribution. A fixed retention period would be wrong in both directions: destroying the record while the contribution is still published would destroy SynC's ability to honor the license it granted the public, and holding it long after the content is gone would retain personal data without a purpose.
• The six-year tail after a contribution leaves the corpus is calibrated to the limitation periods of the claims the record exists to defend — contract claims arising under the Contributor License Agreement and copyright claims relating to the contribution.

Standards Contributors and Moderation Records (Sections 1.1, 4.4 and 5.2):

When SynC issues an erratum on, places a hold on material within, or revokes an adopted revision of a SynC Standard (Terms of Service §5A.6), several records arise. Each is retained differently, and the differences are deliberate.

Public moderation log entries are not deleted.

• Every moderation action is recorded in a public register: the action taken, its date, the reason category, the level applied, the standard and adopted revision it reached while those remain published, the number and section numbers of any clauses it reached, an address of its own for the entry, and the other entries in the same matter.
• The register does not name the moderator who acted, the person or organization who reported the material, the author of the material, or any project that holds it, and it does not carry the free-text note a moderator records internally. An entry recording that a contributor's display name was reset states that fact without naming the contributor. An entry recording an erratum states whether it was issued by SynC or by a community administrator, and does not name the administrator; who issued an erratum is recorded on the erratum itself, internally, and is not published.
• Entries are not deleted, and they survive the content they describe: a standard being retired, a revision being removed, or the account of anyone involved being closed. The register is the record of SynC's own conduct, and a register whose entries the parties to them could remove would not be one.
• Because an entry carries no identifier of a contributor, of a reporter, or of a moderator, it is not ordinarily a record about you and cannot be located by your identity. Where an entry would otherwise identify a person, it is written so that it does not.

The record that we gave you notice is kept separately, and is not pseudonymized.

• When SynC places, narrows, releases or lifts a hold, the Services notify the people with a stake in it: the owners and administrators of affected projects, the author of the adopted revision the notice identified, other contributors to the affected standard, and the users who adopt the standard. We keep a record that each notice was sent: who it was sent to, which of those parties they were notified as, which action and which clauses it concerned, which channels were used, and whether delivery succeeded.
• This record exists to prove that a required notice was given, to you and to anyone who later asks. For that reason it is held separately from your account, it is not affected by the anonymization described in Section 4.4, and it is not deleted when your account is deleted.
• It is retained for six (6) years from the date of the notice it records. That is the period for which it is kept notwithstanding a deletion request (Section 5.2); after it, a deletion request reaches this record in the ordinary way. We do not operate a process that deletes these records automatically at the end of that period, and we will not describe one we do not run; if we begin operating one, we will state it here under Section 13.
• We rely on the establishment, exercise or defense of legal claims as the basis for keeping it: GDPR Article 17(3)(e) and CCPA §1798.105(d)(1) where those laws apply, and the same reasoning where they do not. Section 5.2 states the corresponding limit on a deletion request.

Other moderation actions are notified too, and the notices cannot be switched off.

• There is no silent moderation. When SynC removes an editorial revision of yours from public view or restores it, or resets your display name, the Services notify you. When SynC resets the title of a standard, the contributor whose title was replaced and the contributor whose revision the replacement was taken from are both notified. When SynC removes a standard from public view or restores it, the users who adopt it are notified. These notices, like the hold notices above, are sent in the Services and by email, and they are not subject to your notification preferences: a notice you could switch off is one that could be switched off for you.
• A notice of this kind names the action and what it reached. It does not carry the free-text note a moderator records internally, and it does not name the moderator.
• These notices are ordinary notifications: they are kept with your account and deleted with it. The separate record of notice described above is kept for hold notices.

A non-public copy of withheld content may be retained.

• Where a hold or revocation arises from copyright or content-validity concerns rather than legal compulsion, SynC may retain a non-public copy of the material it withheld (Terms of Service §5A.6.3). The copy is access-restricted, is not published, is not returned to the project that held the material, and is used for no purpose other than legal hold, audit, and the defense of claims arising from the action.
• It is retained for as long as a claim arising from the action could reasonably be brought, and no longer. It is deleted when the hold or revocation has ended and no such claim remains reasonably possible.
• The copy may contain your User Content, and personal information within it. It is not a second copy of your project: it holds only the material the action reached.

A counter-notification is recorded and is not published.

• If material you contributed is withheld in response to a copyright notice and you send a counter-notification (Terms of Service §5B.4), we record the date it was received and the reference under which it is filed, the date we forwarded it to the party who sent the original notice, the dates by which the material is due to be restored, and whether we were told that a court action was filed. The text of your counter-notification is not copied into that record. Forwarding it to the party who sent the original notice is required by the statute and is the one disclosure of it we make.
• Neither your counter-notification nor this record is published, in the moderation log or anywhere else. The register records only that a counter-notification was received, as the reason category for a later action, and does not say who sent it.
• The record holds dates and a filing reference and no identifier of you. Your counter-notification itself is correspondence with us, and we keep it for as long as a claim arising from the notice or the counter-notification could reasonably be brought, on the same basis as the record of notice above.

A copyright notice we receive is recorded, and the record names the author of the material it identified.

• When SynC's designated agent receives a copyright notice about SynC Standards material (Terms of Service §5B.3), we record the date it was received, how it reached us, a filing reference, whether the complaining party was an organization, a natural person or an authorized agent, the standard and revisions it identified, the author of the revision it identified, the hold or revocation we acted through, and the outcome: received, acted on, upheld, restored following a counter-notification, withdrawn, or no action. The complaining party's name and the text of the notice are not copied into the record. When we email the author a copy of the notice (Section 4.9), we record that a copy was sent, when, and which site administrator sent it; where no copy could be sent because we have no email address for the author, we record that instead. The record holds neither the copy nor the cover text.
• A copyright notice about material stored in a project, rather than in the SynC Standards library, is recorded in the same way, against the account that stored the material, with the project it concerned and the company whose project it was. It is recorded under the same policy but is not counted toward the automatic suspension described below (Terms of Service §5B.5).
• If you are the author of a revision a notice identified, or the account that stored material in a project a notice identified, this record is about you. It is what the repeat-infringer policy in Terms of Service §5B.5 counts, and only a notice recorded as upheld counts.
• It is not published, and it is not projected into the public moderation log, which does not identify who reported material or whose material was reported.
• It is retained for as long as a claim arising from the notice, or from the action taken on it, could reasonably be brought. That is the period for which it is kept notwithstanding a deletion request (Section 5.2). We rely on the establishment, exercise or defense of legal claims as the basis for keeping it: GDPR Article 17(3)(e) and CCPA §1798.105(d)(1) where those laws apply, and the same reasoning where they do not. We do not operate a process that deletes these records automatically, and we will not describe one we do not run.

The notice itself is kept as correspondence.

• The notice as we received it, with the sender's contact details, is kept in the Designated Copyright Agent's mailbox, not in the Services' database (Section 4.9). The filing reference in the record above is what connects the two.
• It is retained for as long as a claim arising from the notice, or from the action taken on it, could reasonably be brought, on the same basis as the counter-notification above. The copy we sent to the author is the author's to keep; we do not retrieve it.

A suspension of your wiki contribution privileges is recorded, and is lifted rather than deleted.

• When SynC suspends your ability to contribute to the SynC Standards Wiki under Terms of Service §5B.5, we record the suspension: your account, the ground, the number of upheld notices and the threshold in force at the time, the notice that reached it, and the date. If a site administrator lifts the suspension, we record who lifted it, when, and the reason they gave. The record is not deleted when the suspension is lifted: the lifted record is what shows that it was.
• You are notified of a suspension and of its lifting in the Services and by email, and those notices cannot be switched off (Section 12.3). The notice does not name the complaining party, the notice's reference, the count or the threshold.
• The record is not published and does not appear in the public moderation log.
• It is retained while a suspension stands and, after it is lifted, for as long as a claim arising from the suspension or from the notices that led to it could reasonably be brought, on the same basis as the record of a copyright notice above, and it is kept notwithstanding a deletion request for that period (Section 5.2).

A decision to terminate an account under the repeat-infringer policy, or not to, is recorded.

• When a site administrator terminates your account under Terms of Service §5B.5 and §16.2, or records a decision not to terminate it although a ground for termination was met, we record the decision, the ground, the administrator's written reason, the notices relied on and how many of them were upheld on each side of the Services, and what the termination did and deliberately left alone (sessions ended, API keys revoked, and the company roles, project roles, invitations and share links left in place, by identifier and count, not by name). If the account is later reinstated, we record who reinstated it, when, the reason they gave, and the status restored. The record is reversed by a recorded reinstatement, not by deletion.
• The written reason is internal and is not sent to you. You are notified of a termination in the Services and by email, and that notice cannot be switched off (Section 12.3); it states the ground and how to ask for the decision to be reconsidered.
• The record is not published and does not appear in the public moderation log.
• It is retained on the same basis and for the same condition as the record of a copyright notice above, and it is kept notwithstanding a deletion request for that period (Section 5.2).

What account deletion does to these three records. Each of them points to our identifier for your account. If your account is deleted, the account record they point to no longer carries your name or email address (Section 4.4), so from then on the records identify you only by that identifier; they are not deleted with the account, for the reasons stated above.

Material withheld from public view has not left the corpus.

• A hold withholds identified material while the adopted revision containing it stays published. A contribution may therefore stop being publicly readable without any revision having been revoked or removed.
• Where that happens, the non-public linking record described under Contributor Attribution Records above continues to be retained, on the same condition and for the same reasons: the contribution remains part of the published corpus, and the attribution and licensing chain for it is still owed. A hold does not start the six-year tail described in that rule.
• The public-facing attribution on an adopted revision is unchanged by a hold. How your attribution appears is your own choice; see Section 4.4 and CLA §2A.5.

Derived Search Data (Section 4.1A):

• Embedding vectors for indexed content are retained for as long as the content they derive from. They are derived data: deleting the content removes it from the search index, and no separate deletion request is needed for the vectors.
• Query-vector cache. We keep a cache of search queries and the vectors computed for them, so that a repeated query does not require another call to the embedding provider. The cache is shared across all users and keyed by the text of the query itself. It carries no account identifier and no link to the person who ran the search. Entries are evicted on a least-recently-used basis rather than after a fixed period. Because an entry holds no identifier of any kind, it cannot be located by, or associated with, you — including in response to an access or deletion request.
• Query text recorded as search telemetry is retained under the Search Telemetry rule below.

Derived Citation Data (Section 4.5):

• The citation index is derived data, rebuilt from published content. Publishing a document replaces its index entries in full, so the entries describe only the current published revision; deleting a document removes its entries at the moment of deletion. No separate deletion request is needed for them.
• An index entry records the citation as authored — the citation marker's text, its position in the document, and the SynC Standard and clause it points to — together with which document it appears in. It carries no account identifier; who owns the citing document is determined from the document itself, under the same access rules that protect the document.
• Deprecating a published document without deleting it does not remove its entries: a deprecated document still cites what it cites, and the maintainers of the cited standard remain entitled to the count.
• Drafts and unpublished working copies are never indexed.

AI Assistant Conversations (Sections 1.1, 4.1A and 4.2A):

A conversation with the AI assistant is retained for 180 days from its last activity — not from when it was created. Sending or receiving a message in a conversation is activity, and it restarts the 180 days. A conversation you keep using is therefore never deleted while you are using it, and a conversation you stop using is deleted 180 days after the last message in it. Deletion at the end of that period is automatic.

• This period is measured from last activity because a working conversation must not expire underneath you. Continuing a conversation is the way to keep it; copying it out (Section 8.1) is the way to keep it permanently. We do not offer, and do not intend to offer, an action whose only effect is to exempt a conversation from this period — a retention period a user can switch off is not a retention period.
• We do not warn you before a conversation expires. There is no notice, no email, and no expiry countdown shown against individual conversations. This Policy is the disclosure; the Services may additionally state the period where your conversations are listed.
• You may delete any of your conversations at any time, and deletion is immediate and final. There is no trash, no holding state, and no recovery period: a conversation you delete is gone from the Services at once and cannot be restored to you. As with other User Content, a copy may persist in database backups for the period stated under Backups above.
• We limit how many conversations we store for you, and how long a single conversation may run. These are backstops against runaway storage rather than everyday behaviour, and they carry no interface. When you are at the limit and start a new conversation, the conversation you have gone longest without using is deleted to make room for it. The current limits are available on request at privacy@synergyinconstruction.com.
• The statement about you that a conversation stores (Section 4.1A) is part of that conversation. It is deleted when the conversation is deleted, by you or at the end of the period above, and it follows your account under Section 5.2. It is kept as it stood when the conversation started, so that the record of what the assistant was told is the record of what it was actually told.
• A summary of a conversation's earlier part (Section 4.1A) is part of that conversation. It is deleted when the conversation is deleted, by you or at the end of the period above, and it follows your account under Section 5.2. Nothing of it is kept once the conversation is gone, other than the copy that may persist in database backups for the period stated under Backups above.

This period is separate from, and runs independently of, the periods stated above for account deletion. The two must not be read together:

• Deleting your account does not immediately delete your conversations. They are retained through the period in which your account can still be restored, precisely so that restoring your account restores them intact.
• Conversations are deleted when your account is permanently deleted, whether or not their 180 days have run.
• While your account exists, the 180-day rule is the only rule that ends a conversation, other than your own deletion of it.

Requests at the Inference Provider (Section 4.1A):

• A request to the AI assistant (your prompt, the content in scope, our internal identifiers for your account and company, and the statement about you) is transmitted to an inference provider to be answered. We do not store the request in that form; what we store is the conversation, under the rule above.
• The provider that served a request may keep it for the period its own published terms state, and no provider we use is permitted to keep it for its own purposes or to train on it. Each provider's own data-handling documents, which state that period, are linked from our subprocessor list, which names every provider a request may reach without stating which one served yours. Those documents are the authority for the period; neither this Policy nor the subprocessor list restates it, so that you are never left with two versions of it. A request a provider keeps includes the statement about you that was sent with it.
• We do not set those periods and we do not state them as our own. A provider is named on the subprocessor list, with links to its documents, before any request is sent to it; a change to a provider's own period is made in that provider's documents, and Terms of Service §5.3.3 states the notice we give where a change materially reduces the protections it describes.
• Where we have a zero-data-retention arrangement with a provider for our own account, the subprocessor list says so; this Policy does not assume one.

Usage and Analytics Data:

• Usage information (Section 1.2) is held in the records this Section describes under Search Telemetry and Product Analytics Data, and by the web-analytics processor named below, each for the period stated there. We state no separate period for it, because no process of ours enforces one
• May be retained indefinitely in aggregated form that does not identify you
• Cloudflare Web Analytics data is retained by Cloudflare under their published retention policies; because Cloudflare states that no visitor identifier is created, we have no means of re-associating this data with you

Search Telemetry (Section 1.2):

• Search-and-click records are deleted 90 days after collection by an automated daily job. This applies to signed-in searches and to anonymous public-wiki searches alike
• Because a click is recorded on the search record itself rather than separately, deleting the record removes the query and the click together
• Anonymous search records carry no identifier of any kind, so they cannot be located by, or associated with, you or your device — including in response to an access or deletion request

Product Analytics Data (PostHog):

• Event data is retained by PostHog under the retention policy applicable to our PostHog plan (typically 7 years for events, configurable down to 30 days)
• PostHog's retention schedule for session recordings is shorter — typically 30 days under the default for our plan, after which PostHog states that recordings are deleted. While session replay is switched off in our account, as it is as of the Effective Date (Section 4.1), no recording is made, and PostHog states that a recording made before it was switched off is deleted on that schedule
• Upon a verified deletion request (see Section 8), we will delete or anonymize identified product-analytics data associated with your user ID via PostHog's delete-person API
• A page view sent from the public SynC Standards library or our legal pages under a visitor identifier that was never joined to an account (Section 4.1) carries no name, address or account, and we cannot locate it by you; the same is true of the profile the processor keeps for that browser. Where the identifier was joined to your account when you signed in, a deletion request is answered by asking the processor to delete the person it holds for your user ID, which is that profile, and the events recorded under it; what the processor deletes is governed by its own documents, linked in Section 4.1, and we do not restate them

Email Interaction Data (Sections 1.2 and 4.1):

• Delivery and interaction records for the email we send are held by our email-delivery processor and are not stored in our own database, so there is no copy of them in your SynC account for this Section to reach
• We are not able to state a retention period for them, and we will not invent one. How long that processor keeps this data is determined by its own service configuration and published terms rather than by a setting we maintain, and we do not currently hold a documented figure for it. If we establish it, we will state it here under Section 13
• Because these records sit with the processor rather than with us, a request about them is handled as described in Sections 8.1 and 8.4 rather than by deleting a row in our database

Error Monitoring Data:

• Error events transmitted to Sentry are retained according to Sentry's standard retention for our plan and are used solely to diagnose and remediate errors
• Scrubbed and filtered as described in Section 4.1 prior to transmission

Billing and Invoice Records (Sections 1.1 and 4.1):

• The record of what your company bought, its subscription's status and periods, the amounts charged and whether they were paid, which user started each purchase, and the event records the processor sent us about them (Section 4.1) is held in the Services' database, in our account with the processor, and in our own financial records
• We retain these records for as long as tax, accounting, and audit law requires us to keep financial records — the period stated under Legal and Compliance Data below — and they are not deleted on account deletion during that period, because the obligation to keep them is ours and does not end when your account does. The seats and credits a record of purchase supports lapse when the subscription or the account ends; the record of the purchase does not
• The processor keeps its own records of the transactions it processed for the periods its own terms and legal obligations require; we do not set that period and do not state it here. Payment card and bank account details are held by the processor and never by us, so there is nothing of that kind in our records to retain or to delete

Call Bookings (Sections 1.1, 4.1 and 11):

• A booking is kept in our calendar and at the scheduling processor. The email address of each colleague the person booking invited is kept with it, in the same places and for the same time. We do not operate a process that deletes bookings after a period, and we will not describe one we do not run; if we begin operating one, we will state its period here under Section 13
• A booking is not linked to any SynC account. A request under Section 8 reaches it in the ordinary way, and asking us to delete it is the way to have it removed from our calendar; a colleague who was invited can ask in the same way to have their address removed from it. The processor's own retention applies to its copy, as its privacy policy states
• Email we exchange with you, or with a colleague who attended, after the call (Section 11) is correspondence held in our mailbox with our workspace provider. We apply no deletion period of our own to it, and a request under Section 8 reaches it in the ordinary way
• A recording of a call, and any transcript or meeting notes we make from it (Section 4.1), are kept in our own storage until we delete them. We do not operate a process that deletes them after a period, and we will not describe one we do not run; if we begin operating one, we will state its period here under Section 13. Anyone who was on the call can ask us under Section 8 to delete them, and we do

Legal and Compliance Data:

• Retained as required by applicable law (typically 3-7 years for financial records)
• Retained as necessary to resolve disputes or enforce agreements

5.2 Deletion Requests

You may request deletion of your personal information at any time (see Section 8). Upon deletion:

• We will delete or anonymize your personal information within 45 days
• A copy of your information persists in backups, of the database and of the files you uploaded, until those backups age out, for the periods stated in Section 5.1 (Backups), the longest of which is 365 days. A deletion request does not reach a backup, and a backup is used only to restore the Services after data loss
• We may retain certain information as required by law or for legitimate business purposes
• Linked sign-in identities and passkeys are deleted with your account, and you can delete any of them yourself at any time, immediately, in Profile → Security (Sections 5.1 and 8.1)
• API keys are revoked when your account is terminated and go with your account on the schedule stated in Section 5.1, and you can revoke any of them yourself at any time, immediately, from the page that lists them (Sections 5.1 and 8.1). Revoking does not reach what an app already received through the key; a request about that goes to the app's maker under its own privacy policy. The request log is kept for 90 days from each request and no longer (Section 5.1)
• Anonymous wiki-search records cannot be removed on request because they carry no identifier linking them to you; they are deleted for everyone at 90 days (see Section 5.1)
• Entries in the query-vector cache (Section 5.1) likewise carry no identifier linking them to you and cannot be singled out on request; they are evicted on a least-recently-used basis
• Billing and invoice records are retained for the period stated in Section 5.1 notwithstanding a deletion request, because tax and accounting law requires us to keep them. This exemption reaches those records only — the billing contact details on a purchase or invoice, the record of what was bought and of each charge and its payment, and the processor's event records about them — and applies only if your company has made a purchase or we have invoiced it. It does not extend to any other category of personal information, and it does not reach payment card or bank account details, which we never hold
• Your conversations with the AI assistant are deleted when your account is permanently deleted. They are not exempt from a deletion request and are not retained past it. They are, however, deliberately not deleted at the moment you ask to close your account: they are kept through the period in which the account can still be restored, so that restoring it recovers them, and are then deleted with the account. You do not have to wait for that — you can delete any conversation yourself at any time, immediately (Section 5.1)
• SynC Standards contributions licensed under CC-BY-SA 4.0 remain part of the public repository; following account deletion your public-facing attribution is removed (pseudonymized) as described in Section 4.4, while a limited, non-public linking record is retained for legal-claims and licensing-integrity purposes (CLA §2A.4), for the period stated in Section 5.1 (Contributor Attribution Records)
• Project distribution and access records are retained on their own schedule notwithstanding a deletion request. These records (Section 5.1) are kept as reasonably necessary to establish, exercise, or defend legal claims arising from the distribution of project content. On that basis they are exempt from deletion on request — under GDPR Article 17(3)(e) and CCPA §1798.105(d)(1) where those laws apply, and on the same reasoning where they do not — for the fifteen-year period stated in Section 5.1 and no longer, after which the personal identifiers in them are redacted. This exemption is limited to the distribution records themselves: it does not extend to any other category of personal information we hold about you, and a deletion request remains fully effective as to everything else within the 45-day commitment above. If you are a share-link recipient with no other relationship to SynC, these records are the only category of your personal information to which this exemption applies.
• The record that we gave you notice of a moderation hold is retained on its own schedule notwithstanding a deletion request. This record (Section 5.1, Standards Contributors and Moderation Records) exists to prove that a notice SynC was obliged to give was given, to you and to anyone who later asks. On that basis it is exempt from deletion on request — under GDPR Article 17(3)(e) and CCPA §1798.105(d)(1) where those laws apply, and on the same reasoning where they do not — for the six-year period stated in Section 5.1 and no longer. It is not affected by the anonymization applied to contributor attribution on account deletion (Section 4.4). This exemption is limited to that record: it does not extend to any other category of personal information we hold about you, and a deletion request remains fully effective as to everything else within the 45-day commitment above.
• The record of a copyright notice that identified material you authored or stored, the record of a suspension of your wiki contribution privileges, and the record of a decision to terminate your account under the repeat-infringer policy or not to, are retained on their own schedule notwithstanding a deletion request. These records (Section 5.1, Standards Contributors and Moderation Records) are kept to operate the repeat-infringer policy in Terms of Service §5B.5 and to establish, exercise, or defend legal claims arising from the notice, the suspension or the termination. On that basis they are exempt from deletion on request, under GDPR Article 17(3)(e) and CCPA §1798.105(d)(1) where those laws apply, and on the same reasoning where they do not, for as long as such a claim could reasonably be brought and no longer. This exemption is limited to those records: it does not extend to any other category of personal information we hold about you, and a deletion request remains fully effective as to everything else within the 45-day commitment above.
• Public moderation log entries are not deleted, and are not ordinarily records about you. An entry records what SynC did, when, and under which category. It carries no identifier of a contributor, a reporter or a moderator, and where an entry would otherwise identify a person, it is written so that it does not. Because an entry holds no identifier of you, it cannot be located by, or associated with, you, including in response to an access or deletion request, and an entry is not removed once written.
• Deleting a project through the Services is not a deletion request. It removes the project from your workspace and ends recipients' access, and for 30 days it can be undone (Section 5.1). It is not a request to erase the project's contents, and we do not treat it as one. To ask for erasure, use Section 8.
• A company's records of what you did in its projects and libraries, and the history of the names your account has used, are retained notwithstanding a deletion request. A deletion request removes your account and everything that belongs to it alone (Section 5.1). It does not reach a company's record of who published, uploaded, commented, adopted, changed or archived what, which keeps the name you had at the time, and it does not reach the name history those records are read from. We keep them as the company's record of its own work and as reasonably necessary for the establishment, exercise or defense of legal claims by the parties who rely on a published revision, under GDPR Article 17(3)(e) and CCPA §1798.105(d)(1) where those laws apply, and on the same reasoning where they do not. This exemption is limited to those records and that history: it does not extend to any other category of personal information we hold about you, and a deletion request remains fully effective as to everything else within the 45-day commitment above. What you can ask for instead: the company that holds a record can instruct us to withhold your name from its records, and we do so on its instruction; SynC may withhold a name under the Terms of Service, and does so where the law requires it; the record then shows that the name was withheld, with the reason and the date, and the name stays in the history behind it (Section 1.2). Where the company that held the records has been dissolved and no one is left to instruct on its behalf, SynC decides a request to withhold case by case under the Terms of Service
• Files and other content you stored in a company's project are that company's record and are not deleted with your account (Section 5.1), on the same footing as the records above. If you want a file's contents erased, ask the company that holds the project: a deletion request to us reaches a file in a company's project only where that company agrees or the law requires it. A file that has left the Services persists in backup for the period stated in Section 5.1 (Backups). A filename or description that identifies you can be corrected on request without altering the file or the revision that holds it

6. Data Security

6.1 Security Measures

We implement technical and organizational measures appropriate to the size and nature of our operations to protect your information, including:

Technical Safeguards:

• Encryption in transit (TLS 1.2+) for all traffic between your browser and the Services
• Passwords hashed using bcrypt; credentials are never stored or logged in plain text
• Automated daily database backups, encrypted, with tiered retention (Section 5.1, Backups)
• Encryption at rest (AES-256) of the disks of the servers the Services run on, which hold the live database, with keys managed through our hosting provider's key service
• Uploaded project files copied each night to a separate backup bucket with its own write credentials and a lock against early deletion; the copies are not encrypted by us, and the storage provider encrypts every stored file, live and backup, at rest with AES-256 under keys it manages (Section 5.1, Backups)
• Secure API authentication and rate limiting. An API key is shown to you once, when it is created and when it is rotated, and is then kept only in a form that cannot be read back, so a lost key is replaced by rotating it rather than shown again
• A key can never do more than the person it belongs to: every request is checked against what that person's account can do at the moment of the request and against the permissions on the key, and some actions are never available to a key at all (Section 4.10)
• The Services assume that text inside the content a connected app reads, such as a comment, may try to instruct the app, and that the app may follow it. Our limits on what a key may do are enforced by the Services on every request, and do not depend on the app asking you first
• Sign-in with Microsoft or Google is verified on our server against the provider, each sign-in attempt is single-use, and no access token is stored
• We limit repeated failed sign-in attempts and wrong codes against an address, with a temporary hold rather than a lockout, so that an attacker can slow the real owner down but not shut them out
• Email verification codes, sign-in codes and link tokens are stored only in a form that cannot be read back; a code is single-use and short-lived, and we limit how often codes are sent and how many times one may be tried
• A passkey signs you in by proving, on your device, possession of a private key that never leaves it. We hold only the public key, which can check that proof and cannot make it, so nothing we hold could be used to sign in as you with a passkey
• The list of where your account is signed in carries nothing that could be used to take over a session
• Before a change that would give a way into your account that outlives the browser session you are using, we ask you to confirm it is you on that session, as described below
• Passwords are checked against a public list of passwords exposed in data breaches, as described below, and a breached password is refused
• Access to production systems restricted to authorized personnel and protected by key-based authentication

Organizational Safeguards:

• Access to personal information limited on a need-to-know basis
• Data processing agreements with the third-party processors we engage directly; for the downstream AI inference and embedding hosts, the controls described in Section 4.1A
• Incident response procedures, including the breach notification practices described in Section 6.3

The breached-password check. A password that has appeared in a public data breach is a password an attacker already has a list of, so the Services refuse one. When you set a password, we check it before accepting it, and ask you for a different one if it is found. When you sign in with a password that is found, we do not start a session; we send you to set a new one instead, because the password you just used is one you should stop using everywhere. The check works as Section 4.1 describes: only the first five characters of a one-way hash leave our servers, the comparison is made on our servers, nothing that identifies you accompanies the request, and if the lookup service does not answer the check is skipped. The check is a safeguard for your account and creates no record about you: we do not store the result of a check, and we do not keep a record of which passwords were refused.

Confirming it is you. A browser that was left signed in already has the session; what it should not have is a way to turn that session into something that outlives it, or to take the account, or the ways back into it, away from you. So before you set or clear your recovery address, change your primary email address, remove a verified email address, add or remove a passkey, link or unlink a Microsoft or Google account, create or rotate an API key, or start deleting your account, the Services ask you to confirm it is you on the browser session you are using. You confirm by typing your password, by using one of your account's passkeys, or by signing in to Microsoft again, which we ask Microsoft to require afresh and accept only when Microsoft reports that you did (Section 1.3); a sign-in by password or by passkey made on that session a short time before counts as well. An emailed code does not count, and neither does an earlier sign-in with Microsoft or Google. An account with no password, no passkey and no linked Microsoft account has none of these to offer, so for the two changes that would give it one, adding a passkey and linking a provider, a sign-in on that session a short time before, by any method, or a fresh sign-in to Google counts instead; for its other changes it is asked to add a passkey first. A confirmation holds for a short time, on that browser session alone. Section 1.2 states what is recorded when you confirm, and Section 8.1 names the controls that ask for it.

6.2 Limitations

While we take reasonable measures to protect your information, no security system is impenetrable. We cannot guarantee absolute security of data transmitted over the internet or stored on our systems. You are responsible for:

• Maintaining the confidentiality of your account credentials
• Using strong, unique passwords
• Enabling two-factor authentication (if available)
• Reporting any suspected security incidents

6.3 Security Incidents

In the event of a data breach affecting your personal information, we will notify you and the relevant authorities without undue delay, within the timeframes required by applicable law.

Terms of Service §5.6 states, separately, what we do when a security incident exposes a company's User Content, whether or not personal information is affected: we notify the company's administrators. That commitment is a term of the Terms of Service, and this Policy does not restate it.

7. Where Your Information Is Processed

7.1 The United States, and Use from Elsewhere

SynC is based in the United States and offers the Services to customers there. Personal information is processed and stored in the United States, and by the service providers described in Section 4.1 where they process: for the providers whose region is ours to choose, that is the United States, as Section 4.1 states; for the others, the provider's own documents, linked from Section 4.1 and from the subprocessor list, state where it processes, and this Policy does not restate them. We do not direct the Services to any other country, and we do not block access from elsewhere: anyone may read what is shared with them or published in the SynC Standards library, and may comment on and respond to it, from wherever they are. If you use the Services, or contact us, from outside the United States, you do so on that basis, and your information is transferred to, stored and processed in the United States, and in other countries where a service provider of ours operates.

These countries may have data protection laws that differ from those in your country of residence.

Specifically, the third-party processors disclosed in Section 4.1 as of the Effective Date include:

• Cloudflare, Inc. (Web Analytics) — global processing infrastructure with US headquarters
• PostHog, Inc. (Product Analytics) — US cloud (us.i.posthog.com) with US headquarters
• Functional Software, Inc. d/b/a Sentry (Error Monitoring) — US-region ingestion endpoint
• Amazon Web Services, Inc. (Email Delivery, Amazon SES) — US region
• Stripe, LLC (Payments) — where its Data Processing Agreement states (linked in Section 4.1 and on the subprocessor list). This processor receives, for companies that buy seats or credits or that we invoice, the company's name and contact email, our identifiers for the company and the purchase, and the items and quantities bought; the purchaser gives it card and billing details directly; and it returns purchase, payment and subscription status to us. It receives no content, conversations, credentials, or usage data
• Cal.com, Inc. (Scheduling, where our website offers a booking page): where its privacy policy and subprocessor list state (linked in Section 4.1 and on the subprocessor list). It receives the details you give when you book a call, including the email address of each colleague you invite, and nothing else. Our workspace provider, Google Workspace, holds the resulting calendar entry, with each invited address on it, and hosts the video call. A recording of a call, made where everyone on it agrees, is made and held by us and goes to neither provider (Section 4.1)

As described in Section 4.1, this list reflects our current processors and is not exhaustive or permanent; a current subprocessor list is published at synergyinconstruction.com/legal/subprocessors and is available on request. Microsoft and Google, where you sign in with them, are not among these processors (Section 4.1): where they process your account is a matter between you, or your organization, and them, and you choose them. An app or tool you connect to your account with an API key (Section 4.10) is not among these processors either: where the app's maker processes what the app receives is a matter between you and it, under its terms, and you choose it. The breached-password check (Section 6.1) transfers no personal information anywhere: the five characters of a hash it sends identify no one.

Inference and text-embedding requests are restricted to processing hosts we have vetted, with automatic failover disabled, so that hosts outside that set are excluded by configuration rather than by preference. Each host's own documents, which state where it processes content, are linked from our subprocessor list; neither the list nor this Policy restates them.

7.2 If You Are Outside the United States

We do not operate a compliance programme for the data-protection law of any country other than the United States, and this Policy does not promise one. In particular, we do not represent that a transfer safeguard of our own, such as standard contractual clauses that SynC has signed, is in place for each service provider that may receive personal data from the EEA, the UK or Switzerland. Where a provider offers such a safeguard in its own data processing terms, the link beside that provider on our subprocessor list is where the provider states it, and we rely on the provider's terms as they stand.

What this Policy does give you does not depend on where you are. The rights in Section 8.1, to access, correct and delete your personal information and to see and switch off what the AI assistant is told about you, are open to everyone. Section 8.2 describes the additional rights we recognize for readers in the EEA, the UK and Switzerland, and Section 14.3 states where to write. Where the law of your country gives you a right this Policy does not describe, write to privacy@synergyinconstruction.com and we will consider the request in good faith.

7.3 Data Processing Addendum

Business customers may request a Data Processing Addendum (DPA) to formalize our data protection commitments. Contact privacy@synergyinconstruction.com to request a DPA.

8. Your Privacy Rights

Depending on your location, you may have certain rights regarding your personal information:

8.1 Rights for All Users

Access and Portability:

• Request a copy of the personal information we hold about you
• Receive your data in a structured, machine-readable format
• Where you are in the EEA, the UK or Switzerland and ask for access, you may ask us to identify the actual recipients of your personal data rather than the candidates our subprocessor list names, including which inference provider served your requests to the AI assistant, and we will, unless identifying them is impossible or the request is manifestly unfounded or excessive

Correction:

• Update or correct inaccurate or incomplete personal information
• You can update most information directly in your account settings
• You can change your name in your profile. The change applies to your account and to the records you make from then on; a record you made earlier keeps the name you had when you made it (Section 1.2). Your Name on Company Records below states the one choice you have about that

Your Name on Company Records:

• What a record shows. A record you made in a company's project or library shows the name you had when you made it, from the history described in Section 1.1. On a record view (a revision's history and detail, a standard's changelog, and an adopted-revision record) the name is shown as recorded
• Show your current name on earlier records. If your name has changed, one setting on your profile, "Show my current name on my earlier records", shows your current name on the records you made under an earlier name. Everyday lists then show your current name, and a record view shows both, your current name first and the recorded name after it, for example "Dana Okafor (recorded as Dana Reyes)". The election is yours alone, it covers all of your records in every company, it is recorded as an act with its date (Section 1.2), and you can withdraw it at any time. It stays in force if you delete your account, because it was your choice and no one is left to ask; a withholding takes precedence over it
• What you cannot do. You cannot withhold your own name, and deleting your account does not change what a record shows (Section 5.2). You can ask the company that holds the record to withhold your name, and you can report to us at privacy@synergyinconstruction.com that an account is using your name; each goes through an act we record and show on the record (Section 1.2)

Your Sign-In Methods:

• See them. Profile → Security → Sign-in methods lists whether your account has a password and which Microsoft or Google accounts are linked to it, with the address each asserted when it was linked and when it was last used, and, where the Services offer passkeys, each passkey on your account with its name, when it was added and last used, and whether it is of a kind that syncs between your devices
• Add one. You can link a Microsoft or Google account from that page after confirming it is you (Section 6.1). We never link one silently: a link is made only from that page, or when you sign in with a provider whose verified address matches your account and you then enter that account's password, a code emailed to it, or one of its passkeys, and confirm the link. You can add a passkey from the same page after confirming it is you, and rename it there; we email every verified address on your account when one is added and when one is removed, so that a change you did not make is noticed (see Security Notices below)
• Remove one. Removing a linked account or a passkey deletes our record of it at once (Section 5.1). The last way into your account cannot be removed: if your account has no password of its own and one linked account, set a password first, using "Forgot password" on the sign-in page, and then remove the linked account. A passkey can always be removed, because a passkey is added to an account that already has a password or a linked account, so removing it never leaves you without a way in
• What removing does not do. It does not touch your Microsoft or Google account, and it does not remove SynC from any list that provider keeps of the applications you have signed in to; that is done at the provider. Removing a passkey does not delete it from your device or your password manager; that is done there
• Correct it. The name and address we received from the provider became your account details; correct them in your profile like any other account information

Your Recovery Address (where the Services offer one):

• Designate one. In Profile → Security you can designate one verified address on your account as your recovery address, change it, or clear it, after confirming it is you (Section 6.1). Your primary address already receives a password reset, so it cannot be the recovery address; making your recovery address your primary clears the designation
• What it does. A password reset or a sign-in code is sent to the address you type when that address is your primary or your recovery address. Any other address you type is answered by sending to your primary (Section 1.2)
• What it does not do. Designating a recovery address gives no one else access to your account, and it does not change where your notifications go: project and activity notifications still go to your primary address
• We email every verified address on your account when your recovery address is set, changed or cleared (see Security Notices below)

Security Notices:

• Every verified address. When your password is changed, your primary address is changed, an address is added to or removed from your account, your recovery address is set, changed or cleared, or a passkey is added or removed, we email every verified address on your account, not only the primary, so that a change you did not make is noticed at an address the change did not touch. When an address is removed, the removed address is told as well. An address that has not been verified receives nothing, including notice of its own addition
• They cannot be switched off, and there is no separate list of who receives them: the verified addresses on your account are the list. Adding an address and verifying it adds it to the list, and removing one removes it (Section 12.3)

Where You Are Signed In:

• See them. Profile → Security → "Where you're signed in" lists each browser session on your account: the browser and operating system, when it signed in, when it was last active, and how it signed in, with this browser marked (Section 1.2)
• End one, or all the others. You can sign out any other session from that page, or all of them at once. This browser is ended by signing out. If you do not recognize a session, sign it out and then change your password, which also ends every other session
• A session you do not end expires seven days after the browser last used it (Section 5.1)

Your API Keys and the Apps and Tools You Connect With Them:

• See them. The page that lists your API keys shows each key with its name, what it may do, when it was created and when it was last used, and the recent requests made with it (Section 1.2). The log of your own requests is yours to read, search terms included
• Create one, with less than you can do. Creating or rotating a key asks you to confirm it is you (Section 6.1). You pick the key's permissions from your own; publishing, sharing, deleting and moderating start unticked, and a key has them only where you tick each one (Section 4.10)
• Revoke one. You can revoke or rotate any key at any time. A revoked key stops on its next request. There is no grace period and no notice to the app beyond the refusal it receives
• What revoking does not do. It does not remove SynC from any list the app keeps of what you have connected, and it does not remove anything the app already received; both are matters for the app, under its terms
• Your company's administrators can see which members of the company hold a key, when each was last used and how much it has been used; they do not see the individual requests. They can switch off access by API keys and connected apps for the whole company, in which case no key, yours included, can read or change that company's projects until the switch is on again. The switch starts on
• What an app is told when it is refused. A refusal says why, in plain words the app can repeat to you: that you lack a permission or a seat, that you asked too often, that a share link's export setting or a company's switch stops the request, or that the action is one no key may take
• Access. If you ask us for a copy of the personal information we hold about you, that includes your key records and the request log for them (Section 1.2)

Deletion:

• Request deletion of your personal information (subject to certain exceptions)
• Note: SynC Standards contributions licensed under CC-BY-SA 4.0 remain in the public repository; your public-facing attribution is removed (pseudonymized) on account deletion as described in Section 4.4
• Note: Anonymous wiki-search records (Section 1.2) and query-vector cache entries (Section 5.1) hold no identifier, so we have no way to find the ones that came from you; search records are deleted for everyone at 90 days, and cache entries are evicted on a least-recently-used basis
• Note: Records of project distribution events are retained for the period stated in Section 5.1 and are exempt from deletion during that period as described in Section 5.2, because they are kept to establish, exercise, or defend legal claims arising from distributed project content
• Note: The record that we gave you notice of a moderation hold is retained for the period stated in Section 5.1 and is exempt from deletion during that period as described in Section 5.2; public moderation log entries hold no identifier of you and are not deleted
• Note: The record of a copyright notice that identified material you authored or stored, the record of a suspension of your wiki contribution privileges, and the record of a decision to terminate your account under the repeat-infringer policy or not to, are retained for the period stated in Section 5.1 and are exempt from deletion during that period as described in Section 5.2
• Note: Deleting a project through the Services removes it from your workspace and is not a deletion request; to have its contents erased, ask under this Section (see Sections 5.1 and 5.2)
• Note: A company's records of what you did in its projects and libraries, including the files you uploaded, keep the name you had at the time after your account is deleted, and the history of your names that those records are read from is kept with them; the company that holds a record can instruct us to withhold your name from it (Sections 5.1 and 5.2)

Your Conversations with the AI Assistant:

• List and revisit. You can see your own conversations, most recently used first, and reopen any of them
• Rename. Titles are generated automatically (Section 2.2); you can replace one with your own
• Copy. You can copy a conversation out of the Services as readable text — the exchange and the plain-language record of what the assistant did, which is what you saw. The copy is of your transcript, which is unchanged and complete; the summary of a conversation's earlier part (Section 4.1A) is not shown to you and is not in it. This is the way to keep a conversation beyond the retention period in Section 5.1
• Delete. You can delete any of your conversations at any time. Deletion takes effect immediately and is not staged: there is no trash and no recovery window, so a deleted conversation cannot be restored to you
• Access. If you ask us for a copy of the personal information we hold about you, that includes your stored conversations and any summary stored with them (Section 4.1A)
• These controls are available to you whether or not your account currently has access to the AI assistant. If AI access ends, you keep the ability to read, copy, and delete the conversations you already have; you are simply unable to start or continue one

What the Assistant Is Told About You:

• See it. From the assistant's panel you can read the exact lines about you that are sent with your requests (Section 4.1A)
• Switch it off. One setting on your account, "Tailor answers to my profile", stops your first name, role, discipline, company type and company name, and how the project you are in records your company, from being sent. It is stored on your account, applies wherever you sign in, and takes effect from your next conversation; a conversation already under way keeps the statement it started with. It is on unless you switch it off
• What the switch does not stop. The lines stating what your account may do and what your role on the current project lets you do, the line stating whether you belong to the company whose project it is, and our internal identifiers for your account and company, are still sent, because they keep the assistant within your permissions and stop it proposing actions you cannot take. They describe your rights and carry nothing about you that those rights do not already reflect; the membership line names no company
• Correct it. The statement is built from your profile, your employer record, and the project's record of which companies take part in it. Correcting those corrects what the assistant is told, from your next conversation
• If you are in the EEA, the UK or Switzerland, switching tailoring off is the way to object to it under Section 8.2, and no other step is needed

Opting a Project Out of Improving the Services (Terms of Service §5.3.1):

• A project's administrator can opt that project out, in the project's settings or, until that setting is available in the Services, by asking us at privacy@synergyinconstruction.com naming the project. From then on we do not use that project's content, or what the Services produce from it, to evaluate or improve the Services, and we delete the copies we kept of it for that purpose (Section 5.1)
• A company administrator can set the default for the company's new projects. The default applies to projects created after it is set; a project that already exists keeps its own setting
• What an opt-out does not do. It does not undo an improvement already made with the help of the project's content before the opt-out: the copies are deleted, and what the Services learned stays learned, as Section 5.1 states. It changes nothing else about the Services for that project
• If you are in the EEA, the UK or Switzerland, opting a project out is the way to object to this use under Section 8.2 for that project, and no other step is needed. A person who is not an administrator of a project may ask the project's administrator to opt it out, or write to us, and we will tell the administrator

A Call Booked With Us (where our website offers a booking page):

• If you booked it. Asking us at privacy@synergyinconstruction.com to delete the booking is the way to have it removed from our calendar (Section 5.1); the processor's copy is governed by its own privacy policy, linked in Section 4.1
• If a colleague invited you. Your email address was entered by the person who booked the call, and the invitation is the first you hear from us. Declining the invitation does not remove your address from the booking; asking us at privacy@synergyinconstruction.com does, and we then do not email you about the call. If you are in the EEA, the UK or Switzerland, that is the way to object under Section 8.2, and no other step is needed
• Follow-up. If we email you after the call and you do not want to hear more about it, reply and say so, and we stop. That email is not marketing email and carries no unsubscribe link; Section 12 governs marketing email, and nothing about a call subscribes you to it
• If the call was recorded. You were asked at the start, and you could have said no. Anyone who was on a recorded call can ask us at privacy@synergyinconstruction.com to delete the recording and anything we made from it, and we delete them (Section 5.1); that is also how you withdraw the consent you gave. A request for a copy of your personal information reaches what we hold from a recorded call you were on in the ordinary way

Opt-Out of Product Analytics and Session Replay:

• Request that your activity not be captured by our product-analytics processor (PostHog): the page views, clicks and form submissions your browser sends, the events our own server sends about what you did while signed in, and session replay if it is switched on (Section 4.1)
• Contact privacy@synergyinconstruction.com to opt out. The Services have no setting that does this, and we are not describing one here. We will tell you what we have done; at the least, we delete the identified data the processor holds about you (Section 5.1)
• If your browser's time zone places it in the European Economic Area, the United Kingdom or Switzerland, the processor is not loaded in your browser and your browser sends it nothing, without any request from you (Sections 4.1 and 10). That rule does not reach the events our server sends; the request above does
• You may also clear or block the processor's cookie and browser storage in your browser's settings (Section 10)

Objecting to Email Tracking:

• You may object to the email tracking described in Section 1.2 by contacting privacy@synergyinconstruction.com, and you may object to it under Section 8.2 if you are in the EEA, the UK, or Switzerland
• The Services provide no per-recipient setting that turns email tracking off, and we are not describing one here, because one does not exist. If you object, we will consider what we can do for the mail we send you and tell you the answer. We are not promising in advance that we can exclude your messages from it
• Two things you can do without us, stated so that you can judge them for yourself. Link rewriting is applied to a message when it is sent, so the only way a click is not recorded is not to follow the link — you can instead reach the same place by signing in to the Services directly. Where open tracking is enabled, configuring your email program not to load remote images prevents the open from being recorded; that control is yours and does not depend on us
• Note: most of the email SynC sends is transactional and cannot be unsubscribed from (Sections 12.2 and 12.3), so opting out of marketing communications does not end email tracking

A note on AI training. Earlier versions of this Policy offered a right to opt out of having your User Content used to train AI models. That right was removed in v1.8 because the use it applied to is prohibited outright: we do not use your content to train generative or foundation models, for ourselves or for anyone else, so there is nothing of that kind to opt out of. Terms of Service §5.3.1 states the full scope of that prohibition, the conditions under which we may build models that classify or score content without generating text, and its exceptions, which are the ones summarized in Section 2.2: content you submit to the SynC Standards library, feedback you direct to SynC, and any separate written agreement you execute, which the Terms say we will not require as a condition of providing the Services to you. Using your content to evaluate and improve the Services, which Terms of Service §5.3.1 permits, is not training, and the project opt-out above is the control you have over it.

8.2 Additional Rights for EEA, UK, and Swiss Users (GDPR)

Right to Restriction:

• Request restriction of processing in certain circumstances

Right to Object:

• Object to processing based on legitimate interests
• Object to direct marketing at any time

Right to Withdraw Consent:

• Withdraw consent for processing based on consent (does not affect prior processing)

Right to Lodge a Complaint:

• File a complaint with your local data protection authority

8.3 California Residents (CCPA/CPRA Rights)

California residents have additional rights under the California Consumer Privacy Act (CCPA) and California Privacy Rights Act (CPRA):

Right to Know:

• Request disclosure of categories and specific pieces of personal information collected
• Request disclosure of categories of sources, purposes, and third parties with whom we share information

Right to Delete:

• Request deletion of personal information (subject to exceptions)

Right to Opt-Out:

• We do not sell personal information, but you may opt out of sharing for cross-context behavioral advertising

Right to Correct:

• Request correction of inaccurate personal information

Right to Limit Use of Sensitive Personal Information:

• Request limitation of use of sensitive personal information (if applicable)

Right to Non-Discrimination:

• You will not receive discriminatory treatment for exercising your privacy rights

Authorized Agent:

• You may designate an authorized agent to make requests on your behalf

8.4 How to Exercise Your Rights

SynC operates exclusively online and has a direct relationship with the users of the Services. Requests may be submitted by email, and signed-in users may also exercise most rights directly through account settings:

• Email: privacy@synergyinconstruction.com
• Subject Line: "Privacy Rights Request"
• Include: Your name, email address, and description of your request

We will respond to verifiable requests within:

• 45 days, which is the period the CCPA allows; for a CCPA request the law allows one extension of a further 45 days, and we tell you if we take it
• Sooner where applicable law requires it

We may need to verify your identity before processing your request.

9. Children's Privacy

The Services are not intended for children under the age of 18, and we do not knowingly collect personal information from children under 18. If we become aware that we have collected personal information from a child under 18, we will take steps to delete such information promptly.

If you believe we have collected information from a child under 18, please contact us immediately at privacy@synergyinconstruction.com.

10. Cookies and Tracking Technologies

10.1 Types of Cookies We Use

Strictly Necessary Cookies:

• Essential for the Services to function (e.g., session management, authentication)
• Cannot be disabled without impairing functionality
• Where passkeys are offered, opening the sign-in page sets a session cookie before you sign in. The session behind it holds nothing but a one-time value for a passkey sign-in, and the cookie expires within fifteen minutes; it identifies no one and is replaced by your ordinary session when you sign in (Section 1.1)

Functional Cookies:

• Remember your preferences and settings
• Enhance user experience and personalization

Analytics Cookies:

• Collect information about how you use the Services
• Help us improve performance and user experience
• Our product-analytics processor (PostHog) keeps a per-browser identifier in a first-party cookie and in your browser's local storage, both named ph_<project key>_posthog, so that the identifier survives between visits. On the public SynC Standards library and our legal pages, a script of our own keeps a visitor identifier in local storage under the name ph_wiki_did, which the processor adopts when you later open the application in the same browser (Section 4.1). These are non-essential. None of them is set in a browser whose time zone places it in the European Economic Area, the United Kingdom or Switzerland, where the processor is not loaded at all. See Section 4.1 for the full disclosure of what PostHog receives and how a session recording, where replay is switched on, is masked.

Note on Web Analytics: Our current public-site web analytics processor (Cloudflare Web Analytics) is cookieless and does not set, read, or rely on any cookie or other persistent identifier on your device. See Section 4.1 for details. This is distinct from our product-analytics processor (PostHog), which does set a cookie and browser storage; the two processors serve different purposes. Both are present in the application and on the public SynC Standards library and our legal pages: the web-analytics processor counts traffic in aggregate, and the product-analytics processor records one browser's path under an identifier (Section 4.1).

Note on Wiki Search: The wiki-search records described in Section 1.2 do not involve a cookie or any other identifier stored on your device. Nothing is written to your browser to produce them. The same is true of the query-vector cache described in Section 5.1.

Note on Email Tracking: The tracking applied to the email we send you (Section 1.2) uses a rewritten link and, where enabled, an invisible image in the message. Neither is a browser cookie, neither is covered by the cookie controls in Section 10.2, and no cookie opt-out reaches them. They are carried inside the message, are applied by our email-delivery processor when it sends the message, and operate in your email program rather than on our site — so declining cookies here has no effect on them, and clearing cookies does not remove them. Section 4.1 states what our email-delivery processor receives; Section 8.1 states what you can do about it.

Advertising Cookies: none. We set no advertising or marketing cookie, and no cookie on our surfaces tracks your activity across other websites (see Section 15.3).

10.2 Cookie Management

You can control cookies through:

• Browser Settings: Most browsers allow you to refuse cookies or delete existing cookies
• Direct Opt-Out: You may opt out of non-essential cookies — including the product-analytics processor's cookie and browser storage, and session replay where it is switched on — at any time by contacting privacy@synergyinconstruction.com (see Section 8.1)
• No consent banner, and a region rule instead: We do not ask for consent to the product-analytics processor's cookie and browser storage, and the Services have no preference control for them. Instead, the processor is not loaded at all in a browser whose time zone places it in the European Economic Area, the United Kingdom or Switzerland, so nothing of its is set there (Section 4.1). The rule reads your browser's time zone, not where you are: a browser set to another time zone, a VPN or a travelling laptop can fall either side of it. Clearing your browser's cookies and site data removes the identifiers; a browser the rule does not exclude is given new ones on its next visit

Note: Disabling certain cookies may limit functionality of the Services.

10.3 Do Not Track

Some browsers support "Do Not Track" (DNT) signals. Currently, there is no industry standard for how to respond to DNT signals. We do not currently respond to DNT signals.

11. Third-Party Links and Services

The Services may contain links to third-party websites, applications, or services that are not operated by SynC. This Privacy Policy does not apply to those third-party services.

We are not responsible for the privacy practices of third parties. We encourage you to review the privacy policies of any third-party services you access.

Third-Party AI and Embedding Services: When you use AI-assisted features or semantic search, the content in scope for your request is processed by third-party providers on our behalf, subject to the constraints described in Section 4.1A and the commitments in Terms of Service §5.3.3. The providers we use or may use, with links to their own privacy and data-handling documents, which state where they process content and how long they keep it, are published at synergyinconstruction.com/legal/subprocessors. That list names every provider a request may reach without stating which one serves at a given time, and does not restate what a provider's documents say.

Payment Pages and the Billing Portal: When you buy seats or credits for your company, pay an invoice, or change your company's subscription or payment method, you do so on pages hosted by our payment processor (Section 4.1): a payment page and a billing portal. Those pages are operated by the processor, not by SynC, and the Services send you to them and receive you back from them. The payment card details you enter on them are collected by the processor directly and never pass through the Services, and the processor's own privacy policy — linked in Section 4.1 and on our subprocessor list — applies to what you enter there. The processor reports the outcome of what you did on its pages back to the Services, as Section 4.1 describes.

Signing in with Microsoft or Google: When you choose to sign in with Microsoft or Google, the Services send you to that provider's sign-in page and receive you back from it. What you enter there, including your password at the provider and any second factor, is entered on the provider's page and never reaches us. The provider shows you what SynC has asked for before you agree, and its privacy policy governs what it does with your account and with its record of the sign-in. Section 1.3 states what we receive back and what we do with it.

Booking a call: Where our website offers a booking page, you book a call with us on a page hosted by our scheduling processor (Section 4.1), not by SynC; the link on our site takes you to it, and the page carries a short notice from us about what you enter. What you enter there is collected by the processor directly and passed to our calendar, and the processor's privacy policy, linked on its page, applies to what you enter. If you enter the email addresses of colleagues to invite, the processor sends each of them the calendar invitation, naming SynC as the organizer, at the address you entered; a colleague has not seen the booking page, so the invitation carries a line from us saying that their address was entered by the person who booked, what we hold the booking for, and where this Policy is. The call itself is held on a video-meeting service provided by our workspace provider, under that provider's terms. At the start of the call we may ask everyone on it whether we may record it; if anyone declines, the call goes ahead unrecorded, and nothing on the booking page is that consent. Where everyone agrees, we record the call ourselves and hold the recording, and any transcript or notes we make from it, in our own storage, for our own reference and for following up on that call, and for nothing else (Sections 4.1, 5.1 and 8.1). After the call, we may email you, and a colleague who attended, about it, as Sections 2.5 and 4.1 describe; that email comes from our own mailbox, is about the call, and is not marketing email.

Apps and tools you connect with an API key: Where you use an API key from an outside app or tool (Section 4.10), everything about that app, including the conversation you have with it, the page you use it on, and what it shows you about SynC, is the app's, and its maker's privacy policy governs it. We do not see your conversation with the app; we see the requests it makes on your behalf (Section 1.3). What the app's maker keeps of what it reads, and whether it trains on it, is for its terms to say, and we do not promise that it does not.

12. Marketing Communications

12.1 Types of Communications

With your consent (where required), we may send you:

• Product updates and new feature announcements
• Educational content and best practices
• Industry news and insights
• Special offers and promotions
• Invitations to webinars and events

12.2 Opting Out

You may opt out of marketing communications at any time by:

• Clicking the "unsubscribe" link in any marketing email
• Updating your email preferences in account settings
• Contacting support@synergyinconstruction.com

Note: You cannot opt out of transactional emails (e.g., account notifications, password resets, billing statements) that are necessary for the Services.

12.3 Tracking Applies to All of Our Email, Not Only Marketing

The link rewriting and open tracking described in Section 1.2 are applied by our email-delivery processor to the messages it sends for us. They are not limited to marketing email, and unsubscribing from marketing does not remove them from anything else.

Most of the email SynC sends is transactional, not marketing — account verification, sign-in codes, the notice that someone tried to create an account with your address, the notices that a passkey was added to or removed from your account, the notices that your password or your primary address was changed, that an address was added to or removed from your account, or that your recovery address was changed, which go to every verified address on your account (Section 8.1), company and project invitations, share-link notices, notifications you have switched on, notices of moderation action that cannot be switched off (Section 5.1), including notice that your wiki contribution privileges have been suspended or restored, notice that your account has been terminated under the repeat-infringer policy, and, where SynC disables access to material you contributed in response to a copyright notice, the statement that you may send a counter-notification and the copy of the notice we send you (Section 4.9), and required notices about your account or your legal agreements with us. Section 12.2 states that you cannot opt out of transactional email; it follows that opting out of marketing communications under Section 12.2 does not stop that mail and does not stop it being tracked.

Section 8.1 states what you can do about the tracking itself, including what we can and cannot offer.

13. Changes to This Privacy Policy

13.1 Updates

We may update this Privacy Policy from time to time to reflect changes in our practices, technologies, legal requirements, or other factors.

13.2 Notice of Material Changes

When we make material changes, we will notify you by:

• Posting the updated Privacy Policy with a new Effective Date
• Sending email notification to your registered email address
• Displaying a prominent notice in the Services

A material change takes effect no sooner than thirty (30) days after that notice, except a change that the law requires, which takes effect when the law requires it, and a change that only adds to your rights, which may take effect on posting.

13.3 Your Acceptance

Continued use of the Services after changes become effective constitutes your acceptance of the updated Privacy Policy. If you do not agree to the changes, you must discontinue use of the Services.

13.4 Review History

Previous versions of this Privacy Policy are available upon request by contacting privacy@synergyinconstruction.com.

13.5 Changes from Version 1.2

Version 1.3 (effective May 27, 2026) carries v1.2 forward in full and adds disclosures for one newly added third-party data processor:

• PostHog (Product Analytics + Session Replay) — a product-analytics and session-replay processor used to measure feature usage, conversion funnels, and qualitative drop-off across the application. Added to Section 4.1 with full disclosure of categories of data received (event data, identified user association after login, and session recordings), processing location (United States, PostHog US cloud at app.posthog.com), session-replay input masking (typed text masked by default, password fields always masked, ph-no-capture DOM redaction), and the fact that PostHog sets first-party cookies on your browser.
• Section 3 (Legal Basis) was updated to add product-analytics processing under Legitimate Interests (subject to consent for non-essential cookies) and to call out the product-analytics processor's cookies and session-replay recordings under Consent.
• Section 5.1 (Data Retention) was updated to add retention notes for PostHog event data and session recordings, and to describe the deletion mechanism for identified product-analytics data.
• Section 7.1 (Cross-Border Transfers) was updated to add PostHog as an additional US-based recipient of transferred data.
• Section 8.1 (Rights for All Users) was updated to add an explicit opt-out for product analytics and session replay.
• Section 10.1 (Cookies) was updated to disclose that PostHog sets first-party cookies (in contrast to the cookieless Cloudflare Web Analytics processor), and Section 10.2 was updated to note that you can decline non-essential cookies (including PostHog) where required by law.
• Section 15.3 (CCPA categories disclosed) was updated to reflect that Internet activity is now disclosed to web-analytics, product-analytics, and error-monitoring providers.

No other substantive changes were made; all prior obligations, definitions, and user rights from v1.2 remain in effect.

13.6 Changes from Version 1.3

Version 1.4 (effective May 29, 2026) carries v1.3 forward in full and makes one clarifying change to how third-party processors are described. It does not add, remove, or change any processor, data category, processing purpose, safeguard, or user right.

• Section 4.1 (Service Providers and Processors) now states expressly that the named processors are those used as of the Effective Date, that the list is not exhaustive or permanent, that the categories of data, purposes, and safeguards described continue to apply to any processor performing the same function if a processor is later added, replaced, or discontinued, and that a current subprocessor list is available on request. The three analytics/observability processor headings (Web Analytics, Product Analytics, Error Monitoring) were reworded to identify each named vendor as our current processor for that function rather than as the sole permanent provider.
• Section 7.1 (Cross-Border Transfers) was conformed to describe the listed processors as those disclosed as of the Effective Date and to cross-reference the non-exhaustive framing in Section 4.1.

This change was made so that adding, replacing, or discontinuing a processor in the ordinary course — for the same function and within the same categories of data, purposes, and safeguards already disclosed — does not render this Policy inaccurate. A change of that kind is not, in itself, a material change; material changes (for example, a new category of data, a new processing purpose, or a new transfer destination) continue to be handled under Sections 13.1–13.3. No other substantive changes were made; all prior obligations, definitions, and user rights from v1.3 remain in effect.

13.7 Changes from Version 1.4

Version 1.5 (effective June 9, 2026) carries v1.4 forward in full and makes the corrections described below. It does not add or remove any processor, data category, or processing purpose, and it does not reduce any user right. Several descriptions of our practices were corrected to match what we actually do — in each case the correction makes the Policy more accurate, not the practice less protective.

• Contributor-attribution treatment corrected and clarified as pseudonymization. Sections 4.4, 5.1, 5.2, and 8.1 were corrected to describe accurately what happens to your SynC Standards contributor attribution when you delete your account. The prior text stated that contributions remain in the public repository "with attribution." In fact, on account deletion your public-facing attribution is removed so that the public can no longer identify you (CLA §2A.3), while SynC retains a limited, non-public, access-restricted record linking each contribution to its contributor only as reasonably necessary for legal-claims and licensing-integrity purposes (CLA §2A.4). Because that retained record can in principle re-associate a contribution with you, the overall treatment of your contributor-attribution data is pseudonymization rather than anonymization for data-protection purposes. The contribution content itself continues to be retained under CC-BY-SA 4.0. This conforms the Privacy Policy to the Contributor License Agreement, Section 2A.
• Entity-name correction. The data controller is now identified consistently as "Synergy In Construction, LLC, a Wyoming limited liability company" (preamble and Section 14.1), correcting the prior description "a Wyoming corporation" to match the legal entity named in the Contributor License Agreement and the Terms of Service.
• Security-practices disclosure conformed to actual practice (Section 6.1). The list of technical and organizational safeguards was corrected to describe the measures we actually maintain (TLS 1.2+ in transit, bcrypt password hashing, automated daily backups with tiered retention, restricted key-based production access, need-to-know access, processor data processing agreements, and incident response procedures). Claims of practices not currently performed — regular third-party security audits and penetration testing, intrusion detection and prevention systems, formal employee training programs, and at-rest encryption — were removed so the Policy does not overstate our security posture.
• Breach notification (Section 6.3). Reworded to commit to notification "without undue delay, within the timeframes required by applicable law," rather than "typically within 72 hours" — the 72-hour period under GDPR applies to notifying the supervisory authority, not affected users.
• Cookie controls (Sections 8.1, 10.2). The reference to a "Cookie Preference Center available in your account settings" was removed because that control does not currently exist. The Policy now accurately describes the available controls: browser settings, a direct opt-out via privacy@synergyinconstruction.com, and a commitment to provide a consent mechanism before non-essential cookies are set where applicable law requires one.
• Data-protection contact (Section 14.3). Retitled from "Data Protection Officer" to "GDPR and Data-Protection Inquiries" and clarified that SynC has not designated a formal DPO (one is not currently required); voluntarily claiming a DPO would trigger formal GDPR obligations that do not reflect our current operations.
• DPIA statement (Section 15.4). Corrected from a claim that DPIAs "have been conducted" to a forward-looking commitment to conduct them where required by law before undertaking high-risk processing, noting that no such processing occurs as of the Effective Date.
• AI-training current-practice statement (Section 2.2). States that as of the Effective Date we do not train AI models on User Content, and commits to obtaining opt-in consent where applicable law requires it before such use — aligning the Policy's consent legal basis (Section 3) with the opt-out mechanism and with Terms of Service §5.3.3.

No other substantive changes were made; all prior obligations, definitions, and user rights from v1.4 remain in effect.

13.8 Changes from Version 1.5

Version 1.6 (effective August 3, 2026) carries v1.5 forward in full and makes two changes: the entity's state of organization and contact block are updated for a redomestication, and a new disclosure is added for anonymous wiki-search telemetry. It does not remove any user right, and it does not add or remove any third-party processor.

• The entity redomesticated from Wyoming to Florida. Synergy In Construction, LLC completed a statutory conversion from a Wyoming limited liability company to a Florida limited liability company, effective upon the entity becoming active in Florida on August 2, 2026. A statutory conversion changes the entity's state of organization; it does not create a new entity. The same legal entity continues, with the same Employer Identification Number, and remains the data controller for all personal information it held before the conversion. No personal information is transferred to, or disclosed to, any new or different entity as a result — the conversion is not a business transfer under Section 4.6, and Section 4.6's notice obligation is not triggered by it. The controller is accordingly now identified as "Synergy In Construction, LLC, a Florida limited liability company" (preamble and Section 14.1). This change does not affect any party's rights. Note that this Policy contains no governing-law or venue clause; the corresponding governing-law and venue changes were made in the Terms of Service (v1.5, §17).
• The street address was removed; contact is by email (preamble, Sections 8.4 and 14.1). SynC no longer publishes a street address in this Policy. The controller's identity and contact details required by GDPR Article 13 are given in Section 14.1 as the entity's legal name, its form and state of organization, its country, and the privacy mailbox privacy@synergyinconstruction.com. Requests to exercise your rights are submitted to that same mailbox (Section 8.4), which is the address this Policy already designated for every privacy request, opt-out, subprocessor-list request, and DPA request. No method of contact available to you under v1.5 has been withdrawn other than postal mail, and no right is narrowed: every right in Section 8 is exercised exactly as it was before.
• New disclosure: anonymous wiki-search telemetry (Sections 1.2, 2.3, 3, 4.1, 5.1, 5.2, 8.1, 10.1). This Policy now discloses that when you search the public SynC wiki without signing in, we record what you searched for and which result you opened, so that we can see which standards are missing or hard to find. These records include no IP address, device or browser identifier, and no link to any account; they are never used to build a profile of you, and they are deleted after 90 days. The disclosure is carried through to the legal basis (legitimate interests, Section 3), the purpose (Section 2.3), retention (Section 5.1), and cookies (Section 10.1 — nothing is stored on your device to produce these records). Section 4.1 states that this telemetry is first-party and is disclosed to no processor. This does not narrow any right, but it does record one limit on the deletion and access rights in Section 8.1: because an anonymous search record holds no identifier, we have no means of finding the records that came from any particular person, so we cannot single them out in response to a request; they are deleted for everyone at 90 days. Searches you run while signed in continue to be ordinary account activity associated with your account, and are covered by the same 90-day deletion.
• Section 8.4 additionally notes that SynC operates exclusively online and has a direct relationship with users of the Services, which is the basis on which an email address serves as the designated method for submitting requests under the CCPA.

No other substantive changes were made; all prior obligations, definitions, and user rights from v1.5 remain in effect. The addition of a previously undisclosed collection practice is a material change, and notice is given under Sections 13.1–13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services.

13.9 Changes from Version 1.6

Version 1.7 (effective August 7, 2026) carries v1.6 forward in full and accompanies Terms of Service v1.6, which replaced permanent "Vested Access" for share-link recipients with owner-revocable access. This version states retention rules for two categories of records this Policy already disclosed collecting but did not give retention periods. It does not add or remove any processor and does not change what is shared with any third party. Section 1.2's description of distribution records is extended to name two event types the platform now records — the removal of a recipient's access, and the deletion of a distributed project — which are first-party records in the same category this Policy already disclosed (share-link creation, acceptance, and access records).

• Retention period stated for project distribution and access records (Sections 3, 5.1, 5.2, 8.1). Section 5.1 now states that records of project distribution events (Section 1.2) are retained for up to fifteen years from the event, per record; that they survive project deletion and account closure; and that at the end of the period the personal identifiers in them are redacted rather than the records deleted. Section 5.2 now states expressly that these records are exempt from deletion requests for that period — and no longer — because they are kept to establish, exercise, or defend legal claims arising from distributed project content, and that the exemption reaches no other category of personal information. Section 3 adds the corresponding legitimate-interests basis. Previously, these records had no stated retention period, and Section 5.2's 30-day deletion commitment was unqualified as to them; stating the rule and its limit resolves that tension in the text rather than leaving it to interpretation.
• Retention rule stated for contributor-attribution records (Sections 5.1, 5.2). The non-public record linking a contribution to its contributor (Section 4.4) previously had a purpose limit but no stated retention rule. Section 5.1 now states it: the record is retained for as long as the contribution remains available in the public SynC Standards corpus, plus six years, with "remains available" defined by the permanence of adopted revisions. This is a condition tied to the content's lifecycle rather than a fixed period, and Section 5.1 now explains why the two categories of records carry rules of different kinds.
• No automated deletion mechanism is claimed. The earliest distribution records reach the end of their retention period in 2041. This Policy states the retention rule; it does not describe an automated redaction mechanism, and none is asserted to exist.

The statement of a previously unstated retention period — including that certain records are retained after project deletion and account closure and are exempt from deletion requests for a defined period — is a material change, and notice is given under Sections 13.1–13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. No other substantive changes were made; all prior obligations, definitions, and user rights from v1.6 remain in effect.

13.10 Changes from Version 1.7

Version 1.8 carries v1.7 forward in full and accompanies Terms of Service v1.7, in which SynC withdrew its reserved right to use customer content as AI training or research material. This version does two things: it conforms this Policy to that withdrawal everywhere the reserved right appeared, and it closes a live disclosure gap by describing the AI-inference and text-embedding processing that this Policy did not previously describe accurately.

No user right is narrowed by this version except the AI-training opt-out, which is removed because the practice it opposed is now prohibited outright for everyone. Every other change either strengthens a commitment or corrects a description to match what we actually do.

What was disclosed inaccurately, and is now fixed. v1.7 §4.1 named our AI processors as "Grok by xAI, Google Gemini, OpenAI, Anthropic," and §11 repeated that list. In production the platform routes inference through an inference router, which was named nowhere in the Policy and which selects a downstream host per request — so the operative data policy is the selected host's, not the router's. Separately, semantic search converts content into numeric vectors through a third-party embedding service, which v1.7 did not disclose at all, and the index it builds covers customer content: company libraries, project specifications, and customized standards. The disclosure was therefore simultaneously over-inclusive (naming vendors not in use) and incomplete (omitting the two that are). New Section 4.1A describes both flows and the controls applied to them; the vendor instances now live on the published subprocessor list, where they can be kept current without a version bump.

• Section 2.2 rewritten. The "AI Training and Model Improvement" block — which permitted using User Content to train models after removing identifiers, and permitted aggregating the result with other users' data — is deleted in full and does not survive in any form. The "Current Practice and Your Rights Regarding AI Training" block, which reserved the right to begin training and offered an opt-out, is also deleted. In their place, §2.2 states that we do not use User Content to train generative, general-purpose, or foundation models, whether or not it has been anonymized or aggregated, and defers to Terms of Service §5.3.1 for the scope of that commitment, its conditions, and its exceptions, which govern if the two ever differ. This is deliberate: two documents each defining "training" is how the two documents come to disagree. §2.2 also discloses that we may build models inside the Services that classify, score, or flag content, and states the three conditions §5.3.1 imposes on them — structured outputs rather than generated text, never distributed outside the Services, and no reproduction of your content to anyone not already authorized to see it. The prohibition is narrower than an earlier draft of this version, which barred any machine-learning model at all and would have foreclosed ordinary product features that cannot reproduce a specification. The commitment customers rely on — that specifications are not fed to language models — is unchanged. The "Third-Party AI Services" block is replaced with one covering both inference and embedding and pointing at the published subprocessor list.

• New Section 4.1A (AI Inference and Embedding — What Leaves Our Servers). Describes what is transmitted for the AI assistant and for semantic search, states that embedding covers your own standards and project specifications and not only public content, and states the three categories of control applied to each request: logging and training prohibited at the provider, processing restricted to vetted hosts with automatic failover disabled, and fail-closed behaviour so that a constraint is never relaxed in order to complete a request. It states what a request carries — only the content in scope, never credentials or payment details — and where the resulting vectors are stored.

• Section 4.1 processor categories corrected. The AI bullets naming four vendors are replaced with two functional categories (inference providers and routers; text-embedding providers). Several other illustrative vendor examples were removed because they named services not in use — email delivery, customer support, authentication, and additional cloud platforms are now described by function. The payment-processor entry is now expressly conditional, because no payment processor is integrated. The "processors change over time" paragraph now points to the published subprocessor list in addition to the on-request list.

• Section 3 (Legal Basis) conformed. The Consent basis for "AI training using anonymized User Content" is deleted; there is no such processing. Two entries are added to describe the §4.1A processing: contract performance for transmitting content to answer a request you made or to run a search you asked for, and legitimate interests for building and maintaining the search index, because content is embedded when it is created or changed rather than only when a search is run.

• Section 4.5 narrowed and retitled "Aggregated Statistics." v1.7 §4.5 permitted sharing "aggregated, anonymized, or de-identified data" with research partners, industry organizations, business partners, and the public. Read against the definition of anonymization then in force, that could be read to permit publishing de-identified customer specification text. §4.5 now permits sharing only aggregated statistics of the kind described in Terms of Service §5.3.2, and states expressly that we do not share your content, or any adaptation or excerpt of it, whether or not identifying details have been removed.

• Section 5.1 retention conformed, and a gap filled. The "Anonymized Data" block — "retained indefinitely," "cannot be re-associated with you" — is deleted, because there is no such category. A new "Derived Search Data" block states retention for the two things semantic search actually creates: embedding vectors, retained for as long as the content they derive from and removed from the index when that content is deleted; and a query-vector cache, which is shared across all users, keyed by the text of the query, carries no account identifier and no link to the person who ran the search, and is evicted on a least-recently-used basis rather than after a fixed period. This also repairs a cross-reference: §4.1A points to Section 5 for a retention rule that Section 5 did not previously contain.

• Sections 5.2 and 8.1 conformed. The statement "Anonymized data in AI models cannot be removed" is deleted from both, as is the Opt-Out of AI Training right in §8.1. §8.1 now carries a short note explaining why that right was removed rather than deleting it silently. Both Sections gain a note that query-vector cache entries, like anonymous search records, carry no identifier and therefore cannot be singled out in response to a request — a limit on the deletion right that arises from the absence of an identifier, not from a retention policy.

• Section 7.1 (Cross-Border Transfers). States that inference and embedding requests are restricted to vetted hosts with automatic failover disabled, so that other hosts are excluded by configuration rather than by preference, and that the jurisdictions those hosts process in are published on the subprocessor list. The jurisdictions are deliberately not named in this Policy: the host set is a configuration value, and naming it here would make this Policy inaccurate on a deploy.

• Section 11 conformed. The four-vendor AI list, which survived verbatim from v1.7 and had the same defects as the §4.1 list, is replaced with a pointer to the subprocessor list.

• Section 15.3 corrected. v1.7 stated that commercial information had been "collected and disclosed" to payment processors in the preceding twelve months. No payment processor is integrated with the Services, so no such disclosure occurred. This was over-disclosure rather than under-disclosure, so the risk was low, but it is corrected here.

• Accuracy corrections carried over from v1.7. Four descriptions were corrected to match what we can actually state. §2.3 listed "conduct research and development for new features" as a purpose applying to all collected information, including your specifications — which contradicted the new prohibition on using content as research material; it is now limited to usage data and structural statistics. §7.2 asserted that Standard Contractual Clauses are implemented for international transfers; it now states that we rely on appropriate safeguards, which may include SCCs where required. §4.1 and §5.1 stated a processor's conduct as fact ("deleted by PostHog," "cannot be re-associated with you"); these are now attributed to the processor, because we can contract and configure but cannot know. §1.1 described your password as "encrypted," which is not what happens — §6.1 correctly says hashed with bcrypt, and §1.1 now says hashed. None of these changes any practice; each removes a statement we could not stand behind.

• Drafting annotations removed. The inline reviewer's notes carried in the v1.7 reference file were editorial annotations addressed to counsel, not disclosures, and were already excluded from the published v1.7 by the publishing migration's content guard. They are not carried into this version's text. No operative sentence they annotated is changed by their removal.

Notice of these changes. The withdrawal of the reserved AI-training right, the removal of the corresponding opt-out, and the disclosure of a previously undisclosed category of processing (text embedding) are material changes, and notice is given under Sections 13.1–13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. No other substantive change is made; all other obligations, definitions, and user rights from v1.7 remain in effect.

13.11 Changes from Version 1.8

Version 1.9 carries v1.8 forward in full. It accompanies the citation feature, under which a document published on the main site can cite a SynC Standard by clause, and it makes one substantive addition: it discloses the citation index that feature maintains and the aggregate citation counts the Services can display from it. This version takes effect no later than the first release that serves those counts.

No user right is narrowed by this version. Nothing previously permitted is withdrawn and nothing previously prohibited is permitted; the changes disclose a new category of derived processing and state its retention rule.

• Section 4.5 extended. A new passage describes the one aggregate statistic the Services display to other users: the number of citation occurrences pointing at a SynC Standard, which may include citations made in documents the viewer cannot read. It states the limits that bound the disclosure — a bare number of occurrences, with no titles, authors, organizations, or any other detail that varies with the hidden documents; occurrences rather than documents, so the number cannot distinguish one document with many citations from many documents with one; citing documents named or linked only to viewers already authorized to read them — and states plainly what an observer of the public number can infer over time and what they cannot.
• Section 2.3 extended. The citation index is added to the processing purposes: resolving citations for readers of the citing document, warning Wiki editors about the impact of an edit on documents that cite the edited clause, and producing the Section 4.5 counts.
• Section 3 extended. A legitimate-interests entry is added for maintaining the citation index and displaying the Section 4.5 counts, in the same form as the entry for the search index.
• Section 5.1 extended. A "Derived Citation Data" block states the retention rule in the same form as Derived Search Data: index entries are derived from published content, replaced in full on each publication of the citing document, removed at the moment that document is deleted, and never created from drafts. It also states the one asymmetry — deprecating a document without deleting it leaves its entries in place, because a deprecated document still cites what it cites.
• Self-references now render as links. Four references to the subprocessor list (Sections 2.2, 4.1, 7.1, and 11) were written as bare text and did not render as links; they are now markdown links to the same page. No wording is changed.
• Section 13.10's closing drafting note shortened. Its final clause pointed readers at internal review records that do not ship with this Policy; the clause is removed. No operative term is affected.

Notice of these changes. The disclosure of a new category of derived processing — an aggregate statistic visible to other users and to the public, derived in part from documents their viewers cannot read — is announced under Sections 13.1–13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. All other obligations, definitions, and user rights from v1.8 remain in effect.

13.12 Changes from Version 1.9

Version 1.10 carries v1.9 forward in full. It accompanies Terms of Service v1.8 and the AI chat-history feature, under which your conversations with the AI assistant are stored on our servers instead of existing only in your browser. This version discloses what is stored, states the retention rule that governs it, and states who can see it. It takes effect no later than the first release that stores conversations on production.

No user right is narrowed by this version. Nothing previously permitted is withdrawn and nothing previously prohibited is permitted. The changes disclose a new category of stored content, state its retention rule and its limits, and record the controls you have over it.

What is new is the storage, not the collection. v1.9 §1.1 already disclosed that we collect "AI chat interactions and queries," and §1.2 already listed "AI interaction history" as usage information. What that text did not say is that a conversation is now kept — as a durable record, on our servers, for a stated period — rather than living in your browser until you close the tab. A retention period is the disclosure a reader actually needs, and v1.9 did not contain one for this category. That is what this version adds. For the same reason, no new category of personal information arises under Section 15.3, and that Section is unchanged by the conversation disclosure.

This version also closes a second, unrelated disclosure gap: the tracking applied to the email we send. SynC's email is delivered by a third-party processor which rewrites every link in a message so that a click is recorded before you are redirected, and which can also record that a message was opened. Neither the processor nor the tracking was disclosed in any previous version of this Policy. That is a category of automatically collected information, a processor receiving your personal data, and a transfer to the United States, and the link rewriting is directly visible to any reader who hovers over a link in our email and sees an unfamiliar awstrack.me address. It is now disclosed in Sections 1.2, 3, 4.1, 5.1, 7.1, 8.1, 10.1, 12.3, and 15.3.

• Section 1.1 extended. A new passage states what a stored conversation contains: your messages, the assistant's replies, and a plain-language record of the actions it took and the outcome of any change you approved. It states that a machine payload produced by an action is reduced to identifying information before the conversation is stored, that the provider and model serving each exchange are recorded, and that a conversation carries the context it was started in and may be restored automatically when you reopen the assistant in that context — with the Services showing you that this has happened.
• Section 2.1 extended. Storing conversations, and restoring a recent one, are added to the service-delivery purposes.
• Section 2.2 extended. Two AI-feature purposes are added: continuing a stored conversation, which requires transmitting it to a provider again, and generating a short title for it by a separate small inference request. A bullet is added to the no-training block stating that your messages to the assistant are User Content and the no-training commitment applies to them, and that storing a conversation does not create a training use.
• Section 3 extended. A contract-performance entry covers storing, restoring, and re-transmitting a conversation, because those are what the feature you are using consists of. A legitimate-interests entry covers generating titles and enforcing the storage limits in Section 5.1.
• Section 4.1A extended. States that continuing a stored conversation retransmits it — in the reduced form described in Section 1.1 — because the provider holds no memory between requests, that title generation is a separate request over the same content, and that reading a stored conversation transmits nothing, because displaying history is a database read.
• New Section 4.2A (Conversations with the AI Assistant Are Private to You). States that the Services provide no means for anyone else to view your conversations — no sharing control, no team or company visibility, no view for a project owner or another participant, and no administrative view in the product — and that conversation content never enters a published document, a revision record, or an export of project content. It states expressly that this describes what the Services do and is not a claim that the stored records are beyond our reach: our personnel may access them where necessary to operate, secure or repair the Services, to answer your own request under Section 8, or under Section 4.7. Section 4.2 is conformed with one sentence directing the reader here.
• Section 4.2A also states the permission-drift position, and states it in the honest direction. Your own past conversations are retained as your record, and that retention does not depend on your still having access to the material they discuss — so a conversation survives the removal of a share link, a change of role, or the deletion of the content. This version deliberately does not claim that a stored conversation contains no project content, because that claim would be false: reduction removes raw payloads, not the assistant's prose, and prose written about a specification restates parts of it. What is offered instead is bounded retention, invisibility to other users, and immediate deletion on demand.
• Section 5.1 extended. A new "AI Assistant Conversations" block states the retention rule: 180 days measured from last activity, not from creation, restarted by each message, with automatic deletion at the end. It states that no expiry warning is given and that no action exists whose only effect is to exempt a conversation from the period; that your own deletion is immediate and single-stage, with no trash and no recovery; and that limits exist on the number of stored conversations and the length of one, enforced by deleting the conversation you have gone longest without using. The block states expressly that this period is separate from and independent of the account-deletion periods above — conversations survive the account-restoration period so that a restored account recovers them, and are deleted when the account is permanently deleted, whether or not their 180 days have run.
• Section 5.2 extended. A deletion-request entry states that conversations are deleted with a permanently deleted account, are not exempt from a deletion request, and are deliberately not deleted at the moment you ask to close the account — with the reason, and with a pointer to the immediate self-service deletion that does not require waiting.
• Section 8.1 extended. A new block records what you can do with your conversations: list and revisit, rename an automatically generated title, copy one out as readable text (the way to keep one past the retention period), delete one immediately, and receive them as part of an access request. It states that these controls remain available if your account's access to the AI assistant ends — you keep read, copy and delete, and lose only the ability to start or continue a conversation.

The email-tracking disclosure described above is made in the following places.

• Section 1.2 extended — email interaction data. A new passage states that our email-delivery service applies tracking to the messages it sends for us: that every link is rewritten to resolve through the tracking domain awstrack.me, which records the click and then redirects you, and that this is why hovering a link in our email shows that address rather than ours; and that where open tracking is enabled on our account, an invisible image in the message records that it was opened. It states what each records — which link or which message, with IP address, date and time, and client information — and that no email interaction record is written to your SynC account or to our application database.
• Section 4.1 extended — Email Delivery processor (Amazon SES). A processor entry is added in the same shape as the Web Analytics, Product Analytics, and Error Monitoring entries, identifying Amazon Web Services, Inc. and Amazon SES, stating US processing, the purpose, the categories of data received, what is not received, and that the tracking is configured on our email-delivery account rather than built into the Services — which is why Section 8.1 does not offer a switch in the product. The "Transactional email delivery services" bullet now points at that entry.
• Section 3 extended. A legitimate-interests entry is added for measuring whether the email we send is delivered and acted on.
• Section 5.1 extended — and states a retention period we do not know. A new "Email Interaction Data" block states that these records are held by the processor and not in our database, and then says plainly that we are not able to state a retention period for them and will not invent one, because the period is set by that processor's configuration and terms rather than by a setting we maintain and we do not currently hold a documented figure. It commits to stating the period here once established. Every other retention rule in Section 5.1 gives a period or a condition; this one gives neither, and says so rather than appearing to.
• Section 7.1 extended. Amazon Web Services, Inc. is added to the list of processors receiving transferred data, with US-region processing, because email delivery is a transfer to the United States like the three already listed.
• Section 8.1 extended. A new block states that you may object to email tracking by contacting us and under Section 8.2, and states the limits honestly: there is no per-recipient setting that turns it off and this Policy does not describe one, because one does not exist; if you object we will consider what we can do and tell you the answer, without promising in advance that we can exclude your mail. It also states the two things you can do without us — not following the link, and configuring your email program not to load remote images — and notes that a marketing opt-out does not reach transactional mail.
• Section 10.1 extended. A note states that email tracking is not a browser cookie, is not covered by the cookie controls in Section 10.2, and is reached by no cookie opt-out, because the mechanisms are carried inside the message and operate in your email program rather than on our site. Section 10 already referred to "web beacons, pixels, and similar tracking technologies" while describing only site cookies; this closes that gap.
• New Section 12.3. States that the tracking applies to all of our email and not only marketing, that most of the email SynC sends is transactional — verification, invitations, share-link notices, notifications, and required legal notices — and that unsubscribing from marketing under Section 12.2 therefore neither stops that mail nor stops it being tracked.
• Section 15.3 updated. Email-delivery providers are added to the recipients of Identifiers and of Internet activity disclosed for business purposes. No new category of personal information arises; the recipient set changes.

Notice of these changes. Beginning to retain a category of user content that was not previously retained and stating the period for which it is kept, and disclosing a previously undisclosed category of automatically collected information together with the processor that collects it and the transfer to the United States that it involves, are material changes, and notice is given under Sections 13.1–13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. All other obligations, definitions, and user rights from v1.9 remain in effect.

13.13 Changes from Version 1.10

Version 1.11 carries v1.10 forward in full and accompanies Terms of Service v1.9, which rewrites the Terms' Section 10 (Fees and Payment). This version makes one change: SynC has engaged a payment processor and connected the Services to it, and this Policy now discloses that — who the processor is, what the Services send it, what you give it directly, what it sends back, what we store of that, where it processes, and how long the records are kept. It does not add or change any other processor, and it does not narrow any user right.

What changed in fact, and why the disclosure is shaped the way it is. v1.10 §15.3 stated that no payment processor was integrated with the Services and that the payment-processor entry in §4.1 named a category we would engage, not one in use. That was true when written and is no longer true. Firms now buy seats and AI credits through Stripe: the Services open a purchase page that Stripe hosts, the purchaser pays there, Stripe reports the result back, and the Services grant what was bought and keep the record. A seat subscription then renews through Stripe automatically, on the authority the Terms of Service §10 state. The disclosure is written to that shape, in both directions — what goes to the processor and what comes back — because a reader who is told only that "a processor is used" will assume either too much or too little. Two things a reader might assume are stated not to happen: card and bank numbers are entered on the processor's page and never reach the Services, and no content, conversations, credentials, or usage data go to the processor. v1.8 corrected §15.3 because v1.7 had claimed a disclosure to a processor that did not exist; every sentence added here describes what the Services actually do, and Appendix A of the drafting record ties each one to the code that does it.

• Section 1.1 revised. The "Payment Information" block is replaced by a "Billing Information" block that states what we actually hold: the billing contact details the purchaser enters on the processor's page and the processor reports back to us (or gives us in writing for an invoiced arrangement); the purchase and subscription records — what was bought, quantities, periods, status, renewal date and count, credit packs, amounts charged and paid, and which user started each purchase; the processor's identifier for your firm's billing account and the event records it sends us. It states expressly that payment method details are not collected by us — you give them to the processor directly, on its page — and that the processor's records may state the kind of payment method but never its number.
• Section 4.1 extended — Payments processor (Stripe). A processor entry is added in the same shape as the Web Analytics, Product Analytics, Error Monitoring, and Email Delivery entries. It identifies Stripe, LLC; states the purpose (selling seats and credit packs, charging and renewing subscriptions, hosting the billing portal, issuing invoices and receipts); states how it is used — the Services are connected to it, open its purchase page, and receive its reports, and subscriptions renew through it automatically; separates what we send it (the firm's name and contact email, our identifiers, the item and quantity, a trial end date) from what you give it directly (card details, purchaser name and email, billing address, promotion code, and any change made on its portal) and from what it sends back (subscription status, items and quantities, period dates, booked changes, amounts charged and paid, an invoice link, and the billing details you entered — the kind of payment method, never its number); states what is not sent or received (credentials, content, conversations, usage data); states US processing, with the processor's own statement that it may transfer data to its affiliates and sub-processors in other jurisdictions; and records that, by its own Data Processing Agreement, Stripe acts as a processor for some data and as an independent controller for other data. The "Payment processors, where and when payment functionality is enabled" bullet becomes unconditional and points at that entry.
• Section 2.1 and Section 3 conformed. "Process transactions and subscriptions" becomes selling seats and credits to your firm, keeping the record of what it holds and has paid for, applying what the processor reports, and notifying your firm of a failed payment or a coming lapse. The contract-performance basis "Transaction processing" becomes selling to your firm and operating its subscription, including disclosing its name and billing contact details to the processor and receiving purchase and subscription status back.
• Section 4.1 (PostHog) sharpened. The "No payment data" bullet previously said card details were entered into the processor's "hosted fields," which describes an embedded form on our pages. There is none: the purchase page is the processor's own, outside the Services. The bullet now says that no payment details are entered anywhere on our surfaces, so they are never in the DOM available to PostHog. That remains true with the integration, because the integration sends you to the processor's page rather than embedding it.
• Section 5.1 extended — Billing and Invoice Records. A retention block states where these records live — the Services' database, our account with the processor, and our own financial records — that we keep them for as long as tax, accounting, and audit law requires financial records to be kept, that they are not deleted on account deletion during that period, that the seats and credits a purchase supports lapse while the record of the purchase does not, and that the processor keeps its own transaction records for periods it sets and we do not state. It also states that there is nothing of the card-or-bank-details kind in our records to retain or delete.
• Section 5.2 extended. A deletion-request entry states that billing and invoice records are retained for that period notwithstanding a deletion request, because the obligation to keep them is a legal one, and states the exemption's limits: it reaches those records only — including the processor's event records about them — only for firms that have made a purchase or been invoiced, and never card or bank details, which we do not hold.
• Section 7.1 extended. Stripe, LLC is added to the list of processors receiving transferred data, with US processing and the processor's stated onward transfers, in the same form as the four entries already there, and with a summary of what it receives from us, what the purchaser gives it, and what it returns.
• Section 11 extended. A "Payment Pages and the Billing Portal" note states that the page on which you buy or pay, and the portal on which you change your firm's subscription or payment method, are operated by the processor, not by SynC; that the Services send you to them and receive you back; that what you enter there is collected by the processor directly; that the processor's own privacy policy applies to it; and that the processor reports the outcome back to the Services. These are third-party pages you are sent to, which is what Section 11 is about.
• Section 15.3 corrected the other way. The paragraph stating that no payment processor is integrated and no commercial information has been disclosed to one is removed, because neither half is true any longer. Commercial information is now listed as collected and as disclosed — for firms that buy seats or credits, or that we invoice, and consisting of the billing details and purchase, subscription and payment records described in Section 4.1. Identifiers are also listed as disclosed for payment processing, for the same firms. A replacement paragraph states that payment card and bank account details appear in neither list because we never hold them, that we therefore do not collect the financial-account information the CPRA treats as sensitive, and that a user whose firm has never bought anything and never been invoiced has no commercial information with us at all.
• The subprocessor list is updated in step. The page at synergyinconstruction.com/legal/subprocessors, which previously stated that no payment processor was engaged, now lists Stripe with its disclosed processing locations, links to its privacy terms, and a description of the connection between it and the Services.
• No other change. No other processor is added, removed, or changed. The AI-inference and text-embedding disclosures (Sections 2.2, 4.1A, 7.1), the conversation-retention rules (Sections 1.1, 4.2A, 5.1), the email-tracking disclosures (Sections 1.2, 4.1, 5.1, 8.1, 10.1, 12.3), the distribution-record and contributor-attribution retention rules (Section 5.1), and every right in Section 8 are carried forward unchanged.

Notice of these changes. Disclosing a new processor that receives a category of personal information — commercial information — not previously disclosed to any third party, together with the transfer to the United States that it involves and the new category of records the Services keep, is a material change, and notice is given under Sections 13.1–13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. The disclosure applies in practice only to firms that buy or are invoiced; the notice is given to all registered users regardless. All other obligations, definitions, and user rights from v1.10 remain in effect.

13.14 Changes from Version 1.11

Version 1.12 carries v1.11 forward in full. It accompanies Terms of Service v1.11, which describes holds on SynC Standards material and gives project deletion a restore period, and Contributor License Agreement v2.5, which adds a contributor's election of pseudonymous attribution. This version makes two sets of changes. It states retention rules for the records that SynC Standards moderation produces, which no previous version of this Policy described, and it states what happens to a project you delete, which no previous version described either. It does not add, remove, or change any processor, and it does not change what is shared with any third party.

Moderation records (Sections 3, 4.4, 5.1, 5.2, 8.1 and 12.3). v1.11 contained no rule for any record that moderation of the SynC Standards library produces, and three of those records are deliberately designed never to be deleted or pseudonymized. Stating them is the sharper of the two changes.

• New Section 5.1 category — Standards Contributors and Moderation Records. Six parts. The public moderation log is described as what it is: a register of every moderation action — what was done, when, under which reason category and level, and what it reached — that names no moderator, reporter, author or project, carries no internal note, records an erratum as issued by SynC or by a community administrator without naming the administrator, and whose entries are not deleted and survive the content and the accounts they concern. Because an entry holds no identifier, it is not ordinarily a record about anyone. The record that we gave you notice of a hold is disclosed as a record kept separately from your account, not pseudonymized on account deletion and not deleted with the account, retained for six years from the notice on the basis of the establishment, exercise or defense of legal claims — with the statement that no process deletes it automatically at the end of that period and that this Policy does not describe one. Other moderation notices — of a revision of yours being hidden or restored, of your display name being reset, of a standard's title being reset, and of a standard being removed from public view or restored — are disclosed as mandatory, sent in the Services and by email, not subject to notification preferences, and kept with your account. The non-public copy of withheld material that Terms of Service §5A.6.3 reserves is described: access-restricted, never published, not returned to the project that held the material, and retained on a condition — for as long as a claim arising from the action could reasonably be brought — rather than for a period this Policy would have to invent. A counter-notification you send under Terms of Service §5B.4 is disclosed as recorded by its dates and filing reference, forwarded to the party who sent the original notice as the statute requires, and otherwise never published. And material under a hold is stated not to have left the public corpus, so the linking record described under Contributor Attribution Records continues to be retained and the six-year tail in that rule does not start.
• Section 4.4 extended. Three paragraphs are appended. The first discloses that you may elect to have your public-facing attribution shown under a stable pseudonym — for one contribution, for all of your contributions to one standard including future ones, or for all of your contributions — at any time and reversibly (CLA §2A.5); that each election and change is recorded privately as a record of your account and is never published; what the election replaces and what it preserves; and that it does not affect the non-public linking record or the anonymization applied on account deletion. The second states one consequence plainly: a public notice of withheld material names the adopted revision the material first appeared in, that revision has a public byline, and a reader can reach that byline in one step — together with why the originating revision is named, and that the election is what answers it and will never be asked of you. The third states where the moderation record can be found and which of its pages ask search engines not to index them.
• Section 5.1's Contributor Attribution Records rule conformed. The rule defined when a contribution leaves the public corpus by revocation or removal of every revision containing it. Material withheld under a hold is a third state that sentence did not contemplate; it now states that such material has not left the corpus and that the linking record continues to be retained.
• Section 5.1's framing paragraph conformed. It counted two categories of records with rules of different kinds; with the categories this version adds it now says several, and explains the kind of rule each new one carries.
• Section 5.2 extended. Two bullets state how the new records behave under a deletion request: the record of notice is exempt for the six-year period stated in Section 5.1 and no longer, in the same shape as the existing distribution-records exemption and with the same limit to that record alone; and public moderation log entries are not deleted and, holding no identifier of you, cannot be located by your identity in response to a request.
• Sections 3, 8.1 and 12.3 conformed. A legitimate-interests basis is added for the public register, the record of notice and the non-public copy; Section 8.1's deletion notes gain a note for the record of notice and the public register; and Section 12.3's list of transactional email now names notices of moderation action that cannot be switched off.

Deleted projects (Sections 1.2, 3, 5.1, 5.2 and 8.1). v1.11 had retention rules for account deletion, distribution records, contributor-attribution records, derived data, conversations, telemetry, analytics, email, error monitoring, billing and legal records, and none for the thing a construction customer would most expect to find: what happens to a project they delete. The Services now state a 30-day restore period when a project is deleted, and once the product states a period the Policy has to state what that period is and what it is not.

• New Section 5.1 category — Deleted Projects. Deleting a project removes it from your firm's workspace at once and ends every recipient's access at that moment. The project is retained so that it can be restored for 30 days from the deletion, fixed at that moment and not extended by anything; restoring it returns the project and the access its recipients held. After 30 days the project can no longer be restored through the Services, and it is not erased at that point: we do not operate a process that permanently removes deleted projects, and this Policy does not describe one; what the 30 days bounds is recoverability through the Services, not the life of the data. A deletion request under Section 5.2 reaches a deleted project's content in the ordinary way and is not delayed by the restore period. Records of distribution events survive both the deletion and the restoration, and a restoration is recorded in the same way a deletion is.
• Section 5.2 extended. A bullet states that deleting a project through the Services is not a deletion request: it removes the project from your workspace, can be undone for 30 days, and is not a request to erase the project's contents. Erasure is asked for under Section 8.
• Sections 1.2, 3 and 8.1 conformed. Section 1.2's list of distribution records now names the restoration of a deleted project alongside its deletion; Section 3 adds a contract-performance basis for retaining a deleted project so that it can be restored; and Section 8.1's deletion notes gain a note that the Delete control is not a deletion request.

What this version deliberately does not say. It does not state a period after which a deleted project is erased, because no such period is kept. It does not describe an automatic deletion of the record of notice at six years, because no such process runs. It does not describe the public moderation log as permanent or as never edited, because an entry page can gain or lose a statement of SynC's own that SynC may withdraw. Each of those would be a sentence this Policy would later have to retract, and this version states the practice instead.

Notice of these changes. Declaring a category of personal information — the record that we gave you notice of a moderation hold — exempt from deletion on request and from the anonymization applied on account deletion, for a stated period, reduces the position a reader of v1.11 would have understood themselves to hold, and is a material change. So is disclosing that a project deleted through the Services is retained after the restore period ends. Notice is given under Sections 13.1–13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. The attribution election and the moderation notices add capabilities and protections and withdraw nothing. All other obligations, definitions, and user rights from v1.11 remain in effect.

13.15 Changes from Version 1.12

Version 1.13 carries v1.12 forward in full. It does two things. It describes sign-in with Microsoft or Google, so that what we receive from a provider, what we do with it, what we do not receive, and how you disconnect are stated before the Services offer it. And it discloses three sign-in security records the Services keep, and one outbound check they make, that no previous version described. It does not add, remove or change any processor, and it does not change what is shared with any third party.

Sign-in with Microsoft or Google (Sections 1.1, 1.3, 2.1, 3, 4.1, 5.1, 5.2, 8.1, 11 and 15.3). v1.12 named authentication providers in two places and said nothing about them in either: Section 1.3 listed them as a source, and Section 4.1 listed them among our service providers. This version replaces both. Section 1.3 now states what we ask a provider for (the standard sign-in scopes and nothing more), what we receive (your name, your email address, whether the provider verified it, and the provider's stable identifier for your account, which for Microsoft includes the identifier of the directory the account belongs to), what we do not receive (your password there, any second factor, your contacts, files, mail or calendar, and no ongoing access), and what we use it for (to sign you in, to create or link your account, and to recognize you next time). It states that we do not use that information for advertising, profiling or model training and do not sell or share it, and it carries the statement Google requires of applications that receive Google user data. Section 4.1 no longer lists authentication providers as our processors, because they are not: a provider you sign in with acts for you, or for your organization, and learns from us only that you asked to sign in. The subprocessor list is unchanged for the same reason. Section 5.1 states that a linked identity is kept while the link exists and is deleted at once when you remove it; Section 8.1 describes the Sign-in methods page, the rule that the last way into an account cannot be removed until a password is set, and what removing a method does not do at the provider; Section 11 describes the provider's sign-in page as a third-party page you are sent to; Section 15.3 adds the provider's identifier to the identifiers we collect and states that the provider is a source, not a recipient. Section 1.1 notes that an account created this way may have no password of its own. Where the Services do not yet show the sign-in controls, nothing in these Sections applies to you until you use them; they are published first so that the disclosure precedes the practice.

Sign-in security records (Sections 1.2, 2.6, 3, 5.1 and 6.1). The Services throttle failed password sign-ins per email address, verify an address by a 6-digit code as well as a link, and keep an audit record of provider sign-ins and of the linking and unlinking of a method. Section 1.2 discloses each record and what it holds: the throttle record holds a hash of the typed address rather than the address, a count and a hold time, and is cleared when you sign in or reset your password; the code is stored as a keyed hash, never as the code; the audit record names the provider and not its identifier for you. Section 5.1 states each record's life: failures forgotten after 24 hours and the record deleted after seven days untouched; the code dead when used, after about ten minutes, after five attempts, or when a newer email replaces it. Section 6.1 describes the mechanisms.

The breached-password check (Sections 2.6, 3, 4.1, 6.1, 7.1 and 15.3). When you set a password, and when you sign in with one, our server sends the first five characters of a one-way hash of it to a public breached-password lookup service and compares the answer on our server. This version discloses that check and states its limits plainly: the password and the full hash never leave our servers; the five characters go with nothing that identifies you; the prefix matches many hundreds of unrelated hashes and is not personal information; the lookup service is therefore not a processor of your personal information and is not on the processor list; the check is skipped if the service does not answer; and the check creates no record about you. A breached password is refused when set, and a sign-in with one starts no session and sends you to set a new one.

Terminology. This Policy now says "company" where it said "firm", in Sections 1.1, 4.1, 5.1, 5.2, 7.1, 11 and 15.3. The word is changed and nothing else: it still means the organization on whose behalf you use the Services, and no disclosure, retention rule or right changes with it.

What this version deliberately does not say. It does not describe what Microsoft or Google keep about your sign-in, because that is theirs to describe and their privacy policies do. It does not promise that removing a sign-in method removes SynC from the provider's own records, because it does not. It does not name the breached-password lookup service, because the check sends it nothing that identifies you and the Policy describes it by what it does.

Notice of these changes. Collecting a new category of personal information, the identifier a sign-in provider assigns to your account, from a new source, is a material change, and notice is given under Sections 13.1–13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. The disclosure applies in practice only to people who choose to sign in with a provider; the notice is given to all registered users regardless. All other obligations, definitions, and user rights from v1.12 remain in effect.

13.16 Changes from Version 1.13

Version 1.14 carries v1.13 forward in full and publishes on the same day. It accompanies Terms of Service v1.12, which states SynC's repeat-infringer policy as it operates, states that the author of SynC Standards material identified in a copyright notice receives a copy of the notice by email, states what applies when you sign in with a Microsoft or Google account, and corrects the description of how a request reaches an inference provider. This version makes six sets of changes. It discloses the short statement about you that each request to the AI assistant now carries, together with one thing that was already happening and that no previous version said. It states retention rules for records that moderation of the SynC Standards library produces and that v1.13 did not describe: the record of a copyright notice we receive, the record of a suspension of wiki contribution privileges, and the record of a decision to terminate an account under the repeat-infringer policy. It discloses what we do with the information in a copyright notice, including that a copy goes by email to the author of the material it identified. It discloses a new processor, for booking a call with us, ahead of our website offering it. It corrects the description of the path a request takes to an inference provider, and states how our subprocessor list now names providers. And it states where the Services are offered and where personal information is processed, and withdraws a promise about transfer safeguards that v1.13 made and this version does not. Apart from the scheduling processor, it does not add, remove or change any processor.

The statement about you (Sections 1.1, 2.2, 3, 4.1A, 5.1, 8.1 and 15.3). Each request to the inference provider now carries a short statement about the person the assistant is working for, so that its answers can be pitched to them and so that it does not propose actions they cannot take. This version discloses that statement in full: what is in it, what is deliberately left out of it, which part of it you can switch off and how, that it is stored with the conversation, and what the provider states about keeping it. The part you can switch off includes the name of your company and, for the project you are working in, how that project records your company among its participants (for example as the Development Owner or the Engineer of Record), as the project records it and marked where your company has not confirmed it; a role your company has declined is not sent, and nothing is sent where the project does not name your company. The names of the other companies on a project are not sent. It also discloses one thing that was already happening and that no previous version said: every request has carried our internal identifiers for your account and your company, which the assistant uses to address its requests to our own systems.

This is not profiling, and we say so because a reader may reasonably ask. The facts sent are ones you declared, from fixed lists, and they are used as declared. Nothing is evaluated, inferred or predicted about you from them, and the lines describing what your role lets you do are derived from your permissions, not from any assessment of you. No decision about you is taken on the basis of the statement, by the assistant or by us; an answer pitched to a specifier is information you may act on or ignore. Section 15.4's statement that we do not engage in automated decision-making with legal or similarly significant effects remains true.

• Section 1.1 extended. The statement about you is added to the list of what a stored conversation contains.
• Section 2.2 extended. Two purposes are added: telling the assistant what your role lets you do, and pitching its answers to who you are.
• Section 3 extended. A contract-performance basis is added for the identifiers and the rights lines, which are what keep the assistant within your permissions. A legitimate-interests basis is added for the tailoring, with the switch named in the same sentence as the way to object.
• Section 4.1A extended. States that requests carry our internal identifiers for your account and company; describes the statement about you in two parts, what you may do, sent always, and who you are, which you can switch off; lists what is not sent; states that the statement is fixed when a conversation starts, is capped, is not an instruction to the assistant, and is not sent with title generation; and states that the constraints in that Section apply to the whole request. "What a request carries" is reworded so that it no longer implies the provider is told nothing about you but your prompt and your documents.
• Section 4.1A's controls are restated for both ways a request reaches a provider, directly on our own account or through a routing service, and Section 2.2 no longer says that we contract with no inference provider directly, which has not been so since requests from the AI assistant began going to the serving provider directly. This corrects a description and changes no commitment.
• Section 5.1 extended. The statement is added to the "AI Assistant Conversations" rule, deleted with the conversation. A new "Requests at the Inference Provider" block states, as a maximum across the providers on our subprocessor list, how long a provider may keep a request in the ordinary course, the circumstances in which one may keep it longer, and that each provider's own statement is linked from the list.
• Section 7 restated. See "Where the Services are offered" below; the transfer-safeguard sentence an earlier draft of this version would have added to Section 7.2 is not made.
• Section 8.1 extended. A block states the view, the switch, what the switch does not stop and why, the one-conversation lag, and that the switch is the way to object under Section 8.2.
• Section 15.3 updated. Identifiers and professional information, including your company's name and how the project records your company, are now listed as disclosed to inference providers, with the condition, and a sentence states that nothing disclosed to an inference provider is sensitive personal information under the CPRA.

Where the Services are offered (preamble, Sections 3, 7 and the closing note). v1.13 said that SynC is based in the United States and that information is transferred there if you access the Services from elsewhere, and then, in Section 7.2, promised appropriate safeguards for transfers from the EEA, the UK and Switzerland. This version states the position plainly and withdraws that promise.

• The preamble and Section 7.1 state that the Services are offered to customers in the United States and that personal information is processed and stored there. We do not direct the Services to any other country and do not block access from elsewhere; anyone may read what is shared with them or published in the SynC Standards library, and comment on and respond to it, from wherever they are. A person who uses the Services, or contacts us, from outside the United States does so on that basis. The Terms of Service v1.12 state the same posture, and require a United States entity for a paid plan (Terms of Service §2 and §10.3); nothing in this Policy turns on where you are.
• Section 7.2 is retitled "If You Are Outside the United States" and no longer promises a transfer safeguard. Former Section 7.2 said we rely on appropriate safeguards for those transfers, which may include standard contractual clauses and adequacy decisions. We do not operate a compliance programme for the data-protection law of any country other than the United States, and Section 7.2 now says so, and says that we do not represent that a safeguard of our own is in place for each provider; where a provider offers one in its own terms, the link beside that provider on the subprocessor list is where it states it. This is a material change: a reader in the EEA, the UK or Switzerland who relied on the former sentence held a position this version does not offer. It withdraws a promise; it withdraws no right. Section 7.2 also says what does not depend on where you are: every right in Section 8.1, the additional rights Section 8.2 recognizes, and a request under the law of your own country, which we will consider in good faith.
• Section 3's heading and introduction, and the closing note, are conformed. Section 3 was headed "Legal Basis for Processing (GDPR Compliance)" and addressed to users in the EEA, the UK or Switzerland; it now states the ground for each category of processing for everyone, in the terms the GDPR uses so that a reader there can see where they stand, and says that this describes our practices and does not make the Services an offer to any other country. The closing note no longer says the Policy was drafted to comply with the GDPR. No legal basis listed in Section 3 is removed or changed.
• Nothing in Section 8 is narrowed. Section 8.1 remains open to everyone, including the request to identify the actual recipients of your personal data; Sections 8.2, 8.3 and 14.3 are unchanged.

Moderation records (Sections 3, 5.1, 5.2, 8.1 and 12.3). v1.12 and v1.13 described six kinds of moderation record. Three more exist, and each is about a person.

• New Section 5.1 block: the record of a copyright notice. When our designated agent receives a copyright notice about SynC Standards material, we record its date, channel, filing reference, the type of complaining party, what it identified, the author of the revision it identified, what we acted through, and its outcome; not the complaining party's name and not the notice's text. A notice about material stored in a project is recorded in the same way against the account that stored it. The record is what the repeat-infringer policy in Terms of Service §5B.5 counts, and only a notice recorded as upheld counts. It is not published. It is retained for as long as a claim arising from the notice or the action could reasonably be brought, on the basis of the establishment, exercise or defense of legal claims, and it is kept notwithstanding a deletion request for that period.
• New Section 5.1 block: the record of a suspension. When we suspend an account's ability to contribute to the wiki under that policy, we record the suspension and, if it is lifted, who lifted it and why; the record is lifted rather than deleted. It is not published. The account is notified, and that notice cannot be switched off. Retained on the same basis and for the same condition as the notice record.
• New Section 5.1 block: the record of a termination decision. When a site administrator terminates an account under that policy, or records why an account was not terminated although a ground was met, we record the decision, the ground, the written reason, the notices relied on, and what the termination did; a reinstatement is recorded on the same record rather than by deleting it. The reason is internal. The account is notified, and that notice cannot be switched off. Retained on the same basis and for the same condition as the notice record.
• Account deletion. These three records point to our identifier for the account; after the account is deleted they identify the person only by that identifier, and they are not deleted with the account.
• Sections 3, 5.2, 8.1 and 12.3 conformed. The legitimate-interests basis for moderation records names the three new records and the policy they operate; Section 5.2 states their exemption from a deletion request, limited to those records and to the period stated; Section 8.1's deletion notes gain a corresponding note; Section 12.3's list of email that cannot be switched off names the suspension and termination notices, the counter-notification statement, and the copy of a copyright notice.

Copyright notices we receive (Sections 3, 4.9, 5.1 and 12.3). No previous version said what happens to the information a person puts in a copyright notice. New Section 4.9 states it: what a notice carries; that when we act on a notice against SynC Standards material we email the author of the identified revision a copy of it as received, with the sender's postal address, telephone number and email address removed and the sender's name or organization kept, under fixed cover text stating that it is the sender's statement and that SynC has made no finding; that the copy goes by email only and the in-app notification carries none of its text; that no copy is sent where we have no email address for the author, and that a notice about project material is not copied to anyone; why we send it, which is so that the author can decide whether to send a counter-notification, which the law requires us to forward to the sender in full; that the sender's contact details go to no user; and that the notice itself is kept as correspondence in the Designated Copyright Agent's mailbox rather than in the Services' database. Section 5.1 states that the notice is kept for as long as a claim arising from it could reasonably be brought, and that we record when a copy was sent to the author and by whom, or that none could be sent, and nothing else about it. Section 3 adds the legitimate-interests basis. Terms of Service §5B.3 and §5B.4 carry the corresponding statements to senders and to authors; this Policy discloses the practice and does not restate those Sections.

Booking a call (Sections 1.1, 2.5, 3, 4.1, 5.1, 7.1, 11 and 15.3). Where our website offers a booking page, a visitor can book a call with us on a page hosted by a scheduling processor, Cal.com. This version discloses the processor before the page is offered, so that the disclosure precedes the practice; until the page is offered, nothing is sent to it. It discloses what that page collects, which is a name, a work email address, a company name, an optional line, and a time; that the visitor enters it on the processor's page under the processor's own privacy policy; that the booking is placed in our calendar with our workspace provider and the call held on its video service; that nothing else reaches the processor and a booking is not linked to a SynC account; and that we keep bookings without a deletion period we would have to invent. The processor is named in Section 4.1 and on our subprocessor list, and its name is on the booking page itself. This is a material change: a new processor, for a new purpose, receiving the personal data of people who may have no other relationship with SynC. Notice is given under Sections 13.1–13.3.

Providers listed as candidates (Sections 2.2, 4.1, 4.1A, 5.1, 8.1 and 11). Earlier versions said that our subprocessor list published our "current" providers. For AI inference, more than one provider may serve a request, and which one serves can change from one deploy to the next. Our subprocessor list now names every provider we use or may use for each function, and says so, without stating which of them serves at a given time; a provider is named there before any content or personal data is sent to it. This version conforms the sentences that point at the list, and states in Section 8.1 that, where the GDPR applies to you, an access request may ask us to identify the actual recipients of your personal data, including which inference provider served your requests, and we will. Every processor this Policy named in v1.13 remains named in v1.14, and Microsoft and Google remain named in Section 1.3 as sign-in providers you may choose. This version and the subprocessor list also stop restating what a provider's own documents say: where a provider processes content, how long it keeps a request and whether it trains on it are stated in the provider's own terms, data processing addendum, privacy policy or data-handling page, which the list links, and Sections 2.2, 4.1, 5.1, 7.1 and 11 now point to those documents rather than summarise them, so that a reader is never left with two versions of a fact that the provider's document governs. No commitment changes with that: Terms of Service §5.3.3 and Section 4.1A still state what no provider is permitted to do, and Section 4.1 still states the United States region of each account whose region is ours to choose.

What this version deliberately does not say. It does not state the number of notices at which a suspension is applied, because that number is a setting and the Terms say only that it may be as low as one. It does not state a fixed period for the notice, suspension or termination records, because we do not keep one; it states the condition. It does not say which named provider is serving the AI assistant at any time, because that can change within the list without any change to what this Policy describes, and because Section 8.1 states how to ask. It does not describe the copy of a copyright notice as a finding, or as a request that the author do anything, because it is neither.

Notice of these changes. Disclosing a new category of personal information to an existing processor for a new purpose, declaring three categories of personal information exempt from deletion on request for a stated condition, disclosing that the name or organization of a person who sends a copyright notice is given to the author of the material it identified, adding a processor that receives the personal data of visitors who book a call, and withdrawing the transfer-safeguard promise in former Section 7.2, are material changes, and notice is given under Sections 13.1–13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. All other obligations, definitions, and user rights from v1.13 remain in effect.

13.17 Changes from Version 1.14

Version 1.15 carries v1.14 forward in full and publishes on the same day as Terms of Service v1.13, which answers the questions a company's counsel asks before signing: SynC's liability and its limits, an indemnity that runs both ways, how a company gets its content out, what SynC owes if it discontinues the Services, confidentiality of User Content and notice when a security incident exposes it, advance notice of a change, and whether a signed agreement can vary the Terms. This version makes two sets of changes of its own, three that accompany those Terms, and a third set of its own that follows an audit of the obligations this Policy takes on. The two of its own are corrections to Section 5, both of the same kind: each replaces a sentence that described something the Services do not do with a statement of what they do, and each adds facts about the practice that no previous version stated. The three that accompany the Terms narrow the aggregated statistics we share outside the Services (Section 4.5), point at the incident-notice commitment the Terms now make (Section 6.3), and give a notice period for a material change to this Policy (Section 13.2). The audit set removes four statements that described a practice we do not run or a target with no legal function, and softens three commitments to what we can keep (Sections 4.6, 5.1, 5.2, 8.4, 10.1, 10.2 and 14.4). It does not add, remove or change any processor, and it adds no recipient of your information. The one change to what is shared with a third party, in Section 4.5, narrows it.

Account deletion and the files in a company's project (Sections 5.1, 5.2 and 8.1). v1.14 said that User Content is retained for up to 30 days after account deletion to allow for data export, which a reader could take to mean that files they uploaded are deleted at about that point. That is not what happens, and it should not happen, when the content sits in a company's project. This version states the practice: content stored in a company's project, including files you uploaded to it, is that company's project record; it is not deleted when your account is deleted and remains with the company, which Terms of Service §16.2 already states. Where a file is part of a published revision, it cannot be removed or replaced, because a published revision is fixed and every copy distributed from it is checked against it. When your account is permanently deleted, the file, its description, its place in the project and the company's record of who uploaded it remain. The 30-day export period now applies, as it always did in practice, to content that belongs to your account alone.

• Section 5.1 revised. The User Content and Project Data rule states the distinction above. It also states three things no previous version said. A company's projects are not deleted by any process we run: a project with no activity for the period the company has set, 24 months unless it changes it, is archived, after the company's retention period it is flagged for administrator review, and removing it is a decision, not a process. Uploaded files are copied each night to a backup, and a file that has left the Services persists in that backup for the period the Backups block states. And the 30 days after account deletion is stated as the period, not "up to" it: content that belongs to your account alone is kept for 30 days so that it can be exported under Terms of Service §16.4, and may be deleted after that. The Account Information rule states the same 30 days as the period in which a deleted account can be restored. Both rules now say "while your account exists, including while it is suspended" in place of "the duration of your active account", because a suspension under Terms of Service §16.2 deletes nothing.
• Section 5.2 extended. A deletion-request entry states that such files are not deleted with your account, that a request to erase a file's contents should go to the company that holds the project, that a request to us reaches a file in a company's project only where that company agrees or the law requires it, and that a filename or description that identifies you can be corrected on request without altering the file or the revision.
• Section 8.1 extended. The deletion notes gain a corresponding note.

Backups (Sections 5.1 and 5.2). v1.14 said that backups may retain data for up to 90 days, in three places in Section 5.1 and once in Section 5.2. The schedule we run keeps some copies longer, and this version states it: daily, weekly and monthly database backups, with the number of copies kept on our own server, the periods for which copies are kept in our cloud storage, up to 365 days for a monthly copy, and the period for which a second weekly copy is kept in a separate cloud storage account, up to 120 days. A new Backups block in Section 5.1 states that schedule, states that a backup holds the database as it stood when it was taken and that information removed from the live Services persists in backups until the last copy holding it ages out, states that a backup is used only to restore the Services after data loss and never to recover deleted information, and states two further facts. Database backups are encrypted. And uploaded project files are backed up, which no previous version said: each night the files uploaded to projects are copied into a separate backup bucket at the same provider, with its own write credentials and a lock against early deletion; the backup mirrors what the Services hold and can be up to about a day behind; the Services remove a file only when no revision of the project uses it, and a removed file's copy is kept in the backup for the period the block states, the same as the longest-kept database copy, and then deleted; the file copies are not encrypted by us, though the storage provider encrypts every stored file, live and backup, at rest under keys it manages, and they are not copied to the second cloud storage account. Section 6.1's list of safeguards says the same in two lines, and adds that the disks of the servers the Services run on, which hold the live database, are encrypted at rest. The Account Information, User Content and AI Assistant Conversations rules in Section 5.1, and the deletion-request entry in Section 5.2, now point to that block instead of stating 90 days, and the deletion-request entry on files in a company's project points to it for how long a removed file persists. Both storage providers were already named on our subprocessor list; neither is new.

What this version deliberately does not say. It does not say that we can remove your name from a file whose contents identify you, because the contents of a file in a published revision cannot be changed; it says that the filename and description can be. It does not describe backups as permanent or as beyond reach, and it does not promise that the backup schedule will never change; it states the schedule as run and undertakes to state a new one here. It does not say that restoring a backup re-applies deletions made since the backup was taken, because no process does that; it says that a backup is not restored in order to recover deleted information. It says that database backups are encrypted, that the file copies are not encrypted by us, that our storage provider encrypts every stored file at rest under keys it manages, and that the disks of the servers the Services run on are encrypted at rest. It does not promise that a backup of a file or of the database will be complete, or that a restore from one will succeed, because a backup is a process we run and describe here, not a warranty; Terms of Service §5.6 and Section 14 state what is and is not warranted. It does not state a period after which a company's projects are deleted, because none is kept: it states the archive and review steps that run and says that removal is a decision.

Notice of these changes. Disclosing that content you stored in a company's project is not deleted with your account, that copies of your information persist in backups for up to 365 days rather than 90, and that the backup copy of an uploaded file persists for the same period after the file leaves the Services, each reduces the position a reader of v1.14 would have understood themselves to hold, and each is a material change. That uploaded files are backed up at all adds to that position and is noticed with them. Notice is given under Sections 13.1 to 13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. Section 13.2 of v1.14, under which this version is published, sets no notice period, so these changes take effect on posting, in step with Terms of Service v1.13. The thirty days Section 13.2 now gives apply to every change after this version. All other obligations, definitions, and user rights from v1.14 remain in effect.

Changes that accompany Terms of Service v1.13 (Sections 4.5, 6.3 and 13.2). Three of the questions Terms of Service v1.13 answers touch this Policy, and this version makes the corresponding changes. They publish with the changes above.

• Section 4.5 narrows the aggregated statistics we share outside the Services. Former text said we may share aggregated usage statistics with research partners, industry bodies, business partners and the public, including in industry reports and benchmarks, and said nothing about how aggregated. The Section now states three limits on any statistic shared outside the Services: it never names or identifies a customer, a project or a person; it is never derived from the content or usage of a single customer; and it is aggregated across enough customers that no customer's contribution to it can be worked out from it. A figure that would not meet that test is not shared, and a customer is not named as a source without its written agreement. The recipients are unchanged and none is added. This narrows what we may share and is not a material change; it is favourable to every customer, and it is stated here so that the limit is a commitment rather than a practice. The one aggregate statistic the Services display to other users, the citation count, is unchanged and is described in the same Section.
• Section 6.3 points at Terms of Service §5.6. Former Section 6.3 stated our breach-notice practice for personal information and nothing else. Terms of Service §5.6 now commits SynC to notify a company's administrators when a confirmed security incident has exposed the company's User Content, whether or not personal information was affected. That commitment is a term of the Terms of Service and is not restated here; Section 6.3 gains one paragraph saying so, so that a reader who comes to this Policy to ask "will I be told?" is sent to the answer. Not a material change to this Policy; the practice for personal information is as it was.
• Section 13.2 gives thirty (30) days' advance notice of a material change to this Policy, except a change the law requires and a change that only adds to your rights, which may take effect on posting. Former Section 13.2 gave notice by three means and no period. This mirrors Terms of Service §18.2 as revised in v1.13, so that the two documents give the same notice. Favourable to every reader; it adds a commitment and withdraws nothing.

Notice of these three changes. None of the three reduces a position a reader of v1.14 held; each adds to it. They are noticed with the changes above, by the same means, and take effect with them.

Statements removed or softened after an audit of this Policy's obligations (Sections 4.6, 5.1, 5.2, 8.4, 10.1, 10.2 and 14.4). Each earlier version added commitments; this one also reads back through them. A stated practice is an obligation to follow it, so a line that describes a practice we do not run, or a target we would not always meet, is a line this Policy should not carry. Seven lines are changed on that reasoning, and none of them changes what the Services do.

• One deletion clock (Sections 5.2 and 8.4). Former Section 5.2 said we delete or anonymize personal information within 30 days of a request, and former Section 8.4 said we respond within 30 days for most requests and 45 for CCPA requests. Both now say 45 days, the period the CCPA allows, with the one further 45-day extension the CCPA allows for a CCPA request, and sooner where applicable law requires it. The three deletion-exemption entries in Section 5.2 that referred to "the 30-day commitment above" refer to the 45-day commitment. This is a material change: it lengthens, by 15 days, the time within which we commit to answer a request and to delete, and a reader of v1.14 held the shorter figure. Section 14.4 now points to Section 8.4 instead of stating its own figures, so its former 30-day line for a request made under the rights in Section 8.2 is withdrawn and the 45-day period applies to every request.
• Section 14.4 no longer states a 5-business-day target for general inquiries. It was a service target with no legal function, stated as a commitment. Section 14.4 now refers to the period in Section 8.4. Withdrawing the 5-day target is not a material change: no right of yours turned on it. Withdrawing its 30-day line is part of the material change in the entry above.
• Section 10.1 no longer describes "Marketing Cookies", and Section 10.2 no longer offers industry advertising opt-out tools. Former text described cookies that track activity across websites for targeted advertising, "only used with your consent", and pointed at the Network Advertising Initiative and Digital Advertising Alliance opt-out tools. We set no such cookie and run no advertising technology, which Section 15.3 already said; the block described a practice that does not exist, and the opt-out tools reach nothing on our surfaces. Section 10.1 now says so in one line. Not a material change: nothing is collected or shared that was not before, and no control you could use is withdrawn.
• Section 5.1 no longer states that usage and analytics data is "typically retained for 24-36 months". No process of ours enforces that period; the periods that do apply are the ones the same Section states for search telemetry, for product analytics at PostHog and for web analytics at Cloudflare. The line now points at those and states no separate figure. Not a material change in substance, since the stated period was not one we ran, but it withdraws a figure a reader of v1.14 saw, and it is noticed with the rest.
• Section 4.6 states when notice of a business transfer is given. Former text said we notify you before your personal information is transferred and becomes subject to a different privacy policy. It now says before the transfer, or, where the transaction does not allow notice before it, as soon as the law and the transaction allow. This is a material change: in a transaction that closes under confidentiality, the notice may follow the transfer rather than precede it, which is less than a reader of v1.14 was told.
• Section 5.1 (Email Interaction Data) no longer promises to establish the processor's retention period. Former text said we would state the period here once we had established it. It now says that if we establish it, we will state it here. Not a material change: the period was never stated, and the statement that we cannot state one is unchanged.

Notice of these changes. The 45-day clock in Sections 5.2 and 8.4 and the business-transfer notice in Section 4.6 are material changes, and notice is given under Sections 13.1 to 13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. They take effect on posting, with the other material changes above. The remaining changes in this group are not material and are noticed together with them. All other obligations, definitions, and user rights from v1.14 remain in effect.

13.18 Changes from Version 1.15

Version 1.16 carries v1.15 forward in full. It discloses three sign-in records the Services keep, or will keep, that no previous version described: the emailed sign-in code, the facts a browser session now records about itself so that you can see where your account is signed in, and the passkey. Each is stated before the feature that keeps it is switched on, so that the disclosure precedes the practice, as v1.13 did for sign-in with Microsoft or Google. It does not add, remove or change any processor, and it does not change what is shared with any third party: none of these records leaves our servers.

Emailed sign-in codes, and the notice to the owner of an address (Sections 1.2, 1.3, 2.1, 2.6, 3, 5.1, 6.1, 8.1 and 12.3). Where the sign-in page offers it, you can ask for a 6-digit code by email instead of entering your password, and the code signs you in. It goes to your account's primary email address whichever of your addresses you typed, as a password reset does. Section 1.2 discloses the record: the code in a form that cannot be read back, never the code, with why and when it was sent, when it expires, a count of attempts against it, and when it was used or replaced; no address, network address or browser is stored on it. Section 5.1 states its life: single-use and short-lived, and the record deleted within a day of the code being sent. Section 6.1 states that codes are limited in how often they are sent and how many times one may be tried. Sections 1.3 and 8.1 now say that a code emailed to your account, as well as its password, can confirm a link to a Microsoft or Google account that is waiting on your confirmation. The same Sections disclose a change to what happens when someone tries to create an account with an address that already has one: the page answers as it would for a new signup, and we email the owner of the address a notice that an attempt was made, with a sign-in code where codes are switched on, and with nothing about who made the attempt. Our audit record notes that a code was sent and that a signup named your address, each with the network address and browser of the request that caused it. Section 2.6 adds the purposes and Section 3 the bases. Section 12.3 lists the sign-in code and the notice among the transactional email that cannot be unsubscribed from.

Where you are signed in (Sections 1.2, 2.6, 3, 5.1, 6.1 and 8.1). Each browser session on your account now records when it signed in, how, when the browser last used it, and the browser's own description of itself, and Profile → Security shows you those sessions and lets you end any of them, or all the others at once. Section 1.2 discloses what is recorded and says plainly that none of it is new information about your device, which the same Section already listed; what is new is that it is kept on the session for the session's life. Section 5.1 states that life: a session ends when you sign out, when you end it, when a credential change ends it for you, or seven days after the browser last used it, and the facts written on it go with it. Section 6.1 states that the page carries nothing that could be used to take a session over. Section 8.1 records the control.

Passkeys (Sections 1.1, 1.3, 2.1, 2.6, 3, 5.1, 5.2, 6.1, 8.1, 10.1, 12.3 and 15.3). Where the Services offer them, you can add a passkey to your account and sign in with it. Section 1.1 discloses the record: the public key and its credential identifier, a usage counter, how the passkey connects, whether it is of a kind that syncs and whether it does, the model identifier of the authenticator, a name that starts as a description of the browser that added it and that you can change, and when it was added and last used. It states what we never receive: the private key, and any fingerprint, face or device PIN, which are checked on your device and go nowhere; and it states that a passkey sign-in asks for no email address. Sections 1.3 and 8.1 say that a passkey, like a password or an emailed code, can confirm a link to a Microsoft or Google account that is waiting on your confirmation. Section 5.1 states that the record is kept while the passkey is on your account and deleted at once when you remove it, and that removing it here does not remove it from your device. Section 6.1 states that we hold only the public key and nothing that could be used to sign in as you with a passkey. Section 8.1 records the controls, including that we email you when a passkey is added and when one is removed, and that a passkey can always be removed because no account relies on one alone. Section 10.1 discloses the short-lived session cookie the sign-in page sets, holding only the one-time challenge, when passkeys are offered. Section 15.3 adds the credential identifier to the identifiers we collect and states that a passkey is not biometric information. Like the sign-in provider disclosure in v1.13, this text is published ahead of the control, and nothing in it applies to you until you add a passkey.

Housekeeping. Two changes of form. A second "Contact Information" heading, which stood between Sections 13.14 and 13.15 in v1.13, v1.14 and v1.15 with no text of its own, is removed; no sentence changes with it. And the sign-in safeguards in Section 6.1, and the sign-in records in Sections 1.2, 5.1 and 8.1, are now described by what each does for you rather than by how it is built: attempt limits, sending limits, hold lengths, hashing methods, re-entry windows and similar mechanics that v1.15 stated are no longer stated, and a number is kept only where it says how long a record is kept. This Policy discloses what we keep, why, who receives it and for how long; it is not a description of our security controls, and stating a control's workings here would make this Policy the place an attacker reads first and the document we would have to republish to change a setting. No record, purpose, retention period or right changes with this.

What this version deliberately does not say. It does not describe how our sign-in protections are built, for the reason just given. It does not say that a sign-in code is weaker than a password, because it is not: a password reset already gives full access to whoever reads the mailbox, and a code gives the same, faster, and changes nothing else. It does not tell the owner of an address who tried to sign up with it, because the notice carries nothing about the attempt but that it was made. It does not describe the browser list as a list of devices, because what a browser says about itself is what is recorded, and a browser can say what it likes. It does not say that a passkey proves who you are, because it proves that the device holding it was unlocked; it says what we receive, which is a signature.

Notice of these changes. Keeping a new category of record about you, the emailed sign-in code, the facts a session records about itself, and the passkey's public key and credential identifier, is a material change on the reasoning of v1.6 and v1.13, and two of the three apply to every account holder rather than only to people who choose a new way to sign in: a browser session records these facts whoever signs it in, and the notice that a signup named your address goes to every address that has an account. None of the three reduces a position a reader of v1.15 held. Notice is given under Sections 13.1 to 13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. This version takes effect on posting, and none of these records is kept, no notice to the owner of an address is sent, and neither sign-in codes nor passkeys are offered before it is posted. All other obligations, definitions, and user rights from v1.15 remain in effect.

13.19 Changes from Version 1.16

Version 1.17 carries v1.16 forward in full. It makes four changes. Two are about the email addresses on your account: it discloses the recovery address, which you may designate so that a password reset or a sign-in code can reach you at an address other than your primary, and it states that security notices about your account go to every verified address on it, not only the primary. The third is the step the Services now take before a sensitive change to your account: they ask you to confirm it is you, and record that you did. The fourth is in the AI assistant: when a conversation grows long, its earlier part is summarized and the summary is kept with it. It does not add, remove or change any processor. Nothing here leaves our servers except the email we send you; where you confirm by signing in to Microsoft again, the sign-in request the provider already receives whenever you sign in with it (Section 1.3); and the request that summarizes the earlier part of a long conversation, which goes to an inference provider the conversation is already transmitted to (Section 4.1A).

The recovery address (Sections 1.1, 1.2, 2.1, 5.1 and 8.1). Where the Services offer it, you can designate one verified address on your account as your recovery address, and a password reset or a sign-in code is sent to it when it is the address you type. Section 1.1 discloses the record, which is our note of which of your addresses it is. Section 1.2 corrects a sentence v1.16 carried about where a sign-in code goes: v1.16 said it goes to your primary address whichever address you typed, and it now goes to the address you typed when that address is your primary or your recovery address, and to your primary otherwise; a password reset is sent the same way. Section 2.1 adds the purpose. Section 5.1 states that the designation is kept until you change or clear it or remove the address, and is deleted with your account. Section 8.1 records the control, states that the primary cannot be the recovery address because it already receives a reset, and states what a recovery address does not do: it gives no one else access to your account, and it does not change where your notifications go. Like the passkey disclosure in v1.16, this text is published ahead of the control, and nothing in it applies to you until you designate a recovery address.

Security notices go to every verified address (Sections 2.6, 3, 8.1 and 12.3). When your password is changed, your primary address is changed, an address is added to or removed from your account, your recovery address is set, changed or cleared, or a passkey is added or removed, we email every verified address on your account rather than the primary alone, so that a change made by someone else is noticed at an address they did not touch. When an address is removed, the removed address is told as well, and an address that has not been verified is told nothing, including of its own addition. v1.16 said that we email you when a passkey is added or removed, and nothing about which address; Section 8.1 now says which, for the passkey notices and for the password, address and recovery-address notices, and Section 12.3 lists those notices among the transactional email that cannot be unsubscribed from. Section 2.6 adds the purpose and Section 3 the basis. Project and activity notifications are not affected and still go to your primary address.

Confirming it is you before a sensitive change (Sections 1.2, 1.3, 2.6, 3, 5.1, 6.1 and 8.1). Before you set or clear your recovery address, change your primary email address, remove a verified email address, add or remove a passkey, link or unlink a Microsoft or Google account, create or rotate an API key, or start deleting your account, the Services now ask you to confirm it is you on the browser session you are using, by your password, by one of your passkeys or by signing in to Microsoft again; Section 6.1 states what counts, what does not, and what an account with none of those has to offer. Section 1.2 discloses what is recorded: the session records when you last confirmed and how, for its own life, beside the facts v1.16 said it records, and our audit record notes that you confirmed, how, when, and the network address and browser of the request; a wrong password typed to confirm is counted as a failed sign-in. Section 1.3 states that a Microsoft sign-in made to confirm sends us the same information as any other, and that we read from it the time Microsoft reports for that sign-in. Sections 2.6 and 3 add the purpose and the basis, and Section 5.1 states the life of the two records. Section 8.1 drops two rules v1.16 stated, that a Microsoft or Google account could be linked after re-entering your password or shortly after signing in, and that a passkey could be added shortly after signing in; this one step replaces both. Section 6.1 also states that an API key is shown once, when it is created and when it is rotated, and is then kept only in a form that cannot be read back; v1.16 said nothing about how an API key is kept.

Summarizing a long conversation (Sections 1.1, 2.1, 2.2, 3, 4.1A, 5.1 and 8.1). When a conversation with the AI assistant grows long, the earlier part of it is condensed into a written summary by a separate request to the inference provider over that part of the stored conversation, and the summary is stored with the conversation. From then on, continuing the conversation transmits the summary, the stored record of the changes made or proposed in that earlier part, and the recent part, in place of the whole earlier conversation; v1.16 said that continuing a conversation transmits the conversation again, and Section 4.1A now states what is transmitted once a summary exists. Section 1.1 discloses the record, Sections 2.1, 2.2 and 3 add the purpose and the basis, and Section 5.1 states that the summary is deleted with its conversation. Section 8.1 states that an access request includes any summary stored with your conversations, and that a copy of a conversation is of your transcript, which is unchanged and complete, and does not include the summary, which is not shown to you. The commitment in Section 2.2 that we do not train on your content applies to the summary as it applies to the conversation it was made from.

What this version deliberately does not say. It does not describe how a recovery address is confirmed before it takes effect, or how a reset or a code sent to it is protected, for the reason v1.16 gave: this Policy states what we keep, why, who receives it and for how long, not how our sign-in protections are built. For the same reason it does not state how long a confirmation that it is you holds on a browser session, nor the length at which a conversation is summarized, nor what the summarizing request costs. It does not say that a recovery address makes your account recoverable in every case, because it does not; it is one more address a reset can reach. It does not say what our support team can and cannot do to recover an account, because that is a matter for the Terms of Service and our help pages, not for this Policy.

Notice of these changes. Keeping a record of which of your addresses is your recovery address is a new record about you, and a material change on the reasoning of v1.16, though it is kept only if you designate a recovery address and is cleared when you clear it. Sending security notices to every verified address adds to what you are told and withdraws nothing. Recording when and how you confirmed it is you adds a fact to two records this Policy already disclosed, the browser session and the audit record, and asks more of you before a sensitive change rather than less. Keeping a summary of the earlier part of a long conversation is a new record about you, and sending that part of the conversation to be summarized is a new purpose for a transmission this Policy already disclosed; it is material on the same reasoning. None of these changes reduces a position a reader of v1.16 held. Notice is given under Sections 13.1 to 13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. This version takes effect on posting; no recovery address can be designated, and no conversation is summarized, before it is posted. All other obligations, definitions, and user rights from v1.16 remain in effect.

13.20 Changes from Version 1.17

Version 1.18 carries v1.17 forward in full. It makes one set of changes, about your name on a company's records, and they replace a rule this Policy has carried in one form or another since v1.5: that when your account is deleted, your name is removed from the record of what you did. Under this version it is not. A company's record of who published, uploaded, commented, adopted or changed what in its projects and libraries shows the name you had when you made the record, and keeps showing it after your account is deleted; what deletion removes is everything else that identified you. The same version states the one way a name can be shown differently from how it was recorded, which is through an act we record and show on the record, and gives you one choice of your own about it. It does not add, remove or change any processor, and nothing in it leaves our servers.

The history of your name (Sections 1.1, 5.1 and 15.3). v1.17 listed your name among the account details we collect and said nothing about what happens to the earlier names an account has had. Section 1.1 now discloses that we keep a history of them: each name, the period it was the name on your account, and the category of evidence we then held that the account belonged to a real person, which is none, a verified email address, or a verified email address at a domain a company you held a seat or a role in had registered as its own. The category is kept and the evidence is not, no address or identifier is written to the history, and the category is not shown on any record. We do not edit the history, and deleting your account does not change it. Section 5.1 states that the history is kept for as long as any record read from it and is not deleted or anonymized with the account, and states that where two of your accounts are merged the record of the merge is kept as the statement that they were the same person, and each account's records keep that account's own name. Section 15.3 adds the earlier names to the identifiers we collect.

What a company record shows (Sections 1.2, 2.1, 3, 4.2, 4.4 and 5.1). Section 1.2 discloses that a record of an act in a company's project or library stores our identifier for your account and the time of the act and no name, and that the name it shows is looked up from the history as it stood at that time, so that a record shows the name you had when you made it and a later change of name does not alter it. It states that a revision of a company library standard now records who published it and when. It states that a notification names the person who acted as they were when the notification was sent. Section 4.2 states that a record shows your name to everyone who can see it, including recipients of a distributed revision. Section 4.4 states that it describes the public SynC Standards library only, and that a company's record of your work follows this different rule and is not pseudonymized; the treatment of wiki attribution, including "Former Contributor" on account deletion, is unchanged. Section 5.1 states the rule in the User Content and Project Data block: a company's record of who did what keeps the name you had at the time, for the life of the record, with no clock of ours applied to it, after your account is deleted, and the same rule applies to an outside participant named on a company's records. Sections 2.1 and 3 add the purpose and the bases.

Acts on a name (Sections 1.2, 2.6, 3, 5.1 and 8.1). A name is shown differently from how it was recorded only through an act we record, and Section 1.2 discloses the three. A name may be withheld, on the instruction of the company that holds the record for that company's records only, by SynC under the Terms of Service for impersonation, an abusive name, someone's safety or an identity that was not confirmed, or where the law requires it; the record then shows "Name withheld" with the reason and the date wherever it is shown, including in a notification. A name may be annotated by SynC alone, while a report that an account is not who it says it is looked into, with "(identity disputed, under review)" after it. A name may be superseded, which is your own election to show your current name on your earlier records. Each act records whose name it governs, its scope, the act, a reason from a fixed list, who instructed it, who carried it out and when; it ends only by a recorded release; it is noted in our audit record by identifiers and categories; and no act changes a record, the history, or the content check on a published revision, which the verification page states. Where a name is withheld on a project revision already sent to recipients, the withholding and any release is written as an event on that revision's distribution record, and the revision as served to a recipient says that the name was withheld after it was sent to them, with the reason and the date; Section 5.1 places those events under the fifteen-year distribution rule, and states that the event does not carry the name. Section 1.2 also says that we do not send you a notice when a name of yours is withheld or annotated. Section 8.1 records the election: one setting on your profile, "Show my current name on my earlier records", under which everyday lists show your current name and a record view shows both, as "current name (recorded as earlier name)"; it is yours alone, covers all of your records in every company, is recorded with its date, can be withdrawn at any time, stays in force if you delete your account, and yields to a withholding. Section 8.1 also states what you cannot do, which is withhold your own name, and what you can ask for instead. Sections 2.6 and 3 add the purposes and the bases.

Account deletion and deletion requests (Sections 5.1, 5.2 and 8.1). v1.17 said that your account information is deleted or anonymized after the 30-day restore period, and that a deletion request is answered within 45 days, and it carved out from that only the company's record of who uploaded a file. Section 5.2 now carves out every company record of what you did in its projects and libraries, and the name history those records are read from, on the basis of the company's record of its own work and of the legal claims of the parties who rely on a published revision, citing the same provisions the distribution-records carve-out cites, and states the limit: the exemption reaches those records and that history and nothing else. It states what you can ask for instead, which is that the company that holds a record instruct us to withhold your name, and that SynC may withhold a name under the Terms of Service and does where the law requires it; and it states that where the company has been dissolved, SynC decides such a request case by case. Section 5.1's User Content and Project Data block states that deleting your account is not a way to remove your name from these records. Section 5.1's distribution-records rule states that deleting your account does not shorten the fifteen-year period, and that the redaction at its end reaches the distribution record and not the company's project records. Section 8.1's deletion notes and its Correction entry are conformed: you can change your name in your profile, and the change applies to your account and to the records you make from then on.

Records made through an integration (Section 1.2). Where a record is made with an API key rather than from a signed-in session, the record now stores which key made it, and the name on it is shown with "via API" after it.

What this version deliberately does not say. It does not say that your name is never removed, or that a record is permanent; it says that we do not edit the history and apply no clock of our own to a company's records, and Section 5.1 states what does and does not remove a project. It does not state how a withholding is carried out inside SynC, who at SynC may carry one out, or how far a withholding reaches when it is written, for the reason v1.16 gave: this Policy states what we keep, why, who receives it and for how long. It does not describe the category of identity evidence as verification of anyone: it records what evidence we held about a mailbox or a domain, and it says nothing about whether a company is the business it names. It does not say that we tell you when your name is withheld or annotated, because we do not; the act is visible on the record. It does not promise recipients anything beyond the mark on the revision and the event on its distribution record. It does not restate the Terms of Service: what a company may do with its records, and what you agree to at sign-up, are the Terms' to state, and this Policy discloses the practice.

Notice of these changes. Keeping a history of the names your account has used, with the category of evidence held at each, is a new record about you, and material on the reasoning of v1.16 and v1.17. Declaring a company's records of your work, and the name history, retained notwithstanding a deletion request, and stating that account deletion no longer removes your name from them, reduces the position a reader of v1.17 would have understood themselves to hold under Sections 5.1 and 5.2 as v1.17 wrote them, and is a material change on the reasoning of v1.7, v1.12 and v1.15. The election to show your current name, the visible and dated mark on every withholding and annotation, the event on the distribution record, and the "via API" channel add to what you are told and withdraw nothing. Notice is given under Sections 13.1 to 13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. This version takes effect on posting; no history of names is kept, and no act on a name is recorded, before it is posted. All other obligations, definitions, and user rights from v1.17 remain in effect.

13.21 Changes from Version 1.18

Version 1.19 carries v1.18 forward in full. It discloses one use of User Content that Terms of Service v1.16 §5.3.1 permits, and it corrects two sentences in Section 8.1 that a project opt-out makes untrue. It does not add, remove or change any processor; a provider that processes content for this purpose is one already named for the Services, under the controls Section 4.1A already describes.

Using your content to improve the Services (Sections 2.2, 2.3, 3, 4.1A, 5.1 and 8.1). We may use what you upload, and what the Services produce from it, to evaluate and improve the Services: to find out why a result was wrong and put it right, to make the Services read documents and answer questions better, and to measure how well they do. Section 2.2 states the limits the Terms set, in one sentence each: your content stays confidential; it is not sold or licensed; it is not used to train, fine-tune or improve a generative, general-purpose or foundation model; and nothing built from it reproduces or discloses the substance of your content to anyone not already permitted to see it. Section 5.1 states that what we keep for this purpose is kept while it is useful for the purpose and no longer, that it is deleted on opt-out and with the content, project, account or company it came from, that it may persist in backups for the Backups periods, that it may name people who are not users, and, plainly, that an improvement already made stays made after the copies are deleted. Section 8.1 states the control: a project's administrator can opt the project out, in the project's settings or by asking us until that setting exists; a company administrator can set the default for the company's new projects; and an opt-out deletes the copies and does not undo what was already improved. Sections 2.3, 3 and 4.1A add the purpose, the basis and the provider sentence.

Section 8.1's closing note corrected. v1.18 said there was "nothing to opt out of" and that a written agreement is one "we will never require". The note now says there is nothing of the training kind to opt out of, that the Terms say we will not require a written agreement as a condition of the Services, and that using your content to improve the Services is not training and is what the project opt-out controls. Section 2.2's bullet that there was "no training use to opt out of" is replaced for the same reason.

Section 2.2 points at the users' rule. One bullet says that the Terms of Service forbid using the Services to collect other people's content, content shared with you, or information about other users to train or evaluate a model (Terms of Service §9.2A), and that your own content remains yours to export and use. This Policy does not restate the rule.

What this version deliberately does not say. It does not say that we anonymize what we use, because uploads cannot reliably be anonymized and the Terms already say that de-identified content stays confidential. It does not state a retention period, a staff access log, a per-document exclusion or a removal timer, because the Services have none of those and this Policy discloses nothing we do not do. It does not say that your content is "not shared with third parties", because our service providers are third parties and Section 4.1A states what they receive. It does not say that an opt-out undoes an improvement, because it does not. It names no technique, model type or vendor.

Notice of these changes. The project opt-out and the company default add to what you can do and withdraw nothing. This version takes effect on posting, as v1.16, v1.17 and v1.18 did, in step with Terms of Service v1.16. We post this Policy with a new Effective Date and display it in the Services for acceptance. All other obligations, definitions, and user rights from v1.18 remain in effect.

13.22 Changes from Version 1.19

Version 1.20 carries v1.19 forward in full. It makes one set of changes, about booking a call with us, and three things are new in it. The person booking may enter the email addresses of colleagues to invite to the call, and those addresses go where the booking goes. Where everyone on the call agrees at its start, we may record the call, and may later make a transcript or meeting notes from the recording. And after the call we may email the person who booked, and a colleague who attended, about it. It does not add, remove or change any processor: the scheduling processor and the workspace provider that v1.14 named receive the same booking, with the invited addresses on it; a recording is made and held by us, and no provider receives it; and the follow-up email goes through neither the scheduling processor nor the email-delivery processor.

A colleague you invite (Sections 1.1, 2.5, 3, 4.1, 5.1, 7.1, 8.1, 11 and 15.3). v1.19 listed what the booking page collects as a name, a work email address, a company name, an optional line and a time. Section 1.1 adds the email address the person booking enters for each colleague they invite, and says that a colleague learns of it from the calendar invitation. Section 4.1 adds those addresses to what the processor receives and to the booking placed in our calendar, and a new line, A colleague you invite, states what we hold about a colleague, which is the address and nothing else; that they entered nothing and have not seen the booking page; that the invitation carries a line from us saying so and where this Policy is; and that they can ask us to remove their address. Section 3 states the basis: our legitimate interest in holding the call the person who booked it arranged with the people they chose to bring, stated as our interest and not as a request of the colleague's, because the colleague made none. Section 5.1 states that an invited address is kept with the booking, in the same places and for the same time, and is removed on request. Section 7.1 adds the addresses to what the processor receives. Section 8.1 records the controls, including that declining the invitation does not remove an address and asking us does. Section 11 describes the invitation. Section 15.3 adds the invited address to the identifiers disclosed to the processor.

Following up after the call (Sections 2.5, 3, 4.1, 5.1, 8.1 and 11). v1.19 stated one purpose for a booking, which was to schedule and hold the call. Section 2.5 adds a second: after the call, we may email the person who booked, and a colleague who attended, to send what we said we would send, to answer what was asked, or to propose a next step. Section 3 places it on the same basis as the call, a step taken at the request of the person who booked before any contract. Section 5.1 states that the correspondence is held in our mailbox with no deletion period of our own, and is reached by a request under Section 8. Section 8.1 states that replying and asking us to stop is how it stops. Sections 2.5 and 11 say in terms that this is correspondence about the call and not marketing email, that booking a call is not consent to marketing email and neither is attending one, and that Section 12 governs marketing email as before; nothing in Section 12 changes.

Recording the call (Sections 1.1, 2.5, 3, 4.1, 5.1, 7.1, 8.1, 11 and 15.3). No previous version said anything about recording a call. Section 1.1 discloses what is collected where everyone on the call agrees: the recording, and any transcript or meeting notes we make from it. Section 2.5 states the purpose, our own reference and following up on that call, and states what we do not do with them: publish them, use them for marketing, use them to train, fine-tune or evaluate a model, or use them to evaluate or improve the Services under Section 2.2. Section 3 places the recording on consent, asked of everyone at the start of the call, with the statement that anyone may decline and the call goes ahead unrecorded, and that asking us to delete the recording withdraws the consent. Section 4.1's new line, Recording the call, states that we ask on the call and not on the booking page, that nothing on the booking page is consent to recording, that we make the recording ourselves on our own equipment and hold it in our own storage, that neither the scheduling processor nor the video-meeting service makes or receives it, that a service we used to make a transcript or notes from it would be named on our subprocessor list first and none is named as of the Effective Date, and that no one outside SynC sees a recording or anything made from it. Section 5.1 states that they are kept in our own storage until we delete them, with no deletion period we would have to invent, and that anyone who was on the call can have them deleted. Section 7.1 states that a recording goes to neither provider named for the call. Section 8.1 records the control. Section 11 describes the question at the start of the call. Section 15.3 adds audio and visual information to the categories collected, and states that it is disclosed to no service provider as of the Effective Date.

What this version deliberately does not say. It does not say that a colleague consented to anything by being invited, because they did not; it says who entered their address, what we hold, and how they have it removed. It does not say that we tell the person who booked when a colleague asks to be removed, because no process does that. It does not state a period after which a booking, the correspondence about it, or a recording is deleted, because we run none, as v1.14 said of bookings. It does not say that a follow-up email is transactional mail that cannot be stopped; it says the opposite. It does not make the notice on the booking page, or anything in a calendar invitation, the consent to recording: the consent is asked for on the call, of everyone on it, and a person who was invited by a colleague and never saw the booking page is asked the same question. It does not describe any use of a recording outside SynC, because there is none. It does not restate the notice on the booking page, which is on that page, or describe the processor's own confirmation email, which is the processor's.

Notice of these changes. Our website has not offered the booking page under v1.19 or any earlier version, so this version, like v1.14, describes the page before a booking is taken through it, and nothing it describes has happened to anyone under the earlier text; no call has been recorded. This version takes effect on posting, as v1.16 to v1.19 did. We post this Policy with a new Effective Date and display it in the Services for acceptance. All other obligations, definitions, and user rights from v1.19 remain in effect.

13.23 Changes from Version 1.20

Version 1.21 carries v1.20 forward in full. It makes one set of changes, about our product-analytics processor (PostHog): it states what that processor now receives and from which pages, states that session replay is switched off and what is masked if it is switched on, and replaces what earlier versions said about consent to that processor's cookies with what we do. It does not add, remove or change any processor. The processor, its location in the United States and its terms are the ones v1.3 named; the host this version names, us.i.posthog.com, is that processor's US cloud, as app.posthog.com was.

What the processor receives, and from where (Sections 1.2, 3, 4.1, 5.1 and 10). v1.3 described a handful of named events, such as a project created or a datasheet revision saved, and session replay. Section 4.1 now says what is sent. In the application: a page view on each page you open and the time you leave it; an event when you click a link or a button or submit a form, with the kind of element, its place in the page and the address a link points to, and without the text or labels of the element, so that a control labelled with a project, standard or datasheet name is recorded as used without the name, and nothing for typing, scrolling, mouse movement or the content of a document; and the named signup and datasheet events. On the public SynC Standards library and our legal pages, which no earlier version named as surfaces this processor reached: one page view per page, sent by a script of our own under a visitor identifier, with the two events the "Use in a project" control already sent. From our own server: an event when a signed-in user creates, publishes, exports or distributes a project, imports a standard, saves a datasheet revision, or starts a trial or takes or releases a seat, which v1.3's event list covered without saying that these come from our server rather than your browser. Section 4.1 also says that every address sent is first stripped of any share-link token, which the Services have done since the processor was added and which no earlier version said. Section 1.2 adds browser storage to the list of technologies we use, and Section 10.1 names the cookie, the local-storage item of the same name, and the ph_wiki_did identifier the library and legal pages keep.

Identification (Section 4.1). v1.3 said that on sign-in the per-browser identifier is joined to your user ID and email address. It is now also given your name and our identifier for your company, so that a person in the processor's records can be recognized; signing out breaks the link.

Session replay is switched off, and what is masked if it is switched on (Sections 4.1 and 5.1). v1.3 to v1.20 described session replay as running, with typed text masked by default and the ph-no-capture class used on high-sensitivity surfaces. As of the Effective Date recording is switched off in our account with the processor and no recording is made. The configuration that applies if it is switched on is stated as it is: every input and all page text are masked, so a specification, datasheet, comment or conversation, which render as text, would not appear in a recording; an element marked ph-no-capture is left out entirely, and no surface carries that class, because masking all text covers the same ground; and recording stops on a page whose address is a share link. v1.20's statement that we use ph-no-capture on high-sensitivity surfaces was not accurate and is withdrawn. Section 5.1 says that no recording is made while replay is off.

No consent banner, and a region rule in its place (Sections 3, 4.1, 8.1 and 10). v1.3 to v1.20 said the processor's cookies were "subject to your consent where required" and that you "may manage preferences"; v1.5 removed a cookie preference center that did not exist and kept, in Section 10.2, a commitment to provide a consent mechanism before such cookies are set where the law requires one. No consent was ever asked for and no preference control exists. Those statements are withdrawn and replaced with what we do. Section 3 moves the processor's cookie and browser storage off the Consent basis, which we never relied on, and states the legitimate interest it runs on. Sections 4.1 and 10.2 state the rule: in a browser whose time zone places it in the European Economic Area, the United Kingdom or Switzerland, the processor is not loaded at all, so no cookie, storage or event comes from that browser; the time zone is read in the browser and not sent; the list is wider than those places; the processor stays off if the time zone cannot be read; and the rule is a heuristic that a browser's time-zone setting, a VPN or a travelling laptop can defeat either way. The same sections say what the rule does not reach: the events our own server sends about what a signed-in user did, which go to the processor wherever the user is. Section 8.1 keeps the way to object that every version since v1.3 has offered, writing to privacy@synergyinconstruction.com, and now says plainly that the Services have no setting for it and what we do on a request.

What this version deliberately does not say. It does not say that the region rule knows where you are, because it reads a time zone. It does not say that session replay will never be switched on, because we may switch it on; it says what is masked if we do. It does not say that the events our server sends are excluded by region, because they are not. It does not say that you can switch product analytics off in the Services, because you cannot; it says how to ask us. It does not describe the web-analytics processor differently: that processor is cookieless and unchanged, and only the sentence saying that the two processors ran on different surfaces is corrected.

Notice of these changes. This version describes more collection by an existing processor than v1.20 did, on two surfaces no earlier version named for it, and withdraws statements about consent that earlier versions made and never acted on. On the reasoning of v1.14 and v1.16 it is a material change. The practices it describes were built on 2026-10-10 and are released together with this version, so that nothing is collected under the earlier text. Notice is given under Sections 13.1 to 13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. This version takes effect on posting, as v1.16 to v1.20 did. All other obligations, definitions, and user rights from v1.20 remain in effect.

13.24 Changes from Version 1.21

Version 1.22 carries v1.21 forward in full. It makes two changes to the description of our product-analytics processor (PostHog) in Section 4.1, and corrects one sentence of it. It does not add, remove or change any processor, and no new data is collected: what changes is how the processor keeps what it receives, and how accurately this Policy describes two things it already received.

A profile for each browser (Sections 4.1 and 5.1). v1.21 described the per-browser identifier under which events are sent, and said that on sign-in it is joined to your user ID, your email address, your name and our identifier for your company. It did not say how the processor holds the events sent under an identifier that has never been joined to anyone. Under v1.21 the processor kept a profile only for a browser that had signed in, or that had opened a standard in the library offering the "Use in a project" control, whose events were sent in a way that made one. As of the Effective Date the processor keeps a profile for every browser it hears from, signed in or not: the events from that browser, together under its identifier, with the properties the processor derives from them, such as the location derived from the IP address, the browser and operating system family, and the page and referring site with which the browser first arrived. Section 4.1 says so, says that nothing is collected for the profile that the same Section does not already list, and says that for a visitor who has not signed in the profile carries no name, email address or account; on sign-in the Identification entry applies as it did. Section 5.1 places the profile with the page views under the same identifier: where the identifier was never joined to an account, we cannot locate it by you; where it was, a deletion request reaches it with the rest.

Your IP address, and what the processor derives from it (Section 4.1). v1.21 said that with every event the processor derives "country-level geolocation" from your IP address. That understated it on both counts. The processor derives a location to city or region level, which Sections 1.2 and 15.3 of the same version already said of the location we collect, and it receives the IP address itself with each event your browser sends and keeps it with the event. Section 4.1 now says both, and says that the location is derived from a network address and can be wrong. This corrects a description; the practice is as it was under v1.21.

The "Use in a project" control (Section 4.1). v1.21 said that using the control is the one thing that loads the processor's own script on the library and legal pages, and that an event is sent if you use it. The script is loaded, and the event sent, when you reach the control, by pointing at it, moving keyboard focus to it or using it, and Section 4.1 now says so. As of the Effective Date the processor's script is configured on those pages to send that one event and nothing else: no page view, no clicks, no recording and no text from the page. Section 4.1 says that too.

What this version deliberately does not say. It does not say that the profile holds anything the processor did not already receive, because it does not. It does not say that the location is precise, or that it is where you are: it is derived from a network address, to city or region level, and can be wrong. It does not say that the processor discards the IP address, because we have not confirmed a setting that would make it so; it says that the processor receives and keeps it. It does not describe the web-analytics processor differently; that processor is unchanged.

Notice of these changes. This version discloses that an existing processor keeps a profile for a browser that has never signed in, which v1.21 did not say, and states that the processor receives and keeps your IP address and derives a location from it to city or region level, where v1.21 said less. On the reasoning of v1.5 the correction makes the Policy more accurate and the practice no less protective; on the reasoning of v1.14 and v1.16 the profile is a material change, and the whole is noticed as one. The profile is released together with this version, so that no profile is kept for a browser that has not signed in under the earlier text. Notice is given under Sections 13.1 to 13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. This version takes effect on posting, as v1.16 to v1.21 did. All other obligations, definitions, and user rights from v1.21 remain in effect.

13.25 Changes from Version 1.22

Version 1.23 carries v1.22 forward in full. It does two things. It describes how you can use an API key from an outside app or tool, including an AI app, so that the app reads and, where you allow it, changes what you can, and it states what such an app receives and cannot receive, who is responsible for what, and what you and your company's administrators can see and switch off. And it discloses, for the first time, the log the Services have kept of every request made with an API key, and the record kept of each key, with how long each is kept. It does not add, remove or change any processor. An app you connect is not a processor of ours, and this version says why.

Apps and tools you connect with an API key (Sections 1.2, 1.3, 2.1, 2.2, 2.6, 3, 4.1, 4.1A, 4.2, 4.8, 4.10, 5.1, 5.2, 6.1, 7.1, 8.1, 11 and 15.3). The new Section 4.10 states what a connected app receives: what you could read yourself, within the permissions you put on the key, and if the key carries permission to make changes, the changes you could make, except those no key may make. It states what no key can reach: your sign-in methods, passkeys, sessions and other keys, your company's billing, seats, membership and roles, bringing a person into a project or appointing who leads it, and anything the Services ask you to confirm it is you for; and that publishing, saving a standard revision, sharing, deleting and moderation start unticked when a key is created and are available to an app only where you tick each by name. It states that a key can never do more than you can, because every request is checked against your account as it stands at that moment. It states that the app and its maker are not our processors, act for you under their own terms, and are not on the subprocessor list, and that we control what leaves and not what happens after: not what the app's maker keeps or trains on, not whether the app asks you before a change, and not whether the app is misled by text in what it reads. It states that the commitments in Sections 2.2 and 4.1A about our own inference providers do not reach an app you connect. Section 1.3 discloses what we receive from a connected app, and that we do not see your conversation with it. Section 4.2 states that a recipient of a share link may read what it shares through an app the recipient connected, where the link allows export, and that the export setting is the one control. Sections 4.10 and 8.1 state that an administrator of your company can see which members hold a key and how it has been used, and can switch off access by API keys and connected apps for the company. Section 6.1 states that the Services assume text in content may try to instruct an app, and enforce their limits on every request regardless. Section 11 states that the app's pages and your conversation with it are the app's. Section 15.3 adds a connected app as a recipient at your direction.

API keys, and the log of their use (Sections 1.2, 2.6, 3, 5.1, 5.2 and 8.1). The Services have logged every request made with an API key since keys were introduced: which key made it, the method and address of the request, the result, the network address and software description it came from, and the time. No earlier version disclosed that log, and until this version no process deleted its rows. Section 1.2 now discloses it, Section 5.1 states that rows are deleted 90 days after the request by an automated nightly job, which runs from this version's release, Section 8.1 states that you can see the requests made with each of your keys and what your company's administrators can see, and Section 3 states the basis. Section 5.1 also states, for the first time, the life of a key's own record, including that a revoked key is kept as the record that it was revoked.

What this version deliberately does not say. It does not say what the maker of an app you connect does with what it receives, because that is theirs to say and their privacy policy does. It does not say that revoking a key removes anything the app already holds, because it does not. It does not say that the Services can tell when an app has been misled by text in a document, because they cannot; it says what the Services enforce regardless. It does not name any app or its maker: an app presents your key, and the Policy describes apps by kind. It does not describe a way of connecting an app other than a key, because none is offered; where one is, this Section applies to it in the same way.

Notice of these changes. Disclosing a new kind of recipient of your information, chosen by you, is a material change on the reasoning of v1.13 and v1.14. Disclosing a log of API requests that earlier versions did not mention adds to what you are told; it is disclosed here because the log exists, and the disclosure withdraws nothing. The sentence that our commitments about our own inference providers do not reach an app you connect states a limit that v1.22 did not state and that a reader of Section 4.1A could have read as broader than it was; we state it so that no one relies on a protection that does not exist for a flow they choose. Notice is given under Sections 13.1 to 13.3 by posting this Policy with a new Effective Date, sending email notification to registered users, and displaying a prominent notice in the Services. This version takes effect on posting, as v1.16 to v1.22 did. All other obligations, definitions, and user rights from v1.22 remain in effect.

14. Contact Information

14.1 Data Controller

Synergy In Construction, LLC, a Florida limited liability company, is the data controller responsible for your personal information.

Contact Details: Synergy In Construction, LLC A Florida limited liability company United States Email: privacy@synergyinconstruction.com

14.2 Privacy Inquiries

For questions, concerns, or requests regarding this Privacy Policy or our data practices, contact:

Privacy Team: Email: privacy@synergyinconstruction.com Subject Line: "Privacy Inquiry"

General Support: Email: support@synergyinconstruction.com

14.3 GDPR and Data-Protection Inquiries

SynC has not designated a formal Data Protection Officer, and one is not currently required for our processing activities under applicable law. For GDPR-related or other data-protection inquiries, contact our privacy team: Email: privacy@synergyinconstruction.com Subject Line: "Attention: Data Protection"

14.4 Response Time

We respond to a request to exercise a right under Section 8 within the period Section 8.4 states.

15. Additional Disclosures

15.1 California "Shine the Light" Law

California Civil Code Section 1798.83 permits California residents to request certain information about disclosure of personal information to third parties for direct marketing purposes. We do not share personal information with third parties for their direct marketing purposes.

15.2 Nevada Privacy Rights

Nevada residents may opt out of the sale of certain personal information. We do not sell personal information as defined under Nevada law. If you have questions, contact privacy@synergyinconstruction.com.

15.3 Categories of Personal Information (CCPA)

In the past 12 months, we have collected and disclosed the following categories of personal information for business purposes:

Categories Collected:

• Identifiers (name, and each earlier name your account has used, see Section 1.1; email; IP address; and, if you sign in with Microsoft or Google, that provider's identifier for your account; see Section 1.3; and, if you add a passkey, its credential identifier; see Section 1.1)
• Commercial information (for companies that buy seats or credits, or that we invoice: billing contact details, and the record of what was bought or invoiced, the subscription's status, and whether each charge was paid — see Sections 1.1 and 4.1)
• Internet activity (usage data, browsing history on our Services, search queries, session recordings)
• Geolocation data (city/region level)
• Professional information (job title, company)
• Inferences (preferences, characteristics)
• Audio and visual information (the recording of a call booked with us, and any transcript or meeting notes we make from it, where everyone on the call agreed to the recording; see Section 4.1)
• Sensitive personal information (account credentials)

Categories Disclosed for Business Purposes:

• Identifiers (to service providers for hosting, product analytics, email delivery, support, and — for companies that buy seats or credits, or that we invoice — payment processing)
• Commercial information (to our payment processor, for companies that buy seats or credits, or that we invoice: the company's name and contact details, the items and quantities bought, and the invoice content described in Section 4.1)
• Internet activity (to web-analytics, product-analytics, error-monitoring, and email-delivery providers)
• Identifiers (first name) and Professional information (professional role and discipline, the type and name of the company you are with, and how the project you are working in records that company among its participants), to inference providers, for users who have not switched off tailoring of the AI assistant's answers (Section 4.1A); and Identifiers (our internal account and company identifiers) to inference providers, for every request to the AI assistant
• Identifiers (name, work email address) and Professional information (company name), to our scheduling processor, where you book a call with us; and Identifiers (email address) of each colleague you invite to that call, to the same processor (Section 4.1)
• Identifiers (your name and email address as your account shows them), Professional information (your role and company), and the content of the records you can read, including the names of the people on them, to an app or tool you connect to your account with an API key, at your direction and within the permissions you gave the key (Section 4.10)

Payment card and bank account details appear in neither list, because we never hold them. You provide them directly to our payment processor on a page it hosts; they do not pass through the Services, and we cannot disclose what we do not receive. For the same reason, we do not collect the financial-account or payment-card information that the CPRA treats as sensitive personal information. What the processor sends back to us about a purchase may state the kind of payment method used, and never its number (Section 4.1). Commercial information is collected from, and disclosed for, companies that buy seats or credits or that we invoice; a user whose company has never bought anything and never been invoiced has none. Where you sign in with Microsoft or Google, the provider is a source of personal information, not a recipient of it: the provider learns from us only that you asked to sign in to SynC, and nothing is disclosed to it. An app or tool you connect to your account with an API key is a recipient you chose: what it receives, it receives because you gave it the key and it asked, and the disclosure is at your direction. It is not a sale or a sharing of personal information, and the app's maker is not our service provider. The five-character hash prefix sent to a breached-password lookup service (Section 4.1) identifies no one and is not personal information. A passkey is not biometric information: where you unlock one with a fingerprint or a face, that check is made on your device and its result is not sent to anyone, so we do not collect the biometric information the CPRA treats as sensitive (Section 1.1). Nothing disclosed to an inference provider is sensitive personal information as the CPRA defines it: no credentials, no financial-account or card details, no precise geolocation, and no contents of communications other than the request you make of the assistant, are sent. A recording of a call booked with us (Section 4.1) is in the first list and not the second: we make it ourselves and hold it in our own storage, and as of the Effective Date no service provider receives it; a service we used to make a transcript or notes from one would be named on our subprocessor list before we sent it anything.

Categories NOT Sold or Shared:

• We do not sell or share personal information for cross-context behavioral advertising

15.4 Data Protection Impact Assessments (DPIA)

Where required by applicable law, we will conduct a Data Protection Impact Assessment before undertaking high-risk processing activities, such as automated decision-making with legal or similarly significant effects. As of the Effective Date, we do not engage in such processing.

---

Last Updated: October 14, 2026 Version: 1.23

This Privacy Policy was drafted to comply with the privacy laws that apply to SynC as a United States business offering the Services to customers in the United States, including the CCPA/CPRA, as of the Effective Date. Where it uses the terms of the GDPR, it does so to describe our practices to a reader outside the United States, not as a statement that the Services are offered there (Section 7).

For questions or to exercise your privacy rights, please contact privacy@synergyinconstruction.com.