Summary

The native single-level reference Include path (EF-368) declines a join whose inner sequence is not a bare collection scan, which closes query filters in all three spellings (anonymous, TPH-root-inherited, and EF10 named). It does not close TPH discriminator narrowing: an Include whose target is a derived entity type in a TPH hierarchy is admitted natively, because EF records no discriminator predicate on the join's inner select, so the bare-collection-scan check is satisfied.

Measured

Probed on branch EF-368 at the fix-wave commit, using a derived-type Include target (Ticket.Owner : VipParty, query filter removed, otherwise the EF-368 test model):

• MongoQueryMode.NativeOnly succeeds - no decline. The shape goes native with a plain $lookup + $unwind carrying no discriminator condition.
• The one shape where the missing discriminator could plausibly matter - a required navigation typed to the derived type whose foreign key points at a base-type document - throws InvalidOperationException identically under Native, DriverLinq and NativeOnly.

Severity, stated precisely

• No measured wrong data. There is no mode divergence in any probed shape, so this is not in the same class as the query-filter hole EF-368 fixed (which returned 2 rows where 1 was correct, in every mode).
• Not a regression introduced by EF-368. The metadata-based guard that EF-368 replaced did not check discriminators either, and the native collection-Include path (EF-339) appears to share the same gap.
• It is filed because it is an unguarded case in a guard family whose other members are all closed, in an area that has produced silent-wrong-data bugs three times (EF-358, EF-369/EF-370, and the EF-368 query-filter hole). The risk is that a future widening - admitting ThenInclude, sibling references, or nav-expansion LeftJoin generally - reaches a shape where the absent discriminator does change the row set.

What to do

First, determine whether a TPH derived-type reference Include can ever return rows the driver-LINQ fallback would not - i.e. whether the absent discriminator is observable for any reachable data shape. If it cannot, close as by-design and record why in src/MongoDB.EntityFrameworkCore/Query/AGENTS.md.

If it can, either add the discriminator to the emitted $lookup (a pipelineform lookup with a $match on the discriminator field) or decline the shape - and check whether EF-339's collectionInclude path needs the same treatment.

Where this is recorded

docs/superpowers/specs/2026-08-04-native-reference-include-design.md (the conjunct 2 and conjunct 5 as-built notes) and the inline comments on TryConfirmReferenceInclude and MongoSelectDefinition.IsBareCollectionScan all state explicitly that discriminator narrowing is not closed. An earlier revision of those comments claimed it was; that claim was measured false and corrected before EF-368 was squashed.