SQL Compositions

Suppose you need to read a name from the Address Book for a given AB#. You can, of course, build an Orchestration for it — in maybe just under two hundred clicks. Or you can write this:

That is the entire idea. For an enormous class of everyday questions, a line or two of SQL is the most direct, most reviewable, most honest expression of the answer there is — and anyone who administers JD Edwards can read it at a glance and say “yes, that is what it does, and nothing else”.

A SQL Composition takes that expression and makes it a capability: named, described, reviewed, published to the groups who should have it, and withdrawn centrally the moment it should not be. The AI is handed the capability — never the SQL, never the database. It supplies the values the capability asks for and receives the answer. It cannot see the statement, cannot vary it, and cannot go beyond it, because it was never given the means to.

Sets, not single answers

Data questions rarely stop at one record. Which suppliers match this fragment of a name? What did we sell, grouped the way the CFO thinks about it? Which items are below minimum at this branch? A SQL Composition answers with the whole set — ranked, filtered, bounded — which is exactly what an AI needs to resolve an ambiguous request or draw a chart worth looking at.

Minutes, honestly

The Address Book example is not a toy: entity resolution — “which customer did the user mean?” — is a capability every practical agent needs, and it is a single readable statement away. The gap between “we should have that” and “every entitled user has it” is measured in minutes, not projects.

Reviewed before it is real

A SQL Composition is exercised against the target it will serve before anyone publishes it, and it does not reach an AI until somebody releases it, to a named audience, on purpose. What the capability accepts and what it returns are described by its author — in business language — so both the AI and the reviewer know precisely what they are looking at.