Here are a few comments.

I wonder if what Operation exposes is the right level of information. Shouldn't it rather be the entity itself?
That's an open question and I understand that offering the latter is much more difficult. I guess seeing code using this recovery API will help us clarify things. You might even want to start with that.

I suppose some backend will offer asynchronous failure callbacks. We will need to offer the GridDialect a facility to cope with:

• exception based failures from the NoSQL API
• subsequent error report API call (like Mongo's)
• asynchronous, callback based error report

Returning the error(s) via an exception is the more natural JPA way of doing things. The challenge is the mismatch between an underlying async based error report at the NoSQL level and and direct exception.
I am definitely not in favour of Mongo's approach to optionally call an error report API after your operation.
I like the callback API. The challenge is that it is easiest to enlist a global callback but that makes it hard to cope with the rollback of a the specific set of operations related to a specific use case. It is more natural to attach a callback per use case.... except we don't really have a natural API to attach callbacks to. We can use OgmSession as you suggest.

All in all, this requires experimentation but:

• I would explore the callback API
• I would also explore an option to enforce an exception at flush time (in case of failure)