All examples · Raw Markdown

Independent numbered questionnaire specification

Version 2. Newly fictional, CAWI, English. The numbers and response codes below define the research contract independently of either parser. .qube is the default implementation; .odin is the independently implemented compatibility example. Do not infer the expected route from a script under test. Q01–Q35 retain their original identities. Q36–Q53 add the portfolio and procurement modules; numeric order is the coding identity, not the display order.

All asked items require a response. Free text accepts 1–200 Unicode characters, except Q34 which accepts 1–600. The focus-tool label is an interview label, not a verified organisation or vendor identifier. Numeric answers are whole numbers. Multiple-choice selections require at least one code; None must be alone. A respondent can leave the interview rather than answer. Endings are Complete or Screenout; no partial interview is a complete.

Eligibility and current portfolio

Chosen-tool experience

Adoption criteria and intent

Purchasing process and planned investment

AI policy and final measures

Interview route

flowchart TD
    A[Consent, adult and decision influence] --> B{Eligible?}
    B -->|No| X[Screenout]
    B -->|Yes| C[Organisation and current categories]
    C --> D{Current software?}
    D -->|Yes| E[Repeat portfolio module for each selected category]
    E --> F[Chosen-tool experience and renewal]
    D -->|None| G[Adoption criteria and future intent]
    F --> G
    G --> H[Procurement participants and recent decision gate]
    H --> I[Annual budget availability gate]
    I --> J{Future adoption planned?}
    J -->|Yes| K[Project categories, business case and requirements]
    J -->|No| L[Paid-tool price vignette where applicable]
    K --> L
    L --> M[AI policy, recommendation and improvement]
    M --> N[Complete]

The category loop is a small decision graph of its own. An unknown count still permits category role and change-plan answers. A one-tool category skips coordination. Only replace/consolidate plans ask their reasons. These are per-category conditions: an answer for one category must never control another category’s branch.

Behavioral contracts

1. Screenouts stop before organisation/experience questions. No assent or inferred eligibility is filled in by the host.
2. Nonusers reach adoption criteria, barriers and AI policy; they never see tool-specific labels, ratings or recommendation.
3. Every repeated portfolio item retains its category identity. Satisfaction, count availability, coordination and change reasons for one category must not overwrite or route another category.
4. Other follow-ups appear only for their specific code. Exclusive None plus an ordinary code is rejected atomically, without advancing or retaining the invalid selection.
5. Q15 is asked for renewable paid licences; continuing a free tool is still asked at Q16.
6. Criteria retain stable codes after randomization; Other stays last and no substantive code is duplicated or removed.
7. Numerical and cardinality bounds reject invalid values without changing the current question or accepted answer record.
8. Synthetic scenario expectations explicitly list ordered visits and skipped branches. Successful records retain submitted values and separate repeated identities. A saved/restored session must finish with the same answers and route.
9. Q35 distinguishes an available access-count estimate, an unknown count and a refusal. Only Yes asks Q12; neither unavailable category stores a Q12 answer or blocks Q13 and the remaining applicable tool questions. The numeric lower bound remains one for an available estimate.

Cross-engine equality is semantic: numbered items, codes, repeat member identities, submitted values and endings. Internal IDs, record encoding, random streams and event formats differ. The focused test script reports actual runtime evidence and limits; the specification alone does not certify implementation.

10. Q53 distinguishes estimated, unknown and refused category counts. Q36/Q37 remain absent for unavailable estimates, never zero; Q38/Q39 remain asked. Reconstruction inside the loop must preserve its member and all earlier answers.
11. Only recent personally influenced decisions ask Q43–Q45. No recent decision is required for eligibility: respondents may be planning their first purchase.
12. Only an available expenditure estimate asks Q47. Budget refusal/unknown must not skip the planned-project module or become a zero-spend band.
13. Future projects can include categories absent from today’s portfolio. Q48 permits one to three categories; every category is coded in the same domain as Q07. Q49–Q51 measure project maturity and requirements independently of current-tool satisfaction.
14. The hypothetical paid-price vignette is separate from the unaided continuation measure Q16. No current price or respondent willingness to pay is inferred from Q52.

Analysis populations and missing values

• Organisation profile, procurement participants, budget availability and adoption barriers: all eligible completes.
• Portfolio measures: organisations selecting the individual category. Tool counts use Q53=1; coordination uses those with at least two estimated tools. Unknown and refused counts have distinct gate codes and no numeric payload.
• Change reasons: category cases planning replacement/consolidation, rather than all software users. Each respondent may contribute several category records; account for this dependence in formal analysis.
• Recent procurement: Q42 in 1–2. Supplier count, trial and gates share this population. Counts are respondent estimates, not verified procurement records.
• Spend bands: Q46=1 only; unavailable budgets are reported separately. The fictional population is New Zealand organisations so the NZD bands have one interpretation.
• Planned investment: Q28 in 1–2, including nonusers. Future categories are a separate multiselect measure, not a change to current portfolio membership.
• Price continuation: known paid-tool users (Q14 in 1–4). Compare with Q16 descriptively within this group; do not derive price elasticity or revenue predictions from one hypothetical change.

Multiple-response percentages may exceed 100%. Treat Don’t know, refusal, Cannot judge, skipped/inapplicable and an actual zero on the recommendation scale as different states. A saved record contains only applicable respondent answers; runtime applicability markers are metadata, not imputed responses.

All examples · Raw Markdown