What does that have to do with incpa?

I send this server a question encrypted. It stays encrypted yet the server distinguished my ciphertext enough to produce a coherent reply. That means there was enough information in the ciphertext for the server to perform the inference, even if it was obscured to where it looks indistinguishable, it apparently wasn't.

This doesn't remove trust from the equation, it puts the trust directly on the algorithm. Probably one no one can explain to me like I'm 5. But because it's encrypted I am no longer breaking the law by processing on protected data. I imagine very large contracts await on the other side. Lots of money to be made.

the server doesn't do what you say. Roughly, the server has a fixed circuit C they run on the ciphertext. They run this same circuit on any ciphertext. They give you back the result. the fact that the result, when decrypted, gives the desired answer isn't something the server can verify though.

Think about a very simple setting, say a database lookup. I send an index `i` in a database I want to lookup. The server sends back DB[i] or whatever.

In the clear, the server can immediately fetch the correct row. Under FHE, the server does a full scan of the database, and (roughly) for each row will do something like DB[i] * (encrypted selector variable that is 0 or 1 depending on if it is the row you want).

This is actually a baby version of FHE known as "Private Information Retrieval". For it, you (roughly) can design an encryption scheme that supports linear function evaluation. For example, a ciphertext Enc(m) can be paired with a matrix A to produce Enc(Am). You can then encrypt the ith basis vector m := e_i, and view the database as a matrix DB, to get DB * Enc(e_i) = Enc(DB*e_i) = Enc(DB_i). This works, and can be implemented in ~1k LoC, e.g. it is not particularly complicated to practically instantiate (though this basic sketch has some performance issues).