Local storage is only one part of a privacy review
A birth profile saved on a computer can still become part of a request sent to a model provider. A session can stay in a local folder while a screenshot of it reaches a public forum. When reviewing privacy in a reading application, follow the information through each step of the task.
The inspected Mystilink desktop repository documents birth profiles as local JSON files under the project root's .mystilink/profiles/ directory. It also documents profile references that resolve stored data into a snapshot for user context. Those two details describe different stages: where a profile is stored and how selected information can enter a conversation.
This article offers a review procedure. It does not establish a published privacy policy, a retention guarantee, or the behavior of every released build. Use the application's current disclosures and the provider's terms when deciding whether to submit real personal information.
Draw the route before adding personal data
Use a fictional profile for the first review. Write down where you enter it, where the application saves it, and what happens when you reference it in a message. You need a concrete answer to a simple question: which fields reach the model for this request?
A birth profile can contain more information than the present task requires. A discussion about how a profile form works may need no birth data at all. A calculation exercise might need selected date and location fields while having no use for a person's name or relationship notes. Reducing the input is often the easiest privacy decision available to the reader.
A local path by itself gives no answer about encryption, operating-system access, backups, or sync software. If a folder is included in a cloud backup, review that backup separately. If several people share the computer or account, review access there too. Avoid inferring protections from a folder name.
Check the request route
The platform's inspected desktop integration document distinguishes an account-authenticated Newton gateway route from direct-provider BYOK requests. The gateway uses an account JWT. BYOK means the client uses a user-supplied provider key for a direct provider connection, according to that document.
These routes have different parties involved, so identify the selected route before sending a profile. A provider name or model label alone may be insufficient to tell you which connection is active. Consult the current connection settings and relevant documentation. Never paste an access token or provider key into a forum post to demonstrate the setup.
For a meaningful review, separate the content of a model request from account authentication. A token authorizes a request; it should not become part of the reading itself. If you capture network evidence during a developer review, redact credentials before saving or sharing it. A content writer generally needs a description of the route, not raw traffic containing secrets.
Review diagnostics as a separate channel
The inspected privacyLevel.ts defines strict, balanced, and diagnostic levels. Strict disables remote diagnostic reporting through its environment override. Diagnostic enables that reporting through the same override. Balanced falls back to whether the saved diagnostics setting is explicitly enabled.
This is a narrow statement about the diagnostic decision in that file. It does not imply that strict mode disables model requests or every possible network connection. A reader may still deliberately submit a message to a remote model. Explain these controls using the activity they govern so that a setting name does not become a broader promise.
The same file checks whether a diagnostics consent prompt has already been asked. A check for that state does not demonstrate the complete wording, timing, or consent behavior of a released interface. If you are evaluating a build, record what the screen actually shows and whether an environment setting overrides it.
Look beyond the application window
Privacy reviews often stop after a message is sent. Continue through saved transcripts, support attachments, and exported notes. A harmless-looking excerpt may include an identifying date, family relationship, or place name in surrounding text. Review the whole shared artifact before posting it.
For a public bug report, replace the person and birth details with a fictional profile that reproduces the issue. If the problem disappears after replacing a field, report that relationship without exposing the original value. A private support channel is still a transfer of information; include only what the recipient needs to investigate.
Deletion also needs a specific object. Removing a profile from an application's list, deleting its local file, deleting a session, and requesting deletion from a remote service are different operations. Verify the current product's documented behavior for each relevant store. Do not assume one delete action reaches every copy.
Keep a short review record
Record the build, connection route, diagnostic configuration, and fictional test used. Add unanswered questions with the party responsible for answering them. For example, the application maintainer can explain which context fields are assembled, while the selected provider's published terms address its handling of received requests.
Revisit this record when changing providers, enabling diagnostics, or moving a project folder into a sync service. A practical privacy review stays close to actual actions. It gives the reader enough information to decide what to enter, what to omit, and where another check is needed.