Written for the Director of Solutions / Client Onboarding — the seat that answers the RFP, prices the tender, and inherits, on every win, the question the operation has never had a clean answer to: how does one building truthfully belong to twelve clients at once?
The multi-tenant tension is structural, not operational. One dock, one shift, one reach truck — and N confidentiality boundaries with N audit rights layered over them. Client A's contract entitles their auditor to a complete custody record of Client A's freight. Client B's contract promises Client B that nothing of theirs is visible to anyone else. Both promises attach to the same physical hour of the same physical dock, worked by the same crew.
The industry's standing answer is double-keeping: per-client WMS integrations, per-client portals, per-client exports — the operation recorded N times, once per contractual lens. Your solutions team prices that tax into every bid, your IT team maintains it forever, and every reconciliation between the copies is a small argument waiting for an audit to find it.
One record, N grants
The architecture that retires double-keeping records the operation once — every receipt, putaway, pick, and cross-dock handoff captured as events, each carrying the attested observer who performed it and the warrantor account standing behind the capture — and gives each client a granted view scoped to their own freight. What a client sees is derived at read time from their grant; what is outside their scope is absent from their view. Not masked, not greyed out — absent, with no shape left behind to argue about.
Here is one day on one dock, three shippers' freight, read from all three chairs:
the operation, recorded once: 06:40 receive SSCC pallet (shipper A) · who: dock crew, attested · capturedBy: site acct 07:15 receive SSCC pallet (shipper B) · same crew, same dock door 09:02 cross-dock move · reach truck RT-3 · operator attested 11:30 ship shipper A freight, ASN reference attached 13:10 ship shipper C freight shipper A's granted view: their receipts, their moves, their shipments — complete, with the attested performer on every act, and the shared resources (dock door 4, RT-3, the attested operator) visible exactly where they touched A's freight shipper B and C: absent shipper B's granted view: the same 07:15 receipt and every touch of B's freight — complete for them, silent about everyone else
Read what the 09:02 entry does across the views. The reach-truck move exists once in the record. Each client whose freight it touched sees it, inside their own scope, with the same attested operator — so when two clients' auditors each verify their own custody chain, they are verifying the same fact, not two separately keyed accounts of it that might disagree. That is what "honestly serves two audits" means: agreement is structural, because there is nothing separate to disagree.
The logistic-unit identifiers doing the joining are the ordinary GS1 machinery your labels already carry — the SSCC at the pallet, cases and eaches beneath it — so the record's grain is the grain your operation already marks.
Verifiable from the client's side, without joining anything
The grant's second property is the one your RFP responses should lead with. Every event's identity is computed from its content under the standard's own hash (CBV 2.0 §8.9), so a client's auditor can verify any event in their view independently — recompute the hash, compare, done — without joining your systems, without a login to anything beyond their own view, and without taking your word or ours for the record's integrity. The record is append-only by construction: no service identity in the system holds an update or a delete grant, so what their auditor verified in March is what exists in November. The evidence-grade detail is the custody answer.
For your seat, that converts a defensive RFP clause into an offensive one. "Describe how our data is segregated from other clients'" is usually answered with policy language — access controls, training, NDAs. The grant architecture answers it with structure: your view is compiled from your grant; other clients' operations are absent from it, and every event in it is independently verifiable from your side. Policy promises behave until they don't. Structure doesn't have a behavior.
The onboarding and offboarding story
Client onboarding under this model is a grant, not an integration project: scope drawn to the contract — their SKUs, their inbound programs, their date range — and the view exists. The per-client WMS integration your pricing currently carries as a permanent tax becomes a scoping exercise. Offboarding is the same move reversed: the grant ends, the view ends, and nothing rewrites — what each side held through the relationship, each side holds after it, which is exactly what both sides' counsel want to hear. The same architecture from the supplier's chair — one plant record, N customer mandates — is worked in the SharingGrant brief.
The upsell hiding in your next tender
Traceability clauses in shipper RFPs are mostly answered softly across your competitive set — a compliance paragraph, a portal screenshot; how to answer the clause hard is its own brief. A bid that answers with demonstrable, client-verifiable custody — the attested performer on every handoff, including the temporary-labor and agency shifts where custody actually changes hands (the dock's staffing reality), scoped views with structural segregation, evidence an auditor can check from their own chair — is not answering the clause. It is repricing it, from a checkbox into a differentiator worth naming in the win theme.
One operation, recorded once, honestly owned by everyone it serves. That is the sentence your next tender has been missing.
If there is a tender on your desk with a traceability clause in it, start the interview — it asks about your client mix and your docks, and it ends with exactly one promise about contact.