Privacy policy

Social OS ("we," "us," "the service") is a social media management platform. Your organization ("you," "your business," "the Tenant" in our systems) signs up, connects its own social accounts, and uses the service to plan, generate, review, and publish content to those accounts. This policy describes what data we collect from and about your business in the course of providing that service, how we use it, who else touches it, and how you can get it deleted.

This policy does not cover the personal social media accounts of your team members beyond what's needed to operate the service on your business's behalf, and it does not cover Meta's, Google's, or any other platform's own handling of your data once it leaves our systems under your account's authorization — their own privacy policies govern that.

We collect the data needed to run your account and produce your content, and nothing beyond that:

• Business and brand information you give us at signup and onboarding: your business name, locale, timezone, brand voice and tone preferences, goals, and the answers to our onboarding questionnaire.
• Brand assets you upload or approve for use as reference material: your logo, brand guide, product photos, and prior approved posts. Each asset is tagged with where it came from (uploaded by you, captured during onboarding, or a prior post you approved) and whether it's cleared for the system to use as a reference in new content.
• Connected account credentials, when you connect a Facebook Page, Instagram account, or other supported channel. We never see or store your password — we receive an OAuth access token from the platform, which is encrypted before it’s stored (see §4).
• Generated content — the copy, images, and video the service produces for you, every version of it, and every edit you make (see §4’s note on edit history).
• Approval and review actions — who approved, requested changes to, or rejected a piece of content, and when.
• Publishing and performance data — confirmation that a post published successfully, and the post's own engagement metrics (impressions, engagement, clicks) once it’s live, pulled back from the connected platform. [DRAFT NOTE: as of this draft (2026-08-10) nothing is actually published yet — the publish path and the metrics-pull writer have not shipped (the code that would call a platform to publish or read metrics is explicitly a stub). This describes the designed data flow, not current behavior; do not publish it as present-tense until that path is live. Same status as the Meta paragraph in §5.]

We do not collect data about your business's customers, website visitors, or anyone outside your own team and your own connected-account audience metrics.

We use this data for exactly one purpose: to run the content service you signed up for — building your strategy and calendar, generating draft content grounded in your actual brand, routing it through your review, publishing it to your own connected accounts once you approve it, and showing you how it performed. We do not use your business’s data to build advertising profiles, and we do not sell it. [DRAFT NOTE: "we do not sell your data" is a business commitment, not something enforced by a line of code.]

Every piece of generated content records which of your onboarding answers and brand facts it was based on, so we can always show you why the system produced what it produced.

Your business's data is isolated from every other business on the platform. The database enforces this at the row level — every table that holds your data is scoped to your account, and the application role the service runs under can only read or write rows that carry your account's identity. This isn't a policy we follow; it's a database-level rule that holds even if a bug in our application code tried to violate it. The one exception is a narrowly-scoped internal background role used to run the publishing and job queues — it can process queued jobs across accounts because that's how a shared worker fleet operates, but it deliberately has no access at all to your brand content, strategy, or edit history, and every job it processes is still tied to the one account it belongs to.

Connected-account tokens are never stored in readable form. When you connect a Facebook Page or Instagram account, the access token we receive is sealed with authenticated encryption (AES-256-GCM) before it touches the database, bound to your specific account so it cannot be decrypted under any other account’s context even if the encrypted value were somehow read out of place. What we store on your connected-account record is a pointer to the sealed value, never the token itself.

Your edit history is preserved, not overwritten. When you or your team edits a piece of generated content, we keep the before-and-after record — this is how the system learns your brand's voice over time and how it earns more autonomy on future content, and it is never modified or deleted except as part of a full account deletion (§6).

We use a small number of third-party services to generate and publish your content. Each receives only what it needs to do its specific job, scoped to the specific piece of content it’s working on:

• Google (Gemini API) — generates draft copy and, for image content, still images, and performs image edits when you request a revision. Google receives the prompt built from your brand voice, brand facts, and content brief, plus (for image generation and edits) your approved reference images. Google does not receive your connected-account credentials or your customers' data — it never receives anything beyond what’s needed to produce or edit that specific asset.
• Atlas Cloud — generates video content (Seedance). Atlas Cloud receives the keyframe image and prompt for the specific video being generated, and nothing beyond that. The service is designed to fall back to two other video providers if the primary path is unavailable — BytePlus (Atlas Cloud's underlying provider) and Google's Veo as a last resort. [DRAFT NOTE: the BytePlus and Veo fallback routes are specified in the render code but are not actually live — there is no working call to BytePlus today (with a BytePlus key present the code does not reach a BytePlus API; it only stubs when the key is absent). They are named here for honesty about the intended data flow, not because a video is being sent to them today. Same treatment as the Meta paragraph below: do not publish these as current behavior until the routes are live, and confirm you're comfortable naming them at all.]
• Meta (Facebook and Instagram) — publishes your approved content to your own connected Page and/or Instagram account, and provides back the engagement metrics for posts you've published. Meta only ever publishes to, or reads metrics from, the specific account you connected and authorized — never any other Page or account. [DRAFT NOTE: as of this draft (2026-08-10), the runtime code that calls Meta's publishing API has not shipped — the permission set, data flow, and scope are fully specified but not yet implemented. This section describes the shipped design once that lands. Do not publish this policy claiming a live Meta integration until the publish path is actually live.]

We do not sell your data to any of these providers or to anyone else, and none of them are authorized to use your business's data for any purpose beyond producing or publishing the specific content you requested.

While your account is active, we keep your data for as long as you're using the service, so your strategy, calendar, drafts, and history stay intact.

If you close your account, we first make an export bundle of your data available to you (your plans, generated content, edit history, and performance metrics), then your data is marked for deletion and permanently, irreversibly deleted no later than 30 days after account closure — this applies even to records we otherwise keep as a permanent history (like your edit history), because account closure overrides that. Your connected-account tokens are revoked immediately at closure, not held for the 30-day window. [DRAFT NOTE: this describes the RULED design — the automated purge job that enforces the 30-day deletion has not been built yet as of this draft. Do not publish this section until that job is built and tested, or the policy will assert something the system doesn't yet do.]

If you disconnect Meta (Facebook/Instagram) specifically, or if Meta notifies us that a user has removed the app's access, we treat that the same way as an account-closure deletion request for the data covered by that connection — export first, then the same 30-day deletion path, never an immediate irrecoverable delete on receipt of that notice. [DRAFT NOTE: same status as above — this is the ruled behavior for the Meta data-deletion callback Meta requires us to provide; the callback endpoint itself has not been built yet. This is a submission blocker for Meta App Review, tracked separately, not just a documentation gap.]

You can ask us, at any time, to:

• See what we hold about your business — we’ll provide the same export bundle described in §6.
• Delete your data — closing your account triggers the deletion process in §6; you can also request deletion directly without fully closing your account, and we’ll treat it the same way.
• Correct inaccurate data — brand facts, business information, or anything else we have wrong.

To exercise any of these, contact us using the details in §9.

If we materially change how we collect, use, or share your data, we’ll update this policy and notify active accounts before the change takes effect.

[CONTACT DETAIL NEEDED — company legal entity name, mailing address, and a support/privacy email. Not yet established as of this draft; do not publish without it.]