Suppose authors of an embedded rule language request age>=18=>allow without spaces or parentheses. The visual change is small. Deciding where it belongs requires asking which layer recognizes the pieces before any rule runs.
In Racket, the reader establishes the initial syntax representation. Under ordinary reading, that fragment can arrive as a symbol rather than the sequence of operators its author imagines. A macro could deliberately parse the symbol's spelling, but that would be a little parser inside the notation. It would not redefine the lexical conventions surrounding the macro. A custom reader is appropriate when the language actually needs different token boundaries or delimiter rules.
Expansion has another job. Given recognized syntax, it can reject malformed rule forms, establish bindings and translate a rule into calls. Runtime code must still obtain an age value, decide what happens when it is absent and perform any permitted action. If the notation later adds an attempt form, expansion may arrange a call to a retry engine. Whether that engine repeats a test, an action or both needs a runtime contract.
A named language can package the reader and expander starting points when these choices form a coherent authoring environment. That also creates documentation and tooling obligations. If the request merely means calling an existing comparison and returning a decision, a plain library call may already express it clearly. I would justify the additional boundary through the rules authors need to read and maintain.