It would largely function by pictures I would imagine. Let's say, for example, each crate of goods had a QR code, EDIT: with the private key known only to the supplier.

So the supplier gets these QR codes(public keys) , slaps them on the crates and sends the crates on thier way. The receiving end then must provide not only a video of those crates being opened in a food distribution center, but the video must include the QR codes in the footage. Then the supplier will know thier goods have not been hijacked, particularly if the video includes the goods being handed out on camera.

Those videos can then be published along with the QR codes for external verification on a blockchain.

There is no reason the system you describe could not be engineered as a variation on how Bitcoin operates.

If you want the operation of the blockchain you create to be decentralised then you need three independent miners only (but more is fine and less is fine also if you do not care if it is decentralised but not very redundant) and block creation does not need to be difficult or expensive because you are not trying to provide proof-of-work and with limited miners even the existing algorithm would make it very easy. Block time does not have to be ten minutes on average either as it is with Bitcoin, it just needs to be as responsive as necessary - one block per hour?.

My suggestion is, the donor knows how much of particular goods are to be sent. In your system, the donor privately receives from the scheduled recipient of the goods the private sending address (which can be pre-created in your system and can be individual to each donor or shipment, in Bitcoin usually sending addresses are not easily visible until the transaction is sent which will be the last thing in this case). Then, the goods are shipped with a record of the donor receiving address attached. When the goods are received the recipient tallies the goods and sends x amount of the tally to the donor address using their previously provided secret sending address. The donor knows that the goods were receipted by the correct recipient and in what quantity. The donor has a proof of receipt for the delivery. All addresses can have various details attached at either end, details which can if necessary also be broadcast into the transaction pool for inclusion in your blockchain, separately or with the attached transaction, or when each address is created (just don't broadcast the recipient address when it is created until the transaction is sent!), or the details can remain private (transparency probably requires that most relevant details are published to the blockchain). Donors, recipients and your service each run the client node software and somewhere you have one or, as many as necessary miners. No one can steal the goods and report them correctly receipted and accounted for without knowing the private recipient sending address. You could even have the supply chain report progress to the donor receive address as the goods move at each step, secret addresses would not be necessary while the goods are in your control, just one sending address for each checkpoint in your control would permanently be enough I suppose and the addresses can be labelled or named if necessary with that data transmitted with the transaction at each checkpoint since you are not aiming for anonymity. The data would all be auditable. Block contents can be encrypted if privacy is required. This usage turns the terminology for sender and recipient around because they refer the 'receipt of goods message' that will later be sent.

... I don't know if that sounds useful?

What is involved? Programmers.

It may be possible to start directly with the Bitcoin Core client software and modify it for your use, sometimes it makes development quicker to pull apart a working model. I would not suggest a fork of the Bitcoin blockchain, build a new blockchain from the beginning.

Your intended use is certainly acheivable.