Not a Malli user but a heavy Spec user -- <top-ns>.<component>.interface.specs is my preference.

That said, for s/fdef I generally put the specs right above the function definition. For data specs, I put them in .interface.specs (since fn specs are generally not used separately from the function they apply to). So that means my interface nses will require interface.specs if the fn spec needs data specs too.

I appreciate it @U04V70XH6! thats what I've been gravitating towards myself, nice to have confirmation

This feels like a good advice. Maybe something that we could add to the documentation?

@U0482NW9KL1 am hitting the same problem/solution space.. been delaying thinking about this for a couple weeks, but i have to convert this part of the codebase. I think the approach i'm going to take here, is a bit more declarative, 'require' is great if you have a dependency ordering, it's not needed for malli schema, in so far as there's any order to schema, it's orthogonal to require load order , the most efficient registry choice is actually just a java.util.HashMap that's precomputed at load time which maps keys to schema. So basically, at load time, i'm just going to search for 'spec.clj/schema.clj' or 'spec.edn/schema.edn' on the classpath, load them all, merge all the maps (key->schema), throw if there's any key conflicts, then finally convert it to a java.util.HashMap, and then you have your malli registry. Also you can do all this at 'compile time', so AOT builds will have full merged registry precomputed. Probably going to start implementing this soon, i can send you code snippets if you're interested in this approach. Other suggestions here in this thread are great too.