Skip to content

Predicate explainability

No due date 0% complete

Currently, any given predicate in predicates.ts only returns a boolean that indicates whether the provided history/serialization passes it. But just returning a boolean isn't sufficient: I almost always hear people ask, "wait, but why doesn't this serialization satisfy ?"

If a predicate isn't satisfied, we should be telling the user why it failed. If clie…

Currently, any given predicate in predicates.ts only returns a boolean that indicates whether the provided history/serialization passes it. But just returning a boolean isn't sufficient: I almost always hear people ask, "wait, but why doesn't this serialization satisfy ?"

If a predicate isn't satisfied, we should be telling the user why it failed. If client 0 writes A and then B, and client 2 receives B and then A, we should say something like:

Monotonic writes requires client 2's serialization to place A before B, since client 1 wrote A before B.

While we should start off by implementing explainability only when predicates fail, we could eventually expand to justifying why predicates succeed.

This effort has several facets to be described in other issues:

  • It needs to be testable
  • It must be exhaustive (we need to report all instances of how a given predicate fails)
  • It needs to be shown in the UI
Loading