thank you for removing the peer dependencies!

That being the case, would you have a pointer towards another approach I might take? Where in some contexts, I want tighter validation than others for the same spec/key?

is there some reason not to s/or all the options?

and then s/and in more constrained predicates when needed?

and separately, are these tighter constraints actually helping you enough to be worth the trouble?

Say I'm using Datomic-like data structures in my application, as Datomic is my primary data store and they're nice data structures to do business logic on anyway. I have a new (not yet persisted) entity that contains a reference to another, (should-be-pre-existing) entity. If I want to transact that data, I'll use a look-up ref (which will guarantee failure if that entity doesn't already exist, which is what I want). If I use a map as that reference, it will create that entity (which is not what I want). I can create a spec that accepts a map or a lookup-ref as valid values for the key, but in the tx-data case, I only want the lookup-ref version, not the map version. Am I thinking about this wrong?

Stepping back, datomic transactions are a DSL. does it make sense to spec it as a DSL, or to spec your particular use of it?

The latter is going to be a challenge because the meaning of keys is overloaded

As a DSL, the keys are opaque and meaningless

but if you try to spec the DSL at a more semantic level, you may conflict with the “read” view of those keys (i.e. what you get from d/pull, etc)

sometimes, it's just not worth getting down to that level of specificity

or if you need to, consider making a new DSL for your transactions, and speccing that instead

and have functions that transform to the transaction dsl

@U09R86PA4 that makes sense. Cheers.

Stronger than that. @U09R86PA4 that really clarifying. doubleplussgood