Glossary
What is a parameterized data operation?
A parameterized data operation is a pre-defined data operation that accepts typed parameters and runs the same tested query or business logic every time. The operation is fixed at design time. Only the parameter values change at runtime.
This is distinct from runtime-generated queries, such as text-to-SQL output, where the model writes a new query for each request. A parameterized data operation substitutes values into a tested operation; a runtime-generated query writes a new operation. The difference shows up the first time two consumers ask the same question and get different answers.
What parameterized means in practice
Parameterization is runtime substitution of typed values into a tested operation, not runtime generation of new operations. An operation might accept a customer identifier, a date range, and a status filter. Those three parameters are typed: identifier is a string of a defined shape, the date range is a pair of dates, the status is one of an enumerated set. Anything outside those types is rejected before execution.
What does not change between calls is the operation itself. The joins, the filters, the calculations, the column projections, all sit in the operation as authored, tested, and reviewed. Two consumers asking the same question with the same parameters get the same answer because the operation is fixed.
Failures, when they happen, are predictable. A parameter is out of range, a record is missing, a connection drops. They are not silent semantic drift in the query itself.
How it differs from text-to-SQL
Text-to-SQL converts a natural-language question into a SQL query at runtime. The model decides which tables to read, how to join them, which filters apply, and how to aggregate. The query is new every time.
A parameterized data operation reverses the order. The query is written and tested ahead of time by people who know the schema. The model, or the user, picks which operation to call and supplies parameters. The model never writes the query.
That distinction is the foundation of deterministic execution. Same input, same output. Reviewable, auditable, repeatable.
How it differs from a stored procedure
Stored procedures are also tested operations with parameters. The shared shape is real. What differs is scope and reach.
A stored procedure lives in one database and serves whichever client connects to that database. The client needs database credentials. The procedure executes under the permissions of the connecting login. Access control sits in the database, audit sits in the database, and reuse outside the database means rebuilding the procedure in whatever the next system speaks.
A parameterized data operation in a governed access layer serves every consumer through one path: a business user in a self-service tool, an AI agent over Model Context Protocol, an application reading through an API, a partner system through a published endpoint. Access control, business definitions, and audit live in the access layer, not duplicated per consumer. The same operation reaches all of them.
For the contrast applied to AI agents specifically, see dhino's Dataverse MCP server vs Microsoft's.
How dhino runs parameterized data operations
In dhino, parameterized data operations are packaged as data access templates. The template carries the operation, the typed parameter list, the access rules, and the business definitions. Consumers supply parameters; the platform runs the operation.
The same template feeds Fetch for business users and Trust for AI agents. The operation is defined once. Every consumer reads from it.
Related terms
See parameterized data operations in practice
Tell us what your consumers are asking for: a report, an AI agent, a partner API. We will show you what one tested operation, parameterized once, looks like across all of them.