Early access · now onboarding 5 design partners
Survey design and analysis you can defend.
svyLab understands your questionnaire, guides the methods, produces traceable estimates and
reports, and keeps every survey ready for the next question. 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 (DHS, MICS, NHANES) 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.”
The problem
The plan is real. The system holding it isn't.
Most recurring survey programs already have a written analysis or tabulation plan. What they don't have is a system that runs it the same way each time and can show its work.
The plan lives in last wave's script
Forty standard tables, re-derived every round from syntax one person understands. When they move on, the program's memory goes with them.
The weights can't be reproduced
Control totals in a spreadsheet on a laptop. Two years later nobody can re-run the calibration — or say which margins were used.
The last step is copy-paste
Estimates transcribed into a report by hand. Every transcription is a chance for a wrong number in a published table.
The method is invisible to the reviewer
Which weight? Which variance estimator? How were the missing codes handled? The answer is a person, not a record.
How it works
One chain, from instrument to report.
svyLab is built around the artifacts a survey program already has — a questionnaire, a sampling design, weights, an analysis plan, a report — and makes each one versioned, checked before it runs, and readable by a reviewer. The plan is written once and the methodology is acknowledged once, by a human. Every wave after that: attach the new file, preflight, run, report.
-
1
Instrument
Import the questionnaire — an XLSForm from ODK or Kobo, or a written spec. It is linted against 86 rules, so a skip pattern that can never fire is caught before collection. A codebook exists before any data does.
-
2
Data
Upload the wave. The survey design is proposed from file metadata — never guessed from column names. Conformance to the instrument reports conform, violate, or undetermined, and variables read as questions and labels, not codes.
-
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. Preflight shows each task's spec before it runs. Every line of generated code is inspectable — and it is just
svy. -
5
Report
A branded PDF from the run — plus the codebook and a methods appendix from the same chain. When wave 2 arrives: diff the instrument, re-preflight the same plans against the new file, run.
Where the AI is — and isn't
svyLab uses AI to draft weighting steps from a sentence of intent, to propose variable matches
when a field was renamed in the field, and to turn plan tasks into specs and
svy code.
It never picks a method silently. Methodology is declared by a person; every draft is an editable form, not a wall of code; and anything the pipeline cannot resolve from the plan and the instrument is surfaced for review rather than decided. The point of the AI is to make survey methodology visible — not to hide it.
Built for organizations that answer to reviewers
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.
An open engine
Every number is computed by svy — open source, validated
against R's survey package across 18 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: the engine is open, and results are plain, versioned JSON. What stays valuable is the governance and lineage you accumulate — not data held hostage.
Open source
The platform is new. The engine isn't.
svy (formerly samplics)
is the open-source Python package for complex survey analysis: design-based estimation, weighting,
replicate weights, small-area estimation, and SPSS / Stata / SAS I/O. Everything svyLab computes
runs through it — and you can run it yourself.
- 18
- estimators validated against R's survey, to at least six decimals
- 12–24×
- faster than R on a one-million-row stratified two-stage design
import svy # Read the wave and declare the design df = svy.read_parquet("wave1.parquet") design = svy.Design(stratum="region", psu="cluster", wgt="final_wgt") sample = svy.Sample(data=df, design=design) # Design-based estimates, with SEs, by domain est = sample.estimation.mean( ["income", "food_share"], by="urban_rural" ) print(est) # est · se · lci · uci · cv · deff · df
How it fits together
svy is free. What does svyLab add?
The engine stays open source, forever — everything svyLab computes, you can compute in a notebook. What svyLab adds is the layer that turns computation into a survey program: the instrument, the plans, the documents, and the governance around them.
Your organization's sandbox; versioned datasets, weights, and plans; lifecycle and audit trail; the preflight and review screens; hosting.
The instrument as an artifact, plans that compile to code, documents from typed results — all checked before anything runs.
Design-based estimation, weighting and calibration, replicate weights, small-area estimation, SPSS / Stata / SAS I/O. Validated against R. Free forever.
Three things the open engine doesn't do
- The instrument is data, not a Word file
- Questionnaires import from XLSForm (ODK, Kobo), are linted against 86 rules, versioned and diffed between waves — breaking, review, or compatible — and checked against each data file: conform, violate, or undetermined. A codebook exists before any data does.
- Plans that compile to svy code — and are checked before they run
- Weighting and analysis plans turn intent into typed, editable steps. Preflight resolves every column and control category and restates the methodology in prose; the generated code is inspectable and is just svy. AI drafts; a person decides.
- Documents from typed results, not copy-paste
- Codebooks, methods appendices, and branded reports render from the same versioned results — so a number in a published table traces back to a task in a plan, a weight, and a question on a form.
Early access
How we're working with the first institutions.
svyLab is in early access. We're onboarding a first cohort of five design partners — organizations that run surveys on a schedule: statistical offices and ministries, survey research firms, university survey centers, and the implementers behind DHS-, MICS-, and LSMS-style programs. 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
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.
-
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 — DHS, MICS, or NHANES — 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,
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, whose estimators are validated against R.
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, Excel, and SPSS / Stata / SAS files with their labels; XLSForm instruments from ODK and Kobo.
What's ready today, honestly?
Instrument import and linting, data upload with design confirmation and instrument conformance, and weighting plans with preflight are built. Analysis-plan runs and branded reports 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.
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.