What to know of implementation besides contract?

Both L and D in SOLID encourage us to program against contracts, not actual implementations. But does that mean an interface consumer should not know the implementation, or just that he should not rely on implementation doing something not stated in a contract explicitly?

I mean, we can have a method to create a new NumericParameter in DB, but its interface only says that! It does not say that NumericParameter is actually an inherited entity spanning over 2 tables, or that the method also creates one more related entity to save some more data about the created entity. Those are implementation details.

It's very clear why one should not depend on implementation doing something. But maybe it's justifiable to depend on implementation NOT doing something (even if it's not stated in a contract?) Otherwise, how are you going to modify your code at all? Any time you add some activity, it can come to conflict with something that is happening in some of the other methods and services you call. Like, you read a DB row "for update", then call foo() and then write a row back with some modifications, but it appears that foo() already made some changes to the same row - in this very transaction - and they will be overwritten.

On the other hand, implementation can be changed. If some consumer depends on it NOT doing something, then at some moment that dependency may break. Meaning, not only have we to examine what code is called from the code being edited, but also possible callers of the code. Everything that may be happening in any transaction triggering this code, we must know in details.

Somehow I think that is a smell, but how do you live without it? I usually try to ignore implementation details, but on multiple occasions that ended up in some conflicts.