The reporting owner needs a release diagnosis and a corrected customer order-count model. Build five evidence artifacts, preserve customers without orders, then recommend the smallest semantic repair from the supplied release evidence.
A Harbor Cart report changed after a release that was meant to clean text codes.
The model still compiles, but duplicate updates now enter the mart and customers without matching orders disappear. You need to rebuild the evidence at each grain and identify the release correction that addresses the actual regression. Don't explain a count change with an invented business trend.
Keep raw records available for comparison. First establish current order and customer models, then build a customer-level count with the intended join. Inspect missing amounts separately so a cleanup doesn't turn unknown into recorded zero.
The last step gives you the failing release behavior and asks for a checked recommendation. A materialization change can alter execution cost, but it doesn't repair a multiplied join or a dropped unmatched entity.
select order_id, customer_id, lower(trim(status)) as status, amount, ordered_at, updated_at, upper(trim(currency)) as currency from {{ source('shop', 'orders') }} where order_id is not null qualify row_number() over (partition by order_id order by updated_at desc, amount desc nulls last)=1
The example shows the connected analytics project pattern. Follow the stated business rule when applying it.