Sourcing: Reading V3+V4 Compliance & Security Requirements Inline
Why the bidder sees the request’s compliance and security picks on the bid detail itself, instead of having to navigate elsewhere to figure out what they’re bidding on.
A bidder pricing a job needs to see what the job requires. If the compliance and security picks live three clicks away from the bid form, half the bids price for the wrong scope. The sourcing module surfaces V3 (compliance) and V4 (security) requirements inline on the bid detail page so the bidder reads them while typing the price.
What V3 and V4 carry
V3 is the compliance section of the request: the frameworks the customer requires (GDPR, R2v3, ADISA, NAID AAA, sector-specific). V4 is the security section: the erasure standards, the on-site flag, the chain-of-custody requirements. Together they define what the customer needs the disposal to meet — and what the bidder has to commit to.
Inline rendering
The bid detail page (/sourcing/bids/[id]) renders V3 and V4 as labeled chips next to the request summary, before the price input. Each chip shows the requirement’s name and (for security) the picked level. Hover or tap reveals the full code definition from the catalog, so a bidder unfamiliar with a specific framework can read what it actually requires without leaving the page.
Why on the bid detail, not the request detail
Because the bid detail is where the bidder makes the price commitment. Putting the requirements there means the bidder reads them in the moment that matters. The request detail still has the full breakdown for the curious; the bid detail has the parts the bidder can’t skip.
Coverage-driven filtering
If V3 or V4 includes a code the bidder’s tenant doesn’t have in active Coverage, the platform doesn’t route the request to them in the first place. The codes shown on the bid detail are codes the bidder is, by Coverage configuration, capable of providing. That’s by design — bidders never see requests they can’t fulfil.