This isn't an answer, because I was wondering as well how to do the following, which may or may not be the same thing as you're asking how to do:
How do you prevent the same item (hash of a digitized item) from being tokenized into an NFT more than once when the script doesn't have access to the blockchain history?
Maybe it's possible to use the Statemachine feature to maintain a map of NFTs to item hashes, so it could track all the item hashes that have been minted with this policy?
I guess someone else could possibly make trivial changes to the policy's code just to change the script address, and then could mint a duplicate NFT of the same asset, but a statemachine could at least track assets for this one particular script.
This is all assuming a minting policy script can work with a statemachine, or a Datum.
I noticed in this set of instructions for minting NFTs using the cardano-cli that metadata can be attached to the NFT. https://developers.cardano.org/docs/native-tokens/minting-nfts/
Meaning that it might be possible to add a datum value to the minted token somehow.
In order to check for duplicates across the whole BC, it might be necessary to use a third party NFT registry app.
One thing that shows up in a later Plutus Pioneer lecture is using an NFT to verify that the correct oracles are being referenced. I think it's in the Uniswap code. The Uniswap operator mints an NFT as a kind of id, and the SC that runs the swap pools uses that NFT to make sure that only the operator can control the Dapp.
Using that idea, your contract could do something similar, making sure that no one else is running the same contract to make duplicates. This combined with some form of mapping to make sure no one duplicates the same asset on your contract, and registering with an NFT registry, might be a fairly solid way to ensure uniqueness of the assets being tokenized.
I could of course be missing something, I'm fairly new to this too.