TEST YOUR IDEA ON A SMALL SCALE
Have an idea? Try it, see what actually works and improve it.
Labs give you a practical space to test a question in real conditions. Run a small trial, listen to the people involved, spot problems early and move a useful idea towards production.
My place in the ecosystem
Learn by trying
Before defending an idea, run it on a small scale and see what it is really like.
Labs bring research, design, technology and field knowledge together in short trials. Choose one question, prepare a first version, gather real feedback and use what you learn to make the next decision.
The first aim is not a flawless product. It is a better understanding of the right question.
From idea to learning
Narrow the question, make a first version and try again with what you learn.
A Lab does not expect a perfect product on the first attempt. A small, affordable and reversible trial helps you learn whether the idea works in practice.
Narrow the Question
Choose one part of the larger idea that you can test in a short time.
Make a First Version
Prepare a simple prototype, piece of content, workflow or field trial and observe it in real use.
Use What You Learn
Record the feedback, improve the idea, try a different route or decide to stop at the right time.
Who will you work with?
Bring together the people who know the issue, the people who will use the result and the skills needed to make it.
A Lab team may include the person carrying the issue, a field expert, researcher, designer, technical builder and people affected by the trial. Everyone does not need the same skills; the question, the making and the feedback are carried through different roles.
A good trial helps you learn what an idea really is before asking others to believe in it.
What Labs are not
Not a maker showcase, limitless sandbox, product department, competition stage or another name for Build.
Running an experiment does not give anyone permission to test on people, children, data, income, labour or a place without consent or without a way back.
Not a maker showcaseThe focus is the question, the evidence, what failed and what happened in use—not displaying a device. Not a limitless sandboxA trial still respects clear prohibitions, serious uncertainty, people’s rights and the risk of harm. Not a product departmentA Lab learns and tests. Build turns a proven direction into something usable and maintains it over time. Not a competition stageThe value of the work lies in honest evidence, responsible use and correction—not speed, prizes or visibility. Not a place for human experimentationWork involving real people or sensitive settings requires clear consent, low risk and the right to withdraw. Not another name for BuildA Lab reduces uncertainty; Build turns tested learning into a usable result.
Types of Lab
Test a research, service, technology, learning or field idea in a small trial setting.
Different Labs use different tools. Their shared aim is to learn what works and what needs to change before making a large commitment.
Field and Community Lab
Tests observations and small interventions in neighbourhoods, families, schools, professions and organisations.
Technology and Software Lab
Tests code, data, models, agents, automation, security and local deployment in practice.
Machines and Robotics Lab
Tests assumptions about sensors, devices, mechanics, energy, physical safety, manual control and maintenance.
Media and Representation Lab
Tests truth, representation and the risk of misleading people in text, image, sound, video, games and interfaces.
Farming, Craft and Place Lab
Tests ways of working with soil, water, plants, animals, materials, buildings, food and handcraft.
Fiqh, Usul and Agreement Lab
Examines a new programme, agreement or financing model through a limited, reversible pilot with independent review.
From an issue to a trial
A Mission defines the need, a Circle develops the question and a Lab tests the idea on a small scale.
Keeping these roles distinct prevents a long discussion from being mistaken for a trial—or one successful demo from being treated as a real solution.
Missions and Circles
Prepare the need and the question
- Listen to the people living with the issue
- Compare sources and existing ways of working
- Choose one testable assumption
Labs
Run a small trial and record what you learn
- Run the smallest safe trial
- Record positive and negative results together
- Decide on another trial, a move into Build or a stop
The Lab team
A good Lab brings together people who know the idea, people who will use it and people who can make it.
The team is clear about who carries the need, who sets up the trial, who observes its use and who records the result.
Lab Lead
Keeps the question, timetable, budget, method and day-to-day trial moving.
Participant Voice
Keeps the real need, the setting of use and the rights of affected people visible.
Field Expert
Checks the method, measurement, safety and professional limits.
Rights and Agreements Adviser
Examines agreements, rights, labour, ownership, payment, liability, serious uncertainty and public benefit.
Safety and Privacy Adviser
Checks privacy, child safety, security, misuse, stopping conditions and remedy.
Learning Recorder
Keeps the assumptions, method, data, errors, decisions, versions and handover notes together.
A small and reversible trial
The first trial should not be the biggest show; it should be the lightest step that teaches you the most.
Begin with few people, little data, a short period and a clear way out. Compare the result with the current method or another solution.
Start Small
Test the main assumption with the fewest people, least data, money, equipment and time.
Compare Fairly
Compare the trial with the current method, a no-tool route or another solution.
Make It Reversible
Data should be erasable, access closable, money refundable and the system stoppable.
Pause and Decide
At agreed points the trial does not continue automatically; the team looks again and decides.
Work Carefully with Real People
Consent, the burden of participation and the right to leave must be clear, with limited impact.
Keep an Alternative Open
If the pilot fails, participants must not lose access to learning, payment, a service or a safe route.
How do you test a technology idea?
Test a model or piece of software in real conditions—not only by its accuracy score.
Look at sources, permission, errors, human intervention, provider dependence, devices and connectivity together.
Dataset
Test sources, permission, representation, exclusions, labelling, quality, deletion and access.
Model and Agent
Test errors, hallucinations, tool use, human intervention, lost context and situations where it must not be used.
Software and Automation
Examine dependencies, security, data access, logs, export, a manual route and shutdown.
Device and Sensor
Test calibration, physical harm, maintenance, energy use, network failure and emergency stopping.
Provider and Infrastructure
Assess price, APIs, data portability, shutdown risk, local deployment and mirror alternatives.
Human Judgement
Test where an automated score must give way to a person’s informed decision.
A negative result is still knowledge
When an idea does not work, you can see the mistake before it grows.
If the result is unclear, do not call it a success. Record what did not hold, what conditions were missing and why the trial stopped.
Negative Result
Write down why the assumption did not hold and what should not be repeated.
Unclear Result
If the evidence is too weak, do not claim success; decide whether to measure again or stop.
Record of Harm
Record effects on people, data, budget, equipment, time, the environment and reputation.
Correction
Correct faulty data, methods, agreements, representation or publication and inform those affected.
SIDRA
Accept that some questions should not be pursued without the necessary expertise, evidence or rights.
WAQF Memory
Keep the failure note so that another team does not have to repeat the same mistake.
When is an idea ready for Build?
A working prototype is not enough; the real need, usability and responsibility for what comes next must also be ready.
Before moving into Build, the team makes clear what has been confirmed, what risks remain and who will maintain the result.
Need and ParticipantsHave the real need, the setting of use and the measures of benefit and harm been confirmed? Technical EvidenceHas the main assumption been repeated, with limits and failure conditions recorded? Rights and AgreementsAre agreements, labour, ownership, payment, data, consent and liability clear? Safety and RemedyAre privacy, security, child safety, representation, misuse, stopping and remedy covered? Quality and CareHave usability, accessibility, support, versions, closure and handover been planned? A Responsible TeamAre the budget, roles, maintenance lead and route into real use clear?
What a Lab leaves behind
A Lab produces more than a prototype: it leaves a learning record that makes the next decision possible.
Keep the question, the trial method, the sources used, positive and negative results, open risks and the next step together.
Lab Brief
The question, Mission, assumption, method, roles, duration, risks and stopping conditions.
Assumption and Evidence Card
The expected sign, measurement, comparison, result and confidence level.
Rights and Safety Notes
Agreements, rights, labour, data, security, child safety, stopping and remedy.
Trial, PoC or Prototype Record
Set-up, materials, code, data, versions, repetitions, errors and visuals.
Negative Result and SIDRA Note
The failed assumption, what remains unknown, the route set aside and the conditions for trying again.
Build Readiness or Closure
A decision to move into Build, run another Lab, revise the Mission, share a WAQF method or stop completely.
When a real Lab period opens, its subject, team, duration and participation conditions will appear here.
Meeting format
- — Small trial workshop
- — Field observation
- — Concept or tool proof
Duration and rhythm
- — Short and reversible trials
- — Question → trial → observation → learning → next decision
- — The duration will be published for each Lab according to its subject, method and level of risk.
Who carries it?
- — Person or community living with the issue
- — Field expert or master
- — Lab lead
- — Observation and learning recorder
Current status
No open cycle · preparation continues
This page explains the programme model. Dates, capacity, team and a working application path will be published together when a real cycle opens.
Safety and responsibility
Before a trial begins, the team explains who may be affected, what consent and privacy conditions apply, what will be recorded, what could cause harm and who can stop the work.
Intended outputs
From trial to product
Move into Build when you are ready to turn a confirmed need into something people can use.
Build turns what a Lab has learned into an outcome with real users, maintenance and continuing responsibility.