Our API processes Bounds with a conservative approach, allowing clients to specify them as either 'Inclusion' or 'Exclusion' types. Clients provide one pair of bounds at a time, tagged accordingly. The philosophy is to ensure safety by:
Intersecting Inclusion Bounds: Multiple Inclusion bounds intersect to form the narrowest possible range, focusing on restrictive aggregation.
Unioning Exclusion Bounds: Multiple Exclusion bounds merge into a broad range, aiming for extensive coverage.
This method ensures that the aggregated bounds is never less conservative than any of the input bounds.
However, in reporting bounds within data streams, we've moved away from labeling them as 'Inclusion' or 'Exclusion'. Instead, we return a single list of bounds, accepting any input request parameter falling within these bounds. This shift leads to a discrepancy: users specify bounds with labels, but receive an unlabeled, aggregated list. This mismatch could cause confusion about the bounds' interpretation.
Proposed solution
A potential solution is to let users submit a list of bounds without specifying 'Inclusion' or 'Exclusion'. Our service could then intersect these lists to derive a final, conservatively aggregated set of bounds, aligning with our cautious approach.
What's needed?
Our API processes
Boundswith a conservative approach, allowing clients to specify them as either 'Inclusion' or 'Exclusion' types. Clients provide one pair of bounds at a time, tagged accordingly. The philosophy is to ensure safety by:This method ensures that the aggregated bounds is never less conservative than any of the input bounds.
However, in reporting bounds within data streams, we've moved away from labeling them as 'Inclusion' or 'Exclusion'. Instead, we return a single list of bounds, accepting any input request parameter falling within these bounds. This shift leads to a discrepancy: users specify bounds with labels, but receive an unlabeled, aggregated list. This mismatch could cause confusion about the bounds' interpretation.
Proposed solution
A potential solution is to let users submit a list of bounds without specifying 'Inclusion' or 'Exclusion'. Our service could then intersect these lists to derive a final, conservatively aggregated set of bounds, aligning with our cautious approach.
Use cases
No response
Alternatives and workarounds
No response
Additional context
No response