---
title: "Data Collection Technical Brief for Vendor Diligence"
url: https://ypai.ai/data-collection/technical-brief/
description: "How YPAI collects, checks and delivers data: consent ledger, signed uploads, SHA-256 delivery manifests, EU-jurisdiction storage and per-project controls."
source: "src/copy/routes (route /data-collection/technical-brief/)"
---

# Data collection infrastructure: a technical brief for engineering, security and procurement teams

> How YPAI collects, checks and delivers data: consent ledger, signed uploads, SHA-256 delivery manifests, EU-jurisdiction storage and per-project controls.

This brief documents the architecture, data flows, evidence artefacts, and regulatory mappings of YPAI multimodal data collection infrastructure. It is written for engineering, security, and procurement teams conducting vendor diligence.

## Executive summary

YPAI is a Norwegian limited company (AS) headquartered in Lysaker, Norway. Data resides in the EEA by default; residency, subprocessors and international-transfer controls are defined per project. The platform covers data collection, annotation, validation, and delivery across audio and speech, image, video, text, LiDAR and 3D point clouds, and sensor modalities. The contributor network spans 150+ languages and 50+ countries.

Four structural properties define the platform: Norwegian corporate jurisdiction with per-project transfer controls; a native review console with self-hosted CVAT and Label Studio configured per project; per-contributor consent records whose events are SHA-256 hash-chained, aligned with GDPR Article 7; and a delivery manifest that binds every delivered file to its SHA-256 checksum and its verified consent record.

- In scope: collection, annotation, QA, delivery, retention, compliance evidence.
- Out of scope: customer model training, customer AI system conformity certification, public pricing.
- Audience: ML engineering, data engineering, security architecture, procurement, DPO, CISO.
- Cross-references: linked DPA, GDPR, EU AI Act, and audit sub-pages on ypai.ai.

## Architectural overview

Data flows through five stages: collect, ingest, annotate, QA, deliver. Capture devices upload over HTTPS. Each upload is authorised by a short-lived, HMAC-signed upload token bound to the session, the track and the SHA-256 of every file part. Recordings, QC working copies, signed consent documents and deliveries are stored in Cloudflare R2 buckets configured for the EU jurisdiction. Transport encryption, key management and customer-scoped keys are specified per project in the DPA and security annex.

Annotation runs in the YPAI native review console, with self-hosted CVAT and Label Studio configured per project. QA operates on annotated outputs. The delivery service writes each delivery with a manifest that carries per-file SHA-256 checksums and consent provenance. The transport to the customer, such as SFTP or customer-managed object storage, is agreed per project.

Every stage boundary carries its own control. Operator surfaces sit behind Cloudflare Access and verify its signed assertion on every request, refusing the request when configuration or verification fails. Service-to-service calls authenticate with their own credentials. Consent events are append-only and SHA-256 hash-chained, and review decisions and erasure receipts are append-only records. Every session, track, QC result and delivery file carries its project scope. YPAI is a Norwegian company. Data residency, subprocessors and international-transfer controls are defined per project, and align with GDPR Article 48 by default. See

## Data collection and provenance

Modality coverage spans audio and speech, video, image, LiDAR and 3D point cloud, sensor (radar, IoT, wearables, environmental), and text and NLP. For audio, image and video, YPAI sets the capture parameters, device class, and signal targets in a versioned capture profile before a session begins, and quality control measures every file against that profile. For LiDAR, sensor and text data, the parameters are set in the project capture plan. The reference standards behind a project's targets are named in its QA plan.

Voice data quality is set at capture. YPAI specifies the acoustic environment, the capture hardware, and the signal targets before a session begins. A device check measures noise and speech level before recording starts, and quality control measures SNR, noise floor and clipping on each recording against its capture profile. The default speech profiles target speech between -26 and -18 dBFS. Loudness targets and any normalisation are specified per project in the QA plan.

Every voice project runs on a capture profile with its own signal targets, set at scoping and checked at quality control. The default speech profiles apply to a quiet indoor room; targets for studio, in-cabin and far-field capture are specified per project in the QA plan.

Video data quality is set by sensor capability, frame cadence, and synchronisation. Multi-device sessions record each device's clock offset and timecode anchors at capture, and QC measures the audio-video offset of recorded files against a 40 ms tolerance.

Image data quality is bounded by sensor physics. YPAI sets resolution, format, blur and exposure limits in the capture profile, and the authenticity check routes an image with an invalid content credential, an editing-software tag or missing camera EXIF to human review, so the corpus reflects physical capture.

Every modality runs the same two-layer quality-control pipeline before a file is delivered.

Each delivered file carries its SHA-256 checksum, its session and track identifiers, a participant identifier, its QC result, and a consent record reference. Consent events are appended to a ledger in which each event carries the SHA-256 of the event before it, and the database keeps that ledger append-only. The delivery manifest is emitted at delivery time as a JSON artefact with its own SHA-256.

What ships with every delivery manifest

Per-file SHA-256 checksums, the session and track each file came from, per-file QC verdicts, participant metadata, accepted and participant hours, and for every file its consent record with verified status, verified record integrity and a verified event chain. The customer receives the data-governance artefacts that support its own EU AI Act Article 10 conformity assessment.

## Identity, access, and annotation infrastructure

The YPAI native human-review console is the platform core: review, rubric execution, attribution, adjudication and QA. Leading annotation platforms are configured per project around it. Self-hosted CVAT handles image and video work (bounding box, segmentation, keypoint and polygon); self-hosted Label Studio handles time-series, audio, vector and multimodal work. SAM 3 concept pre-labelling draws a first pass from a text prompt, a human reviewer decides, and the file records which vertices the model drew.

Each customer project is a separate scope. Every session, track, QC result, invitation and delivery file carries its project scope, and database triggers refuse a row whose scope is missing or differs from its parent. Raw uploads and QC outputs are held in separate EU-jurisdiction buckets from the delivered copy.

Operator and reviewer surfaces sit behind Cloudflare Access. Each request is checked against the signed Access assertion, verified against the team signing keys and the application audience, and refused when configuration or verification fails. Consent actions taken by an operator are attributed to the verified operator identity. The identity provider, MFA method and role matrix for a project's annotation environment are specified in the security annex.

The delivery service resolves one project scope for every delivery, and a database trigger independently refuses a delivery file whose scope differs from its batch.

## Quality assurance and evaluation

Human QA is applied according to the agreed acceptance and sampling plan. The project QA plan sets the review method for each task type, such as dual annotation, adjudication and escalation, and the agreement metric that fits the task: Intersection over Union (IoU) for bounding boxes and segmentation, token-level F1 for sequence labelling, and Diarisation Error Rate (DER) for diarisation. For transcripts, the platform scores each sampled item by word and character error rate and accepts or rejects the batch against the plan's acceptance percentage.

Gold sets, reviewer calibration and agreement tracking are defined per project in the QA plan. In the review console, a control reviewer decides files that have already been decided, blind to the first decision, and the review metrics show the agreement between reviewers. Transcript QA flags any annotator whose own error rates exceed the plan's thresholds.

QA artefacts ship with every delivery

The delivery manifest carries each file's QC verdict and review status. The QA evidence set out in the project QA plan carries the sampling method and the per-batch results. The plan's thresholds are acceptance gates for the delivered data.

## Data delivery and retention

Deliveries are assembled in an EU-jurisdiction delivery bucket, and every file is checked against its SHA-256 before the manifest is finalised. The transport to the customer, such as an SFTP endpoint or customer-managed object storage, is agreed per project. Customer-managed keys and private network connectivity are specified per project in the security annex.

Output formats include JSON with a SHA-256 delivery manifest (default), COCO, Pascal VOC, and customer-negotiated custom formats.

Retention follows the contract. Raw uploads and QC outputs are YPAI working copies, held apart from the delivered customer copy, which is retained as delivery evidence. An hourly job processes consent withdrawals, and each outcome writes an append-only erasure receipt with the storage keys deleted. See

A consent withdrawal stops further collection for that participant and runs through the same deleter, with its outcome recorded in an erasure receipt. The 30-day end-of-contract erasure SLA applies when a contract closes.

## Regulatory compliance and auditability

GDPR and EU AI Act Article 10 obligations are addressed by default in every engagement, with a Data Processing Agreement included as standard. Framework-by-framework detail is in the mappings below.

GDPR under Norway and EEA jurisdiction. EU AI Act Article 10 documentation per delivery. EEA residency by default. DORA evidence for financial-sector ICT third-party engagements.

consent records with verified event chains, per-file QC verdicts and provenance, QA results as set out in the project QA plan, and a delivery manifest with SHA-256 checksums. Reviewer-qualification records and annotation-guideline versions ship where the QA plan includes them.

The evidence package is what the customer receives. A customer conducting its own conformity assessment under EU AI Act Article 10 receives the artefacts listed below, mapped framework by framework, with each control named alongside it.

7.1.1 GDPR Article 7 consent record sample

7.2 EU AI Act Article 10

EU AI Act Article 10 mapping

7.5 US CLOUD Act and GDPR Article 48

The US CLOUD Act can compel US-headquartered providers to disclose data they control, wherever it is stored, which can conflict with GDPR Article 48. YPAI is a Norwegian company. The collection platform runs on Cloudflare, a US-headquartered provider, with storage buckets configured for the EU jurisdiction. Data residency, subprocessors and international-transfer controls are defined per project, and SCCs are available for any customer-directed transfer outside the EEA.

## Appendix

C2PA (Coalition for Content Provenance and Authenticity), CER (Character Error Rate), CVAT (Computer Vision Annotation Tool), DER (Diarisation Error Rate), DORA (Digital Operational Resilience Act), DPA (Data Processing Agreement), GDPR (General Data Protection Regulation), HMAC (Hash-based Message Authentication Code), IAA (Inter-Annotator Agreement), IoU (Intersection over Union), QC (Quality Control), R2 (Cloudflare object storage), RPO and RTO (Recovery Point and Recovery Time Objectives), SCCs (Standard Contractual Clauses), SFTP (SSH File Transfer Protocol), SHA-256 (Secure Hash Algorithm, 256-bit), SNR (Signal-to-Noise Ratio), WER (Word Error Rate).

- Controls restated to match the running collection platform; registered office in Lysaker, Norway.
- [EU AI Act Article 10:](https://artificialintelligenceact.eu/article/10/)
- [GDPR Article 7:](https://gdpr-info.eu/art-7-gdpr/)
- [GDPR Article 17:](https://gdpr-info.eu/art-17-gdpr/)
- [GDPR Article 48:](https://gdpr-info.eu/art-48-gdpr/)
- [Standard DPA terms](https://ypai.ai/speech-data/dpa/)
- [GDPR posture detail](https://ypai.ai/speech-data/gdpr-compliant/)
- [EU AI Act detail](https://ypai.ai/speech-data/eu-ai-act-compliant/)
- [Provenance and audit detail](https://ypai.ai/compliance/provenance-audit/)
- [Parent landing page](https://ypai.ai/data-collection/)

Request an audit or DPA execution from the YPAI compliance engineering team

Back to the data collection overview

{ "_comment": "[SAMPLE] abridged: one entry from files[] in a delivery manifest", "fileId": "file_01J9Q7ZK4M", "sha256": "9b1e...4a07", "objectKey": "audio/file_01J9Q7ZK4M.wav", "mediaType": "audio", "sessionId": "ses_01J9Q6X2PA", "trackId": "trk_01J9Q6X9RB", "participantId": "par_01J9Q5W3DE", "participant": { "language": "nb-NO", "dialect": "Bergen", "ageBand": "25-34", "countryCode": "NO" }, "qc": { "verdict": "PASS", "reviewStatus": "approved", "qcVersion": "[SAMPLE]", "processedAt": "2026-09-14T10:22:31.412Z" }, "consentRecordId": "cr_01J9Q5Y8FG", "consentProvenance": { "consentStatus": "active", "consentIntegrity": "verified", "eventChainIntegrity": "verified", "signedAt": "2026-09-12T09:34:18.000Z", "artifactLink": { "manifestId": "mf-2026-q3-ab12", "fileId": "file_01J9Q7ZK4M", "artifactSha256": "9b1e...4a07" } } }

{ "_comment": "[SAMPLE] abridged; signer contact fields omitted", "id": "cr_01J9Q5Y8FG", "agreementVersionLabel": "[SAMPLE] v1.4", "language": "nb", "participantId": "par_01J9Q5W3DE", "templateSha256": "c9d2...e5b8", "signatureSha256": "a3f9...c4d2", "signedPdfSha256": "b8e1...f7a9", "consentScope": { "purposes": ["asr_training", "evaluation"] }, "signedAt": "2026-09-12T09:34:18.000Z", "integrityStatus": "verified", "status": "active", "withdrawnAt": null, "erasedAt": null }

{ "_comment": "[SAMPLE] abridged; each files[] entry follows the structure in section 3.5", "schemaVersion": 1, "scopeId": "[SAMPLE] customer.offering.project", "deliveryBatchId": "ypai-2026-q3-ab12", "manifestId": "mf-2026-q3-ab12", "generatedAt": "2026-09-20T14:05:09.311Z", "contentSha256": "7f2a...e93c", "totals": { "fileCount": 284, "sessionCount": 142, "acceptedSeconds": 511200, "acceptedHours": 142, "participantSeconds": 1022400, "participantHours": 284 }, "acceptedSessions": [ { "sessionId": "ses_01J9Q6X2PA", "acceptedSeconds": 3600, "participantSeconds": 7200, "participantCount": 2 } ], "files": ["[SAMPLE] see section 3.5"] }

# [SAMPLE] Check every delivered file against the SHA-256 in the delivery manifest. # Run from the root of the delivered batch. jq -r '.files[] | "\(.sha256) \(.objectKey)"' manifest.json | sha256sum --check -