Single contract vehicle — ceiling, period, and what has been ordered through it

Latest transaction for the vehicle, plus two roll-ups.

Detail shape per §1.2: singular vehicle key with the roll-ups as SIBLINGS, not nested inside it.

orders_rollup is the block that makes this endpoint worth calling: the vehicle's own transactions carry the CEILING, but the money moves on the orders placed against it, which live in the contracts table. A vehicle without its orders is a stub.

transaction_rollup/orders_rollup are deliberately scoped to THIS ONE PIID, matching how USAspending's own IDV award view works (verified against their public API contract 2026-08-29: a single award's child-orders view has no cross-awardee aggregation option). On a multiple-award IDIQ, every awardee holds a SEPARATE PIID, so distinct_awardees here can never exceed 1 , that is a structural fact, not a bug, and family-blending the money/order numbers would answer a different question than the one the URL asked. What WAS missing: any signal in this response that the vehicle is part of a larger family at all. vehicle_family below closes that gap cheaply (reusing the same vehicle_family_piids() resolution /holders already proves out) without touching what the roll-up numbers mean.