Planned capability
Draft terms boundary

Pre-launch information, not operative terms

These are not finalized Terms of Use. DewEngine does not yet offer paid production access, and the facts needed for a binding service agreement have not been published. This route explains the intended coverage and the open decisions without asking a visitor to accept them. It is a pre-launch draft for information only. It is not legal advice and not a contract.

01
No acceptance

Visiting the site does not complete a future service agreement

Operative terms normally identify the contracting parties, eligible users, accepted service, effective date, and method of assent. Those foundations are absent here. This page therefore does not use language such as “by using the service, you agree,” and it does not create an account contract through browsing, reading documentation, cloning code, or sending an inquiry. Any later agreement needs a clear acceptance flow connected to the actual operator and the exact product access being provided.

02
Intended scope

Separate public information from customer access

A final document may need different rules for the marketing site, public technical material, a developer console, sandbox functions, hosted production access, support, and downloadable software. Treating those surfaces as one undefined service would obscure which obligations apply. The current console and SDK are development previews, and local packaging is not evidence of a managed customer environment. Future terms should describe each included surface and explicitly exclude anything that is merely planned.

03
Accounts and authority

Future users must act only for accounts they may control

Communication infrastructure can touch provider accounts, messages, mail, calendars, contacts, and social context. A later agreement should require the customer to have appropriate authority, consent, and provider entitlements for every account and action it configures. It should also explain workspace roles, credential protection, incident reporting, and what happens after connection loss. This draft states the design concern only; it does not define enforceable duties or claim that customer onboarding exists.

04
Acceptable use

Provider rules and human rights cannot be abstracted away

Any usable policy must address spam, harassment, impersonation, unlawful surveillance, deceptive automation, rights infringement, credential misuse, security testing, action pacing, and attempts to evade provider controls. It must preserve stricter provider restrictions even where a common API shape is possible. The exact prohibited-use text requires qualified review against released connectors and intended markets. A technical capability page, design-partner conversation, or local test does not authorize activity that a provider or applicable law forbids.

05
Service state

No uptime, support, or continuity promise is hidden here

The repository contains development tests and local smoke paths, but it has no published production delivery objective, customer support schedule, maintenance policy, disaster-recovery commitment, or service-credit framework. This draft makes none of those promises. Final terms must match measured operations and should distinguish provider outages, customer configuration, beta limits, scheduled maintenance, data export, cancellation, and termination. An engineering plan cannot substitute for an agreed service boundary.

06
Commercial terms

Payment and subscription rules remain undecided

There is no published paid plan, billable unit, tax treatment, invoice process, trial, renewal rule, cancellation path, refund rule, or entitlement schedule for DewEngine. A final agreement cannot sensibly describe charges before the product chooses and implements those records. Design-partner discussions are exploratory and do not create a subscription through this page. Commercial language should be versioned with the offer and acceptance record once a real plan exists.

07
Legal completion

Governing rules require an identified operator and reviewed markets

Final terms must name the operator, choose applicable governing rules and dispute handling with qualified advice, define liability and warranty language, address intellectual property, and align with privacy, deletion, subprocessor, security, and provider obligations. None of those choices should be reverse-engineered from a domain or repository location. The completed document should show an effective date, archived versions, a change-notice method, and the assent that applies to each customer.

Questions

Before you build.

Do these Terms of Use bind website visitors or customers?+

No. This is a pre-launch information draft, not an operative contract or legal advice. It does not identify a contracting party, released service, governing rules, commercial offer, or acceptance mechanism.

May I use a planned provider capability because it appears on the site?+

No availability or authorization follows from a route. Capability state, provider approval, account authority, consent, and applicable restrictions must all be satisfied through an actual released product contract before reliance is appropriate.

When will final terms be published?+

No date is promised. Reviewed terms must follow an identified operator, defined product scope, completed privacy and commercial decisions, relevant provider approvals, and an acceptance flow tied to real access.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case