What is conditional visibility?

Conditional visibility is branching logic on audit questions tied to a location attribute, so a unit sees only the questions that match what it actually runs.

For this page, the attribute is the kitchen format. That format decides whether whole question groups, front-of-house, host-station, table-turn, and dine-in-service, appear on the audit at all.

A delivery-only ghost kitchen is not a smaller full-service restaurant. It is a different operation. A ghost kitchen (also called a dark kitchen, virtual kitchen, or cloud kitchen) is a licensed commercial food facility that produces food only for off-premises pickup and delivery, with no dine-in component.

FindLaw covers the model in "Are 'Ghost Kitchens' Legal?", and CloudKitchens breaks down the operating setup in its "Ultimate Guide to Ghost Kitchens". Because there is no storefront and no waitstaff, labor focuses on prep, cooking, packing, and order accuracy, not table service or host duties. The audit question set has to be different, not just shorter.

Conditional visibility solves the mixed-format problem cleanly.

Run the same audit template across 100 units, but a unit set to full-service sees the dine-in-service questions, a counter-service unit sees the pickup-counter questions, and a delivery-only unit sees neither. Read the full mechanic in our conditional visibility explainer for multi-location audits.

Conditional visibility pairs with nullify scoring. Conditional visibility hides the irrelevant group. Nullify scoring makes sure the hidden items count for nothing rather than logging as zeros.

A ghost kitchen without a dining room does not get dinged on dining-room questions it can never satisfy. That pairing is covered in how nullify scoring works alongside conditional visibility. Without it, hiding a group would still leave a hole in the denominator, and the score would lie.

Worked example, conditional visibility in action

Here is the concrete pattern. A multi-brand restaurant group runs one operations audit carrying 48 questions across three kitchen formats, and the kitchen-format attribute on each unit record decides which groups appear.

A delivery-only ghost kitchen sees 30 questions (order-flow accuracy, delivery-handoff staging, packaging and seal integrity, back-of-house food safety) and the dining-room group hides.

A full-service unit sees all 48, adding the front-of-house, host-station, table-turn, and dine-in-service groups. A counter-service unit in the same group sees 38, adding the pickup-counter and self-order-kiosk group but not the table-service group.

The shared back-of-house core is the same for every format. It covers line checks, walk-in and hot-hold temperatures, sanitation, and equipment condition. The kitchen-format attribute, not the auditor's memory, decides the rest.

| Kitchen format | Questions shown | Question groups shown on top of the BOH core | Question groups hidden |
|---|---|---|---|
| Delivery-only ghost kitchen | 30 | Order-flow accuracy, delivery-handoff staging, packaging and seal integrity | Front-of-house, host-station, table-turn, dine-in-service |
| Counter-service | 38 | Pickup-counter, self-order-kiosk | Table-service, host-station |
| Full-service | 48 (all) | Front-of-house, host-station, table-turn, dine-in-service | None |

Ground the food-safety questions in real thresholds so the audit holds up to a health inspector. Time and Temperature Control for Safety (TCS) foods must be held at 135°F or above when hot and 41°F or below when cold under the FDA Food Code, with the danger zone sitting between those two numbers.

AAA Food Handler summarizes the code and the delivery-specific rules in "Food Delivery Safety Issues".

The delivery-handoff and packaging-seal group is unique to the ghost-kitchen format: food should be handed off in sealed packaging, moved in insulated carriers, and dispatched with documented times. A full-service audit carries no delivery-handoff group, and a ghost kitchen carries no table-turn group. That asymmetry is the whole reason to branch on format instead of maintaining separate templates.

Set the critical items to weighted scoring so a temp failure and a smudged label do not carry the same weight. Food safety violations get 10 points.

Cosmetic items get 1. That mirrors how weighted audit scoring with critical-item thresholds separates what matters from what is noise. This branching pattern is close to how a single guest-facing element drives the drive-thru versus dine-in conditional audit, except kitchen format changes the whole service model, not one lane.

Close on the scoring math. A ghost kitchen that scores 30 of 30 is a clean pass. It is not "30 of 48 equals 63 percent, fail." The 18 dining-room questions never applied to it, so nullify scoring keeps them out of the denominator entirely.

How does conditional visibility differ from static audits?

A static audit is one fixed question list applied to every unit, so a ghost kitchen inherits dining-room questions it can never satisfy. It either fails them or piles up a stack of N/A items that clutter the report.

A conditional audit changes the question set per unit based on the kitchen-format attribute, so each format sees a complete, relevant audit and the score reflects only what that unit is responsible for.

| Attribute | Static per-type templates | Conditional audit (Xenia) |
|---|---|---|
| Templates to maintain | One ghost-kitchen, one counter-service, one full-service (3 plus) | One template, branched by kitchen-format attribute |
| Ghost kitchen scored on dine-in questions | Yes, unless deleted per unit by hand | No, dining-room groups hide automatically |
| N/A handling | N/A items penalize the score or clutter the report | Hidden groups are nullified and count for nothing |
| Roll-up across formats | Scores not comparable (different denominators) | One scoring model, comparable across formats |
| New format added | Build and version a fourth template | Add the attribute value, reuse the same template |

The static approach is the market default, and the incumbent templates are genuinely thorough. PopProbe ships a detailed 45-point "Ghost Kitchen Operations Checklist", though it still carries a Service and Guest Experience section a delivery-only unit barely uses.

GoAudits offers a "library of separate restaurant and food-safety templates" by facility type. SafetyCulture publishes a horizontal "Kitchen and Canteen Food Safety Audit Checklist". eAuditor keeps its "restaurant audit" and its "ghost kitchen guide" as two different static documents.

The pattern across all of them is the same: the answer to format variation is "download a different template." Xenia's answer is "one template, and the unit attribute decides what shows."

That is the difference between managing three documents and managing one, covered in depth in conditional checklists versus duplicate templates. For a Zenput shop weighing the move, the Zenput alternative comparison lays out where per-location branching changes the math.

How to set up conditional visibility in Xenia

Setting up a kitchen-format audit in Xenia takes six steps. The attribute does the branching, so the setup happens once and every new unit inherits it.

1. Add a kitchen-format field to each unit's location record. Set the value to delivery-only ghost kitchen, counter-service, or full-service. This attribute, not the auditor, drives every branch that follows.
2. Build one operations audit with question groups. Start with the shared back-of-house core (food safety, line check, walk-in and hot-hold temps, sanitation, equipment). Then add the format-specific groups: ghost-kitchen order-flow, delivery-handoff, and packaging-seal, counter-service pickup-counter and self-order-kiosk, and full-service front-of-house, host-station, table-turn, and dine-in-service.
3. Set the conditional visibility rule on each format-specific group. Show the group only when the unit's kitchen-format matches. For example: if the kitchen-format is delivery-only ghost kitchen, show the delivery-handoff and packaging-seal groups and hide the dine-in-service group.
4. Turn on nullify scoring for the conditional groups. Hidden questions then score nothing instead of counting as zeros against the unit.
5. Add follow-up questions with required photo capture on the critical food-safety items. A walk-in reading over 41°F prompts "what did you find?", requires a photo, and auto-creates a corrective task. Evidence gets captured at the moment of failure, not written up after the fact.
6. Test with one unit per format, then roll out. The AI Template Agent can convert an existing SOP PDF into the digital form with the conditional logic baked in. Uploading a patio or delivery-handoff SOP produces a form with the conditional questions already wired, which cuts franchise rollout from weeks to days.

Keep the language operator-plain during setup. It is the kitchen-format field on the location record, not a rule engine, and it branches deterministically on the attribute you set. Xenia is not deciding the format on its own.

Where do operators see results?

Operators see three results: fairer scores that ghost kitchens actually trust, one template to maintain instead of three, and roll-ups that compare like format against like without a per-unit denominator problem.

The clearest win is by-brand and by-pod visibility. Multi-brand cloud-kitchen operators need audit scores and food-safety data by virtual concept, not just by physical location. That way a director can tell whether one specific brand in the pod is the recurring temperature-violation risk, instead of only knowing the kitchen "had a bad week."

Custom dashboards surface which locations are trending toward food safety failures, which corrective actions are overdue, and which DMs need support, not just a completion percentage. Xenia's own coverage of the format in ghost kitchen software for multi-brand operators walks through the by-concept reporting need.

The second win is closure, not just data. Weighted-scoring audits generate a corrective task automatically on failure. A temp out of range triggers a follow-up question capturing what went wrong, a photo of the corrective action, a task assigned to the kitchen manager with a deadline, and escalation to the DM if it is not closed in time. Audits are table stakes. The differentiator is what happens after the audit.

The migration story is where this lands for multi-format groups. The neighboring incumbents force duplicate templates by design. Graham Enterprise migrated from Zenput to Xenia specifically for conditional visibility and facilities workflow.

Dave's Hot Chicken runs the multi-unit QSR pattern across 321 locations, and Metropolis runs multi-vertical, both operators managing real format variation.

Newk's Eatery rolled 100-plus franchise units onto Xenia in one deployment, and the Newk's Eatery franchise rollout shows the single-template approach at franchise scale. The same conditional model powers the conditional audits overview across every vertical, and it maps cleanly onto restaurant task management across multiple units.

The stakes are rising with the format. Ghost kitchens are one of the fastest-growing operations in food service, tracked by Statista's hub on "ghost kitchens statistics and facts" and by IBISWorld's "Ghost Kitchens in the US" industry report.

These kitchens are inspected under the same risk-based health-department models as brick-and-mortar restaurants, per FindLaw and AAA Food Handler. A group adding delivery-only units every quarter needs an audit that branches by format, not a folder of static templates that grows every time a new concept opens.