Design the visibility and qualification model #12

New Issue

christian · 2026-08-02T03:05:53Z

christian commented

2026-08-02 03:05:53 +00:00

Question

Three tiers were named in the original idea: everyone, qualified vendors, and shortlisted vendors (a retailer-chosen subset of qualified). With no open discovery in v1, all three operate over a retailer-scoped roster.

Resolve: who defines qualified and against what evidence; whether qualification is per-RFP, per-category, or per-retailer; whether tiers can change mid-RFP and what happens to bids already submitted when they do; what 'everyone' means when there is no public marketplace; and whether a vendor can see that an RFP exists but not its contents.

Parent: #1

## Question Three tiers were named in the original idea: everyone, qualified vendors, and shortlisted vendors (a retailer-chosen subset of qualified). With no open discovery in v1, all three operate over a retailer-scoped roster. Resolve: who defines *qualified* and against what evidence; whether qualification is per-RFP, per-category, or per-retailer; whether tiers can change mid-RFP and what happens to bids already submitted when they do; what 'everyone' means when there is no public marketplace; and whether a vendor can see that an RFP exists but not its contents. --- Parent: #1

christian added the

wayfinder:grilling

wayfinder:ticket

labels 2026-08-02 03:05:53 +00:00

christian added a new dependency 2026-08-02 03:06:25 +00:00

#14 Specify the two-party data release rules

christian added a new dependency 2026-08-02 03:06:26 +00:00

#11 Define the tenancy, identity, and authorization model

christian added a new dependency 2026-08-02 03:11:54 +00:00

#23 Design the app framework — retailer and vendor surfaces

christian self-assigned this 2026-08-02 03:38:03 +00:00

christian commented

2026-08-02 03:56:02 +00:00

Resolution

The ticket asked about three visibility tiers. The tiers were the wrong model — they conflated two
orthogonal concepts, and separating them is the substance of this resolution.

1. Eligibility and audience are different things

Eligibility is durable state on the roster entry, scoped to (retailer, vendor, category). A
vendor is approved, or has prior awarded business, with this retailer in this category. It
accrues — approvals, audits, past performance attach to it over time — and it exists independently
of any RFP.

Audience is a per-RFP targeting decision made at issue time. The retailer selects either
ad-hoc ("only A, B, C") or by naming a reusable group.

So everyone / qualified / shortlisted is not an enum on the RFP. It is an audience selected
from a roster that carries eligibility state. This matters beyond tidiness: it survives a retailer
whose own approval vocabulary does not match ours, because their process maps onto eligibility
state without us having to name their tiers.

"Everyone" is already bounded by the cold-start decision — with no open discovery in v1 there
is no public to broadcast to, so "everyone" means every vendor on that retailer's roster. The
model needs no global visibility concept at all.

2. Audience is fixed at issue; access changes by stage

The audience never changes after the RFP is issued. Separately, the RFP moves through stages —
open -> evaluating -> finalists -> awarded — and reaching finalist grants a participant
additional access: clarification rounds, interviews, site visits, revised pricing.

Two things kept deliberately apart: who was invited never changes; what a participant can see
does. The research confirmed this is what real solicitations do — the SLC Airport RFP shortlists
for interviews as a distinct downstream stage.

Widening the audience mid-RFP was declined. Adding vendors after issue gives late entrants
less time and potentially more information, which is the fairness pattern that gets awards
protested.

Consequence the map must carry. Visibility is now a function of
(audience membership, RFP stage, participation state, acknowledgement). That is precisely the
lifecycle-dependent policy the tenancy decision flagged as the hard case for RLS. The data-release
ticket must produce rules expressible in policy SQL over these four inputs — not merely correct
rules.

3. A group is a rule, materialised at issue

A named group ("Tier 1 Produce Suppliers") is defined as a rule over roster attributes —
qualified for a category, insurance current, prior awarded business — so it maintains itself as the
roster changes.

At issue, the rule is evaluated and the resulting vendor set is frozen onto the RFP as an
explicit list. The rule is convenience; the snapshot is the record.

Why the snapshot is not optional. Access is lifecycle-dependent and awards get protested. You
must be able to prove exactly who was invited at issue time, and a live query cannot answer that
once the roster has moved. A live rule would also quietly readmit the mid-RFP widening that was
just declined.

What it costs. Two representations to keep coherent, and retailers will need to understand that
editing a group does not change an RFP already issued.

4. Teaser first, then an acknowledgement gate

An invited vendor first sees a summary — category, scope in outline, timeline, volume band.
Full contents unlock on acknowledgement: confidentiality, conflict-of-interest declaration, intent
to respond. The gate is a per-RFP toggle, so routine sourcing skips it.

Why. This is what the retailer is actually buying when we promise control over who sees the
RFP — private-label specs, formulations, and volume commitments are the sensitive part. It also
yields a signal the retailer wants for free: who opened, who acknowledged, who intends to bid, all
well before any bid arrives.

What it costs. One more state per participant, and a gate that irritates vendors on low-stakes
RFPs if it is not genuinely optional.

Constraints handed to other tickets

Data release inherits four-input lifecycle policy, expressible in RLS.
The vault must handle eligibility staleness: an expired insurance certificate has to be able
to un-qualify a vendor, which means document expiry feeds eligibility state rather than sitting
inert in a document store.
Audit must be able to reconstruct the invited set and the stage timeline, since both are
protest surface.
Category turned out to be load-bearing — eligibility is scoped to it and group rules select
over it. Graduated to its own ticket.

## Resolution The ticket asked about three visibility tiers. The tiers were the wrong model — they conflated two orthogonal concepts, and separating them is the substance of this resolution. ### 1. Eligibility and audience are different things **Eligibility** is durable state on the roster entry, scoped to `(retailer, vendor, category)`. A vendor is approved, or has prior awarded business, with *this* retailer in *this* category. It accrues — approvals, audits, past performance attach to it over time — and it exists independently of any RFP. **Audience** is a per-RFP targeting decision made at issue time. The retailer selects either ad-hoc ("only A, B, C") or by naming a reusable group. So `everyone / qualified / shortlisted` is **not an enum on the RFP**. It is an audience selected from a roster that carries eligibility state. This matters beyond tidiness: it survives a retailer whose own approval vocabulary does not match ours, because their process maps onto eligibility state without us having to name their tiers. **"Everyone" is already bounded** by the cold-start decision — with no open discovery in v1 there is no public to broadcast to, so "everyone" means every vendor on that retailer's roster. The model needs no global visibility concept at all. ### 2. Audience is fixed at issue; access changes by stage The audience never changes after the RFP is issued. Separately, the RFP moves through stages — `open -> evaluating -> finalists -> awarded` — and reaching finalist grants a participant *additional* access: clarification rounds, interviews, site visits, revised pricing. Two things kept deliberately apart: **who was invited never changes; what a participant can see does.** The research confirmed this is what real solicitations do — the SLC Airport RFP shortlists for interviews as a distinct downstream stage. **Widening the audience mid-RFP was declined.** Adding vendors after issue gives late entrants less time and potentially more information, which is the fairness pattern that gets awards protested. **Consequence the map must carry.** Visibility is now a function of `(audience membership, RFP stage, participation state, acknowledgement)`. That is precisely the lifecycle-dependent policy the tenancy decision flagged as the hard case for RLS. The data-release ticket must produce rules expressible in policy SQL over these four inputs — not merely correct rules. ### 3. A group is a rule, materialised at issue A named group ("Tier 1 Produce Suppliers") is defined as a **rule** over roster attributes — qualified for a category, insurance current, prior awarded business — so it maintains itself as the roster changes. **At issue, the rule is evaluated and the resulting vendor set is frozen onto the RFP as an explicit list.** The rule is convenience; the snapshot is the record. **Why the snapshot is not optional.** Access is lifecycle-dependent and awards get protested. You must be able to prove exactly who was invited at issue time, and a live query cannot answer that once the roster has moved. A live rule would also quietly readmit the mid-RFP widening that was just declined. **What it costs.** Two representations to keep coherent, and retailers will need to understand that editing a group does not change an RFP already issued. ### 4. Teaser first, then an acknowledgement gate An invited vendor first sees a **summary** — category, scope in outline, timeline, volume band. Full contents unlock on acknowledgement: confidentiality, conflict-of-interest declaration, intent to respond. **The gate is a per-RFP toggle**, so routine sourcing skips it. **Why.** This is what the retailer is actually buying when we promise control over who sees the RFP — private-label specs, formulations, and volume commitments are the sensitive part. It also yields a signal the retailer wants for free: who opened, who acknowledged, who intends to bid, all well before any bid arrives. **What it costs.** One more state per participant, and a gate that irritates vendors on low-stakes RFPs if it is not genuinely optional. ### Constraints handed to other tickets - **Data release** inherits four-input lifecycle policy, expressible in RLS. - **The vault** must handle eligibility staleness: an expired insurance certificate has to be able to *un-qualify* a vendor, which means document expiry feeds eligibility state rather than sitting inert in a document store. - **Audit** must be able to reconstruct the invited set and the stage timeline, since both are protest surface. - **Category** turned out to be load-bearing — eligibility is scoped to it and group rules select over it. Graduated to its own ticket.

christian closed this issue

2026-08-02 03:56:02 +00:00

christian referenced this issue

2026-08-02 03:56:03 +00:00

Retail RFP transmission system — v1 build spec #1

christian referenced this issue

2026-08-02 15:22:59 +00:00

Define the common schema for RFPs and responses #10

christian referenced this issue

2026-08-02 15:23:57 +00:00

Define the eligibility path for a vendor with no vault #32

christian referenced this issue