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 (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.”
The problem
The analysis plan is real. The system holding it isn't.
Most recurring survey programs already have a written analysis or tabulation plan, a standard table set, an indicator list. What they don't have is a system that runs it the same way each time, can show its work, and makes the next round cheaper than the last instead of starting over.
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, and the report rebuilt from the previous one every round. 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.
Past rounds are archives, not assets
Ten years of waves sit in folders. Comparing this round with the last three, or pooling them for a subnational estimate, is a project of its own rather than a question you can ask.
The data does not carry its meaning
The questionnaire is a PDF and the file is columns of codes. What a variable asked, who it was asked of, and which codes mean missing are known to whoever ran the last round.
How it works
One chain of custody, 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. Each one is versioned, checked before it runs, and readable by a reviewer. The work itself is not a straight line; instruments get revised mid-round and weights get re-run against new margins. What holds is the chain of custody: every published number points back to the task that produced it, the weight it used and the question it came from. The plan is written once and the methodology acknowledged once, by a person. Every wave after that: attach the new file, 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 86 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
svyLab uses AI to draft weighting steps from a sentence of intent, to propose variable matches
when a field was renamed between rounds, and to turn plan tasks into specs and
svy code. The advisor we are building next reads the diagnostics:
the finding that a weight CV rose 43% at raking comes from the rules, the sentence about what that
costs and what to do instead comes from the model.
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. 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.
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 readers and writers for SPSS, Stata and SAS files
with their labels intact. 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; a library that carries rounds forward instead of restarting them; 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 and SAS files in and out. 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, KoboToolbox, SurveyCTO), are linted against 86 methodology 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: national statistical offices and ministries, survey research firms, university survey centers, the implementers behind DHS-, MICS- and LSMS-style programs, and the international agencies and foundations that commission and review them. 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, 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 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.
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.