You can do merkle-tree-signing and other clever things with cryptography to provide auditability without needing any kind of distributed consensus via proof of work/stake/etc. so I think the flowchart could have a couple more "No" branches.
(Yes, private permissioned blockchains aren't necessarily p2p, but I'd argue that they need to use byzantine consensus too -- otherwise there's no reason not to just use a managed database instead.)
https://twitter.com/hikari_no_yume/status/933791331146784768
More seriously, some people apparently consider git a blockchain: https://medium.com/@shemnon/is-a-git-repository-a-blockchain...
Where things got murky was that the cryptocurrency crowd started to talk about the blockchain that backs Bitcoin in terms where the consensus layer was left implicit (our own Linux vs GNU/Linux story if you want to see it that way), then people less knowledgeable about cryptography started pouring in, they learned a bunch of new terminology, and along the way missed the nuance about the consensus layer being left implicit, so in their minds (and the world at large, eventually) blockchain means the combined data structure and consensus layer — It’s fairly obvious that git doesn’t meet the requirements for this definition of “blockchain”.
Proof-of-work is code that passes tests and consensus is "Linus said 'ok'".
That said, if you don't have something like that, then most the rest of the bubbles don't make a whole lot of sense, either. When there's one central authority, they have the ability to unilaterally rewrite history, so you've also lost any features that flow from that not being possible, such as strong auditability.
Git seems like a decent litmus test. Is git, rebase and all, a blockchain technology, or merely a blockchain-like technology?
An example would be that I, as the central entity, know which public keys/key pairs I want to trust, and the proof of work is the owner of said key signing a given block with it. So as the central authority I can't unilaterally rewrite history, but I can unilaterally decide whether the chain is valid.
E.g. Alice wants to deliver a package to Dan by means of Bob and Carlos as couriers. So Alice signs the initial block using her public key and gives the package+signed block to Bob, who signs and gives to Carlos, who signs and gives the package to Dan. Dan can independently verify his trust in Alice, Bob, and Carlos's public keys and then be sure that the package was passed along in the manner recorded in the blockchain.
If trusting Alice, Bob and Carlos's public keys is equivalent to trusting them, then I don't really need a blockchain to verify that they did what they said they did.
If it's not, then I don't trust the blockchain as a record of what happened, because there's no chain of trust between what they wrote in the blockchain and what they actually did.
The reason why this sort of thing works with cryptocurrency is because, with cryptocurrency, the blockchain is reality. If the blockchain says I have 1BTC, I have it. If it doesn't, I don't.
As soon as you try to apply it to something like supply chain management, though, that falls apart. The map is not the territory. So you have to add a whole bunch more stuff to the system to try and ensure that what's been recorded is accurate. Not entirely unlike how, in the story of the stone soup, people had to add a whole bunch more stuff besides the stone to the pot in order to make sure the soup was tasty and nutritious.
I guess you could just store it in a database and store the hashes and signatures as columns but again, that seems more like implementing a blockchain strategy using a traditional RDBMS.
*After your edit: It seems like the blockchain is still useful in this case as a series of signed statements where it can be (generally) verified that each signature was made by a certain entity at a certain point in the chain.
Why would I need to do such a thing? What, in practical terms, does it get me?
The value of the system is that Bob cannot modify what Alice has said and signed. So the only place where Bob could lie is in his own block. Additionally, once Carlos signs his block, Bob and Alice can no longer change their statement either, so we're partly relying on Carlos to verify that he receives the package in the condition described by Bob's block.
One vulnerability I see is Carlos could just cut out Bob and fork the chain with his own block coming right after Alice. To counter that you could have each sender sign off on who they entrusted the package to (i.e. Alice signs her block/creates a block saying she gave the package to Bob).
So essentially the idea is to set up a system of untrusted participants whose identities can be verified/trusted. Bob might have an incentive to lie about who he received the package from or what the condition of the was package when he received it, but he doesn't have much incentive to let other people sign messages using his key.
I'm not sure as a system whether there is actual value or benefits here over other simpler solutions, it's just a fun thought experiment I've been doing to try and figure out scenarios where blockchains could provide real benefits over other systems.
If you can centralize the records management, then you don't have a problem deciding who should own the record store. At that point, good old-fashioned authentication will solve your problem.
If you can't centralize records management, then things get trickier. But I think the trickiest part would still be to come up with a non-contrived logistics scenario where there isn't an obvious custodian you can put in charge of a centralized record.
A tamperproof log with certain commodity hardware might be easier than guaranteeing secure network access to every participant in the chain.
One example I've seen in the wild is Walmart investing in blockchain for food safety. This is me in a sense trying to reverse engineer that thought process/system to figure out what benefits it might bring.
Looks like the system I'm thinking of is roughly a Proof of Authority system (https://en.wikipedia.org/wiki/Proof-of-authority). Your point about blockchain being unnecessary here is one of the points brought up in the Wikipedia article under Comparisons.
How about ZFS filesystem?
One implemtation I would like to see is a consensus algorithm applied to a multiplayer p2p game to prevent hacking.
Another implementation could be for digital assets like textures/skins, 3d models, and animations. This could take something like steam workshop and make it distributed.