ULID is Awesome for Object Identifiers

ULID is a method for generating numbers, they are large numbers -- 128bits. And this is the cool part: Any system can generate these numbers themselves and they will never conflict[0] This removes the dependency on the State for these silly numbers.

Secondly, large, unique value (like these ULID) are the kinds of things that are used by most inventory control/management/reporting types of systems. And this allows one number to remain on the Lot forever (but you still sub-lot out for each sale, this is a viable inventory control method we should embrace).

Thirdly, ULID removes the confusion with our current numbers, that is the 1/I/L or 0/O or profanity problem.

Fourthly, with large unique numbers, finding one is pretty easy, and typos will not likely match other numbers, which prevents miss-identification.

And these large numbers can still be managed/masked by a "friendly-refrence-id" -- like what Danielle is advocating for. But that is solution that is implementation specific, ie: for Danielle and GF customers. ULID is a step in the right direction, industry wide.

However the software in front (eg: Growflow, WeedTraQR, Kraken, Traceweed, LeafOps) implements some management in front of this numbers is their own issue. Using an incrementing integer is a proven anti-pattern of asset management, so really we should be looking at a better patterns for management. Perhaps we should separate the management of assets from the identification of assets -- which are two unique problems, yet not independent from each other.

[0] There is a 1 in 2^80[1] chance that we could generate a duplicate ULID, in the same microsecond, this is, effectively, not possible. [1] 2^80 is 1.21e+24 -- or 1,210,000,000,000,000,000,000,000 -- one point twenty one, giga-giga watts baby!!!

Organized Thoughts

We also get advantage against collision because not all identifiers are sent around from license to license -- there are millions of records for trees that would never collide at any processor or retailer since, at any given point any licensee only has a few tens of thousands of active records that would need to match the scan, which further shrinks the already small probability. And the collision is is completely eliminated because the full number would still be available, we are only talking about collision on the short-display-segment.  So, maybe a user has to add one more digit, or the application search-lookup would have to remember to sort matched results by new-est record on top - which is easy because of the built-in time sort-ability of ULID.

Originally Posted on 502 Cannabis Group