This page records what was checked, how to repeat it, and what was not. All checks ran on synthetic data in the local development environment. They are design and regression checks of this software, not a penetration test and not the qualification of a production deployment.

The rows follow the check matrix of the specification (chapter 16). "PostgreSQL" means the opt-in contract tests of scripts/integration.R; "Chromium" means a real browser against the application under the restricted database role.

The real gateway run is the local Keycloak, OAuth2 Proxy and nginx chain with the directly served application, with one, two and three application processes. It was repeated with the current sources on 3 October 2026; all of its checks passed. It also covers the acceptance of an invitation by the invited account only, the lifetime of an identity and of the gateway session, and signing out; see authentication. Stock Shiny Server OSS drops the identity headers and stays unqualified.

A complete synthetic study is conducted with a marked value in every sensitive field: free-text answers, contact address, name and external reference, the invitation token, the gateway secret, the account subject, original and redacted texts, campaign text, study information, item text, rationales and a database password. The run includes refused and failed operations: a wrong gateway secret, a wrong and a malformed token, an invalid and an outdated answer, a message adapter that fails with the address in its error text, one that refuses with the address in its reason, and a statement the database refuses. The marked values are then searched for in five places:

The server log check reads the log of the database container. Its control runs one refused statement twice: the owner role's failing row is logged with its values, which proves that the live log is read; the application role's is not. Where the log cannot be read the check reports itself as not executed.

In the browser run, the standard error output of both application processes is searched for marked text, contact addresses, study and account identifiers.

Every service call of the application, every job and every message leaves one JSON line on standard error:

{"time":"2026-10-02T17:52:52.006Z","level":"warning","correlation_id":"dc8e1fe1f892","component":"app","operation":"save_response","duration_ms":75,"outcome":"refused","error_class":"DEL_ROUND_CLOSED","error_path":"round"}

Arguments, results, condition messages, request headers, study and account identifiers are never written. A value that does not have the fixed shape of its field is replaced by withheld.

options(delphyr.log_level = ) or DELPHYR_LOG_LEVEL selects off, error, warning (default) or info. options(delphyr.log_sink = function(line) ...) routes the lines elsewhere; a failing destination never changes the outcome of an operation.

A failure message in the interface ends with Reference: and the correlation ID of its entry. A background operation that did not succeed quotes its operation ID, which the worker's entry carries as reference. A person can quote the reference; the operator finds the operation, time and condition class, and nothing about the content.

PostgreSQL writes the values of a failing row, of a duplicate key and of bound parameters into the detail lines of its log. The application role therefore needs

ALTER ROLE delphyr_runtime SET log_error_verbosity = 'terse';

which scripts/configure-dev-role.R sets. With it the log names the refused statement with placeholders and the violated constraint, without detail lines, also when statement logging is switched on.

One thing remains: PostgreSQL quotes a value it cannot convert to the type of its column in the first line of the error, which terse does not remove. The services therefore check identifiers, numbers and times before any statement: the identifier check above covers every identifier argument of every service. An owner or migration session logs with details; it handles no participant input.

Three services accepted a rationale of any length and one bound an unchecked code to a statement before the checks of 2 October 2026; the central limit and the test over all services close this.

A rendered report shows study text as text only. Until 2 October 2026 the report templates wrote table cells where the renderer still interpreted Markdown: a study text such as [label](javascript:…) became an active link and ![x](http://…) an image that the renderer fetched while building the report. Angle brackets were already escaped, so no script element could be written. The templates now write every table, list and block as final markup that the renderer passes through unchanged, and escape the characters that could end such a block or start a shortcode. Reports rendered before that date from untrusted text should be rendered again.

• No penetration test, dependency audit or review by a security team.
• No production deployment: TLS, security headers, rate limits, secret management and network separation belong to the hosting qualification.
• Protection against a database administrator or host administrator is out of scope; the audit trail is append-only for the application role only.
• Availability under hostile load was not examined.