What Is a Source-Linked Evidence Record?
A source-linked evidence record is a collection in which every file, statement, and reported event stays connected to its origin and context. A reviewer should be able to move from a summary entry back to the specific source object, identify who or what supplied it, see which transaction it concerns, and understand what the source can and cannot show.
The goal is not to make several sources look like one continuous account. It is to let the reader inspect the joins between them.
Key points
- A source-linked record keeps every file, statement, and reported event connected to the person or system that supplied it.
- The link should also identify the relevant order, item, parcel, time meaning, original object, and any derivative copy.
- Captured, submitted, reported, and inferred information remain separate even when presented in one chronology.
- Source links improve inspection; they do not make every source accurate or fill unrecorded gaps.
Diagram in words
A source-linked record connects a retained source object to seven inspectable fields: entry identity, source and contributor, transaction relationship, time context, integrity reference, derivative history, and scope or limits. The record leads to a bounded review statement rather than a merged story.
The record is a map, not a merged story
A shipment record may contain an order record, a seller's packing video, a carrier tracking event, a buyer's description, and photographs of a returned item. Those entries can be related without being equivalent.
PackProof recommends preserving four statement types:
| Statement type | Example | Required source label |
|---|---|---|
| Captured observation | A serial label is readable at 00:18 in a video | The original file, contributor, and playback location |
| Participant report | A buyer reports that a corner arrived crushed | The participant and submission record |
| External reported event | A carrier reports delivery at 2:14 p.m. | The carrier record and the time it was retrieved or received |
| Editorial or reviewer inference | Two images appear to show the same labeled unit | The compared entries and the reasoning, labeled as an inference |
Writing “the package was delivered intact” when the available source says only “delivered” removes an important limit. Writing “buyer reports crushed corner” keeps the report attributable. If a photograph also shows a crushed corner, that is a separate captured observation linked to the buyer's submission.
Seven fields make a source link reviewable
There is no universal shipment-evidence schema. The retained source object sits at the center of this PackProof editorial model; seven fields explain how that object belongs in the record.
- Entry identity. Give the object or statement a stable entry ID. A filename alone is weak because filenames can be repeated or renamed.
- Source and contributor. Identify the originating device, service, organization, or participant where known, plus the account or system that submitted the entry. Do not silently equate an account with the person who held a camera.
- Transaction relationship. Connect the entry to the relevant order, item, parcel, tracking reference, or return. Record the basis for the link instead of relying on folder location.
- Time context. Distinguish device-reported capture time, participant-stated time, service receipt time, and external event time. Include the time zone or preserve the offset where available.
- Integrity reference. Identify the hash algorithm and reference digest when used. State which exact source object the value describes and when the reference was created.
- Derivative history. Link every crop, still, preview, export, redaction, or transcription to its retained source object. A thumbnail or copied sentence should lead back to the fuller source.
- Scope and limits. State what the entry covers, what is obscured or missing, and whether the entry is an observation, report, or inference.
Together, these fields answer a practical question: “Why is this entry here, and how can I inspect it?”
A worked shipment example
Imagine order PP-1842 for a phone with a recorded unit identifier. The record contains a seller video, a still image, a carrier event, and a buyer message.
The seller video entry links to the seller submission, order PP-1842, the readable identifier at 00:21, the original video object, its service receipt time, and a SHA-256 reference. Its coverage note says the video ends after the parcel is sealed and does not show carrier handoff.
The still image is not presented as a second original. It is labeled “frame extracted from seller video at 00:21,” linked to that video, and given its own file reference because the still's bytes differ from the source video.
The carrier entry is labeled as a carrier-reported delivery event and linked to the parcel's tracking reference. It is not described as an inspection of the contents.
The buyer message is linked to the buyer submission and service receipt time. If it says “different phone received,” the record preserves that as a report. A reviewer can then compare any buyer-supplied identifier image with the outbound source. A match, visible difference, unreadable view, or missing view is recorded without silently converting the comparison into a conclusion about responsibility.
The entries form one review package, but their origins remain visible.
Keep evidence time separate from event time
A source-linked record usually contains at least two chronologies.
The event chronology concerns the shipment: packing, label creation, carrier acceptance, delivery, receipt, or return. The evidence chronology concerns the record: file creation as reported by a device, upload, system receipt, hash calculation, import, export, and reviewer annotation.
The two can overlap, but they should not be collapsed. A video uploaded on Tuesday may carry a Monday device timestamp. The service can directly support Tuesday receipt; the Monday value may be device-reported metadata. That difference can be routine, especially after offline capture, but the labels matter.
If the source does not establish when a physical event occurred, say so. Ordering entries by upload time does not create an authoritative history of the parcel.
Link derivatives without losing the original
Review often requires convenient versions: a compressed preview, a redacted label, a transcript, a frame at a relevant moment, or a PDF index. Each derivative should identify:
- the source object from which it was made;
- the transformation, such as crop, redaction, transcoding, or transcription;
- who or what created it and when the system received it;
- its own integrity reference where relevant; and
- any information omitted or changed for presentation.
This relationship prevents a polished excerpt from replacing its context. A transcript can help search and review, but it may contain errors. A redacted image can protect private information, but it should not be treated as byte-identical to the restricted original.
Use the source link during review
A reviewer can apply a short inspection sequence:
- Define the question, such as “Which unit was visibly packed?”
- Locate the entries that could address it.
- Open the source object rather than relying only on the summary.
- Confirm the order, item, parcel, and contributor links.
- Interpret each timestamp according to its stated source.
- Verify the file against its recorded reference when integrity checking is relevant.
- Record the answer and the remaining gap separately.
The reviewable dispute record framework applies the same discipline across order, seller, carrier, and buyer sources. The damage-claim source model shows why physical packaging and value documents need their own lanes.
What a source link does not establish
Attribution improves traceability, not truth by declaration. A source-linked record does not automatically establish that:
- a participant's statement is accurate;
- a device clock was correct;
- the camera showed everything relevant;
- a retained file was unchanged before the first integrity reference was created;
- a carrier event describes parcel contents;
- two visually similar items are the same physical unit; or
- a marketplace, carrier, insurer, court, or other reviewer will accept the material.
The W3C's PROV-O Recommendation provides a formal vocabulary for describing provenance relationships among entities, activities, and agents. A commerce record does not need to implement PROV-O to use the underlying discipline: identify the object, activity, and responsible source rather than hiding them in one narrative.
NIST's Digital Evidence Preservation guidance discusses documenting an original source and how a file was created or transferred, along with integrity and storage controls. That publication is written for evidence handlers; it does not certify PackProof or make its law-enforcement practices a universal commerce requirement.
Source links are most useful when they make disagreement and uncertainty easier to inspect. A record should show how its parts connect while leaving each source's boundary intact. For file-level integrity, continue with how SHA-256 helps detect file changes and the broader guide to digital shipment evidence trustworthiness.
Sources
Technical sources reviewed October 24, 2026. The seven-field model, statement types, review sequence, and shipment example are PackProof editorial frameworks.
See the record in context.
Explore how PackProof connects the order, available evidence, and shipping activity.
See the reviewer workflow →