If a bank, law firm, or audit team approved one SuprFlow version, that approval describes that build and configuration. An update can change a model, formatter, clipboard behavior, telemetry, or permission prompt even if the app still opens normally. Keep a small synthetic test pack so the next release can be checked without dictating client information.
SuprFlow uses Sparkle for updates. Sparkle's documentation describes signed update archives and an appcast; that protects the delivery path when configured correctly. It does not attest to how a new app version handles data. Start by recording the installed version, signer, hash or package identifier, release notes, update source, and the previous approved version. The deployment checklist covers the first rollout.
Run the same six checks each time
| Check | Synthetic test and evidence |
|---|---|
| Model and microphone | Dictate a fictional sentence and verify active model, language, input device, and output. |
| Formatter and endpoint | Confirm Default, Cloud API, or Ollama selection, resolved endpoint, and whether staff can change it. |
| Network and telemetry | Observe requests during launch, recording, formatting, an error, and update check; compare categories and parameters with the prior build. |
| Clipboard and history | Check paste, third-party clipboard capture, raw/cleaned/formatted history, delete, and backup policy. |
| Destination | Insert into the actual approved browser form, CRM, mail client, or document; verify focus and final record. |
| License and outage | Restart briefly offline and record any activation prompt or altered feature access. |
Use a unique marker such as “Harbor 274 did not approve the transfer” to expose a changed negation or number. Log expected, observed, pass/fail, evidence, reviewer, and date. A host-only HTTPS trace can reveal destinations but not prove a payload is absent; combine it with source, instrumentation, provider account logs, and release documentation where the risk warrants it. The signed-release test guide gives a fuller method.
Decide whether the update needs a new approval
Escalate if a new endpoint appears, a local mode becomes cloud-capable, telemetry fields expand, history retention changes, the default formatter changes, or the app no longer respects your managed policy. A visual feature update with no observed data-route change still needs the ordinary functionality test, but may be a smaller review. Assign the decision to the firm's product/security owner and record it; do not imply SuprFlow has a built-in central policy lock if that has not been shown.
Questions people ask
Does an update's valid signature mean privacy settings are unchanged?
No. A signature helps verify the update artifact and publisher. The app's data handling still needs to be checked against the approved baseline.
Can we use real client notes to test an update?
Use fictional text for the repeatable route and accuracy checks. Only move to real confidential material after the firm approves the new build and workflow.
How often should a firm repeat this checklist?
At every material app or policy change, and whenever a newly approved formatter, endpoint, or destination changes the data route. The firm can set a shorter routine check for minor releases based on its own risk process.
Related guides
- Verify privacy claims in a signed release
- Can local formatting be enforced?
- What lifetime updates cover
- Bank dictation vendor checklist