delphyrApp

A focused workspace for synthetic Delphi studies.

delphyrApp brings panel responses, round management, editorial review, and coordination into the CTTIR suite. Participants' responses are saved shortly after each change, shown as saved only once committed, and submitted deliberately for a durable receipt. Managers review instruments, advance rounds, prepare feedback, and request private research exports.

The interface offers English, German, and French, with English as the default. Scientific text stays in its stored authored language; selecting an interface language does not translate a protocol or manufacture an instrument translation. This is development software, not a production release.

Synthetic panel workspace

Install and start

Install the core package first, then the application package:

# install.packages("remotes")
remotes::install_github("CTTIR/delphyR", subdir = "packages/delphyr")
remotes::install_github("CTTIR/delphyR", subdir = "packages/delphyrApp",
                        build_vignettes = TRUE)

The repository guide provisions the synthetic PostgreSQL fixture and starts a separate worker. With a repository and actor already resolved by trusted server code:

app <- delphyrApp::run_app(repo, actor, language = "en")
shiny::runApp(app, host = "127.0.0.1", port = 3838)

A fixed actor is shared by every session of that demo instance. A trusted host can instead use actor_factory(session, repo) and repo_factory() for separate session identities and connections. Factory connections close at session end; a directly supplied repository remains the caller's responsibility. Factory errors or missing identities close the session before service access. Browser fields and URL parameters never establish identity or authority.

run_app(sign_out_url = ) adds a sign-out link that ends every session of the account in the process and then follows the gateway's sign-out address. Behind a gateway that routes each account to one process, several processes can serve one study. The local OIDC evidence, with one to three processes, is documented separately. The stock Shiny Server OSS identity-header path and production deployment remain unqualified. No external mail transport is enabled.

Participant workflow

  1. Choose a study; the list of rounds starts with the round that is due.
  2. Read the stored study information and explicitly record consent.
  3. Select a response or allowed special category. A settled, complete entry is saved automatically after a short pause; Save now saves it at once. A round with more than block_fields fields (ten by default) is shown in blocks; the focus moves to the heading of each new block.
  4. Review the overview of answered and open fields and submit deliberately.

A field reads Unsaved change until its own commit returns. A failed save keeps the typed value and does not advance its confirmed revision. A revision conflict from another tab stops automatic saving for that field; the stored response is loaded only on request. Submission first saves complete pending entries and is blocked while any field remains unconfirmed. run_app(autosave_ms = 0) offers explicit saving only. Services independently check consent, ownership, rights, deadline, required fields, and revision sets. Submitted responses cannot be edited. Ratings have no default midpoint and the panel does not see live current-round results.

On connection loss, the interface does not claim that pending changes are saved. The tested reload path restores committed values; it is not an offline editor. Released feedback includes approved aggregates and only the person's own prior answers, with a changed-wording notice where applicable.

Study team workflows

Permission-filtered navigation preserves forms while moving between sections. Managers review round transitions and exact feedback releases, queue analysis and exports, validate instrument imports, and approve future-round protocol amendments after reviewing field changes. Existing rounds retain their protocol.

Editors preserve originals and record separate redactions or summaries. Another person reviews exact versions. Theme coding and item-source/split/merge records remain traceable. Coordinators review contact CSVs and blocking duplicates before creating unbound invitation drafts; importing an address grants no account access. Campaign previews bind exact pseudonyms and text before local sink processing.

Analysis, report rendering, exports, and sink processing belong to a separate worker. Check operation refreshes queued work. Downloads recheck authorization and artifact integrity. A hidden control is never the authorization boundary.

Design and verification

System fonts, teal and slate accents, visible labels, focus states, responsive forms, and restrained surfaces follow the CTTIR brainwritR family. Status messages use a polite live region and do not depend on color. Tables can scroll; reduced-motion preferences are respected. Deadlines include the study time zone and UTC offset.

Namespaced modules call injected services and contain no SQL or consensus rules. Read the workflow vignette and qualification evidence for reproducible local checks.

testthat::test_local("packages/delphyrApp")

The browser checks run in Chromium against PostgreSQL, the core path also in Firefox; keyboard operation, names, headings, contrast and reflow are checked by script. They do not certify every browser, assistive technology or mobile device. A test with a screen reader, real mail and production operation remain distinct gates. Licensed under MIT.

Use of LLM tools

Where applicable, LLM tools were used for narrowly defined, non-authorial tasks: copyediting, prose refinement, Markdown/LaTeX formatting, boilerplate scaffolding (such as CI configurations and build scripts), and code refactoring. Tools included Chat AI, the KISSKI (GWDG) service, and self-hosted Mistral Small (24B, Apache-2.0) served through a local vLLM architecture on an Ubuntu Linux workstation with Intel processors and NVIDIA GPUs. The self-hosted model ran locally, with no data sent to third parties.

All scientific claims, methodological choices, analyses, interpretations and conclusions remain the authors' own. Where applicable, LLM-generated material must be reviewed and revised before inclusion, and references must be verified against their DOI, arXiv ID or ISBN.

Local software setup: vLLM with Python/PyTorch, plus R and RStudio.