Frequently asked questions

• What qualifies as a suitable problem, and what does not?

  A suitable problem is one your organisation has scoped but does not have the internal capacity, or the mandate, to staff. It should be non-critical to ongoing operations, since it is worked by a cohort against a stated duration rather than delivered on an emergency timeline. It falls within one of the five categories the pipeline currently handles: process automation, legacy system modernisation, data strategy, AI adoption or change management.

  A problem is not a fit if a realistic outcome cannot be defined within a cohort's stated duration, or if the work cannot proceed without production system access. Scoping exists to catch this before a cohort is assigned; a problem that cannot be scoped to a safe, time-bound piece of work is not passed through.

• What is required from the organisation, in time and access?

  After you submit the intake form, a scoping call confirms the disclosure tier and the access requirement before anything is shared with a cohort. This is the main time commitment on your side before delivery begins.

  On access, the submission form asks you to select one of: no system access needed, an anonymised data sample, supervised read access to specific systems, or another arrangement described under constraints. What is agreed at scoping is fixed for that engagement rather than expanded later without a further conversation.

• How is confidentiality protected, and what is the anonymisation process?

  Every problem carries a disclosure tier, set before a cohort sees it. At the anonymised public tier, only sector, organisation size band, domain and problem class are visible; no organisation name and no detail that could identify it. Moving to the named tier, where the organisation's name and other identifying detail may be shown, requires your written approval given per instance.

  Separately from disclosure tier, what you submit is encrypted at rest and access is restricted to named individuals working on your problem, not held in a shared inbox. A retention and deletion schedule is stated on the submission form itself. See how we protect your information for the full standard.

• Who owns the intellectual property in the output?

  This is not yet settled and we are not going to state a position here that has not been confirmed. It is being resolved by counsel alongside the partner agreement template, and the resolved position will be published on the confidentiality and IP statement before it governs any engagement. Read that page before you submit a problem; it will govern what a cohort keeps and what your organisation keeps.

• Who performs the work, and what supervision applies?

  Work on your problem is performed by supervised participants, not by employed consultants. A practitioner mentor reviews the cohort's work against a stated quality gate at defined points in the engagement and is accountable for what the cohort produces before it reaches you. This is stated plainly rather than left implicit, because the distinction between supervised participant work and consultant delivery is the basis of the arrangement.

  See the mentorship model for how that review operates.

• What recourse exists if the output is not usable?

  Recourse terms are drafted as part of the partner agreement template and are set out in full in partner terms. That page currently states what the finished terms will cover rather than the terms themselves, because they have not been finalised. We would rather say that plainly than imply a position ahead of it being settled.

  In practice, the mentor's quality gate exists to catch an unusable outcome before it reaches you, which is why supervision, not a post-delivery remedy alone, is the primary control.

• What insurance and liability position applies?

  This has not been finalised. Professional liability and insurance cover for work delivered to a paying client is being settled before that engagement type is offered as a bookable, paid service. Until it is, supervised delivery of your problem to a completed outcome is not something you can book through this site.

  If that is closer to what you need, submit the problem regardless. We record the interest and will contact you directly once that path opens.

• What is published about the engagement, and who approves it?

  Two tiers apply. The anonymised public tier covers sector, organisation size band, domain and problem class, with no identifying detail, and is set automatically once you select it at submission; no separate approval step follows. The named tier adds identifying detail up to and including your organisation's name, and requires your written approval, given per instance, before anything at that tier is published.

  Full detail is on how we protect your information.

• What is the cost, and how does it compare with the alternatives being considered?

  Pricing is not yet published. It publishes alongside the confirmed pilot commercial model, the same position stated on how we are paid.

  We are not going to publish a comparison against consulting rates or other alternatives without figures to substantiate it, so none is offered here. Once pricing is confirmed, any comparison we publish will be stated against a defined basis, not a general claim.

• What is the timeline from submission to cohort deployment?

  Submission is followed by a scoping call, which settles the disclosure tier and access requirement. The problem is then matched to a cohort with mentor capacity and relevant domain experience, and matching depends on current pipeline and mentor availability rather than a fixed queue position.

  We have not published a standard number of weeks for this, because with a small number of cohorts running, a generic figure would not be reliable. If pipeline timing affects your target timeframe, that is discussed directly with you at the scoping call.

• Can the organisation recruit from the cohort, and on what terms?

  The terms for this are not yet fixed. They will be set out in partner terms once drafted, alongside the recourse and IP terms covered elsewhere on this page. If recruitment access matters to your decision to submit a problem, raise it at the scoping call so it is on record ahead of the published terms.

• Can data be kept within the organisation's own environment?

  The current model does not host or operate inside your environment. The submission form offers three access levels: no system access, an anonymised data sample supplied to the cohort, or supervised read access to specific systems, meaning participants view data within your own systems under supervision rather than a copy being taken. Production system access is not part of any of these options.

  Which of these fits your problem is confirmed at the scoping call, against what the problem actually requires rather than a default setting.

Question not covered here? Submit a problem and raise it at the scoping call, or read the fuller model on how it works.