Guardrails/conventions should be enforced in linters, formatters, static analysis tooling; not specs/prompts.
https://developers.openai.com/api/docs/guides/structured-out...
Nothing else operates on the logprobs level and literally bans continuations that fail your schema.
Elixir is where I prefer to build software, so it would be creating a custom Credo rule.
The specification pattern is essentially a builder for a query (or more accurately in our case, for a C# expression for the ORM) and one of the main benefits is that you can put rules into the “build” method which returns the expression to be used, such as “throw an exception if the WithPartionKey() method hasn’t been called”.
Usual ORM disclaimer applies that you should double check the generated SQL is acceptably performant. The specification pattern can make this better or worse, it can result in contorted expressions which result in poorly performing SQL, but you could also put logic in your specification to “ensure” good SQL, e.g. by having a method which uses the correct expression structure which is known to generate good SQL (e.g. EF6 would generate terrible SQL for certain nested Any()’s, but if you used .Contains() instead it was fine) and the encapsulation means that all callers of the method get the benefit.
It worked well for us as reviewing the specification methods in PRs was pretty easy and less experienced developers on the project were more likely to do the performant and working thing than not.