01
Document status
Read this as an honest placeholder, not a formal notice
A legal notice normally identifies the operator, an official place of business, public filing details, responsible representatives, and rules that vary by location. The repository does not establish that complete set. Publishing plausible-looking details would create false certainty, so this route records the gap plainly. A reviewed notice must replace this text before DewEngine presents itself as a paid production service. Until then, nothing here should be relied on to identify a contracting party or satisfy a mandatory disclosure requirement.
02
Operator identity
Do not infer an entity from a product name
DewEngine is the name used for the unified communication infrastructure project described in this repository. That name alone does not prove who legally operates a future service, where that operator is established, or which public record applies. This page intentionally supplies no registration identifier, physical office location, tax identifier, or governing territory. Those facts need documentary verification and appropriate review before publication, rather than being inferred from a domain, email address, source repository, or contributor identity.
03
Project boundary
Development evidence is narrower than a public service
The current repository contains a public website, a developer-console preview, a Quarkus control plane, a connector worker, a source TypeScript SDK, and local container packaging. Its implemented provider slice is development software backed by tests and a fake-provider path. That evidence does not establish a hosted customer service, production account access, provider approval, billing, support commitments, or operational guarantees. The legal notice therefore cannot borrow language that would be appropriate only after those commercial and operational facts exist.
04
Names and references
Third-party references describe integration context
Product and provider names may appear in technical explanations because the project studies communication, mail, calendar, and social integration boundaries. A reference does not by itself claim sponsorship, endorsement, partnership, trademark ownership, or authorization to release a connector. Any future legal notice should separate DewEngine's own materials from third-party names and should link to the applicable attribution or brand information where necessary. Capability pages must continue to show their actual release or decision-gate state beside those references.
05
Responsibility limits
No warranty or liability text has been finalized
Formal notice pages often contain warranty exclusions, liability limits, copyright statements, and rules for external links. Those clauses can have legal consequences and cannot be drafted responsibly without knowing the operator, intended users, service scope, and applicable law. This placeholder does not attempt to create such clauses. Repository documentation may explain engineering limitations, but a technical limitation is not automatically a legal disclaimer, and a roadmap warning is not a negotiated allocation of risk.
06
Questions
Use the published email for factual clarification
The contact route presently evidenced by the site is roki@dewx.com. It may be used to ask what the project is or to flag a factual problem in public content. The address is not presented here as a statutory service address, a guaranteed support desk, or an emergency security channel. Do not send credentials, access tokens, message contents, or other secrets. A future operator must publish purpose-specific contact paths and explain which communications have formal effect.
07
Publication gate
Replace the placeholder only after the facts are verified
Before this route becomes a formal legal notice, the operating identity, authorized representative, mandatory identifiers, official contact route, intellectual-property statements, relevant regulator details, and location-dependent disclosures must be confirmed. Qualified counsel should review the result for every territory where the service will actually be offered. The published version should carry an effective date and change history. Passing a website build or adding billing code would not clear this gate on its own.