Privacy notice drafting page—not an operative notice.

Implementation inventory · Verify before use

Current website signals to reconcile with the final notice.

The present codebase uses the following browser and server storage. This is a technical inventory for legal review, not a settled statement of purpose or legal basis:

• local storage and a first-party preference cookie for the visitor’s necessary-only or analytics choice; the cookie has a 180-day maximum age, while the local-storage preference currently has no automatic expiry and can recreate that cookie on a later visit;
• only after analytics is allowed, HTTP-only cookies for an anonymous cohort identifier and locked experiment controls, configured with a 180-day maximum age;
• session storage for an anonymous session identifier, categorical landing attribution and a limited client-side event buffer, discarded when the browser tab closes and cleared when a visitor selects necessary only;
• first-party dispatch of categorical events to /api/events, which runs without cookies for visitors who have not answered the banner and stops entirely for visitors who select necessary only;
• Google Analytics only after explicit analytics permission, when a measurement ID is configured; Google may then set _ga-family cookies, whose final configuration and retention must be included in the operative notice;
• an optional authenticated HTTPS analytics receiver, when both endpoint and signing-secret variables are configured; it receives only validated event envelopes after analytics permission and never receives exempt pre-choice events; and
• the design-partner waitlist, which collects the contact and categorical qualification fields shown on the form and stores an accepted submission in a separate first-party lead table only when intake and durable database storage have been explicitly enabled.

The waitlist does not persist an IP address. It uses server validation, an origin check, a honeypot, rate limiting and duplicate suppression. An optional notification webhook may run after the durable record is written, but it cannot replace first-party storage.

The current analytics schema rejects common personal fields and does not receive names, email addresses, company details, website values or the optional difficult-request narrative. That technical control is not a legal conclusion that no personal data is processed elsewhere.

Direct response and marketing are separate

The required contact permission covers assessing and responding to the next step selected in the enquiry. It is not a general marketing permission. A separate marketing choice is required only when someone asks for design-partner updates, and it defaults to off.

Proposed lead-retention boundary

For launch, an unprogressed waitlist or direct-enquiry record should be reviewed and deleted no later than 12 months after receipt. If a relevant conversation or commercial relationship starts, only the information needed for that relationship should move into the applicable approved record and retention schedule.

Current implementation gap: the database does not yet enforce that deletion automatically. The operator must approve this period, document exceptions, assign an owner and implement a deletion procedure before public intake is enabled. Analytics retention also requires a separately approved period.

No live request data through the public site

Visitors must not submit identity documents, data exports, credentials, live data-subject requests or other sensitive case material through a public website form. Any future live work needs a separately approved secure transfer route and contractual scope.