Four disciplines that turn raw reporting into input you can trust.

The first draft named the data. This version makes it dependable: a confidence tier on every field, a source-of-truth order so two teams never contradict each other, a freshness bar, and a request loop the AI can pull when something it needs is missing.

Not all inputs are equal. Tag each by how it was produced.

A number counted at the till and a number a manager guessed after service are not the same kind of fact, and must never be treated as one. The tier a field carries decides whether it may move a forecast or trip an alert.

Two lanes, not one feed.

The mistake is forcing everything onto the daily dashboard. Inputs split cleanly into two cadences with two jobs — and keeping them apart is what stops the dashboard lying about a venue because finance hasn't closed the month.

Who owns each input.

Eight functions, each with a bounded reporting job. Value and effort are on the cockpit's 1–5 scale; the lane and cadence tell you which pipeline it belongs to and how often it lands.

Name the feeds, the cadence, and the role each source is allowed to play.

External and platform data should not all be treated equally. Weather and bookings can alter daily operating expectation; tourism is a slow prior; marketing attribution needs a source pipeline and holdout discipline before it becomes decision-grade.

One comp number, two opposite meanings.

Today a comp is one undifferentiated figure buried in leakage — hiding both an operational loss to fix and a marketing investment to measure. The data already exists; someone comped the table on purpose. It just needs an owner and a code. This is the first thing I'd request.

When two teams report the same fact, precedence decides.

Covers show up in the POS, in the reservation system, and in the GM's report — and they won't always match. Rather than average them or let the last upload win, fix a golden-record order per field. Disagreements then become a data-quality flag, not a silent error.

Six templates, ready to distribute.

Minimum-viable field sets — start smaller, not larger; a team fills five fields forever and abandons twenty in a week. Each maps to a path in the daily fact record. Amounts always carry the venue's own currency and are never summed across markets. Expand any template for its schema.

Get compliance by starting small.

Ask each team for a handful of fields, not a data project. The first phase needs no new systems and immediately sharpens the bands, the variance bridge, and RevPASH.

Separate reliable facts from useful context, then turn both into decisions.

Restaurant data has a hierarchy. A POS cover count, a reservation cancellation, and a manager's impression of guest mood should not carry the same weight. This view makes those distinctions explicit so the dashboard can be trusted by operators, owners, and AI agents.

The data ladder: what to trust most, and why it matters.

These are ranked by reliability, explanatory power, actionability, and strategic value. The top rows are not always the most exciting, but they are the hardest to argue with and the most useful for daily decisions.

Every metric needs a management interpretation.

A restaurant dashboard should never stop at the number. Each metric should say what it tells us, what it does not prove, and what action it should trigger. Filter the dictionary by decision area.

Daily, weekly, monthly, and forward views are different jobs.

Month-to-date is useful, but restaurants are not linear. The cockpit should help management move between operating exceptions, weekly patterns, calendar-adjusted ownership reads, and forward revenue risk.

Month shape changes expected revenue before operations do anything.

Do not judge a month by simple days-elapsed pace. Judge it by the expected value of each elapsed and remaining trading day, adjusted for venue, market, premium nights, holidays, events, weather, tourism, mobility, and reservation book.

expected_day_revenue = same_weekday_daypart_baseline
                     × market_premium_day_factor
                     × holiday_or_long_weekend_factor
                     × weather_and_mobility_factor
                     × event_and_tourism_factor
                     × forward_reservation_book_factor
                     × venue_specific_modifier

calendar_adjusted_MTD = Σ expected value of elapsed days
forecast_month_end    = Σ actual elapsed + Σ expected remaining

Never read AED and INR as one operating total.
Never treat a managed venue's gross sales as Atelier's economic exposure.

Per-venue panels: the same KPI means different things in each restaurant.

The global metric dictionary is not enough. Each venue needs its own signal map, trigger logic, data requirements, and AI interpretation rule. This closes the largest coverage gap: metrics existed globally, but not mapped deeply enough to each restaurant.

Delivery is not seat economics. It needs its own unit model.

For Mohalla Cloud and Mohalla d3, gross delivery revenue can hide weak contribution after commissions, packaging, refunds, prep-time failures, and ranking loss. The cockpit should read delivery as a funnel and a unit-economics waterfall.

Service timing links experience, table productivity, and revenue.

Speed is not about rushing luxury service. It is about knowing whether the guest was seated, greeted, ordered, served, and closed at the right pace for the venue and occasion. This is especially important for Tezukuri's busy downtown guests and for RevPASH-driven capacity management.

Patch the fact record so the AI can explain the business more accurately.

The existing canonical record is strong. These additions make the variance bridge more complete and give delivery, service pace, local demand, and managed-venue compliance a place to live.

What to import, where from, and how much to trust it.

Named sources prevent vague integration requests. They also force the cockpit to distinguish daily operating signals from slow macro context and experimental attribution feeds.

Once the data constraint is solved, the portfolio becomes a compounding intelligence asset.

This is the next-generation opportunity map: not more tiles, but a sequence of domains that move from descriptive reporting toward prescriptive and eventually human-supervised autonomous decisions.

Brand focus matrix

Not every restaurant needs every frontier at once. Sequence investment by the economic question each brand lives or dies on.

What not to build yet, even if the metric sounds smart.

More data can make the cockpit worse when the source is weak, the cadence is wrong, or the metric encourages false confidence. These items should be gated, not placed on the daily dashboard.

Give the model a contract, not a vague request to summarize.

The AI should narrate deterministic metrics, not invent them. It should separate fact, interpretation, context, action, confidence, missing data, and memory. It should also track whether yesterday's explanation was later confirmed.

Facts:
  - net sales, covers, APC, channel/daypart mix, leakage, classification
Interpretation:
  - primary driver: covers / APC / mix / leakage / reservation / menu / service / context
Context:
  - weekday, calendar shape, weather, holiday/event, booking book, venue lens
Actions:
  - 1 to 3 owner-routed actions with urgency
Confidence:
  - high / medium / low, with missing data named
Memory write:
  - what was learned, what hypothesis changed, what should be checked next time

daily_memory = {
  venue_id,
  date,
  classification,
  primary_variance_driver,
  calendar_context,
  external_context,
  service_or_menu_notes,
  actions_recommended,
  missing_data,
  confidence,
  hypotheses_created_or_updated,
  next_check_date
}

A large idea bank, organized by decision altitude.

This is the long-form backlog of broad, micro, macro, and governance ideas. Keep it visible, but gate each item on whether the underlying data source exists and whether the metric would change a real decision.