Ski Slope Data Chaos: Why Your Resort Numbers Don't Add Up

Three Ski Resorts, Three Totals

You're the general manager of a ski resort in the Rockies. Last month, you ask a simple question: "What was our net revenue from lift tickets in January?"

The finance team says $800,000. Operations says $1,000,000. Sales says $1,200,000. Before you assume someone's screwing up, hear them out.

Finance is counting recognized revenue—the tickets that were actually used, minus refunds, adjusted for accounting policies. Operations counts every payment received, including refunds processed. Sales counts every ticket sold, even if it's for a future date.

All three are right. They're just answering three different questions.

The Real Problem: Same Data, Different Definitions

Your resort's database has a row for each ticket sale. It looks something like this:

• ticket_id: 10086
• amount: 99.00
• status: 3
• sold_at: 2026-01-12T14:30:00+08:00

That's technical clarity. The database knows the amount is numeric, the status is an integer, and the timestamp is a date-time. But it doesn't know whether "amount" means the sticker price, the after-discount price, or the price including equipment rental.

Even if the field is labeled "revenue," it's ambiguous. Is it the contract value? The amount the customer actually paid? The net after refunds? Including tax or not?

The field name is just a hint. It's not a business definition. And most business metrics don't map neatly to a single database field anyway.

Why Data Warehouses Don't Fix It

You've centralized all your point-of-sale, online booking, and season pass data into a data warehouse. Great. But that only gives you a single source of data—not a single source of truth.

Finance, operations, and sales still pull different fields, different date ranges, and different filters. Without a shared definition of "revenue," each department builds its own report, its own SQL query, its own analysis.

The problem isn't too many reports. It's that business rules aren't managed centrally. BI tools and AI just amplify the chaos.

So before you let your team loose with dashboards, ask: What do we actually want to measure? What are the rules?

That's not a technical problem. It's a governance problem.

You Can't Automate Common Sense

No semantic layer can tell you whether $800,000, $1,000,000, or $1,200,000 is "correct." Those numbers serve different purposes. Sales cares about bookings. Operations cares about cash flow. Finance cares about recognized revenue.

What you need isn't to force one number. You need to:

• Give each concept a clear name
• Define when to use it
• Specify the calculation rules and data sources
• Assign an owner for each definition
• Track changes and versions

Say you decide that "net ticket revenue" means: successful ticket payments in the period, minus successful refunds in the same period.

But if that definition only lives in a meeting note or a PDF, your analysts will still interpret it differently every time.

Making Definitions Machine-Readable

Databases speak technical language: ticket_sales.amount, ticket_sales.status. Business people speak plain English: "successful payment," "last month," "Colorado region."

A semantic layer sits between the two. It takes your agreed-upon definitions and maps them to the underlying data structure.

For "net ticket revenue," the semantic model might look like this:

• Business definition: what you want to calculate
• Semantic layer: breaks it into metrics, measures, dimensions, and relationships
• Database: says which tables and fields feed each piece

The semantic layer isn't just translating field names. It defines which fields make up the measure, what filters apply, and at what granularity to aggregate.

Some semantic layers also enforce row-level security. For example, the Colorado resort manager only sees Colorado data. But that might also be handled by the data warehouse or BI tool.

Remember: the semantic model isn't the database. You still need a query engine and a data warehouse to execute the query.

From Question to Answer: An Example

Let's say a user asks: "What was our net revenue in January for the Colorado region?"

Since "net revenue" could mean three things, the system shouldn't guess. It should ask: "Do you mean contract value, net payments, or recognized revenue?"

Once confirmed, the flow goes like this:

• The user or AI clarifies the question
• The semantic layer provides the approved metric, dimensions, and time range
• The query engine generates and validates the query
• The data warehouse executes it

The result shouldn't just be a number. It should include context:

• metric: net_payment
• metric_name: Net Ticket Revenue
• region: Colorado
• time_range: January 2026
• timezone: America/Denver
• data_updated_at: when the data was refreshed
• permission_scope: what the user is allowed to see

That way, anyone looking at the number knows exactly what it means—and can trust it.

Make Your Business Definitions Reusable

The takeaway? A reliable data answer isn't just a number. It's a number with its definition, time range, data version, and access scope attached.

A semantic layer turns your business definitions into a machine-readable model. Query engines can use it to generate SQL. BI dashboards and AI tools can reuse the same definitions.

No more duplicating logic in every report. No more relying on one analyst's memory.

It's like setting a standard for what "powder day" means—so everyone knows exactly what they're getting.