STRIPED DONKEYWe do the heavy lifting.

Striped Donkey for teams

Connected city data.
Built around your work.

Build and test systems with connected synthetic city records. Start with a working sample, then define the identities, histories and relationships your team needs.

Try a connected example.

32 Nairobi residents. Seven joined tables. Run Python and SQL, compare expected results, and trace records to their original profiles.

Start with the job

What is your team building?

Choose a workflow to see the scope and validation questions to bring into a discussion.

Planning focus

Research & policy

Explore population-linked relationships and historical context with explicit assumptions and source evidence.

Define the scope

Review the population, geography and historical period required by your research question.

Plan the validation

Check calibration sources and model assumptions; plan validation for your intended analysis.

Build or license

Focus on what your team needs to own.

Starting from a documented release changes the preparation work. Your team still decides whether the data fits its use.

Build the environment

Own the foundation.

  • Source evidence and define models
  • Reconstruct histories and connected identities
  • Validate outputs and maintain releases

Start from FCTE

Evaluate a documented release.

  • Inspect the published city and domain coverage
  • Review source context and quality evidence
  • Validate fitness for your own use case
Read the methodology ↗

Define the engagement

Agree the delivery with the scope.

Bring the operational requirements into the same conversation as the dataset.

01

Cities & domains

Choose the records, relationships, geographic detail and period the team needs.

02

Environment & integration

Define the target environment, formats, access requirements and integration boundaries.

03

Release & refresh

Specify a purchased snapshot or recurring updates. Each refresh has its own release identity and evidence.

04

Licence & support

Agree usage rights and delivery. Select preparation, integration and support deliverables from the service catalogue.

Decision context

Match validation to the consequences.

Describe the intended use, affected users, decision consequences and empirical validation plan when requesting access.

Keep the intended use explicit.

Synthetic records support systems and scenario work. They do not describe actual individuals. Stronger consequences need stronger validation.

Review the use classes →

Start your review

See the cities. Inspect a sample.

Explore the available scope before you define the engagement.

Bring your scope.

City, domains, intended use and delivery requirements.

Bring a working result into the conversation.

01 · Evaluate

Run the connected sample.

32 residents, seven tables and exact expected outputs. Check a task in your own environment.

Inspect the working example →
02 · Review

Match the evidence to your use.

Read the original results, exclusions and unresolved gaps for your city and domain.

See measured evidence →
03 · Scope

Agree what will be delivered.

Choose the domains, then include formats, timing and acceptance checks in your quote request.

Build your package →