Website information handling

Privacy notice

This notice explains the information paths presented by this website, the safeguards a configured enquiry service should apply and the choices available to a visitor.

The website presents company, service, research and contact information. Most pages can be read without providing identity details. Information is entered only when a visitor chooses to use an enquiry field or a direct phone, email or messaging link.

The current form implementation validates an enquiry locally and exposes a submission adapter. Unless a real provider is configured, the interface states that the enquiry was not transmitted. A production provider must be assessed, documented and connected before the website represents any web enquiry as delivered.

Information a visitor may provide

An enquiry can contain a name, work email, telephone number, organisation, area of interest and a description of the requested work. The message should contain only the context required for an initial engineering conversation. Credentials, private keys, account passwords, full production datasets and sensitive personal records do not belong in the form.

Selecting a telephone, email or WhatsApp link leaves the website and uses the service chosen by the visitor. That service may process identifiers, message content, device information and delivery metadata under its own terms and privacy practices.

Contact identity and reply channel supplied by the visitor.
Organisation and service context needed to route the conversation.
Message content the visitor deliberately enters.
Anti-spam fields and form timing signals used to reject obvious automated submissions.

Why the information is requested

Contact information is requested so an authorised company representative can understand and respond to a business enquiry if a transmission provider is configured. The service-interest and message fields help distinguish an engineering conversation from unrelated or automated traffic. This purpose does not require the website to request banking credentials, national identifiers or operational secrets.

A later project, recruitment process or commercial engagement may need a separate information notice and a narrower collection process. An initial website enquiry should not be treated as permission to reuse contact information for unrelated profiling or to import confidential source data into a delivery environment.

Validation, spam control and security

Required-field, format and length checks run before the submission adapter is called. A hidden honeypot field and minimum completion interval provide proportionate resistance to simple automated traffic. These checks reduce noise; they are not a substitute for rate limiting, request-size limits, abuse monitoring and server-side validation at the eventual endpoint.

A configured provider should protect information in transit, restrict operational access, avoid copying message content into broad application logs and record failures without exposing the submitted text. The same validation contract used by the browser is reusable at the server boundary, where it must run again because browser checks can be bypassed.

Service providers, location and transfer

No provider is named here because the repository does not establish one. Before a provider is connected, the company should confirm the provider identity, hosting locations, subprocessors, access model, incident process and deletion behaviour. Those details should then be added to this notice and to the implementation record.

Project data-residency decisions are made separately from this public contact surface. A future form provider should not be presented as satisfying a client project residency requirement merely because the main delivery architecture can be configured for a particular region.

Retention and visitor choices

The repository does not establish a production retention schedule for transmitted enquiries. Before launch of a live endpoint, the company should approve a period for unanswered enquiries, active commercial conversations, security logs and suppression records, together with the event that starts each period and the person responsible for deletion.

A visitor may choose not to use the form and can use the published direct contact details instead. Questions about access, correction, deletion, restriction or another privacy concern can be directed to the general company email. A request may require enough information to locate the relevant correspondence and to avoid disclosing it to the wrong person.

Cookies and browser storage

The enquiry form does not require advertising cookies or a cross-site tracking identifier. If analytics, embedded media, preference storage or another optional browser technology is added later, its purpose, duration and choice mechanism should be documented before activation.

Ordinary delivery infrastructure may generate technical request records needed to serve and protect the site. The production owner should keep those records proportionate, prevent sensitive form bodies from entering access logs and publish material changes to the information path.

Privacy questions

Send a concise description of the request to info@wavelinkextractionsltd.com, or write to the Kampala office listed on the contact page. Do not send identity documents until the company confirms a suitable channel and explains why they are needed.

Open contact page