Allow negative departure_load values in stop_visits

[chrisyamas]

Summary

Removes the minimum: 0 constraint from stop_visits.departure_load to permit negative values. APC boarding and alighting counts are probabilistic measurements, and forcing non-negative loads introduces systematic upward bias in aggregated metrics such as passenger miles (see #270 for the statistical argument and the NTD compliance context from C-TRAN).

It was decided to bring this forward as a PR during the Summer 2026 Issues Working Group meeting, and that decision was further validated and confirmed at the July and August 2026 Contributors Group meetings.

This is a non-breaking normative change (constraint relaxation): all previously conformant data remains conformant.

Resolves #270

Changes

Schema Changes (stop_visits)

• departure_load: removed the minimum: 0 constraint
• departure_load: expanded the field description (non-normative) to note that negative values may occur in unadjusted APC data and that producers should indicate when negative values are present and how to interpret them

Other Files Updated

• CHANGELOG.md

Notes

• Per the issue discussion, the expectation is that negative values appear in raw or unadjusted data and that producers strive to remove them from processed datasets. Where a producer designates the presence and meaning of negative values (for example datapackage.json metadata vs. table-level convention) remains an open documentation question from the issue thread and is out of scope here.
• bike_load carries the same constraint and is left unchanged; out of scope for 🐛📄 – Stop Visits departure_load minimum: 0 biases aggregations #270.
• The v1.0 to v2.0 migration guide (Add v1.0 to v2.0 migration guide #274) should gain a consumer note that departure_load may be negative.

Review checklist

Per change management policy, the following must be met before feature branch changes can merge to develop branch:

• All JSON files validate
• Reviewed and approved by 2+ contributors or board members

---

Community review status (updated August 27, 2026)

How community review works: Per the TIDES Change Management Policy, a proposal moves forward once at least three TIDES Contributors outside the originating working group publicly comment with a score: Accepted, Accepted with minor changes, or Substantially revised. A few sentences with your read of the proposal is a complete review.

Originating working group (July 1, 2026 vehicles session): Christopher Yamas, John Levin, Laurie Merrell, Gabriel Sánchez Martínez, Joey Reid. Their work is reflected in the proposal itself; community review comes from Contributors beyond this group.

Review so far: Community review is complete: @CTRAN-Sutinen (who raised the underlying issue #270) and @jabhij have posted scored reviews, and @mtnsguy weighed in supporting the change.

Thanks to everyone who has weighed in on this proposal; it is moving into final consideration for v2.0. Further comments are always welcome.

[github-actions]

Documentation available at: http://tides-transit.github.io/TIDES/feature/issue-270-departure-load

[botanize]

This is ok, but all observations are subject to error, not just passenger counts, what distinguishes departure_load from passenger ons is that departure_load is usually derived from passenger ons and offs. I think what we want to highlight in the documentation is that these tend to be derived and not directly observed, and so have relaxed constraints.

[lauriemerrell]

Cosign Joey's comments

[chrisyamas]

@CTRAN-Sutinen this PR implements your #270 proposal. The minimum: 0 constraint is removed from stop_visits.departure_load, and the description now uses Joey's derived vs. observed framing for why negative values are possible and permitted.

Since the analysis behind it is yours, a comment with a score (Accepted / Accepted with minor changes / Substantially revised) would formalize your review on this one.

[chrisyamas]

@mtnsguy thanks for weighing in. The point that the observation error often isn't in the record that ends up negative is a strong addition, and belongs in how producers think about corrections.

If you're comfortable with the full change, a comment with a score (Accepted / Accepted with minor changes / Substantially revised) makes it count toward community review.

[CTRAN-Sutinen]

Looks good to me!

[jabhij]

Accepted with minor changes

I support removing the minimum: 0 constraint from departure_load. The distinction between observed APC inputs and a derived load is important here: because departure_load can be calculated from boarding and alighting observations, measurement error can legitimately produce negative derived values, particularly at low loads.

My only recommendation is to make the producer/consumer expectations around these values slightly more explicit. Removing the constraint establishes that negative values are valid, but it does not necessarily tell a downstream consumer whether a negative value should be interpreted as an unadjusted measurement, a correction signal, or simply a value that should be retained for aggregate calculations but treated differently for operational reporting.

I don't think this needs to expand the scope of the PR, but documenting that distinction in the migration/consumer guidance would make the change more robust.