VettedHaul Evidence Pack Spec v1.0

Spec version: 1.0.0 Spec URL: https://vettedhaul.com/specs/evidence-pack/v1.0 Status: draft Last updated: 2026-05-21 Editor: Tom Pinder, VettedHaul (Startvest LLC)

---

What this spec is

The Evidence Pack is the artifact VettedHaul produces for a single carrier vetting event. One artifact per booking decision. The pack is what gets handed to defense counsel the day a demand letter arrives.

This document specifies the structure, content, and admissibility guarantees of that artifact. v1.0 is opinionated and minimal. Later versions extend; they do not remove fields.

Why an opinionated spec instead of customer-by-customer

Schema-by-committee produces ten incompatible packs that no carrier discovery process can compare against each other. A single versioned spec produces packs that defense counsel can read on sight, that insurance underwriters can validate against a checklist, and that opposing counsel cannot dismiss as ad-hoc.

The spec is grounded in three convergent constraints:

1. The Montgomery v. Caribe Transport II standard. State-law

negligent-hiring claims now proceed against brokers on the merits. The merits turn on what the broker checked at the moment of booking and what the broker can produce in discovery.

1. The FMCSA four-check baseline. Safety rating, CSA scores (across

the seven BASIC categories), certificate of insurance, and operating authority status are the four data points FMCSA itself publishes and the four points industry convention treats as the floor.

1. Federal Rules of Evidence 901/902 + 803(6). For the pack to be

admissible as a business record, it must be authenticatable, the custodian must be identifiable, and the record must be made contemporaneously with the event.

Everything in the schema below ties back to one of those three sources.

---

Document anatomy

An Evidence Pack v1.0 is a single logical document with five sections. It is exported as a paired PDF + JSON artifact. The JSON is the canonical form; the PDF is a deterministic render of the JSON.

```

1. Pack Identity (who/what/when of the capture)
2. Subject (the carrier being vetted)
3. Four Checks (rating + CSA + insurance + authority)
4. Decision (the booking action and rationale)
5. Authentication (hash, timestamp, custodian attestation)

```

Optional sixth section for Defender-tier monitoring:

```

1. Continuous Monitoring (delta events post-decision)

```

---

1. Pack Identity

Captures who created the pack, when, and on whose behalf. Required for FRE 803(6) custodian identification.

captured_by object:

2. Subject

The carrier being vetted. Pulled from FMCSA SAFER + the broker's input.

3. Four Checks

The four data captures that satisfy the FMCSA-baseline negligent-hiring defense. Each check carries its own source URL, fetched-at timestamp, and response hash so the underlying data can be re-fetched and re-verified in discovery.

3a. Safety Rating Snapshot

Source: FMCSA SAFER (https://safer.fmcsa.dot.gov).

3b. CSA Scores Snapshot

Source: FMCSA SMS (https://ai.fmcsa.dot.gov/SMS). All seven BASIC categories captured in a single snapshot. A carrier missing any category is still captured with a null percentile and a data_insufficient flag.

Each categories[i] object:

3c. Insurance Snapshot

Two-source check. (1) Carrier-supplied certificate of insurance (parsed PDF) and (2) FMCSA L&I database (insurance on file). Concur or diverge.

A Diverge result is a flag, not a fail. Documentation of the divergence is part of the defense; ignoring the COI in favor of L&I is a separate operational policy.

3d. Operating Authority Snapshot

Source: FMCSA L&I (https://li-public.fmcsa.dot.gov).

4. Decision

What the broker did with the four checks. The decision is the act the litigation will turn on.

5. Authentication

Three layers: hash of the canonical JSON, RFC 3161 trusted timestamp, and a custodian attestation statement. Maps to FRE 901 (authenticity), FRE 902(11)/(12) (self-authenticating business records), and FRE 803(6) (records of regularly conducted activity).

rfc3161_timestamp:

custodian_attestation:

chain_of_custody[i]:

Default custodian attestation text

I, the undersigned, am the custodian of business records for [WORKSPACE_LEGAL_NAME]. The information contained in this Evidence Pack was recorded at or near the time of the events described, by a person with knowledge of those events, in the regular course of the brokerage's vetting activity. Records of this kind are kept in the regular course of business. The Evidence Pack and its constituent data captures have not been altered since the time stamps recorded herein.

6. Continuous Monitoring (Defender tier)

Optional section. Present when the pack covers a load with continuous monitoring through delivery.

Each events[i]:

---

Canonical serialization

The JSON is serialized using RFC 8785 (JSON Canonicalization Scheme):

• Object keys in lexicographic order.
• No insignificant whitespace.
• Numbers as the shortest exact decimal representation.
• UTF-8 throughout.

The canonical_json_hash covers sections 1-4 (and 6 if present), with section 5 hashes computed last so they can reference the prior hashes.

Export envelope

Each Evidence Pack exports as a pair:

• vettedhaul-pack-<pack_id>.json — canonical JSON.
• vettedhaul-pack-<pack_id>.pdf — deterministic PDF render of the JSON.

The PDF includes:

• Cover page: pack ID, capture timestamp, custodian, subject carrier.
• Sections 1-6 rendered in document order with the same table structure.
• A final page reproducing canonical_json_hash, the RFC 3161 token

hash, and a human-readable verification instruction: how to re-hash the JSON and confirm a match.

PDF renderer is versioned (pdf_renderer_version) and the renderer output is deterministic for a given JSON input. Two renders of the same pack at different times produce byte-identical PDFs.

Compatibility, versioning, deprecation

• The spec version follows semver. Field additions are minor (1.x).

Field removals or semantic changes are major (2.x).

• A v1.0 pack is forward-compatible with v1.x readers.
• VettedHaul retains historical renderers so a v1.0 pack rendered today

can be re-rendered byte-identically in 7 years (the retention floor).

• Deprecated fields stay in the schema with a deprecated: true flag in

the spec; they are not removed mid-major.

Open items for v1.1

These are deliberately deferred to keep v1.0 shippable:

• Ed25519 signature (required in v1.1; optional in v1.0).
• Multi-custodian co-attestation (when two parties sign the same pack).
• Schema for TMS-integrated booking references (Defender Pro tier).
• Schema for non-US-domiciled carriers (Mexican, Canadian cross-border).

License

This spec is published under CC-BY 4.0. The schema is freely implementable. Use of the "VettedHaul Evidence Pack" name requires a conformance test pass; non-conforming implementations may use the schema but not the name.

Changelog

• 2026-05-21 - v1.0.0 (draft). Initial publication. Five required

sections + optional Continuous Monitoring. RFC 3161 timestamp required. Ed25519 signature deferred to v1.1.