Data handling policy

How we handle data inside Pvalue Analytics QYNA

This page is our plain-language communication to QYNA users. It explains how we treat submitted data during analysis, what our retention posture is, where user responsibility still matters, and what you should assume when working with client, company, or research data in the platform.

Plain-language explanationMinimal-retention postureBuilt for analysis, not storage

Core posture

QYNA is designed for processing work

We built the platform to help you analyse, transform, interpret, and export data for decision-making — not to act as a long-term data warehouse.

What you should assume

Submitted data should be treated as task-bound

When you upload or paste data, you should assume it is being handled for the analytical workflow you triggered, not for unrelated reuse.

What still matters

User judgement remains important

Good governance still depends on what you choose to upload, how you prepare it, and whether your internal rules allow that data to be used here.

What this policy means in practical terms

We want users to understand our operating posture without hunting through dense legal wording. The basic principle is simple: we use data for the analytical work you ask us to perform, and we do not position QYNA as a persistent storage destination.

Why this page exists

Many data-handling pages are technically correct but hard to read. We want this one to be usable. So this page explains our product posture in direct language: what happens when data enters the platform, what our retention philosophy is, and how responsibility is shared between QYNA and the user.

The working assumptions

QYNA is intended for analysis, computation, interpretation, and export workflows.
We do not frame the platform as a long-term repository for your raw or client data.
The fact that a tool can process data does not remove the need for your own governance checks.

How data is handled during use

Depending on the tool, data may be uploaded, pasted, mapped, transformed, visualised, scored, modelled, or exported. Processing remains tied to the task you initiated.

Typical workflow stages

Input stage: you upload files, paste data, or enter values into a tool.
Processing stage: the tool maps fields, computes outputs, and generates analysis artefacts.
Output stage: results are shown to you for interpretation, download, or export.

Why this matters

People often assume all digital platforms handle data in the same way. They do not. Our intention is to support analytical execution, not to create an evergreen stored copy of every file that enters the system. That distinction matters when you decide what data should or should not be uploaded.

Our retention approach is intentionally minimal

We follow a minimal-retention philosophy in QYNA. Data submitted to the platform is intended for immediate analysis use rather than durable storage. In plain terms: our product is meant to help you work with data, not keep it indefinitely for you.

Retention posture

We do not position QYNA as an archival system. We do not want users to treat it as a place for long-term safekeeping of source files or sensitive datasets. The platform is built to support active analytical work and related outputs, not indefinite repository use.

How users should interpret this

Do not treat QYNA as your permanent source-of-truth store.
Do not assume submitted material remains available for unrelated future use.
Use your own governed systems for durable storage, access control, and records management.

The trust principles behind how we think about data

Our product posture is built around need-based handling, limited reuse assumptions, and practical caution. We want users to feel confident using QYNA, but we also want that confidence to be grounded in realistic expectations.

Principles we design around

Need-based handling: use what is required for the requested analytical task.
Limited reuse posture: do not assume submitted data is meant for unrelated downstream uses.
User visibility: outputs should be understandable enough for a user to review before acting.

Why realistic trust matters

Trust is stronger when expectations are clear. Over-promising creates confusion later. So we would rather communicate a precise and practical posture than use vague statements that sound reassuring but do not help users make better decisions about sensitive or business-critical data.

What users should still do on their side

QYNA can support disciplined use, but it cannot replace your own judgement, approvals, contracts, or data governance rules. Good data handling is always shared between platform design and user behaviour.

What we expect from users

Upload only the data needed for the task at hand.
Mask, anonymise, or remove identifiers when analytically possible.
Check whether client contracts, company policies, or sector rules allow this usage.
Review outputs before sharing them externally or using them in business decisions.

Why this section matters

The same platform can be used safely by one team and carelessly by another depending on what is uploaded and how outputs are interpreted. That is why we state this clearly: platform safety and user discipline have to work together.

Pvalue Analytics QYNA · Clear platform communication for users