Upload
What It Is
An upload is the recorded delivery of a file that later work can use as input. It gives staff and integrations a durable reference to the file independently of the machine or browser that supplied it. A spreadsheet, migration manifest or dataset can each have an upload session. Finishing that session makes input available; it does not itself create contacts or run an import.
The client declares the file’s identity and size before sending its parts directly to storage. Rhythm coordinates that conversation and records the assembled version. Part receipts let the client establish what arrived and continue an interrupted transfer. The session’s identity is separate from the file name, so staff do not have to treat a name alone as proof of which input a job read.
What It Is Not
A contact photo and a custom document value belong to record-file handling, even when an import eventually supplies them. An upload here is job input rather than a saved record detail. It is also different from an export produced for download. Its completed state proves that the delivery protocol settled, not that the file’s records satisfy their domain rules.
How It Is Used
Administrators provide files through the job wizard. Integrations and implementation runners drive the upload conversation through the API. Migration staff upload manifests and datasets before registering their coordinated load.
Good use retains the session reference and inspects completion evidence before submission. A declared digest improves the available integrity information, but callers must distinguish a producer’s declaration from a measurement of stored bytes. A file that can be uploaded may still use a format the chosen record operation cannot read. That incompatibility needs attention at job submission rather than an assumption that completed delivery means valid input.
Its Facets
Session condition. This tells a caller whether parts can still arrive, a file is available or delivery has been abandoned. Settled input is kept distinct from an unfinished transfer.
Multipart delivery. Parts separate network transfer from record processing. The client can recover received-part information and request new signed destinations without recreating the intended file input.
Declared and stored evidence. The declared size and digest are claims from the client. Stored size and version identify what arrived. Verified digest evidence is available only where the completion implementation can establish it.
Input format. Content type describes storage input, while the job’s supported parser determines whether that input can become records.
Storage lifetime. Retention affects reuse of old input and cleanup of unfinished transfers. A kept job reference is not a promise that its source file will remain available indefinitely.
How It Relates
Data jobs read completed uploads by their recorded versions. Migration runs compare package declarations against dataset evidence during registration. Reset preserves input that staff may need for another load, while workspace deletion follows a different cleanup contract. The upload therefore supports processing and recovery without owning the resulting domain records.
What It Could Become
Product must decide how large-file digest verification becomes dependable. Archive extraction and richer retention visibility are further open edges. Recovery after a storage-first completion crash also needs examination: commentary describes retry recovery that the inspected completion branch does not establish. Future improvements should make delivery evidence stronger without confusing it with record validation.