Consent response cards and the privacy boundary

What a consent response card is

A consent request is how HQ asks an individual franchisee for permission to use their data in a specific, named way, for example showing their location by name on a leaderboard, citing their numbers in a case study, or including them in a named Item 19 disclosure cohort. The franchisee approves or declines that request from their own side of the platform. When they do, Verinode drops a card into your Feed marking that the response happened.

That card is a consent response card, and it always renders as a network_event item with the Network badge. It tells you a franchisee acted on a consent request. It does not, and never will, show you the private data the request was about. This is the privacy boundary in its simplest form: participation status is visible to HQ, the underlying business data is not, unless and until the franchisee has explicitly agreed to share it.

Where to find it

Open Feed from the HQ sidebar at hq.verinode.ai/feed. Consent response cards appear mixed in with the rest of the network activity stream, network signals, broadcasts you sent, plan activations and outcomes, franchisee plan adoptions, and industry content, sorted newest first (critical-severity items, if any, always float to the top regardless of age).

Consent response cards only appear under the All filter tab. They are not decisions (so they will not show under Decisions), they are not the industry news / vendor content stream (so they will not show under Content), and they are not calendar events (so they will not show under Events). If you are looking for one and you have a filter tab other than All selected, switch back to All.

Cards resolve within a rolling 30-day window: a franchisee's approval or decline only shows in the Feed for 30 days after it happened. Older responses still live on the underlying consent request record; they simply age out of the Feed stream itself.

What the card shows

Title. Reads as <Franchisee> approved a consent request or <Franchisee> declined a consent request. The franchisee name follows the same privacy rule as the rest of HQ: in the default independent_operators entity model, you see an anonymized label like Franchisee #4A2F (a stable, per-operator label built from the last four characters of the operator's internal ID, not their real name). If your network's entity model has been set to same_entity (a single-entity, multi-location enterprise where the locations are legally one operator, not independent franchisees), the real location name passes through instead. Entity model is a network-wide setting; it is not something you change per card. See Network Health for more on how HQ treats franchisee identity across the platform.

Badge. Network, styled in the steel-blue HQ color, the same badge every network_event card carries (plan activations, plan outcomes, and franchisee plan adoptions all share it too).

Severity, and why it matters. This is the one piece of real signal on the card:

• An approved response renders as info severity. The franchisee said yes. Nothing further is required from you.
• A declined response renders as warning severity. The franchisee said no. Declines are worth a second look, not because a franchisee is obligated to say yes, but because a pattern of declines on the same request kind can mean the ask itself needs rethinking, the rationale wasn't compelling, or the franchisee has a concern worth hearing directly.

Body text. If HQ recorded a rationale when the request was first created, explaining to the franchisee why HQ was asking, that rationale is what shows in the card body. It is the reason given, not a private detail HQ pulled from the franchisee's operation. If no rationale was recorded, the body is blank.

Timestamp. The card sorts by (and its relative time reads off) the moment the franchisee resolved the request, the approval timestamp or the decline timestamp, not when HQ originally sent it.

What you will never see on this card: the metric values, the leaderboard position, the case-study numbers, or any other private business figure the underlying request concerned. Only that a request existed, of what kind, and how the franchisee answered.

What the buttons do

Every consent response card carries the standard three-button row:

• Review: the primary action. Acknowledges the card; Verinode logs that you reviewed it and the card marks itself actioned.
• Noted: a lighter acknowledgment for a card you want to register without treating as fully handled.
• Ignore: dismisses the card from the Feed without further action.

There is no drill-through from this card into the franchisee's underlying data, by design. If you need to follow up on a decline, that is a conversation to have directly with the franchisee (through a broadcast, a call, or however your network normally communicates), not a link the card provides. Verinode surfaces the signal; leadership decides how to act on it.

The request kinds behind the card

Consent requests come in a handful of kinds. A card doesn't spell the kind out in its title, but it's useful context for what a franchisee is being asked to agree to:

• Named leaderboard: appearing by name (rather than anonymized) on a ranked comparison.
• Named specific view: being named in a particular report or view HQ wants to share.
• Case study: having their story or numbers featured as a case study.
• Deep data: sharing a deeper cut of their data than the network's default aggregate-only posture.
• Item 19 cohort: being included, by name, in a specific Item 19 disclosure cohort for franchise disclosure document purposes. Approving this kind has one additional effect behind the scenes: the franchisee's approval is mirrored into that cohort's opt-in list, which is what feeds the percentile math and PDF output on Item 19. Declining has no such side effect, the consent record itself, marked declined, is the audit trail. See Item 19 support for how disclosure cohorts use this consent.

Approvals, declines, and withdrawals all carry an audit trail on the underlying request (who acted, when, and why, if a reason was given), even though the Feed card itself only ever shows you the resolved outcome.

Empty states

If nothing has resolved in the last 30 days, no consent response cards appear at all, there is no dedicated empty-state message for this stream specifically. The Feed's general empty state covers it: once every stream is quiet, the Feed shows "All caught up," with the note "Verinode IQ is continuously analyzing your data and scanning industry sources. New decisions, insights, and updates will appear here as they surface," and "Check back soon. Your next briefing is building." If you have a filter other than All selected and nothing matches it, you'll see "No items match this filter."

Best-practice example

Say a card reads Franchisee #7C13 declined a consent request, warning severity, with the body "Requesting your consent to appear by name on the Q3 regional leaderboard so top performers get recognized publicly." That tells you exactly what it should: one franchisee, asked to be named on a leaderboard, said no, and gave HQ the courtesy of a rationale for the ask up front. It does not tell you where that franchisee actually ranks, what their numbers are, or anything else about their operation, that stays theirs unless they choose to share it. If a second and third card show the same pattern for the same request kind, that's the actual signal: not "chase the franchisees," but "the ask, or the reward for saying yes, may need to change."

Related reading

• HQ overview: the Feed's place in the overall HQ shell.
• Network Health: how franchisee identity and the entity model work across HQ.
• HQ Compliance: where compliance-flavored network signals live alongside consent activity.
• Item 19: how Item 19 cohort consent feeds franchise disclosure documents.
• Broadcasting to your network: how the broadcast cards that share the Feed with consent responses work.