Designing a garbling scheme

A new scheme starts on IID garbling with direct capture, which needs no roster, so the form's yes/no questions are listed to tick straight away. A form already built for a token sheet starts on block garbling with token sheets instead, its garbled questions filled in from the form's pattern.

IID or block

• IID garbling: each answer is assigned on its own with probability r, the same chance for everyone, independently. The share assigned varies by chance, overall and in every subgroup. It needs no roster and no blocks; blocks you choose only group the report.
• Block garbling: exactly the share r is assigned within each block of the variables you choose (for example factory and gender), so no block ends up with nobody or everybody assigned by chance. Choose when the assignment is made:
• From a roster before fieldwork: each block gets a quota of its roster size times r, rounded by the rule you choose (round up, round half up, round down, or exact total, which keeps the overall total at r of the roster).
• In interview order: exactly k of every L interviews in each block are assigned as submissions arrive (for a rate of 1/5, 2 of every 10). It needs no roster; the block values can come from the form's own questions.

The plan warns about blocks smaller than the minimum block size (5 by default), and the report never shows their assignment share.

How the answer is captured

• Direct (recommended): the enumerator asks and records the question as usual, and Joripo garbles the answer when the submission arrives, so nothing about garbling is on the phone. You tick the questions to garble and check how their answers are read: which choice means Yes, which No, and which are nonresponse (kept as answered, never garbled). Joripo suggests a coding from the choice list; you confirm it ("I have checked this coding") before freezing.
• Token sheet: the enumerator types a code from a sheet the form pulls in with pulldata(), and Joripo decodes and garbles it on arrival. Add question fills in a garbled question's yes and no tokens, its re-entry field and its slot from the form's pattern; Fill in all adds every one at once. Token sheets are made per respondent, so this design always needs a roster.

Assignment across questions

• Separate (recommended): an independent assignment for each garbled question. A recorded No to one says nothing about the others.
• Shared: one assignment per respondent for every question. Anyone with a recorded No to any question is then provably unassigned, so their recorded Yeses are true.

Respondents and the roster

The respondent ID field identifies a person across submissions, so a re-sent or repeated interview keeps its assignment (and is flagged). With IID garbling and direct capture you may choose instanceID: each submission is then its own respondent.

The roster lists the people the scheme covers, with their ID and block columns, and is stored encrypted. It is required for block garbling from a roster and for token sheets, and optional otherwise. Block variables are picked from the roster's columns once it is uploaded (with how many values each has), or from the form's questions. An empty block value is refused, excluded (no assignment; answers blank and flagged) or made its own "(missing)" block, as you choose. An optional ID pattern checks every roster ID; Joripo proposes one from the ID field's own constraint or from the shape of the roster's IDs, never an ID itself.

An existing key made elsewhere (for example in Stata) can be imported, after the roster, instead of letting Joripo make one.

Protection

• Hard (recommended): the original answers are never stored. Not even a key custodian can learn what a respondent said.
• Faithful: the original answers are kept, encrypted, so that a key custodian can decode them. Destroying the key deletes them.

Fields removed at ingestion are deleted from every stored submission as it arrives; a name ending in * removes every field that starts with it (rand* for rand1, rand2, …).

States

Submissions stored before a scheme was frozen are not garbled and are not in its report. Settings cannot change after freezing; late respondents can be added to a roster design without changing anyone already in the key.