Skip to content

Understand the data journey before you upload

Understand scan-data categories, responsible uploads, user choices and where to find the governing privacy policy.

Start with a repeatable baseline
Browse the complete Tutorials

Understand the data journey before you upload

ASCAND helps you record an object from a structured rotating view. 3D-Scan.Online processes the material you submit and produces project results that you can review and download.

That workflow begins with a practical privacy decision: does the material contain only what is needed for the scan, and do you have authority to process and use it for the intended purpose?

This page explains how to review a scan-data workflow, minimize unnecessary material and find the correct policy or request route. It is not the governing privacy policy and it is not legal advice. Current commitments about personal data, purposes, legal bases, recipients, retention, deletion, international transfers, security and user rights must come from the verified privacy policy and actual service operation.

Before uploading:

  1. inspect the complete recording, not only one representative frame;
  2. remove or avoid unrelated people, documents, screens, labels and surroundings;
  3. confirm that you may capture, upload and use the object and resulting files; and
  4. read the current governing privacy information when your decision depends on policy.

Follow the scan data through the workflow

A scan project can involve several distinct stages:

  1. Local capture: A video or other source material is created on the recording device.
  2. Selection and review: You choose the intended source and check what appears throughout it.
  3. Browser upload: The selected material is transferred to 3D-Scan.Online for the requested workflow.
  4. Processing: The platform and processing system use the submitted material to create project results.
  5. Review and download: You inspect the available result and download the representation needed for the next task.
  6. Optional sharing: You may later share a source, screenshot, model or diagnostic extract with collaborators, Support or a public audience.

These stages form a data lineage, but they do not all have the same purpose or audience. A source recording may contain background context that does not appear in a final model. A screenshot may expose an account or project reference that is absent from an exported mesh. A support bundle may combine several items that were previously separate.

Technical descriptions of upload and processing explain how a result is created. They do not by themselves establish who may access the material, how long it is retained, when copies are deleted or which legal terms apply. Use current Platform Documentation for operating instructions and the governing privacy information for policy commitments.

Know what your project may contain

Review the project by category rather than treating “scan data” as one file:

  • Account and contact context: Information used to reach the service, communicate about an account or route a request.
  • Source capture material: The video, images or other evidence submitted for processing.
  • Project context and identifiers: Names, timestamps, references, settings or other information that connects a source to a project and result.
  • Generated results: Previews, point clouds, meshes, textures, reports or other outputs created from the submitted evidence.
  • Derived material: Converted, repaired, merged, annotated or re-exported models, screenshots and physical reproductions.
  • Support evidence: Messages, screenshots, source extracts or result files supplied to explain a specific problem.

The source may also contain information that was not intended as project content: a person entering the frame, a name on a label, a document in the background, a visible computer screen, location clues or a confidential prototype. An object itself can also reveal personal, cultural, commercial or security-sensitive information.

Whether any item is personal data or subject to another restriction depends on its content, context and governing rules. Do not rely on the file extension or the fact that the final output is “only a 3D model.”

Upload only what the scan requires

Use this pre-upload review:

  • Subject: Is the intended object the only relevant subject throughout the source?
  • People: Are faces, voices, bodies, names or other identifying details present?
  • Surroundings: Are documents, screens, addresses, labels, access points or confidential work visible?
  • Object authority: May the object be handled, recorded and uploaded for this purpose?
  • Result authority: May the resulting representation be reviewed, downloaded, modified, shared or published as intended?
  • Account and device: Are you using the appropriate account, device and institutional route?
  • Source integrity: Have you preserved the original source needed for your own project record or troubleshooting?
  • Policy: Have you checked the current privacy information for any question that depends on service commitments?

If the recording contains unnecessary context, consider a controlled recapture with cleaner framing or surroundings. Cropping may help in some workflows, but it can also remove evidence needed for structured processing. Follow the applicable capture instructions rather than editing the source blindly.

Pause before uploading when authority, privacy, confidentiality, cultural sensitivity, participant safeguards or downstream rights are unresolved. Technical ability to process a recording is not approval to do so.

Treat results and derivatives as separate data objects

One source can lead to several related objects:

  • a project preview;
  • a point cloud;
  • a surface mesh;
  • texture or material assets;
  • a converted export;
  • a repaired or merged derivative;
  • a screenshot or rendered image; and
  • a 3D-printed or otherwise manufactured reproduction.

Each can contain a different subset or transformation of the original evidence. A mesh may preserve recognizable shape. A texture can retain visual detail. A screenshot can include interface context. A physical reproduction can make the captured form accessible outside the original digital system.

Keep the lineage clear: identify the source, project, result type and transformations that belong together. This improves both responsible handling and technical diagnosis.

Downloading, converting, repairing or merging a model does not settle who may access it or how it may be used. A technically successful export is not permission to publish, reproduce or commercialize the object. Review the rights and privacy conditions for the intended downstream use separately.

Share project material deliberately

Before giving another person or system access, define:

  • recipient: who needs the material;
  • purpose: what they need to do with it;
  • minimum evidence: which file, extract or view is sufficient;
  • permission: whether you may share the object, source, result and embedded context;
  • duration and withdrawal: what your own organization or agreement requires; and
  • next use: whether the recipient may only inspect, or may also modify, publish or redistribute.

For Support, begin with a privacy-cleared description of the goal, workflow stage and observable symptom. Do not send passwords, authentication codes, payment-card data, session information or an entire project archive by default. Redact unrelated names, account details and project references. Share source or result files only through a verified route and only when they are necessary and permitted.

For education, review participant information, supervision, device and account use before capture. For museums and institutions, object authority, conservation, cultural conditions, confidentiality, source-data governance and publication rights may all require separate review.

Technical access is not the same as permission. Possessing an object, a recording or a generated model does not automatically establish every right to process, adapt, share or reproduce it.

Use the verified policy and request route

The current governing privacy policy—not this explanatory page—should identify the verified legal and operational information that applies, which may include:

  • the responsible organization and contact route;
  • the purposes and legal bases for processing;
  • relevant data categories;
  • recipients or service providers;
  • international-transfer information;
  • retention criteria;
  • applicable rights and how to exercise them; and
  • complaint or supervisory-authority information.

Do not infer these commitments from a technical diagram, an old interface, an internal engineering document or a previous support reply.

If you have a privacy or scan-data question, make it specific:

My question concerns [account information / source capture / project result / support evidence]. The relevant project or contact context is [privacy-safe reference]. I need verified information about [purpose / access / retention / deletion / correction / another stated right].

Do not send authentication secrets or unnecessary project material to establish the question. The verified route may need to confirm identity or request further information, but this page does not prescribe that process or promise a response or deletion time.

[Read the current Privacy Policy — verify destination before publication]

Contact Support

Check the complete data route before institutional use

Schools, museums and other organizations should record the complete route before asking participants or staff to upload:

  1. Authority: Who has authority to approve the activity and the intended use?
  2. Object: What is being captured, and what restrictions apply?
  3. Participants: Who may appear or be identifiable in the source?
  4. Device and account: Which approved device, browser and account route will be used?
  5. Source review: Who checks the complete capture before upload?
  6. Processing route: Is the current platform route acceptable under the organization’s requirements?
  7. Access: Who may access sources, projects, results and support evidence?
  8. Information lifecycle: What retention, deletion, replacement or withdrawal requirements must be satisfied and verified?
  9. Result use: May the model be taught with, displayed, modified, published, distributed or reproduced?
  10. Escalation: Which unresolved privacy, security, safeguarding, rights or policy question stops the activity?

Do not describe ASCAND or 3D-Scan.Online as institutionally compliant merely because the workflow is technically suitable. Compliance and approval depend on the current service terms, actual implementation, participants, purpose, jurisdiction and the organization’s own requirements.

If any essential part of the route remains unresolved, pause the upload and use the current policy or Contact Support to obtain the missing verified information.Use this page when published guidance does not resolve a question about an ASCAND product, your configuration, 3D-Scan.Online access, an order or a technical problem.