How can you report a research-workspace problem without sharing private research?

Report a behavior rather than an entire workspace

A useful report lets another person understand the gap between an expectation and an observation. Start with one sentence for each. Then add the sequence that produced the gap, the visible message, and whether the behavior repeated. An entire private conversation often contains more sensitive context while making the actual issue harder to locate.

Thesis Lab’s current feedback path is a deliberate disclosure: the user enters and previews the text to share with the team. Private chats, strategy identifiers, results and browser files are not automatically attached. Saved-research encryption does not make text you intentionally send as feedback private from the support recipient.

An original synthetic report format

Consider this invented example, not an observed product defect: Task: save a practice principle saying every claim needs a dated source. Steps: enter that invented sentence, inspect the interpretation, approve the version, then reopen it. Expected: the saved wording matches the approved wording. Observed in this fictional example: one sentence differs. The example illustrates report structure; it does not claim that this bug exists.

Add only an actually observed date and timezone, a general browser and operating-system version if relevant, and the exact non-sensitive error text. If you have not reproduced the problem, say so. Keep a hypothesis such as a synchronization conflict separate from the observation that the text differed.

Replace the input without changing the relevant behavior

Try to reduce the issue to a practice sentence, an invented company or another harmless input. Record which detail matters: punctuation, sentence length, an unresolved question, or a particular button sequence. Do not assume the simplified example reproduces the original issue; verify it, or label it as an untested candidate reproduction.

When simplification changes the outcome, that is useful information. Report that the issue appeared only with the original private input, without automatically sharing that input. A later request for additional material needs a specific purpose and a deliberate disclosure decision. A support request is not blanket consent to collect everything in the workspace.

Preview text, links and images before sending

Remove passwords, API keys, session tokens, recovery keys and invitation codes. Check links for secrets in their query or fragment. If a screenshot is necessary, prepare a synthetic screen where possible and inspect the whole image for names, account details and unrelated private content. Do not assume a crop or casual visual blur has removed every identifying detail.

OWASP’s logging guidance provides a useful supporting principle: secrets and sensitive personal or commercial data require exclusion or protection. This guide applies that minimization idea to a manually prepared report; it does not claim that a feedback message is a security log or that sending a report establishes legal compliance.

Method, sources, and limits

The report template is original and entirely hypothetical. The released feedback boundaries and OWASP source were checked on 26 October 2026. No customer text, screenshot, account record or actual report was collected or submitted. A clear report can help investigation; it does not prove the cause, promise a fix or establish that a private defect was reproduced.