JustDummies

The composer never reads the parameter one of the operands is bound to, so that operand is drawn and thrown away.

Combine generates every part before calling the composer — constraints built, conflict checks run, value produced — and then drops it. Nothing fails: the composed value is well-formed, and simply does not carry the part the call site says it carries.

Noncompliant

IAny<Customer> customer = Any.Combine(
    Any.String().NonEmpty().WithMaxLength(50),
    Any.String().StartingWith("ORD-").WithLength(12),
    (name, reference) => new Customer(name));      // JD027: 'reference' never reaches the Customer

Compliant

IAny<Customer> customer = Any.Combine(
    Any.String().NonEmpty().WithMaxLength(50),
    Any.String().StartingWith("ORD-").WithLength(12),
    (name, reference) => new Customer(name, OrderReference.Create(reference)));

Or drop the operand entirely, if it is genuinely not part of the value:

IAny<Customer> customer = Any.String().NonEmpty().WithMaxLength(50).As(name => new Customer(name));

Saying the draw is deliberate

Name the parameter _, the same way C# spells “I know, and I mean it” anywhere else:

Any.Combine(first, second, (value, _) => new Wrapper(value))   // no diagnostic

Why it happens

The two shapes seen most often are a constructor argument forgotten during a refactor, and a composer whose parameters no longer line up with its operands after one was inserted in the middle. Both leave a generator whose carefully written constraints have no effect on anything the test observes.

What it does not flag

• A parameter named _.
• A composer passed as a method group — its body is not necessarily this compilation’s to read, so which operands it uses is not knowable.
• A composer whose whole body is a throw. It reads no parameter by construction, and is exercising the failure path Combine wraps rather than ignoring an operand.
• A parameter read only inside a nested lambda: that still counts as read.