Privacy notice

01 — Who operates this Site

OmniLabs Systems LLC operates this Site under the OmniLabs Systems name. Where this notice says "we", it means OmniLabs Systems LLC.

Nikita L., Founder / Operator, is responsible for how this Site handles the data described below, and is the person a privacy request actually reaches.

No postal address for formal notices, and no jurisdiction of formation, is published here yet. Publishing a verified address is a condition for replacing this draft, not a detail this draft treats as settled. Until then, the channel in section 11 is the address to use.

02 — Scope

This notice applies to the OmniLabs Systems Site, accessed via the Revenue Leak Scan diagnostic front door and related public pages, and to any submission made through the Request Scan form on those pages.

While the Request Scan form is in mock mode — the default build setting — the form is not rendered on the page at all. No submission surface is presented, so there is nothing to submit and that form creates, transmits, forwards or stores no payload. A Diagnostic Review booking handoff is shown in its place. Which mode a given deployment was built with is a build-time configuration setting; this draft does not state the setting of any particular deployment.

Mock is both the configured default of this build and the setting the operator intends for the published Site and for its preview deployments. That is a statement of intent. The setting actually in force on a given deployment is confirmed at release rather than asserted on this page.

The sections below describe the contracted behaviour that would apply if the server-side endpoint were enabled. Enabling it is a separate, reviewed decision that this draft does not record as taken.

03 — Data we may collect (when a form is wired)

The Request Scan form is contracted to accept the following fields and nothing else:

• businessWebsiteUrl — the public URL to be reviewed.
• workEmail — a reply channel.
• businessType — a routing taxonomy (high-ticket / local / B2B / agency / other).
• checkFirst — an optional free-text hint indicating what the operator would like the scan to check first.
• publicOnlyConsent — an explicit acknowledgement of the public-signal scan boundary.

When the form is submitted, the page also records standard acquisition context so we can route and reply to the request:

• UTM parameters from the URL (utm_source, utm_medium, utm_campaign, utm_content, utm_term) when present.
• The landing page URL the form was submitted from.
• The referring page URL your browser reports, when it provides one.
• The browser user-agent string (server-side, alongside Cloudflare's coarse country flag).
• A server-generated request reference, the server's receipt timestamp, and the submission time reported by your browser's clock.

The canonical contract for this form lives in src/lib/request-form.ts and is the single source of truth for the submission payload. The receiving endpoint (/api/request-scan) builds the record it would forward from that contract plus the acquisition-context fields listed above — any field outside that set is discarded and never forwarded.

The publicOnlyConsent box is an acknowledgement of the scan boundary described in section 05. This draft does not treat it as a settled lawful basis for processing personal data through an activated endpoint. What that acknowledgement has to say, and what it would have to be separated from, belongs to the review that has to happen before any endpoint is switched on.

04 — Data we do not collect

The form does not request, and its field contract does not include:

• phone numbers,
• any patient, medical, clinical, or other protected health information,
• internal-system credentials (CRM, ad accounts, analytics, payment processors, etc.),
• billing or payment information,
• self-reported revenue, traffic, or conversion numbers,
• government identifiers, financial accounts, or any other sensitive personal data.

Operators should not submit any of the above through the form. If a future iteration of the form needs to collect anything beyond the contracted fields, a new privacy notice will be written and reviewed before that change ships.

05 — Public-signal scan boundary

The external Revenue Scan reviews publicly observable signals only — information that is already visible to anyone on the open web at the URL the operator submits.

Internal impact (CRM behaviour, PPC quality, call handling, customer lifecycle, booking funnel completion, follow-up timing, paid media performance, internal staff workflows) cannot be verified from public signals alone. Verifying any of those areas requires explicit access to internal CRM, booking, call, PPC, analytics, or follow-up data — which is out of scope for this prototype and not requested by this form.

06 — The browser-only scan preview

A separate page, /revenue-scan-start, offers a browser-only preview of what a scan workflow looks like. It presents an example business website, an example report email, an acknowledgement checkbox, and a hidden anti-spam field.

In the implementation this draft was written against, those values are read and checked by script running in your own browser, and the page then moves you to a fixed demonstration status screen. The values you typed are not attached to that navigation, and that page's own code issues no request carrying them. Nothing entered there starts a scan or produces a report.

That describes the code on that page as checked. It is not a blanket guarantee about every layer between your browser and the network. The page is a simulation and is not indexed; it is not a production intake channel, and it is not the Revenue Leak Scan itself.

07 — How submitted data would be used

Once a production endpoint is approved, submitted data would be used only to:

• review the public surface of the submitted website,
• reply to the submitted work email with a diagnostic conversation proposal,
• route the request by business type for internal triage.

Submitted data would not be used to send unsolicited marketing, enroll the operator in any list or sequence without explicit consent, or be sold or licensed to any third party.

08 — Storage and retention

While the Request Scan form is in mock mode it is not an active intake channel. It renders no submission surface, so there are no form submissions held and no form-submission retention period to state. Setting one is among the things that have to be decided before the server-side endpoint is ever activated, not afterwards.

If that endpoint were enabled, a submission would be forwarded to an internal intake destination on receipt rather than accumulated here, and no separate long-lived marketing database would be built from this form.

What the operator does hold today is ordinary business correspondence. As a provisional internal policy — subject to qualified legal review, and to what the underlying systems can actually do:

• Direct business email and booking correspondence is kept for up to 24 months after the last substantive interaction, unless an active engagement, a legal obligation, or a documented dispute requires longer.
• Internal prospect and diagnostic working notes are kept for up to 12 months after that prospect or diagnostic engagement closes, unless the material has been folded into an active client record.

Retention of active client contractual and accounting records is not stated here, and this draft sets no period for it. It belongs to the business, legal and accounting requirements that apply to an executed engagement rather than to a notice about public enquiries.

Removing something from the primary systems does not necessarily remove it from a provider's backup cycle in the same moment. Backups managed by a service provider age out on that provider's schedule, and this draft does not promise an item-level purge the operator has not verified is available. Nothing in this section states a statutory retention requirement; establishing what law requires is part of the review this draft is still waiting on.

09 — Third parties and the booking handoff

The site does not embed analytics, advertising pixels, chat widgets, or third-party tracking. Public pages do not automatically load fonts, scripts, images, or other assets from separate third-party domains; the web fonts are self-hosted and delivered with the site.

Linking out is a different thing from embedding, and this Site does link out. When a scheduler is configured for it, the Diagnostic Review page ends in an ordinary outbound link to an external booking provider — by default a Cal.com event, though the destination is a build-time setting. When no scheduler is configured, that page says so and offers no booking link at all. No Cal.com script or embed runs here in either case. Where the link is present, the booking happens on the provider's own site, after you have left this one, and whatever you enter there is handled by that provider under its own terms and privacy practices.

What the link carries is narrow. If the page you arrived on received ordinary campaign parameters, those same allowlisted parameters continue in the link; no cookie, account identifier, report locator, form data or contact detail is added to it by OmniLabs.

This draft does not state which region that provider's account is configured in, where bookings are stored, how long that provider keeps them, or what contractual arrangement governs them. Those are account and contract facts. They have to be verified rather than inferred, and they have not been verified for this draft.

The site is served from Cloudflare Pages. If the Request Scan form were enabled and you submitted it, the form's payload would be sent to a Cloudflare Pages Function (/api/request-scan), which validates the submission server-side and forwards a sanitized copy to an internal intake destination over HTTPS, and that destination is not named in this draft. Cloudflare receives standard request metadata (IP-derived country, user-agent string) in the process of serving the request; the payload itself is not used by Cloudflare for any other purpose.

Separately from anything this Site embeds, a hosting platform can be configured at the account level to keep traffic, performance or security telemetry. What is enabled on that account is a hosting configuration fact this draft has not verified, and it is left open here rather than answered.

Whether personal data reaches a service provider outside your own country, and under what mechanism, is likewise open in this draft rather than a settled "no". Establishing the actual account regions and the contractual arrangements that apply to the hosting platform and to the booking provider is a review step that has to happen before this notice is published. The shape of the source code cannot answer it.

10 — Privacy requests

You can ask to see, correct, or delete personal data the operator holds about you. Send the request to nick@omnilabsmarketing.com. You do not need to have been in touch with us before, and a deletion request does not depend on having received an earlier message from us.

The process the operator has adopted for handling one:

• the request is identified and logged;
• enough information is confirmed to be reasonably sure it concerns your own data — the point is to avoid disclosing or deleting the wrong person's records, so no account credential, government document or other sensitive identifier is demanded as a formality;
• the data is located in the systems actually in scope;
• the action is carried out, or the reason it cannot be is recorded;
• a short completion note is kept.

The operator's internal target is to deal with an ordinary privacy request within 30 calendar days. That is a working target set by the operator, not a statement of a statutory deadline. Whatever deadline applicable law imposes governs instead, and determining which law applies here is part of the legal review this draft is still waiting on.

Deletion is handled as described in section 08: removal from the primary systems is not the same as removal from a provider's backup cycle in the same moment.

11 — Contact and updates

The current contact channel for privacy questions about this Site is nick@omnilabsmarketing.com, read by Nikita L., Founder / Operator. It is an existing published OmniLabs Systems inbox and the address actually in use — not a separate privacy department, and this notice would rather say so plainly than imply a desk that does not exist.

Moving public business, legal and privacy contact to an address on the omnilabs.systems domain is the intended direction. No such mailbox is in service yet, so none is published here; this notice will be updated when one is.

Material changes to this notice will be recorded here with an updated "last updated" date in the page header. That date is a drafting marker rather than an effective date. This notice is a draft: it is not indexed, it has not been through qualified legal review, and it does not take effect as a published privacy policy until that review and an explicit approval record exist.