Early access · now onboarding 5 design partners
A knowledge hub for decisions you can defend.
svyLab turns a survey program into a knowledge hub: methods that stand up to scrutiny, memory the
organization keeps, and every number explainable. AI drafts, rules decide, a person signs off,
and the AI can be switched off. Built on svy, the
open-source Python engine validated against R.
Nothing to install and no data to send. We walk through the pipeline on a public survey (for example DHS, MICS, LSMS, ACS or EU-SILC) or on tables from a report you've already published.
- 1 Non-response adjustment region × urban_rural
- 2 Rake to population margins age_group · sex
- 3 Trim weights > 3.5 × median
- ✓ All 6 columns resolve
- ✓ Control categories match the data · 14 of 14
- ✓ Margins imply one grand total · 12,480,300
- ! 48 adjustment cells · smallest n = 7 Acknowledge ▸
“Base weights are adjusted for non-response within region × urban/rural cells, raked to age-group × sex population margins, then trimmed at 3.5 × the median. Design: stratified two-stage; variance by Taylor linearization.”
Survey design and analysis you can trust.
Instrument, data, weights, plan, report: one chain, run the same way every wave, with the method behind every number visible to whoever asks.
See the chain, questionnaire to report →Institutional memory your organization keeps.
Every validated wave, instrument version, weighting scheme and analysis is kept, versioned and governed. Knowledge accumulates in the organization, and the next question starts from it.
See what the Library keeps →Every number you can explain.
Release rules decide what is published, flagged or withheld, and say why. A definition that moves between waves is recorded, never silent.
See the checks and rules →The problem
The number gets published. The method, the memory and the meaning don't.
Most organizations that run surveys already have the plan, the standard tables, the indicator list. What they don't have is a system that keeps the method defensible, keeps the knowledge when people move on, and keeps every published number traceable to what it means.
The method
A year later, the question comes back
Which variance estimator produced the margin of error on the headline figure, and did the calibration use the same control totals as last round? The totals were typed into a spreadsheet and the syntax has been edited since. Re-deriving the number takes a week and comes back with a caveat. Meanwhile a cell built on twenty respondents printed with the same confidence as one built on two thousand, and nothing flagged it.
The memory
The analyst who ran three rounds leaves
The standard tables were forty scripts only they understood. The folder of past waves is complete, but nobody can say which instrument version goes with which file, or why a recode was chosen. A ten-year trend, or a pooled subnational estimate, becomes a project instead of a question. The next wave starts from scratch and repeats the last one's choices without knowing they were choices.
The meaning
A number in the report is questioned
Which question on the form produced it, who was asked, and which codes counted as missing? The questionnaire is a PDF, the file is columns of codes, and the report was assembled by hand from the previous one. Between two waves a filter changed and the trend carried the seam without saying so. Nothing in the published table points back to what made it, so explaining the number means rebuilding it.
The bar is moving. Since 2025, every finding the World Bank publishes ships with a reproducibility package, the code, data and method behind it, verified by an internal team before release. The Inter-American Development Bank has followed. Nature's editorial in September 2026 says the rest of the international system should too.
Who it's for
Organizations that run surveys on a schedule, and answer for the numbers.
svyLab is built for programs, not one-off studies: the same survey, wave after wave, with a reviewer, an auditor or a minister at the end of it.
National statistical offices and ministries
Official statistics on a calendar, with release rules, a methods appendix for every table set, and the memory of every round kept in the institution rather than in a contractor's laptop.
Survey research firms and polling organizations
Many clients, many waves. The same plan re-run each wave, weights that reproduce two years later, and a track record a client can inspect.
University survey centers
Methods a journal reviewer can check, and continuity when students and staff turn over. The program remembers, not the person.
Implementers of DHS, MICS and LSMS-style programs
Multi-country, multi-round. Instrument versions tracked across countries and rounds, so comparability is recorded rather than assumed.
Agencies and foundations that commission surveys
Consult a delivered project read-only, reproduce a table set from the public-use file, and verify what was delivered without asking for the scripts.
Any team that publishes a number it has to defend
If a figure gets questioned a year later and the answer today is a person, this is for you. Surveys first; the same discipline extends to other designs over time.
The survey lifecycle
Survey design and analysis you can trust.
One chain of custody, from instrument to report: questionnaire, design, weights, plan and report, each versioned, checked before it runs, and traceable to the one before it. The plan is written once; every wave after that is attach, preflight, run, report.
-
1
Instrument
Import the questionnaire as an XLSForm from ODK, KoboToolbox or SurveyCTO, or as a written spec. It is linted against 84 methodology rules, so a skip pattern that can never fire is caught before collection. A codebook exists before any data does.
-
2
Data
The wave, the design it was drawn under and its metadata are held in one place and versioned together. The design is the one declared at planning, carried with the data rather than re-typed per analysis. Conformance against the instrument reports conform, violate or undetermined, and variables read as questions, universes and value labels, never guessed from column names.
-
3
Weights
Describe the intent; get typed, editable steps — non-response adjustment, post-stratification, raking, calibration, trimming. Preflight checks everything before a number is computed; diagnostics afterwards report weight CV, design effect, extreme weights, and achieved margins.
-
4
Analysis plan
The analyses your program runs every wave, written against questions rather than columns, with the methodology declared once: which weight, which variance estimator, which confidence level. Estimates are design-based, reported with standard errors, confidence intervals, design effects and degrees of freedom. Preflight shows each task's spec before it runs, and every line of generated code is inspectable
svy. -
5
Report
A branded PDF from the run, and the documents that travel with it from the same chain: the codebook, the data dictionary, the methods appendix that says which weight and which estimator. When wave 2 arrives: diff the instrument, re-preflight the same plans against the new file, run.
Where the AI is, and where it isn't
AI drafts; it never decides. Every step it proposes is an editable form, the methodology is declared by a person, and anything the pipeline cannot resolve is surfaced for review. It is optional, and the platform is the same platform with it switched off. What it reads, and why that matters →
The knowledge hub
A survey program that understands itself.
Questionnaires, concepts, variables, codes and methods are stored as specs, machine-readable and versioned, and the Library ties every wave, weight and analysis back to them. That makes it a hub rather than an archive: it can be asked questions, and the AI, when it is on, reads it before it drafts anything.
Specs, not documents
A questionnaire is imported as a spec, not a PDF: questions, concepts, codes, skip logic and who was asked, linted against 84 methodology rules and versioned between waves. A codebook exists before any data does, and every variable knows what it means.
A Library that links, not stores
Each validated wave, weighting scheme and analysis is tied to the instrument version and the concepts it used. A question across rounds, or across surveys that share a concept, is a query, not a reconstruction.
AI that reads the record, and only the record
When it is on, the AI drafts weighting steps and analysis code from the specs and the Library, proposes matches when a variable was renamed, and explains a diagnostic in plain words. It never decides a method, and it is optional: switch it off and the hub is the same hub.
The Library
Institutional memory your organization keeps.
A survey program is more than its last wave. Every validated round, instrument version, weighting scheme and analysis is kept, governed and versioned, so the next question starts from what the organization already knows.
Every validated wave, archived whole
Instrument version, data, weights, plan and results are archived together, with the lineage between them. A published number can be traced to the question on the form years later.
Re-weight without rewriting history
An old wave can be re-weighted under the current scheme for a comparison, while the weights that were published stay exactly as they were.
Compare across rounds
The same plan runs on every wave, and a definition that moved between them is flagged, so a trend is read against the changes that could explain it.
Consult without touching
A finished project can be opened read-only: ask a question, run an estimate, export the result, and leave the record as it was. Every project keeps count of what has been asked of it.
Built for organizations that answer to reviewers
Every number you can explain.
Correct, governed, and reproducible by construction. Not by convention, and not by trusting the analyst's memory.
Methodology you can audit
Every analysis shows which estimator, which weight, which variance method — and why. A reviewer reads the record, not the analyst's memory.
One organization, one sandbox
No cross-organization data sharing — by architecture, not just by permission. Members of your organization see your data; nobody else does.
Governance as a feature
Dataset lifecycle (in production → team-finalized → org-validated → archived) and classification (public / restricted) are enforced separately, with an audit trail — the way statistical offices actually manage data.
Reproducible by construction
Instruments, datasets, weights, and plans are versioned. Results are typed, schema-versioned data, not text to be re-keyed. Every run records what it read and what it wrote. What the development banks now assemble after the fact, a round run here produces as a by-product: the scripts, weights, codebook and methods appendix a reproducibility package needs.
An open engine
Every number is computed by svy — open source, validated
against R's survey package across
37 estimators, and fast
enough for a million-row two-stage design.
No lock-in, on purpose
What you build in svyLab you can re-run in Python. A weighting plan downloads as a script that runs outside svyLab and reproduces the same weights, the engine underneath it is open source, and results are plain, versioned JSON reachable by API. What stays valuable is the governance and lineage you accumulate, not data held hostage.
Checked at the door
Each wave's file is confirmed against the sampling design and the questionnaire before any estimate exists. A wrong code or a missing stratum is caught on upload, not in a published table.
Release rules that say why
Your rule, a minimum n or a maximum CV, decides what is published, flagged or withheld. A withheld cell carries its reason, and the reason ships with the table.
Definitions tracked across waves
When a question, a code or a filter changes between waves, the change is recorded and classified, so a trend never carries a moved definition without saying so.
Early access
How we're working with the first institutions.
svyLab is in early access, with a first cohort of five design partners: organizations that run surveys on a schedule and answer for the numbers. The path in is small steps, and none of them starts with sending us data.
-
Step 1 · 30 minutes · free
A walkthrough
On a public survey, or on tables from a report you've already published. Nothing to install, no data to send, nothing sold. You leave with a clear read on whether plan-driven analysis matches how your team works.
-
Step 2 · a few days, mostly ours
One table set, reproduced
If it fits, we reproduce one of your standard table sets end to end, from a public-use file or your own data, your call, and you check the numbers against what you published. The pipeline runs in minutes once it is set up. The few days are ours: agreeing the table set, and matching your published figures line by line.
-
Step 3 · one full round
A design partnership
We run a full round of your survey together, as a paid engagement priced with you and consistent across the cohort. What that involves is below.
The design partnership
First cohort: five organizations · rolling start as spots fill
What you get
- Early access to svyLab, ahead of general availability
- A direct line to the founder — a survey statistician, not a support queue
- Your round shapes the roadmap: what breaks for you gets fixed first
- Your partnership rate locked in as your founding-partner price after launch
What we ask
- One real survey round, run through the platform together
- Three structured feedback sessions over the round
- Candid feedback — and permission to reference the work at the level your organization allows: a private letter, anonymized, or named
Design partnerships are paid engagements. We set the price with each partner, keep it consistent across the cohort, and lock it in as your founding-partner rate after launch. Nothing is sold in the walkthrough, and your organization is never named without written permission. Prefer a services engagement? Same work, familiar paperwork →
Prefer email? info@svylab.com — a person replies, usually within one business day.
Questions we're asked first
Before you book
Anything not answered here — ask on the call, or write to info@svylab.com.
Do we need to send you data for a walkthrough?
No. We use a public survey, for example DHS, MICS, LSMS, ACS or EU-SILC, or, if you send us a link to a report you've published, we walk through how svyLab would produce one of its tables. Data only enters the picture if you choose a reproduction (step 2), and even then a public-use file is usually enough.
Where does our data live, and who can see it?
Each organization runs in its own sandbox: there is no cross-organization data sharing, by architecture. Inside it, datasets carry a lifecycle state and a classification (public or restricted), and every change is audited. svyLab is hosted on Google Cloud today; a single-tenant or on-premise deployment is on the roadmap — tell us early if it's a requirement.
What does the AI actually do — and can it get the methodology wrong?
It drafts. Weighting steps from a sentence of intent, variable matches when a field was renamed
between rounds,
and the specs and svy code for each task in a plan. Methodology
(variance method, weight, confidence level, missing-code handling) is declared by a person and
acknowledged once; every draft is an editable form; and whatever the pipeline cannot resolve from
the plan and the instrument is surfaced for review, never decided quietly. Every number is
computed by svy, the open-source engine. The AI
is optional and can be switched off; the forms are the same either way.
What does it cost?
We don't publish tiers yet. A walkthrough is free. Design partnerships are paid — priced with each partner, consistent across the cohort, and locked in as your founding-partner rate after launch. Commercial pricing follows what an organization holds and governs (datasets, rounds, auxiliary data), not seats, so a small methodology team is never the thing being metered. We'll walk through it on the call.
Which designs and file formats does it handle?
Stratified multi-stage designs with Taylor-linearization or replicate-weight variance (BRR, Fay, jackknife, bootstrap, SDR); surveys with several linked instruments and weights (household, woman, child); CSV, Parquet and Excel; SPSS (.sav, .por), Stata (.dta) and SAS (.sas7bdat, .xpt) files with their value labels, written back out as .sav, .dta and .xpt; and XLSForm instruments, the format ODK, KoboToolbox and SurveyCTO export.
What's ready today, honestly?
Instrument import and linting, data upload with design confirmation and instrument conformance, and weighting plans with preflight, diagnostics and a downloadable script are built. Analysis-plan runs, branded reports, and the advisor that explains a diagnostic in words are being completed with our first design partners this fall, which is exactly why we're doing walkthroughs rather than open signup. You'll see the real thing, not slides.
Do you also do consulting?
Yes — as scoped engagements delivered on svyLab: run a survey round with us, reproduce and audit a published table set, modernize a legacy pipeline, or train the team. Same work as a design partnership, with paperwork a procurement office recognizes. See services, or write to info@svylab.com.
Who is behind svyLab?
Mamadou S. Diallo, PhD, PStat® — a survey statistician with twenty years across official statistics, global health surveys, and industry, and the creator of samplics and svy, the open-source engines behind svyLab (open source since 2020) — through Samplics LLC. svyLab is the platform the package has been building toward.
Open source
Every number is computed by svy, open source and validated against R.
The engine under svyLab is free, forever. Anyone can read the code, check the math, and re-run in a notebook what svyLab computed.
Follow along
svy releases, tutorials, and svyLab updates — a few emails a year.
See it on a survey like yours.
Thirty minutes, on a public survey or your own published tables. Bring the person who owns the analysis plan.