⚡️🗒️Power BI: DAX Calculations [Notes]🆕

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 28-Oct-2026

[feature] DAX Calculations

• {concept} calculated table 
• {def} table created by users using DAX [3]
• stored in the data model [3]
• materialized when the model is refreshed [3]
• becomes a regular table that can participate in relationships, filtering, and reporting [3]
•  unlike a visual calculation or a measure [3]
• enables adding new tables based on data loaded into the model [3]
• instead of querying and loading values into new table’s columns from a data source [3] 
• via a DAX formula that defines the table’s values [3]
• {characteristic} locked after loading
• after the table is loaded or refreshed, its results are locked in and cannot be changed until the table is refreshed [3]
• the results are pre-computed and aren’t dynamically determined [3]
• relatively easy to understand [3]
• because the DAX statement can be inspected and the results can be predicted [3]
• the same statement always returns the same result for the same parameters until the table is refreshed [3]
• {concept} calculated column
• {def} a column created using a DAX formula
• behaves like any other column in a table [3]
• it can be used to define relationships [3]
• {characteristic} calculated row by row 
• can be based on 
• simple formulas (e.g. mathematical operations like addition)
• complex formulas (e.g. combinations of functions) 
• {characteristic} stored in the data model
• ⇒ increases the size of the model [4]
• {characteristic} calculated during refresh 
• calculated when the table is first loaded or refreshed [3]
• can be used in rows, columns, filters, or values of a matrix or any other report [3]
• {exception}[DirectQuery|composite models] computed during the execution of a query [2]
• they do not use RAM, but they are also potentially slower [2]
• they are not evaluated and stored ahead of any query [2] 
• {characteristic}static
• its results cannot be changed until the table is refreshed again [3]
• {characteristic} can be resource-intensive
• especially for large datasets [4] 
• {recommendation} should be used judiciously [4]
• {characteristic} can be used in slicers and filters
•  help create categories users can interact with
• {characteristic) can be used for sorting 
• improves report usability
• {characteristic} support hierarchies and grouping
•  helps organize data into business-friendly groups.
• context transition applies as well [3]
• where a row context is present, and whenever a function is used that iterates over multiple values (aka iterators) [3]
• e.g. SUMX 
• always executed in a row context [2]
• it's possible to create a row context programmatically [2]
• {scenario} placing calculated results in a slicer [2]
• {poor practice} define calculated columns to compute formulas on a row-by-row basis and then aggregate the values [2]
• moving the computation time at data refresh can benefit the overall user experience [2]
• many such scenarios can be successfully solved using iterators instead of creating calculated columns [2]
• categorize text or numbers, especially for filter criteria [2]
• {concept} measure
• {def} a DAX calculation that is evaluated at query time based on the current filter context and returns a result based on the current filter context
• works on sets of rows, producing aggregates of values [2]
• requires aggregators [2]
• computed over multiple lines at once [2]
• does not compute its value on a row-by-row basis [2]
• work on aggregated data [2] 
• reusable
• can reference other measures 
• {characteristic} calculated only when needed
• its output is determined not only by its definition but also by the filter context in which it's executed [3]
•  the same definition can have a different meaning based on the filter context [3]
•  the same measure returns different results depending on
• slicers
• filters 
• visual selections
• row/column groups 
• {characteristic} depends on filter context
•  evaluated within that filter context and often summarizes multiple rows [3]
• {characteristic} consumes little storage/memory
•  only the formula definition, not the results 
• {characteristic} typically used in visuals
•  it can be used by other measures, visual-level/page-level/report-level filters
• used to filter what is displayed
•  it can be used for 
• conditional formatting
• dynamic titles
• dynamic tooltips 
• dynamic format strings
• calculations groups 
• visual calculations 
• {characteristic} must be defined in a table
• a dummy table can be defined for managing (all) measures
• can be moved in between tables
• ⇐ a table is merely a container where the measure is organized without affecting its behavior [2]
• {characteristic} cant be used in relationships
• {characteristic} can't be used direct in slicer fields 
• {type} explicit measure
• created explicitly via the UI 
• can be created programmatically
• via Tabular Editor, TMDL, TOM, XMLA Endpoint, Fabric/PBI, CI/CD
•  
• {type} implicit measure
• created (automatically) when a column is added in the values area of a visual [2]
• not always available
• they do not work when calculation groups are present in the model or when they are disabled in the Tabular model [2]
• {downside} do not guarantee full control over the calculation.
• {benefit} smaller semantic models and lower memory usage
•  store only the DAX formula and metadata, not a value for every row
• {benefit} one measures supports multiple scenarios
• automatically respond to slicers, filters, page/report filters, user selection 
• {benefit} best performance
• faster refreshes, smaller model size, better availability 
• {benefit} reusability 
•  less code duplication, easier maintenance, consistent business logic
• {benefit} support advanced analytics solutions
• time intelligence, running totals, ranking, comparisons, etc. 
• {benefit} centralize business logic
• SSoT/consistent logic across reports 
• {benefit} support modern Power BI features
• tooltips, conditional formatting, dynamic titles, visual calculations, calculations groups, KPIs, etc.
• {recommendation} always define an explicit measure instead of using implicit measures [2]
• allows to modify the global behavior of the calculation without breaking existing reports [2]
• {recommendation} consider creating measures instead of calculated models
• measures are preferred whenever a calculation can be express both ways [2]
• {recommendation} limit the use of calculated columns to the few cases where they are strictly needed [2]
• increase model size, increase refresh time, consume RAM 
• {recommendation} consider moving the calculation to the data preparation stage [2]
• data should be transformed as far upstream as possible and as far downstream as necessary [2]
• {recommendation} use DAX Studio early
•  it allows to inspect the query plan, view filter context, analyze storage engine vs formula engine activity, understand why one measure is faster than another, etc. [2]
• {recommendation} break complex measures into layers [2]
• allows to validate each step independently
• 
  

References:

[1] Greg Deckler & Brett Powell (2024) "Microsoft Power BI Cookbook: Convert raw data into business insights with updated techniques, use cases, and best practices" 3rd Ed.

[2] Alberto Ferrari & Marco Russo (2025) The Definitive Guide to DAX: Mastering the semantic model expression language for Microsoft Power BI, Fabric and Excel

[3] Jeroen ter Heerdt et al (2026) "Microsoft Power BI Visual Calculations: Simplifying DAX"
[4] Cooper Dunn (2025) Microsoft DP-600 Exam Practice Tests: 500 Questions for Implementing Analytics Solutions Using Microsoft Fabric

Acronyms:
CI/CD - Continuous Integration/Continuous Development  
DAX - Data Analysis eXpressions
KPI - Key Performance Indicator
RAM - Random Access Memory
SSoT - Single Source of Truth
TMDL - Tabular Model Definition Language
TOM - Tabular Object Model
XMLA - XML for Analysis

 

⚡️🗒️Power BI: Context [Notes]🆕

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 28-Oct-2026

[DAX] Context

• {def} the set of data that a calculation, visual, or DAX expression evaluates at a given moment
• determines which rows are considered when a calculation is evaluated
• the same measure can return different results depending on the context
• enables users to perform dynamic analysis [5]
• used by measures, calculated columns/tables, iterator functions, slicers & filters, relationships, time intelligence, RLS, etc.
• can make it difficult to troubleshoot formulas [5]
• {concept} evaluation context
• {def} the set of conditions and rules that determines which data is used when a DAX formula calculates a result
• both the row context and the filter context contribute to the evaluation context [3]
• the two are very different, serving different purposes, having different features and different behaviors [3]
• {type} filter context
• {def} the set of filters that are active when a calculation is evaluated
• determines which rows of data are visible to a measure at any given moment [2]
• added when a filter constraint is applied on the set of values allowed in a column or table, by using arguments to a formula [5]
• applies or removes filters to/from tables in the semantic model [2]
•  filters tables in a model [2]
•  propagates filters through relationships [2]
•  managed by CALCULATE [2]
• generated not only by the the current visual but also by other visuals [3]
• each visual has its filter context (aka visual filter context) 
• determined by all the other visuals in the report that interact with that current visual and all the report filters applied through the filters pane (visual-, page-, and report-level filters) [2]
• each cell has its filter context (aka cell filter context) 
• the coordinates of the cell itself determine the filter context of a cell, plus the visual filter context [2]
• sources
• visuals (charts, tables, cards, etc.)
• slicers
• report/page filters
• cross-filtering from other visuals
• DAX functions
• e.g. CALCULATE(), CALCULATETABLE()
• {type} row context 
• {def} the context in DAX where an expression is evaluated for a single row at a time, giving DAX access to the values of the current row
• aka 'the current row' 
• used when Power BI is evaluating one row at a time [1]
• needed to obtain the value of a column for a certain row [2]
•  {warning} trying to access the value of a column in a measure without an active row context results in an error [2]
• exists whenever we create a calculated column or whenever we are computing an expression inside an iteration [2]
• calculated columns have an automatic row context [2]
• the row context for a formula includes the values from all columns in the current row [
• automatically follows the relationships between tables to determine which rows in related tables are associated with the current row [5]
• functions that iterate calculations over a table can have multiple current rows and current row contexts [5]
•  can be created formulas that recurse over an inner and outer loop [5]
• certain functions store the row context from the operation that preceded the current operation [5]
• e.g. EARLIER 
• the function stores two sets of context in memory [5]
• one set of context represents the current row for the inner loop of the formula [5]
• another set of context represents the current row for the outer loop of the formula [5]
• measures don't have a row context [2] 
• if is needed to evaluate an expression row by row inside a measure, is needed to start an iteration to create a row context [2]
• when using iterators, the developer is responsible for creating and handling the row context [2]
• iterates over a table and evaluate its column values [2]
• ⇐ one row at a time
• row context is the result of iterating over rows
• row context equals iteration [2] is not exactly a correct statement
• means that DAX evaluates expressions one row at a time
• during the iteration, DAX creates a row context that gives the formula access to the values of the current row
• functions like SUMX and calculated columns rely on this behavior
• the two aren't identical 
• iteration refers to the process of moving through rows
•  row context is knowledge of the current row during that process
• DAX creates a row context for the current row
• functions like a cursor [2]
• during an iteration, it points to a specific row of the table being iterated, telling the DAX formula which row is currently to be considered [2]
• it does not filter [2][3]
• it simply indicates to DAX which row is currently responsible for providing the values to perform the calculation and where the result of the calculation should go [3]
• it's irrelevant whether a column in the table is used in a particular calculation [3]
• all columns of the table are part of the row context when a calculation is performed [3]
• encountered when (aka created via)
• calculated columns
• the formula defines a calculated column [2]
• iterators 
• perform active iteration over a table [2]
• e.g. SUMX, FILTER, ADDCOLUMNS, etc.
• scans the table row by row, and during the iteration, the row context points to the current row [2]
• the row context is needed to obtain the value of a column for a certain row [2]
• iterator functions create row context while moving through rows
• help create multiple nested row contexts [2] 
• increases the complexity of the code [2]
• can transform into filter context through a mechanism called context transition [3]
• defines the value of a column by providing the exact row [2]
• calculated columns are always executed in a row context [2]
• is not the case for measures [2]
• {limitation} doesn't propagate filters through relationships from one table to another [2]
• {recommendation} use RELATED and RELATEDTABLE to direct and move the row context from one table over to another [2]
• {limitation} does not place any filter [2]
• {concept} context transition 
• occurs when a row context is converted into a filter context [1]
• takes any active row context and transforms it into a filter in the filter context [3]
• requires an active row context [2]
• either CALCULATE is executed or a measure is invoked [2]
• implies a context transition in these conditions [2]
• the row context is transformed into an equivalent filter context [2]
• usually the context transition happens because a measure is being invoked rather than because of an explicit CALCULATE [2]
•  leveraging the context transition leads to better code [2]
• without context transition DAX can only see the current row
• with context transition, DAX can use values from the current row to filter entire tables and compute aggregations
• the process is automatically execute by CALCULATE and CALCULATETABLE [2]
• any statement invoking either of these two functions performs a context transition [2]
• this happens regardless of whether [2]
• the functions functions were written explicitly [2]
• CALCULATE or CALCULATETABLE is used explictely [2]
• a function that conveniently hides CALCULATE or CALCULATETABLE functions from users but still invokes them [2]
• e.g. TOTALYTD
• this happens in calculated columns, whenever [2]
• a row context is present
• a function that iterates over multiple values is used (aka iterators)
• SUMX
• [measures] whenever a measure is invoked, the context transition happens immediately before the measure starts being executed, as if CALCULATE automatically surrounds the measure [2]
• {benefit} opens new ways to optimize the code [2]
• eliminates complex lookup logic
• reduces repeated filtering
• leverages relationships
• enables reusable measures
• improves performance with the storage engine
• pushes work toward the VertiPaq storage engine
• ⇐ highly optimized for aggregations
• {concept} visual calculation [>>]
• {def} DAX calculation that runs directly on a specific visual (table, matrix, chart, etc.) [3]
• {concept} visual calculation context
• context used by visual calculations, where calculations are performed after the visual has already been built
• uses the rows and columns that are visible in the visual itself rather than directly querying the underlying model
• allows users to calculate running totals, moving averages, differences, rankings, and other analyses directly within a visual 
• {recommendation} begin/experiment with simple formulas and relationships to see how context works [5]
• fastest ways to understand how evaluation context actually works
• helps to isolate context behavior 
•  many challenges are related to relationships
• {recommendation} learn filter context before row context
•  filter context appears in  in almost every advanced DAX solution later 
• {recommendation} predict before you run
• discoveries/knowledge results especially when the result differs from expectations
• {recommendation} use simple/small examples
• facilitates review and troubleshooting
• {recommendation} build a playground for learning 
• an experimentation model can prove valuable over time
• {recommendation} use DAX Studio early
•  it allows to inspect query plan, view filter context, analyze storage engine vs formula 
•  

References:

[1] Greg Deckler & Brett Powell (2024) "Microsoft Power BI Cookbook: Convert raw data into business insights with updated techniques, use cases, and best practices" 3rd Ed.

[2] Alberto Ferrari & Marco Russo (2025) The Definitive Guide to DAX: Mastering the semantic model expression language for Microsoft Power BI, Fabric and Excel

[3] Jeroen ter Heerdt et al (2026) "Microsoft Power BI Visual Calculations: Simplifying DAX"

[4] Microsoft Learn (2026) Modify DAX filter context in semantic models [link]

[5] Microsoft Support (202?) Context in DAX Formulas [link]

 

Resources:  

[R1] Microsoft Fabric Community Row vs Filter Context: a Visual Guide [link] 

 

Acronyms:
DAX - Data Analysis eXpressions

RLS - Row Level Security

 

🏭🗒️Microsoft Fabric: Direct Lake [Notes] 🆕

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 13-Oct-2026

[MF] Direct Lake

• {def} Power BI semantic model table storage mode option available in MF [1]
• optimized for large volumes of data to be quickly loaded into memory from Delta tables available in the OneLake [1] 
• leverages VertiPaq query engine [1]
• {benefit} deliver query performance comparable to Import mode 
• without the management overhead of data refresh cycles to load the entire data volume [1]
• similar to Import mode
• {difference}refreshes copies only metadata (aka framing)
•  [Import mode] replicates the data and creates an entire cached copy of the data for the semantic model [1]
•  depends on data preparation being done in the data lake [1]
• {benefit} enables high-performance interactive analysis [1]
•  ideal for semantic models connecting to large data sources
• e.g. lakehouse, warehouse and other data source with Delta tables [1]
• performance depends on well-tuned Delta tables [1]
•  {benefit} performance
• normally outperforms DirectQuery queries when loading and interacting with visuals in reports [1]
• {benefit}maximizes ROI because 
• analyzed data volumes can exceed capacity's max memory limits [1]
• only the needed data to answer a query is loaded into memory [1]  
• {benefit} minimizes data latencies 
•  makes new data available without refresh schedules [1]
• quickly and automatically synchronizing a semantic model with its sources [1]
• {operation} refresh 
• low-cost operation that analyzes the metadata of the latest version of the Delta tables and updates references to the latest files in OneLake
• DL moves data preparation to OneLake
• ⇐ uses the full breadth of Fabric technologies for data prep
• incl. Spark jobs, T-SQL DML statements, dataflows, pipelines, etc.
• {operation} transcoding
• the process of loading data from OneLake only when a query requests a column for the first time 
• {action} the semantic model receives a DAX (or MDX) query 
• {step} determines what columns are needed to produce the result
• {step} determines which columns are already resident in memory [2]
• {step} loads the missing columns from OneLake [2]
•  typically a fast operation, however it can depend on factors 
•  e.g. the cardinality of data stored in the columns
•  remains resident until there's reason for it to be removed (evicted) from memory
• {reason} the model or table was refreshed after a Delta table update at the source [2]
• {reason} no query used the column for some time [2]
• {reason} other memory management reasons [2]
•  e.g. memory pressure in the capacity due to other, concurrent operations [2]
•  SKU determines the maximum available memory for each Direct Lake semantic model on the capacity [2]
• {operation} framing 
• an operation triggered by a refresh of a semantic model [2]
• it usually takes only a few seconds to complete
• ⇐ because it's a low-cost operation where the semantic model analyzes the metadata of the latest version of the Delta Lake tables and updates to reference the latest Parquet files in OneLake [2]
• the process might evict resident table column segments and dictionaries from memory if the underlying data changed [2]
• the point in time of the refresh becomes the new baseline for all future transcoding events [2]
• DL queries only consider data in the Delta tables as of the time of the most recent framing operation [2]
• DL tables are queried to return data based on the state of the Delta table at the point of the most recent successful framing operation [2]
• that time isn't necessarily the latest state of the Delta tables [2]
• the semantic model analyzes the Delta log of each Delta table during framing to drop only the affected column segments and to reload newly added data during transcoding [2]
• {optimization} dictionaries usually aren't dropped when incremental framing takes effect, and new values are added to the existing dictionaries [2]
• helps reduce the reload burden and benefits query performance [2]
• when a Delta table receives no updates, no reload is necessary for columns already resident in memory [2]
•  queries show far less performance impact after framing because incremental framing essentially enables the semantic model to update substantial portions of the existing in-memory data in place [2]
• can fail if a Delta table exceeds the Fabric capacity guardrails [2]
•  e.g. when a Delta table has more than 10,000 parquet files [2]
•  {architecture} Direct Lake on OneLake
•  isn't coupled with the SQL analytics endpoint [2]
•  offers tighter integration with OneLake features such as OneLake security [2]
•  offers more efficient DAX query plans because [2]
• ⇐ isn’t required to check for SQL based security [2]
•  fallback isn't supported [2]
• {architecture} Direct Lake on SQL analytics endpoint
•  a DAX query might use DirectQuery fallback [2]
•  involves seamlessly switching to DirectQuery mode [2]
•  DirectQuery fallback
• retrieves data directly from the SQL analytics endpoint of the lakehouse or the warehouse [2]
•  fallback occurs when SQL based security is detected in the SQL analytics endpoints
•  a DirectQuery operation sends a query to the SQL analytics endpoint. Fallback operations might result in slower query performance [2]
•  {setting} Keep your Direct Lake data up to date
• performs automatic updates of Direct Lake tables [2]
• via semantic model settings >> Refresh 
• {enabled|default} ensures that data changes in OneLake are automatically reflected in the Direct Lake semantic model [2]
•  the semantic model performs a framing operation whenever data modifications in the underlying Delta tables are detected [2]
• {recommendation} leave the setting on, especially when you have a small or medium-sized semantic model
• useful in case of low-latency reporting requirements and Delta tables are modified regularly [2]
•  {disabled} it might be needed to disable automatic updates to allow completion of data preparation jobs or an ETL process before exposing any new data to consumers of the semantic model [2]
•  users can trigger a refresh manually in the Fabric portal [2]
•  via refresh schedule, or programmatically by using the Power BI REST API or TOM [2]
• 
  

References: 
[1] Microsoft Learn (2026) Direct Lake overview [link]
[2] Microsoft Learn (2026) 

Acronyms:
API - Application Programming Interface
DL - Direct Lake 
MDX - Multidimensional Expressions
MF - Microsoft Fabric
REST
SKU - Stock Keeping Unit
TOM - Tabular Object Model
T-SQL - Transact SQL

 

⚡️🗒️Power BI: ALLSELECTED in DAX [Notes]🆕

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 13-Oct-2026

[DAX] ALLSELECTED()

• {def} function that returns all the rows in a table, or all the values in a column [1]
• ignores any filters that might have been applied inside the query [1]
•  removes the corresponding filters from the filter context, restoring the last shadow filter context
• keeps filters that come from outside [1] 
• gets the context that represents all rows and columns in the query, while keeping explicit filters and contexts other than row and column filters 
• does not materialize the resulting table when called directly in a filter argument of CALCULATE or CALCULATETABLE 
• via ALLSELECTED([<tableName> | <columnName>[, <columnName>[, <columnName>[,…]]
• {parameter|optional} tableName
• the name of an existing table 
• cannot be an expression
• {parameter|optional} columnName
• the name of an existing column using standard DAX syntax, usually fully qualified
• cannot be an expression 
• if there is one argument, the argument is either tableName or columnName [1]
• if there is more than one argument, they must be columns from the same table [1] 
• {scenario} used to obtain visual totals in queries [1] 
• {scenario} used as a table expression when it has at least one argument [2] 
• {scenario} used without arguments only as a CALCULATE or CALCULATETABLE modifier [2]  
• {distinction} different from ALL() because 
• it retains all filters explicitly set within the query [1] 
• it retains all context filters other than row and column filters [1] 
• {limitation}[DirectQuery mode] not supported when used in calculated columns or RLS rules [1] 
• only DAX function that leverages shadow filter contexts [3] 
• has a slightly different behavior when
• used in SUMMARIZECOLUMNS 
• mostly produces the expected result [3] 
• removes filters for the currently-iterated group-by column, restoring the original filter set by SUMMARIZECOLUMNS itself [3] 
• SUMMARIZECOLUMNS  can be used in nearly all the visuals [3] 
• inside an iterator
• {warning} can produce weird results [3] 
• does not return the values of a column (or table) filtered outside a visual [3] 
• displays different behaviors, depending on whether it is used in SUMMARIZECOLUMNS or not, and on the presence of shadow filter contexts [3]
• {best practice} don’t create a measure that uses ALLSELECTED within an iteration [3]
•  it can produce unexpected results, poor performance, and difficult-to-understand calculations.
• {best practice} minimize the use of measures that contain ALLSELECTED [3]
• can be safely used only in measures that are directly placed in the reports [3] 
•  

Previous Post <<||>> Next Post

References: 
[1] Microsoft Learn (2026) DAX: ALLSELECTED [link]
[2] DAX Guide (2026) ALLSELECTED DAX Function (Filter) SQL[link]
[3] SQLBI (2026) ALLSELECTED Best Practices [link]

💎🏭SQL Reloaded: QUALIFY in Microsoft Fabric (Before/After)

One recent addition to T-SQL is the QUALIFY clause, which filters rows returned by a query based on a search condition that can reference window (analytic) functions [1]. The QUALIFY clause allows filtering directly in the block in which the window function is defined. According to the documentation QUALIFY can be used directly after HAVING clause:

SELECT select_list
FROM   table_source
[ WHERE <search_condition> ]
[ GROUP BY group_by_specification ]
[ HAVING <search_condition> ]
[ QUALIFY <filter_condition> ]
[ ORDER BY <order_by_expression> [ , ...n ] ]
[ FOR JSON <options> ]

So, for example, if we consider a fictitious Sales Invoices table, to retrieve the customers who bought a product more than once, we had to apply the constraint outside the block in which the window function was defined:

-- product bought more than once by same customer (before)
SELECT *
FROM (-- calculating resultset
	SELECT customer_id
	, product_id
	, SUM(quantity) OVER(PARTITION BY invoice_id, product_id) total_quantity
	FROM [Sales].[sales_invoices]
) DAT
WHERE total_quantity>1

Now, a constraint can be applied directly in the block with the window function via QUALIFY followed by one or more constraints:

-- product bought more than once by same customer (after) 
SELECT customer_id
, product_id
, SUM(quantity) OVER(PARTITION BY invoice_id, product_id) total_quantity
FROM [Sales].[sales_invoices]
QUALIFY SUM(quantity) OVER(PARTITION BY invoice_id, product_id)>1

Given the order in which the constraints are processed, QUALIFY allows to reduce redundancy by referencing a new column defined in the SELECT statement (update 19-Oct-2026):

-- product bought more than once by same customer (after) 
SELECT customer_id
, product_id
, SUM(quantity) OVER(PARTITION BY invoice_id, product_id) total_quantity
FROM [Sales].[sales_invoices]
QUALIFY total_quantity>1

Hopefully this is available on all supported platforms. Otherwise, the logic must be repeated if a second constraint is needed for checking whether the value is within a boundary. Upon case, the logic can become even more complex (e.g. multiple intervals are checked):

-- product bought more than once by same customer (after) 
SELECT customer_id
, product_id
, SUM(quantity) OVER(PARTITION BY invoice_id, product_id) total_quantity
FROM [Sales].[sales_invoices]
QUALIFY SUM(quantity) OVER(PARTITION BY invoice_id, product_id)>1

  AND SUM(quantity) OVER(PARTITION BY invoice_id, product_id)<10

Imagine how complex can become a query like the following (update 19-Oct-2026):

-- product bought more than once by same customer with interval testing
SELECT customer_id
, product_id
, SUM(quantity) OVER(PARTITION BY invoice_id, product_id) total_quantity
FROM [Sales].[sales_invoices]
QUALIFY (total_quantity>1 AND total_quantity)<10)

    OR (total_quantity>21 AND total_quantity)<30)

    OR (total_quantity>41 AND total_quantity)<50)

    OR (total_quantity>61 AND total_quantity)<70)  

Notes:
1) Having fewer blocks of code improves in theory code's readability and hopefully maintainability when the code doesn't need to be replicated as in the last example. This approach should improve also performance, however further tests are needed to validate this. 
2) It's useful to include the same logic used in QUALIFY also in the main SELECT statement, at least for troubleshooting purposes. 
3) The syntax seems to be supported only in Fabric warehouse, respectively SQL Endpoints for warehouse, lakehouse and SQL database.4) QUALIFY clause requires at least one window function in the SELECT list, ORDER BY list or QUALIFY expression (see Msg 8826, Level 16).
4) QUALIFY clause requires at least one window function in the SELECT list, ORDER BY list or QUALIFY expression (see Msg 8826, Level 16). (update 19-Oct-2026)
5) One should check also whether the syntax is supported by all the features. For example, it's not supported by UPDATE and DELETE statements in warehouse. The restrictions for SQL Endpoints should be considered as well.
6) Developers must consider also portability of code when it's the case.
7) According to Copilot, QUALIFY is supported in Teradata (originator of the feature), Snowflake, Google BigQuery, Amazon Redshift, Databricks SQL, DuckDB and ClickHouse. (update 19-Oct-2026)
8) Of course, the window functions can be mixed to address different business questions, though it's maybe a good idea to move the DENSE_RANK in SELECT and reference the new column within QUALIFY (update 19-Oct-2026):

-- first/last customer by product incl. total
SELECT product_id
, SUM(quantity) OVER(PARTITION BY product_id) quantity_total
, FIRST_VALUE(customer_id) OVER(PARTITION BY product_id ORDER BY invoice_date ASC) first_status
, LAST_VALUE(customer_id) OVER(PARTITION BY product_id ORDER BY invoice_date DESC) last_status
FROM [LH_CRM_Data].ERP.[sales_invoices_partitioned4]
QUALIFY DENSE_RANK() OVER(PARTITION BY product_id ORDER BY invoice_date)=1

Happy coding!

References:
[1] Microsoft Learn (2026) SELECT - QUALIFY clause (Transact-SQL) [link]

🤖〽️Prompt Engineering: Copilot Unabridged (Part 216: How Long Can Microsoft and Other Vendors Sustain Massive AI Investments Before It Becomes an Economic Bubble?)

Prompt Engineering Series

Prompt: "write a post of 600 words on the impact of consistent and high‑quality training data on AI"

Introduction

Over the past several years, Microsoft, Google, Amazon, Meta, and other technology giants have invested unprecedented sums into Artificial Intelligence (AI). They are building GPU superclusters, expanding datacenter capacity, training frontier‑scale models, and subsidizing AI usage across consumer and enterprise products. These investments are justified by the belief that AI will become the next foundational computing platform - driving productivity, reshaping cloud economics, and unlocking new trillion‑dollar markets.

But massive investment comes with massive risk. If AI adoption, monetization, and real‑world impact fail to keep pace with spending, the industry could find itself in a classic economic bubble: inflated expectations, unsustainable burn rates, and a painful correction. The key question is how long vendors can sustain this trajectory before the imbalance becomes too large to ignore.

1. Financial Strength Buys Time - But Not Unlimited Time

Microsoft, Google, and Amazon have enormous financial buffers. Microsoft alone generates more than $80 billion in annual operating income, giving it the ability to absorb AI losses for several years. This financial resilience allows vendors to continue investing even when short‑term returns are modest.

However, financial strength is not infinite. If AI revenue fails to scale, vendors will eventually face pressure to reduce capital expenditure. The sustainability window is long - 3 to 7 years - but not indefinite. This is the core of financial runway.

2. Investor Expectations Are the Real Timer

Investors currently tolerate massive AI losses because they believe in long‑term returns. As long as vendors show:

• rapid adoption
• credible monetization pathways
• strong ecosystem growth
• increasing enterprise integration
• the market remains patient. 

But if expectations diverge too far from reality, investor sentiment can shift quickly.

A bubble forms when expectations grow faster than fundamentals. If AI revenue plateaus while spending accelerates, investors will demand:

• reduced spending
• clearer profitability timelines
• more conservative guidance

This is the dynamic of expectation inflation.

3. Infrastructure Expansion Has Natural Limits

Even if vendors wanted to sustain massive spending indefinitely, physical constraints prevent it. Datacenters require land, power, cooling, and specialized hardware. Supply chains for GPUs and networking fabric are already strained.

These constraints slow the pace of expansion and act as a natural brake on bubble formation. Vendors cannot overspend infinitely because the infrastructure simply cannot scale infinitely. This is the logic behind infrastructure bottlenecks.

4. The Bubble Threshold: When Costs Outrun Value

An economic bubble emerges when the perceived future value of AI becomes disconnected from its actual economic output. Warning signs include:

• AI revenue growing slower than AI costs
• enterprises reducing or delaying adoption
• vendors subsidizing usage at unsustainable levels
• datacenter expansion outpacing utilization
• investors questioning long‑term profitability

If these trends intensify, the bubble becomes visible. Most analysts believe the industry has 3–5 years before this risk becomes acute.

5. What Happens If the Bubble Pops?

If AI fails to meet expectations, vendors would be forced to:

• cut capital expenditure
• slow frontier‑model training
• consolidate datacenter expansion
• shift focus to smaller, more efficient models
• prioritize profitable cloud workloads

The industry would not collapse - but it would undergo a painful correction.

Conclusion

Microsoft and other vendors can sustain massive AI investments for several years thanks to strong balance sheets, strategic necessity, and investor patience. But if AI fails to deliver the expected economic transformation, the industry risks drifting into an economic bubble where spending outpaces value creation.

The sustainability window is long - but not limitless. Without measurable returns, vendors will eventually face pressure to reduce spending, recalibrate expectations, and shift toward more efficient AI strategies. The next few years will determine whether AI becomes the next great computing platform - or the next great over‑investment cycle.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🤖〽️Prompt Engineering: Copilot Unabridged (Part 215: What Happens If AI Investments Don’t Meet Expectations?)

Prompt Engineering Series

Prompt: "write a post of 600 words and explain what will happen if the AI investments made by Microsoft and other vendors don't meet the expectations"

Introduction

Over the past five years, Microsoft, Google, Amazon, Meta, and other tech giants have poured unprecedented amounts of capital into Artificial Intelligence (AI) . They have built GPU superclusters, expanded datacenter footprints, acquired strategic partners, and trained frontier‑scale models that cost hundreds of millions per run. These investments are justified by the belief that AI will become the next foundational computing platform - bigger than cloud, bigger than mobile, and potentially bigger than the internet itself.

But what if this future doesn’t materialize as expected? What if adoption slows, monetization lags, or the technology fails to deliver the transformative productivity gains vendors promise? The consequences would be profound, reshaping corporate strategy, investor sentiment, and the trajectory of the entire industry.

1. Financial Pressure Would Force a Strategic Reset

If AI revenues fail to scale, the first impact would be financial compression. AI infrastructure is extraordinarily expensive, and vendors currently tolerate losses because they expect future dominance. Without that payoff, companies would be forced to:

• Reduce capital expenditure on datacenters
• Slow GPU procurement
• Consolidate or cancel frontier‑model training cycles
• Shift investment back toward profitable core businesses

This is the classic pattern of strategic retrenchment - a pivot from aggressive expansion to defensive cost control.

2. Cloud Growth Would Stall

AI is the engine driving the next wave of cloud adoption. If AI underperforms, cloud hyperscalers would lose a major growth vector. Azure, AWS, and Google Cloud rely on AI workloads to justify new datacenter regions and premium compute tiers.

A slowdown would mean:

• Lower utilization of new datacenters
• Reduced demand for high‑margin GPU instances
• Pressure on cloud revenue forecasts

This would be especially painful for Microsoft, whose AI strategy is tightly integrated with Azure’s long‑term growth.

3. Investor Confidence Would Erode

Right now, investors tolerate massive AI losses because they believe in long‑term returns. If expectations are not met, that tolerance evaporates. The market would demand:

• Clear profitability timelines
• Reduced spending
• More conservative guidance
• A shift toward predictable revenue streams

This is the dynamic of market correction - a recalibration of expectations that forces vendors to justify every dollar spent.

4. Competitive Dynamics Would Shift

If frontier‑scale AI fails to deliver, the competitive landscape changes dramatically. Companies that bet heavily on large models would lose strategic leverage, while those investing in smaller, specialized, or hybrid approaches could gain ground.

Meta’s open‑source strategy, for example, would look far more attractive if massive proprietary models fail to produce returns. Smaller vendors could also rise by focusing on niche, cost‑efficient AI rather than universal intelligence.

This is the logic behind competitive inversion.

5. Enterprise Adoption Would Slow

Enterprises currently experiment with AI because vendors subsidize usage. If investments fail, subsidies shrink, prices rise, and adoption slows. Companies would revert to:

• Traditional automation
• Classical machine learning
• Rule‑based systems
• Domain‑specific analytics

AI would remain useful - but not transformative.

Conclusion

If AI investments fail to meet expectations, the consequences would be severe but not catastrophic. Vendors would survive, but the industry would undergo a major strategic reset. Spending would decline, cloud growth would slow, investor pressure would intensify, and the competitive landscape would shift toward smaller, more efficient models.

AI would still matter - but it would no longer be the defining platform of the next era. The companies that adapt fastest to this reality would shape the future, whether or not frontier‑scale AI delivers on its promise

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🤖〽️Prompt Engineering: Copilot Unabridged (Part 214: How Long Can Microsoft and Other Vendors Sustain Massive AI Losses?)

 

Prompt Engineering Series

Prompt: "write a post of 600 words and explain how long the AI investments can be sustained by Microsoft and other vendors as they generate huge losses"

Introduction

The Artificial Intelligence (AI) boom has triggered one of the largest capital outlays in the history of technology. Microsoft, Google, Amazon, Meta, and others are spending tens of billions of dollars annually on GPUs, data centers, research partnerships, and frontier‑model development. These investments generate enormous short‑term losses, raising a critical question: How long can this level of spending be sustained?

The answer depends on three forces: financial capacity, strategic necessity, and market expectations. Together, they determine how long vendors can tolerate losses before AI must begin paying for itself.

1. Financial Capacity: The Balance Sheet Determines the Burn Rate

Microsoft, Google, and Amazon are not startups - they are trillion‑dollar companies with deep cash reserves, diversified revenue streams, and high creditworthiness. This gives them the ability to sustain losses for years, not months.

Microsoft alone generates more than $80 billion in annual operating income, which acts as a buffer for AI losses. As long as core businesses - cloud, enterprise software, Windows, Office - continue to perform, Microsoft can redirect profits to subsidize AI expansion.

This is why financial resilience is the first determinant of sustainability.

2. Strategic Necessity: AI Is Not Optional

AI is the next computing platform. Vendors know that whoever controls the dominant AI ecosystem will shape:

• cloud workloads
• enterprise automation
• developer tooling
• search and advertising
• productivity software

This creates a strategic imperative: spend now or become irrelevant later.

Microsoft’s partnership with OpenAI is not just an investment - it is a defensive moat against Google’s Gemini, Amazon’s Anthropic partnership, and Meta’s open‑source strategy.

This is the logic behind strategic dependency.

3. Market Expectations: Investors Tolerate Losses - For Now

Investors understand that frontier AI is a long‑term play. As long as vendors demonstrate:

• rapid adoption
• strong ecosystem growth
• credible monetization pathways
• increasing enterprise integration
• the market will tolerate losses.

But this tolerance is not infinite. If revenue growth stalls or adoption plateaus, investor pressure will force vendors to slow spending.

This is the dynamic of market tolerance.

4. The Real Constraint: Infrastructure Saturation

The biggest limiting factor is not money - it is physical infrastructure.

Datacenters take years to build. Power grids must be upgraded. Supply chains for GPUs and networking fabric are constrained.

Even if vendors wanted to double spending, they often cannot.

This natural bottleneck slows the burn rate and extends sustainability.

This is the core of infrastructure saturation.

5. When Does the Spending Plateau?

Most analysts expect the current hyper‑investment phase to last 3–5 more years, followed by a stabilization period where:

• model training becomes more efficient
• inference costs decline
• monetization improves
• enterprise AI revenue grows
• datacenter expansion reaches maturity

At that point, losses shrink and AI becomes a net contributor rather than a drain.

Conclusion

Microsoft and other vendors can sustain massive AI losses for several years because they have the financial strength, strategic motivation, and investor support to do so. But this spending cannot continue indefinitely. Physical infrastructure limits, competitive pressure, and the need for profitability will eventually force a shift from expansion to optimization.

AI is following the same pattern as cloud computing: a decade of heavy losses, followed by decades of dominance. The companies investing today are not trying to win the next quarter - they are trying to win the next era of computing.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🤖〽️Prompt Engineering: Copilot Unabridged (Part 213: Why Massive AI Investments Generate Massive Losses)

Prompt Engineering Series

Prompt: "write a post of 600 words and explain why the AI investments made by Microsoft and other vendors generate huge losses,. "

Introduction

Artificial Intelligence (AI) has become the defining battleground of modern technology. Microsoft, Google, Amazon, Meta, and others are pouring tens of billions into AI infrastructure, model training, and ecosystem development. Yet despite explosive public interest and rapid enterprise adoption, these companies report staggering short‑term losses tied directly to their AI initiatives.

This paradox - sky‑high investment, sky‑high losses-is not a sign of failure. It is a structural feature of frontier‑scale AI. To understand why, we need to examine the economics behind training large models, the infrastructure required to run them, and the strategic pressures that force vendors to spend aggressively even when profitability is years away.

1. Frontier‑Model Training Costs Are Exponential

Training a frontier model is not a linear expense. Each generation requires more parameters, more training tokens, larger datasets, and more compute cycles. A single training run for a cutting‑edge model can cost hundreds of millions of dollars.

This is why frontier‑model training is the first and most visible driver of losses. Vendors must run multiple training cycles, safety evaluations, fine‑tuning passes, and inference optimizations. Microsoft’s partnership with OpenAI means Azure absorbs the bulk of these compute costs, directly impacting earnings.

2. Infrastructure Build‑Out Is Historically Unprecedented

AI does not run on ordinary cloud servers. Vendors must build:

• GPU superclusters
• High‑bandwidth networking fabrics
• Liquid‑cooling systems
• Specialized datacenters optimized for AI workloads

Each hyperscale datacenter costs $1–$2 billion, and hardware depreciates quickly. Today’s top‑tier GPU becomes mid‑tier in 18–24 months. This creates a cycle of continuous capital expenditure that depresses short‑term profitability.

This is the core of AI infrastructure economics.

3. Inference Costs Scale With Usage

Traditional software has near‑zero marginal cost. AI does not.

Every query to a large model consumes compute, electricity, and cooling. When millions of users interact with Copilot, ChatGPT, Gemini, or Claude, vendors pay for every token generated.

This is why AI inference is a structural loss generator: revenue must grow faster than usage to break even, which rarely happens in early adoption phases.

4. Monetization Is Still Immature

Most users expect AI to be:

• Free
• Unlimited
• Always available

But the cost structure makes that impossible. Vendors experiment with subscriptions, API pricing, enterprise licensing, and usage‑based billing, yet none of these models currently offset the full cost of running frontier AI.

This is the challenge of AI monetization.

5. Competition Forces Overspending

AI is an arms race. No vendor can afford to fall behind. This creates irrational spending patterns:

• Microsoft invests heavily to stay ahead with OpenAI
• Google accelerates Gemini development
• Amazon pours billions into Anthropic
• Meta open‑sources massive models to shape the ecosystem

In an arms race, losses are tolerated because the alternative is losing strategic control of the next computing platform. This is the logic behind competitive overspending.

Conclusion

AI investments generate huge losses because vendors are not selling a finished product—they are building the foundation of a new computing era. Frontier‑scale AI requires unprecedented capital, massive compute, and continuous reinvestment. The losses are not a sign of weakness; they are the cost of securing future dominance in a market that will reshape productivity, cloud infrastructure, search, advertising, and enterprise automation

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post 

🏭𝐌𝐢𝐜𝐫𝐨𝐬𝐨𝐟𝐭 𝐅𝐚𝐛𝐫𝐢𝐜: 𝐃𝐚𝐭𝐚 𝐖𝐚𝐫𝐞𝐡𝐨𝐮𝐬𝐞 (𝐓𝐞𝐜𝐡𝐧𝐢𝐜𝐚𝐥 𝐎𝐯𝐞𝐫𝐯𝐢𝐞𝐰)

 Introduction (Some Background)

Typically, PowerPoint slides and similar content must be broken in small pieces and structured in such a way that the audience can digest the information presented. Thus, a presentation ends up spreading over multiple slides that must be structured in such a way that it facilitates also digestion, retention, and whatever further aspects are targeted. Conversely, on social networks the average author/publisher has only a small chance of capturing an audience's attention, given that the competition for readers' attention increases exponentially in the long sequence of posts. So, what information would we show for this purpose? 

When I want to learn something, typically I need a few pieces of information/knowledge that would allow me to anchor and integrate the text into existing knowledge. It usually starts with high-level definitions of the main concepts that reflect the various aspects that would help me associate and differentiate the respective concepts from similar concepts or knowledge. The volume of such information depends on many aspects - the complexity of the concepts and the contexts they belong to, how many similar concepts or metaphors are available, the gaps available, analogies and differentiators, etc.

A high-level list of the main capabilities for the respective concept(s) would further allow a (wider) surface to anchor the various information of interest. No matter how much text can be included, we shouldn't forget that a (well-chosen) picture is (often) worth a thousand words. Therefore, a well-chosen image that depicts a high-level representation of the concepts/ideas presented, the architecture or even a metaphor can have a considerable impact on the readers.  

Ideally the image should serve as a sketch or sample of the finished product. Then, even if from the used representation one can guess what are the ingredients used, the difference between a good dish and a fiasco often resides in details. Like in preparing a dish, one needs to know what ingredients are needed and how they must be prepared and used together, for the maximum effect. An experienced cook needs at least the list of ingredients and some general information on how the dish differentiates from other dishes. The more inexperienced the cook, the more information needs to be provided and somewhere a line must be drawn, otherwise a simple recipe becomes the cookbook itself. Therefore, like in any cookbook, I must assume that some basic knowledge is available!

So, as part of the learning/teaching process, I started a series of slides on Microsoft Fabric that should help me narrow down the recipes for delivering great products. The information comes from training material, various presentations delivered by Microsoft or third-parties, the various books and other technical material I read over the years. 

Let's start with the basics - the (data) warehouse!

   📣Technical Overview 

    

Conclusion

The slide barely scratches the surface, especially if we consider it from a broader context - what the average professional must know. Even if the gap between the presented information and a business case, for example, or anything similar capable of convincing the audience is considerable, the slide should serve as a starting point, if not a foundation on which something durable can be built. 

Enjoy the ride and feel free to like it, download it, respectively share it further!

🤖〽️Prompt Engineering: Copilot Unabridged (Part 212: How Multi‑Modal Stressors Enable Holistic Evaluation Through Incomplete or Corrupted Inputs in AI Models)

Prompt Engineering Series

Prompt: "write a post of 600 words on how to use multi‑modal stressors for holistic evaluation in which stress testing reflects the complexity through incomplete or corrupted inputs in AI models"

Introduction

As Artificial Intelligence (AI) systems expand into multi‑modal architectures - processing text, images, audio, diagrams, tables, and code - their vulnerabilities become more complex. Real‑world environments rarely present clean, perfectly aligned inputs. Instead, models must interpret incomplete, corrupted, or partially contradictory signals across modalities. This is where multi‑modal stressors become essential. By deliberately introducing degraded or inconsistent inputs, evaluators can observe how the model prioritizes signals, how it compensates for missing information, and where its reasoning begins to break down.

Incomplete or corrupted inputs matter because each modality activates different representational pathways. Text relies on linguistic priors; images rely on spatial embeddings; audio relies on temporal patterns; code relies on structural logic. When one modality is degraded, the model must decide whether to rely more heavily on the remaining modalities or attempt to reconstruct the missing information. That decision exposes its internal hierarchy of cues, a central theme in instruction‑priority testing.

One of the simplest multi‑modal stressors is the partially corrupted image. For example, an image may be blurred, occluded, or missing key regions, while the accompanying text describes a scene that may or may not match the visible content. This tests whether the model over‑trusts visual fragments or defaults to textual interpretation. The result reveals how the model resolves conflicts between incomplete sensory input and linguistic cues - an essential capability for real‑world robustness.

A more advanced technique involves cross‑signal incompleteness, where each modality is missing different pieces of information. For example:

• The text describes an event but omits the key actor.
• The image shows the actor but hides the action.
• The audio clip provides environmental noise but no speech.

The model must integrate these partial signals to form a coherent interpretation. This exposes whether the model can perform multi‑modal reconstruction, or whether it collapses into hallucination or over‑generalization - patterns often surfaced through weak‑point analysis.

Another powerful stressor is corrupted‑modality contradiction, where the corruption itself creates misleading cues. For example, a distorted audio clip may sound angry even though the text describes a calm conversation. Or a corrupted diagram may misalign labels, contradicting the accompanying explanation. These stressors force the model to determine whether the corruption is noise or signal. The model’s behavior reveals whether it can distinguish reliable from unreliable modalities, a key insight for holistic evaluation.

Incomplete inputs can also be used to test temporal resilience. A video clip may drop frames, skip segments, or freeze mid‑action, while the text describes a continuous sequence. The model must decide whether to trust the visual timeline or the textual narrative. This exposes how the model handles temporal reasoning, a capability often overlooked in single‑modality evaluation.

The most challenging multi‑modal stressors involve hybrid corrupted inputs, where multiple modalities degrade in different ways. For example:

• A table with missing values contradicts a narrative summary.
• A diagram with corrupted labels conflicts with a code snippet.
• An audio clip with static obscures key words while the text misidentifies the speaker.

These hybrid contradictions push the model into conceptual regions where no training example exists. The resulting behavior reveals the model’s cross‑modal arbitration strategy, a crucial insight for understanding its robustness.

Ultimately, multi‑modal stressors that use incomplete or corrupted inputs allow evaluators to move beyond surface‑level robustness. By introducing degradation across text, images, audio, diagrams, and structured data, we can map the deep architecture of model reasoning - how it prioritizes modalities, how it compensates for missing information, and where its internal logic becomes unstable. This is the next frontier of boundary‑stress evaluation: not just testing what the model can do, but testing how it behaves when the world becomes noisy, partial, and imperfect.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post