anchor.diff:  
   For example, most Ring middleware functions modify the request or response map with unqualified keys. However, each middleware could instead use namespaced keys with registered semantics for those keys. The keys could then be checked for conformance, creating a system with greater opportunities for collaboration and consistency.
   
  -Entity maps in spec are defined with https://clojure.github.io/clojure/branch-master/clojure.spec-api.html#clojure.spec/keys[`keys`]:
  +Entity maps in spec are defined with https://clojure.github.io/spec.alpha/clojure.spec.alpha-api.html#clojure.spec.alpha/keys[`keys`]:
   
   [source,clojure]
   ----
  
positive.code: ;;    [-3.0 [:n -3.0]])
  ----
  
  For spec'ed functions we also have https://clojure.github.io/clojure/branch-master/clojure.spec-api.html#clojure.spec.gen/exercise-fn[`exercise-fn`], which generates sample args, invokes the spec'ed function and returns the args and the return value.
  
  [source,clojure]
  ----
  
negative.code: 
  One common occurrence in Clojure is to use maps as tagged entities and a special field that indicates the "type" of the map where type indicates a potentially open set of types, often with shared attributes across the types. 
  
  As previously discussed, the attributes for all types are well-specified using attributes stored in the registry by namespaced keyword. Attributes shared across entity types automatically gain shared semantics. However, we also want to be able to specify the required keys per entity type and for that spec provides https://clojure.github.io/spec.alpha/clojure.spec.alpha-api.html#clojure.spec.alpha/multi-spec[`multi-spec`] which leverages a multimethod to provide for the specification of an open set of entity types based on a type tag.
  
  For example, imagine an API that received event objects which shared some common fields but also had type-specific shapes. First we would register the event attributes:
  
  