One thesis: a custody record needs two different names in it — the observer who performed the act and the account that warrants the record — and any system that stores one field for both has already destroyed the evidence it will be asked for. The vocabulary is short: who is the attested observer — a human, an agent, or an embodied agent such as a robot or autonomous MHE. capturedBy is the warrantor account — who stands behind the capture. They are different questions with different answers, and on your dock they diverge daily.
Words that are not in the vocabulary, deliberately: "user," "operator," "actor." Each of them blurs observation into access and loses the attestation — a "user" is whoever was logged in, which is precisely the fact that tells you nothing.
Why your dock is the hardest case, and therefore the proof
A 3PL receiving dock is where custody actually changes hands, which makes it the exact place the Who is most load-bearing — and the labour that performs the handoff is substantially temporary, agency-supplied, or a carrier's driver: people whose relationship to your systems is thin by design. The legally and operationally meaningful question in a claim, a shortage dispute, or an audit — who handled this? — is the one your WMS records worst, because the person at the pallet and the account in the system are routinely different parties.
Add the delegation case that is already normal in 2026: an agent working a receiving queue under a grant from your operations account. The agent observed; your account warrants. One actor, two grains — in one field, unrecordable.
The same event, written twice
A carrier driver delivers a pallet; the receiving scan posts through your freight broker's integration account. First, the two grains held separate — an EPCIS 2.0 ObjectEvent, the performer carried in a conformant namespaced extension, the identity grains in id.org.ai terms — Agent. Human. Thing.:
{
"type": "ObjectEvent",
"eventTime": "2026-07-31T13:42:10Z",
"epcList": ["urn:epc:id:sscc:0614141.1234567890"],
"action": "OBSERVE",
"bizStep": "receiving",
"readPoint": { "id": "urn:epc:id:sgln:0614141.00000.0" },
"spine:who": "https://id.org.ai/humans/driver-attestation-8842",
"spine:capturedBy": "https://id.org.ai/accounts/broker-integration-04"
}
Now the collapsed version — the one every conventional system writes:
{ "...": "...", "recordedBy": "broker-integration-04" }
Run the audit question against each. Who physically received this pallet? The first record answers: the attested driver, observed under the broker's warranting account — two facts, both preserved, each answerable for separately. The second record answers: an integration account that was not on the dock, has never touched a pallet, and warrants everything in bulk. The collapsed field is not a smaller answer; it is a different answer to a different question, silently substituted. And the substitution is invisible until the day someone asks — which is, definitionally, the worst possible day to discover it.
Note what the honest record does not contain: your company's org identity stamped on the event. Party and organisation grain are derived at read time from grant chains, never stamped — because your org chart changes, sites re-badge, agencies swap, and a record with yesterday's org identity baked in is wrong forever. Derived grain makes the record reorg-proof and revocation-safe: revoke the grant, and future warranting stops without falsifying a single past event.
The regulator-room test
The standard your shippers' auditors read gives you no help here — five dimensions, no performer, party fields at organisation grain, section-numbered in the arc's opening post. So a fully conformant record can say your company received the pallet and can never say who. A network vendor's answer to the audit question is a report computed inside their walls, from records only members can inspect. The answer that holds up in a room with a regulator or an opposing counsel in it is a record that carries the observer and the warrantor as separate, attested facts — verifiable without joining anything. For the seat that answers traceability clauses in RFPs, that sentence is a differentiator with contract value attached; for you it is the difference between an answer and an apology.
One honesty block, because this family does not sell what does not exist: the two-grain design above is exactly that — a design, with the grammar and the join published. Stored custody evidence as a finished product — trace bundles assembled for a named regulator — is designed and not started, and nobody is building it yet; if that changes, people on the list hear it first. What runs today is the identity layer under it: the scan that starts every custody record resolves and verifies locally on this site's verbs, and the SSCC — the identifier your pallets already carry — is the natural place to see the join.
The access flow asks what crosses your dock and who handles it — carrier drivers, agency labour, agents under grant, autonomous MHE. Say so plainly; the provisioning order follows the list.
The one-sentence version, for the next claims meeting: our record says who saw it and who vouches for it, and it can tell those apart. Systems that cannot make that sentence true are not keeping worse custody records. They are keeping none.
Keys open the network half of the verb set. Get an API key — say what arrives at your door, and the provisioning order follows the list.
We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.