Skip to main content

01 · Vision & Scope

Purpose: State the problem Rasd Forms solves, who it is for, what is in and out of scope, how it differs from incumbents, and how we will measure success — so that every later design decision can be traced back to a user need. Audience: The Rasd engineering team; developers and technical decision-makers at UN agencies, NGOs and their implementing partners who are evaluating whether to embed Rasd Forms in their own apps.

TL;DR​

  • Field monitoring at WFP/UNRWA/UNHCR-style organisations runs on XLSForm-based platforms (KoboToolbox, ODK, SurveyCTO, Ona/MoDa) plus CommCare for case work. They are platforms, not libraries: an agency team that wants Kobo-grade offline forms inside its own React or React Native product has no supported path (research/01, research/10).
  • Web form libraries (SurveyJS, Form.io, RJSF, JSON Forms) solve the "form as JSON" problem for the browser but ship no React Native renderer, no offline storage (or a paywalled, web-only one), and are 300–470 kB gzip (research/02).
  • Rasd Forms is an open-core, offline-first forms toolkit — headless engine + React/RN renderers + builder + storage/sync + PWA helpers + theming + capture adapters + license SDK — that developers install into their own app and connect to their own backend (spine §1).
  • Positioning: a library, not a platform. Your UX, your auth, your database, your infrastructure; XLSForm import so existing forms carry over; OpenRosa transport (phase 3) so Rasd front-ends can talk to existing Kobo/ODK/Ona servers.
  • Five personas drive the design: agency developer, M&E form designer, field enumerator on low-end Android offline for days, data-protection officer, IT admin.
  • Non-goals: hosted survey SaaS, analytics/dashboards, identity provider, beneficiary registry, SMS/IVR channel, replacing agency Kobo/ODK servers.
  • Success is measured by developer adoption (time-to-first-form ≤ 30 min), offline reliability (zero data loss, ≥ 99.5 % eventual sync success), and p95 form load ≤ 1.5 s on a 2 GB-RAM Android 8 device.

1. Problem statement​

1.1 How field monitoring works today​

Humanitarian and UN operations produce evidence through a small set of recurring, form-driven activities:

ActivityTypical cadence & settingWhat the form must do
Distribution monitoring (on-site, GFD / cash / NFI)Same-day, high volume, at crowded distribution points, often no signalFast entry, barcode/QR of ration or SCOPE card, auto GPS, headcounts, immediate finalize, batch upload later
Post-distribution monitoring (PDM)4–6 weeks after distribution, household visits over several days (research/01 §4)Consent, household roster (repeat), cascading admin units, FCS/rCSI calculations, photos, Arabic/other local-language switching
Third-party monitoring (TPM)Contracted enumerators, donor-facing evidenceGeo/time audit trail, photo geotags, signatures, tamper evidence, blind re-interview samples
Site / school / health-facility visitsChecklists per facility, monthly/quarterlyMatrix (Likert grids), facility lookup from a dataset, photo evidence, versioned checklists that change mid-cycle
Shelter / needs assessmentsMulti-day, remote areasGeoshape/geotrace, many photos, large P-code lookups, drafts resumed across days on low-storage devices
Complaints & feedback mechanisms (CFM / AAP)Help desks, hotlines, walk-ins; CHS 2024 commitmentsAnonymous & sensitive intake, PII flags, consent, referral categories, follow-up (case-like) status

Across all of these, the platform of record is XLSForm-based: KoboToolbox is the humanitarian default (OCHA/HHI/IRC lineage; UNHCR runs its own server; UNRWA collects "in both English and Arabic" with Kobo), ODK is the reference implementation, WFP's MoDa is Ona under the hood, and SurveyCTO is the commercial ODK derivative. Enumerators use Android apps (KoboCollect / ODK Collect) offline for days: download blank forms while online, fill, save as draft, finalize, send when a connection appears (research/01 §1). CommCare adds native case management for longitudinal work.

1.2 The developer's problem: embedding, not replacing​

Agency IT and innovation units increasingly build their own products — a partner portal, a beneficiary self-service PWA, a supervisor app, an integrated M&E system — and want the forms part to be as good as Kobo's field experience. Today they hit a wall from both directions:

Field-collection platforms are platforms. Kobo, ODK, SurveyCTO, CommCare and Ona sell a server plus a stock Android app plus a web renderer. Their UI is not embeddable as a component: KoboCollect and ODK Collect are Android-only apps, ODK Web Forms is Vue-based (offline drafts still upcoming), and Enketo — Kobo-maintained since March 2025 — remains the only mature offline web XForms renderer. None ships an npm package you can import into a React or React Native screen; custom fields (a lookup against your own registry), custom auth, theming and submission pipelines are impossible or a fork (research/01 §1, research/10 §3.4).

Web form libraries are not field tools. SurveyJS is the best JSON-driven survey engine and the model for our schema shape, but has no React Native renderer (issue #484 since 2017; #6713 since 2023), survey-core alone is 303 kB gzip, offline is a do-it-yourself pattern, and the Creator EULA is per-developer with a non-compete clause. Form.io's renderer is MIT but its offline plugin needs a paid key, is PouchDB/IndexedDB web-only, and react-native-formio was archived in 2023. RJSF and JSON Forms have excellent override registries but no builder, no RN, no offline, and AJV nearly doubles the bundle. Nothing in the React ecosystem combines DnD builder + JSON schema + RN renderer + offline sync (research/02 §9, Table A).

Concrete pain points reported by these teams (forums, issue trackers, research notes): two renderers for one form (web vs. Collect/WebView) that disagree, and a Kobo builder that silently rewrites matrix/rank types; no way to run their own logic (custom element types, validators, registry lookups) inside a stock renderer; offline absent on the web, paywalled and web-only at Form.io, never on RN; Arabic RTL inferred from "the first visible text" and untested per widget (mirrored sliders, bidi numerals, mixed LTR codes); WebView wrappers that stutter on 1–2 GB Android devices; and a procurement mismatch — per-developer perpetual licences (SurveyJS $569–$1,029/dev) or per-submission SaaS meters ($100–$700/month per org) do not map to how an agency budgets an internal product (research/10 §1–2).

1.3 Why now​

Both incumbents are rebuilding their web layer (Enketo → Kobo maintenance; ODK Web Forms default in Central v2026.2). Background Sync is Chromium-only (~77 %), so every serious offline design is an outbox anyway. React 19 makes custom-element embedding practical, Hermes and the RN New Architecture make a shared engine viable, and Ed25519 is in WebCrypto everywhere — the prerequisites for one engine across web/PWA/RN with offline licence verification now exist (research/04, research/05).

2. Vision & positioning​

Vision. Any developer at an agency, NGO or partner can add Kobo-grade, offline-first, Arabic-ready field data collection to their own React or React Native product in an afternoon — without adopting another platform, moving their data, or giving up their UX.

Positioning statement. Rasd Forms is the open-core, offline-first form engine that lets humanitarian engineering teams embed field data collection — RTL, low-end Android, sync — inside their own React and React Native apps, on their own infrastructure.

How we say it, per audience:

  • vs. Kobo / ODK / SurveyCTO / CommCare — a library, not a platform: your UX, your auth, your database; XLSForm import so existing forms carry over; OpenRosa transport so a Rasd front-end can still submit to your Kobo/ODK/Ona server.
  • vs. SurveyJS / Form.io / RJSF — offline storage and sync built in, React Native first-class, Arabic RTL and low-end-Android tuning by default, one engine and one JSON for web and native, humanitarian pricing.
flowchart LR
  subgraph host["Customer's host app (web / PWA / React Native)"]
    R["@rasd/react or @rasd/native<br/>FormRenderer + hooks"]
    C["@rasd/core<br/>engine · REL · validation"]
    S["@rasd/storage-*<br/>IndexedDB / SQLite"]
    Y["@rasd/sync<br/>outbox engine"]
    L["@rasd/license<br/>offline RLT check"]
    R --> C --> S --> Y
    R -.-> L
  end
  B["@rasd/builder<br/>(form designer, browser)"] -- "RFD JSON" --> host
  Y -- "RSP v1 (default)" --> K["Customer backend<br/>(@rasd/server ref. impl. or own)"]
  Y -. "openrosa transport (phase 3)" .-> O["Existing Kobo / ODK Central / Ona"]
  K -. "X-Rasd-License header or tokenEndpoint" .-> LS["Rasd License API<br/>(never called by end-user devices)"]

3. Personas​

PersonaGoalsConstraints & realitiesWhat Rasd must give them
Dana — developer, agency IT / innovation unit (React/TS, some RN, small team, rotating consultants)Ship a partner portal + enumerator app with the same forms; own the data pipeline; pass the security review; fork nothingBudget per project, not per developer; agency SSO; no data to third parties; low tolerance for 400 kB bundlesnpm i and render in < 30 min; headless engine + registry for x: types; storage/sync as adapters; auth via getAuthToken(); zero telemetry; rasd types
Maha — M&E officer / form designer (Excel-literate XLSForm author, not a programmer)Design a bilingual PDM form with skip logic and rosters, preview it in Arabic at phone width, publish v3 without breaking devicesWorks in Kobo today; programme staff review forms; edits happen mid-cycle@rasd/builder with logic editor, translations tab, RTL preview, XLSForm import/export, versioning that blocks breaking changes (spine §4.3b)
Yusuf — field monitor / enumerator (shared 1–2 GB-RAM Android, offline 3–5 days, sunlight, Arabic UI, one hand)Finish 25 households a day, never redo an interview, never lose a formBattery, storage, patchy 3G at night; shared device; interrupted mid-form for hoursrasd-field theme (48 px targets), autosave every 2 s, resumable drafts, finalized → queued without network, visible pending count and last-sync time
Lina — data-protection officerDemonstrate purpose limitation, minimisation, consent evidence and encryption; answer IASC/HLCM-style questionnairesNo beneficiary PII leaves the org's infrastructure; must export and purge; needs audit trailsconsent element with textVersion; bind.sensitive; AES-GCM / SQLCipher at rest; settings.encryption; audit events; export() always available; no Rasd servers in the data path
Omar — IT admin (devices, MDM, backend ops)Provision 200 devices, know what is pending where, revoke a lost device, keep costs predictableRotating enumerator pool; MDM Android; on-prem or single-cloud Postgres; PO/invoice purchasing via UNGM/LTAPOST /v1/devices policy (sync intervals, retention, remote-wipe), @rasd/server with Postgres + S3-compatible tus, annual invoice-able SKU, per-org (not per-submission) metering

4. Key use cases & user journeys​

Each journey names the packages and spine concepts it exercises; acceptance criteria for these journeys are the basis of the end-to-end test plan in 18 · Engineering practices.

UC-1 · PDM household survey, Arabic RTL, four days offline​

Maha publishes pdm-gfd-2026 v3 (locales: ["en","ar"], navigation: "paged", governorate → district cascade backed by geo_gov/geo_dist datasets, hh_members repeat, consent element). Yusuf's Expo app pulls form and datasets on field-office Wi-Fi (GET /v1/forms?since=…, GET /v1/datasets/geo_dist?since=…). For four days he interviews in Arabic (dir="rtl" from locale, Arabic-Indic digits for display, ASCII on save), captures a geopoint (accuracyThreshold: 10), photographs the ration card (image, maxPixels long edge 1280) and finalizes on the spot: draft → finalized → queued, autosaved every 2 s. On day four, in a 3G pocket, the engine sends outbox submissions first (POST /v1/submissions:batch, ≤ 50 per call, Idempotency-Key), then attachments via tus (resumable across drops), then pulls form/dataset deltas. The UI shows "27 pending → 0 pending, last sync 18:42". Nothing is lost if the phone dies mid-upload.

UC-2 · Distribution-day monitoring with barcode and auto-GPS​

At a GFD site, 400 beneficiaries pass a checkpoint. The form is scroll navigation with three elements: barcode (formats: ["qr","code128"], allowManual: true for damaged cards), a select_one with variant: "buttons", and an auto-captured geopoint (autoCapture: true, no user interaction). Each finalize takes < 5 s. The device has intermittent 4G; the sync engine is event-triggered on finalize and drains the outbox opportunistically while Yusuf keeps scanning. Duplicates from a retried batch are answered duplicate, not double-counted.

UC-3 · TPM facility visit with audit evidence​

A contracted enumerator visits 12 health facilities. The form uses a matrix Likert grid, image with geotag: true, a signature from the facility head, and settings.audit with trackChanges: true and location.enabled: true (minSeconds: 60, minMeters: 50). Every submission carries an audit array and definitionHash, so the agency's TPM reviewer can prove the visit happened where and when claimed. Mid-cycle, the checklist changes (v5 adds a question): the device pulls v5, in-flight finalized submissions stay on v4 (never migrated), open drafts are migrated opt-in via migrateSubmission.

UC-4 · Multi-day shelter assessment on a low-storage device​

A shelter team assesses 60 sites over a week: geoshape (mode: "manual"), up to 8 photos per site (multiple, maxCount: 8), a P-code lookup over ~30,000 dataset rows via pulldata(). The device has 800 MB free; estimate() drives a storage warning at 200 MB and photo compression keeps a submission under ~1.5 MB. Drafts resume across days, listed by instanceName (concat(${site_code}, ' – ', ${site_name})).

UC-5 · CFM intake desk with sensitive data​

A help-desk officer records complaints on a shared tablet. Elements carry bind.sensitive: true; settings.encryption.mode is "submission"; storage is SQLCipher (native) or AES-GCM (web); an anonymous path clears identifiers via relevant; the consent element records granted, at, textVersion, method. Lina exports (export() JSONL + blobs) for the DPIA and purges by crypto-shredding. Follow-up status is a phase-later record/case feature (RSP /v1/records), not a v1 requirement.

UC-6 · Developer embeds a form in an existing Next.js portal (PWA)​

Dana imports the Kobo XLSForm with rasd convert xlsform, reviews the two ext["org.getodk.xpath"] warnings, and renders it:

import { RasdProvider, FormRenderer } from '@rasd/react';
import { createDexieStorage } from '@rasd/storage-dexie';
import { createSyncEngine } from '@rasd/sync';
import { createLicense } from '@rasd/license';
import { rasdField } from '@rasd/themes';
import pdm from './forms/pdm-gfd-2026.form.json';

const storage = createDexieStorage({ namespace: 'moda-portal' });
const sync = createSyncEngine({ storage, baseUrl: '/api/rasd', getAuthToken: () => auth.getToken() });
const license = createLicense({ tokenEndpoint: '/api/rasd/license', storage });

export function PdmPage() {
  return (
    <RasdProvider storage={storage} sync={sync} license={license} theme={rasdField} locale="ar">
      <FormRenderer definition={pdm} onFinalize={(sub) => router.push(`/done/${sub.id}`)} />
    </RasdProvider>
  );
}

registerRasdRoutes() and precacheForms() from @rasd/pwa register offline routes and precache the form and its media in the portal's existing Workbox worker; the portal's own Hono backend mounts the @rasd/server RSP handlers. Time from pnpm add to a working offline form: under 30 minutes.

UC-7 · Form designer publishes v3 without breaking the field​

Maha opens <FormBuilder> with features={{ logic: true, translations: true, versions: true }}, moves hh_size into a group (non-breaking — name is the storage key), is blocked from changing income from number to select_one (breaking), fills the Arabic column in the translations grid, previews in RTL at 360 px, and publishes; diffDefinitions(v2, v3) shows the plan and the server rejects any re-publish of "3".

sequenceDiagram
  participant E as Enumerator device (offline)
  participant S as @rasd/storage
  participant Y as @rasd/sync
  participant B as Customer RSP server
  E->>S: autosave draft every change (autosaveMs 2000)
  E->>S: finalize → status finalized → queued (outbox.enqueue)
  Note over E,S: days pass with no network
  E-->>Y: connectivity signal (online / foreground)
  Y->>B: POST /v1/submissions:batch (≤50, Idempotency-Key)
  B-->>Y: per-item accepted / duplicate / rejected
  Y->>S: patch status → synced (or rejected with reasons)
  Y->>B: tus upload attachments (resumable)
  Y->>B: GET /v1/forms?since + GET /v1/datasets/{name}?since
  Y-->>E: events progress + formUpdated — UI shows pending=0 and last sync time

GA acceptance criteria for the journeys​

  • UC-1: 4-day offline run (fake clock, network off) ends with 100 % of finalized submissions synced, attachments uploaded, no duplicate rows server-side.
  • UC-2: 400 finalizes in one session on a 2 GB-RAM Android 8 device without ANR; retried batch yields duplicate, not double counts.
  • UC-3: every submission carries audit[], definitionHash, formVersion; v4 finalized submissions are accepted after v5 is published.
  • UC-4: storage warning fires at the configured threshold; drafts survive app kill and OS restart.
  • UC-5: sensitive fields unreadable on disk without the key (SQLCipher / AES-GCM); export() works with an expired licence.
  • UC-6: a developer new to Rasd reaches a working offline form in a fresh Next.js project in ≤ 30 min following 21 · Getting started.
  • UC-7: breaking edits are blocked in the builder; re-publishing version "3" is rejected by @rasd/server.

5. Scope​

5.1 In scope (v1 unless marked)​

  • Engine: RFD v1 JSON, REL v1, ODK-compatible bind semantics, repeats, datasets, validation with severities, x: element types, ext round-tripping (@rasd/core).
  • Renderers: @rasd/react (web/PWA, also react-native-web) and @rasd/native (RN ≥ 0.81 New Architecture, Expo ≥ 54) with identical public API; @rasd/element custom element + IIFE bundle.
  • Builder: @rasd/builder — palette, canvas, inspector, logic editor, translations, preview, JSON view, versions; non-drag equivalent for every drag (WCAG 2.2 SC 2.5.7).
  • Storage & sync: @rasd/storage interface, Dexie 4 (web) and SQLite (RN) adapters, encryption at rest, outbox engine, RSP v1 client, @rasd/server reference (Node ≥ 20, Postgres, tus/S3-compatible).
  • PWA helpers, media capture adapters, themes (rasd-light, rasd-dark, rasd-high-contrast, rasd-field), i18n/RTL primitives, XLSForm import/export, CLI, testing utilities, license SDK (7-day trial → monthly RLT).
  • Phase 2/3 (designed for, not shipped at launch): openrosa sync transport (Kobo / ODK Central / Ona), editable records/cases (/v1/records, HLC + conflict queue), license dashboard app, ODK-compatible submission encryption layout.

5.2 Out of scope​

  • A hosted survey SaaS (accounts, form hosting, respondent links, data tables). Rasd Cloud, when offered, is only the RSP server + license service run for customers who do not self-host.
  • Analytics, dashboards, PDF export, data-cleaning UIs, Power BI/Tableau feeds — customers do this on their own backend; RSP keeps data in their Postgres.
  • End-user identity (auth is getAuthToken() from the host); beneficiary registries (SCOPE-like), entitlements, payments.
  • SMS/IVR/WhatsApp intake (RapidPro-style) — at most a future adapter.
  • Native Android/iOS SDKs outside React Native; Vue/Angular/Svelte renderers (the custom element covers framework-agnostic embedding).

5.3 Non-goals (deliberate)​

  • Not replacing Kobo/ODK/Ona servers. UN teams will not migrate servers for a UI library; we interoperate (research/01 §5.9).
  • Not metering by submission or end user. Metering is per organisation + apps (spine §9); a library must never look like a tax on beneficiaries' data.
  • Not owning the customer's service worker, auth, or crypto. Workbox route factories, delegated tokens, WebCrypto/SQLCipher only.
  • Not "beautiful by default at any cost." Field ergonomics and bundle budgets (form-runner ≤ 120 kB min+gzip) beat visual richness.

6. Differentiators​

CapabilityKoboToolboxODKSurveyCTOCommCareSurveyJSForm.ioRJSFRasd Forms
Delivery modelHosted platform (AGPL)Platform, self-host (Apache-2.0)Proprietary platformPlatform (BSD/Apache)npm (MIT core, paid Creator)npm + server (MIT/OSL-3.0)npm (Apache-2.0)npm, open-core; optional cloud
Embeddable React componentNo (Enketo link/iframe)No (Vue Web Forms)NoNoYesYesYesYes (@rasd/react, <rasd-form>)
React Native rendererNo (Android app)No (Android app)NoNoNo (#484/#6713)Archived 2023NoYes (@rasd/native, same API)
Offline in the libraryApp-onlyApp-only; web offline drafts upcomingApp-onlyApp-onlyDIYPaid plugin, web-onlyNoIndexedDB + SQLite adapters, encrypted
Sync / server contractProprietaryOpenRosa + RESTProprietaryProprietaryNoneFormio serverNoneRSP v1 (REST+SSE, tus) + reference server; OpenRosa phase 3
Form & logic languageXLSForm / XPathXLSForm / XPathXLSForm / XPathXForms / XPathSurvey JSON / string DSLComponent JSON / JS, JSONLogicJSON SchemaRFD JSON / REL (no eval, static deps) + XLSForm import/export
DnD builderYes (web)NoNoVellumCreator ($569–$1,029/dev)Yes3rd-party@rasd/builder, embeddable, plugins
Custom element typesNoNoNoLimitedYesYesYesx:* registry + ext payload
Arabic RTLInferred from first textYesYesYesCustom-locale flagPartialHost CSSPer-form dir, per-widget tested, rasd-field theme
Runtime bundle (gzip)n/an/an/an/a~303 kB core~415 kB+ AJV≤ 120 kB form-runner
Pricing unitOrg / submissionsProject / submissionsTeam / submissionsMobile usersDeveloper, perpetualEnv + developerFreeOrg + apps; humanitarian discount

Facts sourced from research/01, research/02 and research/10, all checked 2026-08-15.

7. Success metrics​

AreaMetricTarget (12 months after GA)How measured
Developer adoptionTime-to-first-form (fresh Vite or Expo project → offline form rendered)≤ 30 min p50, ≤ 60 min p90Docs-playground funnel; quarterly usability tests with 5 external devs
Organisations with an RLT / trials started; weekly npm downloads of @rasd/core≥ 25 orgs / ≥ 300 trials; ≥ 5,000/weekLicense service (org-level only, never device telemetry); npm
Field reliabilityData loss (finalized submissions never delivered while the device survives)0 known casesFault-injection suite (@rasd/testing); customer incident reports
Eventual sync success of finalized submissions within 7 days of reconnecting≥ 99.5 %Server-side counters in @rasd/server; customer opt-in aggregate
Continuous offline operation without degradation≥ 30 days collection; ≥ 90 days licence (60-day exp + 30-day grace)Playwright/Maestro offline scenarios with fake clock
Performancep95 cold form load, 120 questions + 2 repeats, 2 GB-RAM Android 8 (Snapdragon 4xx-class)≤ 1.5 s native, ≤ 2.0 s Android WebView PWANightly device-lab runs (Maestro, Playwright)
p95 recompute per value change (≤ 500 elements); bundle budgets≤ 16 ms; core ≤ 45 kB, react ≤ 90 kB, form-runner ≤ 120 kBVitest benchmarks; size-limit hard-fail in CI
Accessibility & i18nWCAG 2.2 AA violations (renderer, builder); RTL parity0 critical/serious; 100 % of element types pass RTL visual testsvitest-axe, TalkBack/VoiceOver/NVDA passes; Playwright RTL project
InteropXLSForm fidelity on the public corpus (~140 forms)≥ 95 % parse unchanged; 100 % round-trip without loss (warnings allowed)CI against pyxform
CommercialTrial → paid conversion; annual-invoice share of revenue≥ 8 %; ≥ 60 %Stripe Billing / Invoicing

8. Constraints & assumptions​

  • Support matrix (spine §12): React 19 (18.3 tested); RN ≥ 0.81 New Architecture only, Expo SDK ≥ 54; Android 7+ (API 24) native; Android WebView/Chrome ≥ 100; last 2 versions of evergreen browsers. Research suggests Android 6+ (DHIS2 dropped Android 5 in 2026); the spine's Android 7+ floor is retained.
  • Network is opportunistic. Background Sync API is Chromium-only (~77 %); expo-background-task runs at the OS's discretion; sync is foreground-driven with background top-ups (research/04).
  • Browser storage is best-effort. Safari (ITP) purges script-writable storage after 7 days of Safari use without site interaction unless the app is installed to the Home Screen; we request navigator.storage.persist(), recommend installed PWAs, and treat RN as primary for multi-day offline (research/05).
  • Hermes lacks Intl.PluralRules; Rasd ships compiled CLDR plural functions per locale and the Rasd Mini-Message subset, not a full ICU engine (research/13).
  • No end-user telemetry, ever. Production devices never contact Rasd; licence verification is offline (embedded Ed25519 keys); refresh flows through the customer's backend (spine §9).
  • XLSForm is the interchange, RFD the native format. Import is best-effort with explicit warnings; unmappable XPath is preserved under ext["org.getodk.xpath"].
  • Licensing as configured (Option A): all runtime packages token-gated after the 7-day trial, soft enforcement by default, drafts/sync/export always work. The spine flags Option B (free renderer + storage) as the research-recommended alternative for adoption and DPG eligibility; features[] makes it a configuration change (research/10 §5, 15 · Licensing & billing).
  • Procurement: the primary agency SKU is an annual invoice (PO, bank transfer, Net-30); card checkout serves small teams. A vendor pack (architecture showing no Rasd servers in the data path, DPA, security-questionnaire answers, WCAG/RTL evidence) is a launch deliverable.
  • Clean-room builder — no code or design lineage from SurveyJS Creator (non-compete EULA) or other proprietary builders; boring standard tech (spine P7); phased delivery per 19 · Roadmap.

9. Glossary​

Terms (form definition / RFD, element, submission, record/case, dataset, attachment, renderer, builder, registry, outbox, license token / RLT, host app) are defined once in the spine — see 00 · Design spine §13. This document uses them without redefinition.

Open questions​

  • Option A vs Option B licensing (spine §9): does the founder accept the adoption/DPG trade-off of gating the renderer, or keep renderer + storage under Apache-2.0 and gate builder/sync/enterprise?
  • Should the openrosa transport be pulled forward from phase 3 to launch, given that "submit to your existing Kobo/ODK server" is the strongest migration argument in every research note?
  • Are editable records/cases (CFM follow-up, longitudinal PDM) required by the first two design-partner organisations, or can v1 ship append-only submissions?
  • Which two or three design-partner organisations (agency IT unit + implementing NGO) will validate UC-1/UC-3/UC-6 before GA, and under which discount/free-Team arrangement?
  • Web target for enumerators: do we officially support multi-day offline collection in a browser tab, or document "installed PWA or RN only" for that scenario?
  • Do we commit to a DPG application for the Apache-2.0 packages, and what does that require of documentation and non-PII data-extraction indicators?