Chemical Safety Assistant

Appearance

ADR-0065: The Boot Splash exists, and what may appear on it is a closed set ​

Status: Accepted Date: 2026-09-20

Decisions ​

D-141 The Boot Splash exists, and what may appear on it is a closed set ​

It MAY carry, and nothing else:

  • the product's own name, Thai first, with its English name beside it;
  • the ground colour;
  • one non-interactive mark;
  • the one line saying the app works offline and needs no account — not the Standing Statement, which this screen does not carry.

It MAY NOT carry, ever:

  • a spinner, dots, a progress bar or a percentage;
  • any account affordance, including "sign in", "continue as guest" and "skip";
  • a version string, a build id or third-party branding;
  • anything tappable at all.

Adding a member to that set is a change to this ruling, not a feature.

Context ​

The root component rendered nothing while the startup verification the Corpus-unavailable ruling requires (D-73) was running, so a cold start was a white frame of indeterminate length.

The closed set is the operative part of this ADR, not the splash. A splash is the screen where both a loading animation and a sign-in button arrive later, each one arriving as a small obvious improvement nobody thought needed a ruling. Only a closed set refuses them. This mirrors the closed act set the curated-escalation ruling (D-95) draws for the same reason.

The no-spinner member carries the reasoning of the offline ruling (D-06) and the Not Stated ruling (D-03): a safety application that teaches people to wait for an animation has taught the wrong habit, and the habit starts on the first screen there is. The no-account member carries the no-accounts rulings (D-60, D-61) forward onto a surface that predates the router, where an account affordance would otherwise be nobody's responsibility to refuse.

Decision ​

The application renders a Boot Splash while startup verification runs, and what may appear on it is the closed set declared above.

Rejected options ​

  • No splash; paint the boot ground in the HTML entry document and render nothing — rejected because a blank dark screen for a few hundred milliseconds on a slow floor tablet is indistinguishable from a crash, and nobody can tell you afterwards which one they saw.
  • A splash that states what it is doing in words — rejected for the same reason the spinner is: it is a loading status, and this is the screen where that habit would start.

This ruling may not be re-decided ​

If a change contradicts this ADR: stop and raise it. Do not implement over it.

Specifically: do not add a spinner, a progress indicator or a status line "just while we debug the slow start", do not put an account affordance here because the router has none, and do not treat the MAY list as examples. It is the whole set.

Consequences ​

What becomes true. A cold start looks like the product starting rather than like a crash, and the first screen of the application teaches nothing the product does not mean to teach. A reviewer has one list to check a change against rather than a judgement to make.

What this costs. A slow start now looks identical to a fast one, so a genuinely stuck start is indistinguishable from a working one on the screen itself — deliberate, and the price of not teaching the wait. Every future addition to this screen costs an ADR.

What is closed off. Any loading affordance, any account affordance, and any interaction at all on this surface.

Coverage ​

No upstream finding lands here. The ruling came from adversarial review of the cold-start path and from internal consistency with D-03, D-06, D-60, D-61 and the closed-set form of D-95 (D-104).