Egocentric Data Delivery: Transfer, Checksums and Storage

Egocentric data delivery is everything that happens between a clip being recorded and a batch being readable in your storage: upload, integrity checks, validation, packaging, transfer and clean-up. It is part of the service, not an afterthought.

Format pages on this site describe what a delivered file looks like. This page describes how it gets to you and what is stated about storage and retention along the way.

The path has six stated stages. Devices upload to a cloud bucket, checksums are recorded at ingest, data is validated, accepted data is packaged in your format, it is pushed to your storage, and field copies are deleted after acceptance.

The table below sets each stage against what the site states. Where a detail is not stated, it is marked Not stated and agreed in the spec.

Devices upload daily over encrypted transfer, either directly or through a workstation, into a cloud bucket. Files land in per-site folders, so each capture site stays separate from the next.

Daily upload means a program reaches validation quickly, and a problem with a rig or a session shows up within a day, not at the end of a program.

Transport Layer Security is a standard protocol for a secure channel between two endpoints. The version 1.3 specification describes it as designed to prevent eavesdropping, tampering and message forgery.

The site states that uploads are encrypted with TLS. It does not state a TLS version, cipher suite or certificate policy, so those are Not stated.

A checksum is a short digest computed from a file. The NIST secure hash standard describes hash digests as a way to detect whether messages have changed since the digests were generated. A sha256 checksum recorded at ingest gives a later reader something to compare against.

The site states sha256 checksums at ingest. It does not state that checksums are re-verified at delivery or shipped alongside delivered files, so that step is Not stated.

Every batch is validated against signed accept criteria, with a reject log, before it is packaged. A reviewer also confirms the privacy pass, in which faces, plates and screens are detected and irreversibly blurred at ingest.

Rejected items are recaptured at our cost, and billing is per validated hour, so you pay for what passes validation.

Accepted data is packaged in your format: MP4 with JSON or CSV, MCAP, LeRobot or a custom layout. The site also states RLDS, WebDataset, HDF5, zarr and Rerun .rrd. The format table below sets each against what its official documentation states.

Metadata and calibration files travel with the data. The exact field layout inside each format is agreed in the spec.

Data is pushed to your own bucket on S3, GCS or Azure by cross-account transfer. Delivery is rolling, per validated batch, weekly or on the cadence you agree.

Cross-account transfer means the data is written into an account you own, so you control access once it lands. The access rules you apply on your side are yours to set.

For very large drops, data can be sent on encrypted physical drives instead of over the network. This suits a program whose accepted volume is too large to move practically in one transfer.

The drive encryption standard, shipping method and handling steps are Not stated. They are agreed when a drop is planned.

Data is stored in the United States, in an AWS US region. Alternative storage regions are available if required.

The site does not list which alternative regions are available, so that list is Not stated. Ask for the region you need when you scope the program.

Data goes from the collection country directly to United States cloud storage, and then on to your storage. In-region staging is available on request for programs that need data held in the collection region first.

The site does not state a legal basis for transfer between countries on this page. Country pages state the legal basis only where the site has papered it, and the rest is confirmed per engagement.

Field copies are deleted after acceptance. That is the retention rule the site states for the capture devices and the upload path.

Other retention periods, including how long data stays in cloud storage after delivery, are Not stated. The consent pages also state that delivered footage cannot be recalled after delivery, so plan access on your side accordingly.

A pilot reaches its first delivery in two to three weeks, and a standing program reaches full rate in four to six weeks. Those are program milestones. They assume capture coverage is already in place.

Where coverage is deep, the first validated batch of a Spec Pilot lands in a median of 48 hours from signed spec. Thin environments typically take three to four weeks, and that rule still applies there, so we quote it up front.

The site does not state encryption at rest, key management, access controls, audit logs, certifications or compliance attestations for the delivery path. It also states no transfer speed, no checksum re-verification at delivery and no deletion certificate.

If your security or procurement team needs any of these, list them in the request. The table below sets each against its status.

Every episode links to a signed contributor release through a documented consent chain, and the consent record is part of the delivery. Faces, plates and screens are detected and irreversibly blurred at ingest, and the anonymization record ships with the data.

The site states no further privacy rule specific to the delivery path, so this page makes none.

Tell us your target bucket provider, your format, your cadence and any region requirement. We write that into the spec alongside tasks and accept criteria, then quote reach, timeline and price before capture begins.

A Spec Pilot can prove the whole path, from first upload to a batch readable in your bucket, before you scale. Every collection ships under a perpetual, buyer-owned commercial license.