01
Scope first
A final notice must match the systems people actually use
Privacy text should identify its operator, covered website and product surfaces, affected people, effective date, and relationship to customer instructions. DewEngine currently includes source for a marketing site, console preview, control plane, worker, SDK, and local packaging, but repository presence does not show which components are deployed for real users. This draft therefore avoids pretending to inventory collection on a service that has not been defined or launched. Deployment evidence and data mapping must come first.
02
Data categories
Do not turn a target schema into a collection claim
Architecture documents discuss future workspaces, accounts, commands, events, webhooks, mail, calendars, messages, provider credentials, audit records, and billing references. These are design subjects, not proof that a public service receives every category. A reviewed notice must distinguish account administration, connected-provider content, technical telemetry, support communications, website activity, and commercial records based on an audited flow. It should also identify optional fields, derived data, sources, and what never enters the system.
03
Purpose and authority
Every actual use needs a stated reason
The completed notice should connect each verified data category to a specific purpose, identify the relevant legal basis where that framework applies, and distinguish DewEngine's own decisions from processing performed on customer instructions. Provider-account access also depends on user authorization, provider terms, scopes, and product policy. This placeholder selects no legal basis and makes no controller-or-processor conclusion because the operator, customer contract, release markets, and real processing activities remain unresolved.
04
Vendors and transfers
Publish a verified dependency map instead of a generic list
A production notice may need to explain hosting, identity, email delivery, support, monitoring, payment, and provider dependencies, including where information may move and what safeguards apply. The current repository does not supply an approved public vendor inventory or transfer analysis. No service provider should be named from a package dependency, development tool, architecture option, or unrelated infrastructure note. A final list must come from deployed configuration, signed arrangements, purpose review, and ongoing change control.
05
Retention and deletion
Lifecycle promises require end-to-end proof
The platform blueprint treats deletion as a workflow involving admission fences, provider revocation where supported, active secret removal, storage expiry, backup behavior, and a minimal receipt. Current V006 evidence covers only local credential retirement against a fake provider and does not prove upstream revocation, managed-key erasure, or backup expiry. A real privacy notice must publish category-specific periods or criteria that match implemented jobs and restore tests. This draft makes no immediate-deletion or universal-erasure promise.
06
Security statements
Describe implemented controls without implying certification
The development code includes tenant-scoped records, local authenticated encryption for selected secrets, credential-state tests, signed webhook work, and rules intended to keep sensitive values out of ordinary logs. Those narrow facts do not establish a production security program, managed key service, completed incident process, independent audit, or compliance award. Future privacy and security language should be generated from current control evidence and should explain material limits rather than relying on broad assurances.
07
Individual choices
Rights routes depend on identity, market, and actual records
A finalized notice should explain applicable access, correction, deletion, objection, restriction, portability, consent withdrawal, complaint, and appeal paths without suggesting that every right exists identically everywhere. It must say how identity is verified, which customer may need to handle a request, what exceptions apply, and how to contact the responsible operator. The general email currently shown on the site is not yet documented as an authenticated rights-request workflow or regulator contact.
08
Completion gate
Review the notice after the product and operations are real
Before launch, the operator should complete a data inventory across the website, console, APIs, workers, logs, support, analytics if any, backups, provider integrations, and commercial systems. The result needs qualified privacy review for intended markets, alignment with contracts and product controls, an effective date, and a change process. Cookie or tracking disclosures should follow an actual site audit and consent design, not assumptions. Until those checks pass, this page remains explanatory planning material only.