Data handling at SubOps

What you get from this page

A precise inventory of the tenant data SubOps ingests, the data it deliberately never ingests, how that data is encrypted and isolated, and our commitments around AI training and audit trails. Bring this page to a security or procurement review and most of the data-flow questions answer themselves.

Why this matters

A typical FedEx Ground contractor business runs on a handful of documents — weekly settlements, fuel receipts, payroll runs, work orders, and the occasional manifest — none of which the operator actually wants to surrender broadly. The trust gradient is real: contractors will hand over a settlement PDF before they hand over portal credentials, and they should never have to hand over the latter. This page tells you exactly where the line sits.

How it works

Data SubOps touches

The settlement-audit workflow needs five document classes. All of them are records the contractor already owns and is already exporting from upstream systems.

Data SubOps does NOT touch

This is the more important list. SubOps does not hold, request, automate against, or proxy any of the following:

• FedEx portal credentials (MyGroundBiz, SPOTlight, VMS, MyBizAccount, FedEx Compass, drivertools).
• Session cookies, OAuth tokens, or scraped sessions from any FedEx-owned property.
• Driver phone-number lists for outbound messaging, payroll bank routing/account numbers, or insurance policy numbers beyond the policy reference itself.
• Personal data on drivers beyond what is necessary to attribute work to a route (name, employment dates, role, route assignments).

See the companion page on no FedEx credentials for the contractor-agreement reasoning behind that line.

Encryption posture

• In transit: TLS 1.2+ on every edge. HSTS preload on the marketing and member surfaces.
• At rest: Managed Postgres 18 encryption at rest (provider-managed keys). Object storage (Spaces, S3-compatible) encrypted at rest. Tenant document uploads are stored with per-object server-side encryption.
• In flight between services: All internal service calls run inside the DigitalOcean private network. Public ingress terminates at Cloudflare and DigitalOcean App Platform; the API and worker tiers are not exposed to the open internet.

Tenant isolation

Tenant isolation is enforced at the database layer via Postgres row-level security (RLS), not only at the application layer. Every row in the settlement, payroll, fuel, work-order, vehicle, and parts tables carries a tenantId, and the RLS policies bind queries to a session-level tenant context set at the start of every request. Cross-tenant reads or writes are rejected by Postgres itself.

No AI training on customer data

SubOps does not train shared models on tenant documents. Concretely:

• AI provider calls route through a single capability seam. The seam selects providers that expose zero-data-retention paths and uses store: false (or equivalent) on every call where the upstream supports it.
• We do not embed tenant documents into shared vector stores. Each tenant's retrieval index is scoped to that tenant.
• Model outputs that touch money are always grounded in a sourceRef to the underlying document; nothing is computed by an LLM in isolation. If you read a dollar figure on the Owner Brief, you can click through to the settlement line that produced it.

Audit trail commitment

Every finding and every dismissal in the Variance Inbox is recorded in a typed audit trail:

• Findings carry a review state and the user who acted on it.
• Dismissals are typed via a structured reason taxonomy, not free text — so "why was this dismissed?" answers itself months later.
• Source references are immutable: a dismissed finding still points back to the exact settlement line that produced it.

This is what makes the workflow defensible to a lender, broker, factoring partner, or auditor. The trail does not disappear when staff turn over.

What you see as an evaluator

• Sample Owner Brief and Variance Inbox screenshots, with no real tenant data, on the public sample-brief route.
• The subprocessor list and trust portal control evidence, under NDA, via the trust portal request flow on the SOC 2 roadmap page.

What the system does on the back end

• Document uploads are scanned for size, type, and basic malformation before they touch the parser.
• Extraction is deterministic where possible (table-locked PDFs, fixed-column CSVs) and routed through the AI seam only for the unstructured edges. Every extracted field has a confidence score; low-confidence extractions are routed to a manual review queue before they reach the Owner Brief.
• Backups are taken nightly on Postgres and Spaces. Point-in-time recovery (PITR) is enabled on the managed database.

Common questions

Do you store the original settlement PDF? Yes, in the tenant's Spaces bucket, encrypted at rest. You can request deletion at any time; deletion cascades to derived findings.

Do you sell aggregate data? No. We do not sell aggregate benchmarks, anonymized cohort data, or any other derivation of tenant data to third parties.

What about data residency? US-East (DigitalOcean NYC region). No cross-region replication today. If you need a specific residency commitment under contract, contact us.

Next steps

• For the full subprocessor list and SOC 2 control evidence, see SOC 2 roadmap.
• For the no-credentials commitment in detail, see No FedEx credentials.
• Procurement teams should request the trust portal NDA before scheduling a security review.