Skip to content
Humaniwork

Approach

Research before deployment. Every time, without exception.

No pilot begins before the Diagnostic Sprint is complete: stakeholder map, KPI framework, data gap analysis, DPA executed. We will tell a municipality to wait. Two weeks of delay is worth six months of invalid baseline data.

The Diagnostic Sprint

Two weeks, five steps, and a document you can use either way.

The Sprint is a complete piece of work in its own right. If it concludes that a pilot should not happen yet, you still have a stakeholder map, an indicator framework, and a data gap report you can act on without us.

01

Week 1, days 1 to 3

Stakeholder map

We find out who decides, who is accountable, and who has to be convinced.

  • A working session with the department that will use the output, and a separate one with the Data Protection Officer.
  • We identify the person who signs, the person who is accountable for the outcome, and the person who can stop the project. They are usually three different people.
  • We write down what each of them needs to see before they will say yes.

What exists at the end
A one-page stakeholder map with the decision path and the objections named.

02

Week 1, days 3 to 5

KPI framework

We agree what the engagement is for, in numbers, before anything is built.

  • We define the indicators the Observatory will report, each with a definition, a source, a computation, and a confidence method.
  • The indicator definitions are versioned artefacts, not code constants. When a definition changes later, the historical series is recomputed or explicitly broken with a visible marker.
  • The framework is an instance of a method that has already been through review. Anything this engagement needs that the reviewed method does not cover carries that on its output and goes into the next review cycle.

What exists at the end
A signed indicator specification, and the version of the reviewed method it is built on.

03

Week 2, days 1 to 3

Data gap analysis

We tell you what the platform can and cannot see with the data you actually hold.

  • We inventory the available sources, their update frequency, their coverage, and their known quality problems.
  • We state plainly which of the agreed indicators are computable today, which need a new feed, and which are not computable at all.
  • This is the step where we say no. If the baseline would be invalid, two weeks of delay is worth six months of bad data.

What exists at the end
A data gap report naming every indicator that cannot be produced, and what it would take to produce it.

04

Week 2, days 3 to 5

DPA executed

The Data Processing Agreement is signed and your DPO is briefed before a record moves.

  • Your DPO receives the documentation pack: the data flow, the per-module AI Act classification and its reasoning, the sub-processor list, the retention and deletion policy, and the DPIA support material.
  • The system will not create a data source without a recorded DPA reference and a named DPO contact. This is enforced in the onboarding flow, not by policy.
  • Nothing is ingested before this step closes.

What exists at the end
An executed DPA, a briefed DPO, and a recorded classification for every module in scope.

05

End of week 2

The decision

You decide whether to run a pilot, knowing exactly what it will and will not tell you.

  • We present the framework, the gaps, and an honest projection of what the first quarter of data will and will not support.
  • If the answer is that the data is not there yet, we say so and propose what would change that.
  • The Diagnostic Sprint is a complete piece of work in its own right. It is useful whether or not it turns into a pilot.

What exists at the end
A decision, and a document you can put in front of a council, a funder, or an auditor either way.

Delivery

Five principles that decide what ships.


What a pilot commits to

Pilot deliverables, the week each is delivered, its format, and its recipient.
DeliverableDeliveredFormatWritten for
Diagnostic reportWeek 2PDF and working sessionInnovation director, DPO
Baseline reportWeek 6PDF with accessible data tablesSocial services chief, innovation director
Weekly signal reportWeekly from week 7PDF and platform viewOperational team
Monthly analytical reportMonthly from week 10PDF with sources and limitationsInnovation director, council briefing
Methodology and limitations recordWeek 12PDF, versionedDPO, academic reviewers, auditor
Impact report, ESF+ readyWeek 24PDF and structured data exportFunder, managing authority, council

Source: Humaniwork pilot engagement specification, 2026

Academic review

The method is a document before it is software.

Which is what makes it reviewable by people who did not build it, and what makes the review record an artefact you receive rather than an assurance you are given.

  1. Reviewed before it runs

    The method goes out for review before it touches anyone’s data.

    Index design, baseline construction, and simulation parameters are written as documents and reviewed by a research group that works on that subject. The method is separable from the software on purpose, so it can be evaluated by people who did not build either. An output produced by a method that has not been through this says so on its face.
  2. Re-reviewed on a cycle

    Annually, and whenever the method changes materially.

    Not per client and not per delivery. An engagement runs a version of a method that was already reviewed, and anything an engagement adds goes into the next cycle rather than holding up the work. The version that produced a given output is recorded on it.
  3. What we learn goes back

    Findings, method changes, and failures return to the research group.

    A review is worth something to a research group only if the deployment feeds it. Anonymised findings and the record of what did not work go back, for further research and for the policy questions that research exists to answer. This is the half of the arrangement that makes it a collaboration rather than a favour.

Our standards

Work we do not take.

Four standards, written down, so your procurement office can quote them back to us.

No individual-level output exists anywhere in the system. Analysis runs on neighbourhoods and cohorts, above a minimum cell size enforced at query time, and we decline enforcement, policing, and targeting integrations in writing.
The residents and workers a client is trying to support are not a dataset we resell. No client, broker, or third party buys access to them through us.
A DPA is executed and your Data Protection Officer is briefed before a single record moves. The system will not create a data source without a recorded DPA reference.
A method is written as a document, reviewed before it runs on client data, and re-reviewed on a cycle. Every output carries the review state and the version of the method that produced it, on its face rather than in a footnote, and every module carries a documented EU AI Act classification before deployment.

Start with a diagnostic.

Two weeks. You will know exactly what the platform can and cannot tell you before you commit to a pilot, and you will have a document that is useful either way.