A query returns rows. An application needs a fact.
Query the business fact the application actually needs, not merely the rows a database can return. Keep source authority, identity, scope, time, joins, units, missingness, output semantics, and evidence explicit.
Keep operational application data in typed business objects
Operational entities
Suppliers, customers, cases, claims, orders, invoices, accounts, approvals, configuration, and workflow-facing business objects.
Declared meaning
Canonical identity, legal scope, properties, relationships, classification, CRUD behavior, source ownership, and lifecycle are explicit.
Shared application model
Pages, workflows, policies, queries, and AI components operate on the same business object definitions.
Start the query with the business proposition
Establish the fact being requested before resolving sources, entity bindings, time semantics, authorization, joins, and output contract.
Use the source allowed to establish the fact
Operational databases, ERP, CRM, warehouses, Feature Store, retrieval projections, caches, and APIs can differ in freshness, precision, legal scope, and authority.
Join data around the canonical business entity
Matching identifiers do not necessarily refer to the same business resource in the same tenant, legal entity, source system, region, or time interval.
Let a model propose the question, not the permissions
Generated SQL remains a compiled derivative of the governed definition, not the authority for what the application may ask.
Keep injection safety and business authorization separate
Parameterized queries are necessary, but they do not prove the resource is authorized, the selected property may be disclosed, or the source is authoritative.
Carry scope through joins, aggregates, and derived fields
Authorization must survive joins, subqueries, views, aggregations, derived columns, caches, generated SQL, result projections, and later evidence views.
Make time part of the query contract
Map one governed query from proposition to decision evidence.
Use an architecture review to define business objects, source authority, canonical joins, active scope, temporal contracts, result semantics, and Query-to-Decision Lineage.