Common Intelligence

Legal01 / 03

An account of the information this website receives, why it is used and the choices available to visitors.

Effective date
3 September 2026

01Scope

This policy describes the Common Intelligence public website. It does not describe information handled inside a client engagement, which is governed by the relevant contract and data-processing terms.

02Information received

The site can receive ordinary technical request information from the browser and hosting infrastructure. If you use an external booking link, that service receives the information you choose to provide under its own privacy terms.

  • Technical request information such as IP address, browser type and requested page
  • A cookie-consent choice stored locally in your browser
  • Booking information entered directly into the external scheduling service

03How information is used

Technical information may be used to deliver and secure the site, diagnose failures and understand aggregate service performance. Booking information is used to respond to the requested conversation.

04Storage and consent

The current site stores the value common-intelligence-consent-v1 in localStorage when you choose Essential only or Accept all. This preference lets the interface remember your choice. This policy will be updated before any optional analytics or advertising technology is enabled.

05Rights and contact

Depending on where you live, you may have rights to request access, correction, deletion, restriction or information about how personal data is used. Requests can be made using the contact route provided on this website.

Frequently asked

  • Our work starts from the people already responsible for the operation. The aim is to remove repetitive search, comparison and drafting, while making their judgment easier to apply and keeping accountable decisions with named human owners.

  • They help map the real process, choose the difficult cases, test early versions and define where review or refusal is required. An internal group learns to operate and improve the system before handover.

  • One senior sponsor, access to the people and systems involved, and agreement on the business measure before building begins. Leadership also protects time for operators to participate, because their knowledge is part of the system.

  • It should be frequent, expensive, evidence-heavy and close to a measure the company already trusts. The two-week diagnostic compares candidate workflows and tests the strongest one on real company data.

  • That is why it is tested on real exceptions before production. Corrections become part of the evaluation set, and the system is designed to ask for review when evidence is weak rather than appearing certain.

  • We build in the client environment wherever possible, use the minimum permissions each action needs, and make activity auditable. Data boundaries, retention, human review and prohibited actions are agreed before a production release.

  • The engagement is designed to reduce that dependency. The client receives the source, prompts, evaluation cases, runbooks and controls, and proves the handover by running the next cycle with its own team.

  • We establish the current cost and operating baseline together, then review the same measure after each release. If the workflow does not produce a credible financial or operating improvement, we do not expand it.