This page explains how Rightlight6 should handle room uploads, temporary storage, and audit session data in plain language.
It should read like a clear product-handling page, not like another symptom route or a vague premium support page.
Privacy priority
Because Rightlight6 depends on room images and short walkthrough videos, the privacy layer has to make retention, deletion timing, and third-party model handling understandable before users trust the audit flow.
Upload scope
Room images and short room videos used to generate the audit output.
Retention
Uploads should be stored only for the minimum period needed to render results and debug failures.
Expectation
Users should understand what is temporary, what is saved, and what is sent to model providers.
What matters here
Rightlight6 only works when the system can read room images or short room videos closely enough to describe daylight reach, glare, layering, and visible comfort overlap. That makes upload handling part of the product, not a side note.
The privacy goal is simple: keep only the minimum data needed to run the audit, show the results page, and inspect failures when something clearly breaks. Anything beyond that should be treated as unnecessary scope creep.
Users should not need to infer whether uploads are temporary, whether results pages stay live, or whether third-party model providers ever see their data. Those boundaries should be visible here and consistent with the product flow.