Why Three Gardeners Got Three Different Harvest Numbers

The Garden That Counted Three Ways

You'd think a garden is simple. You plant, you water, you harvest. But ask three people in the same garden, “How many tomatoes did we get last month?” and you'll get three different answers. One says 800 pounds. Another says 1,000. The third insists it was 1,200. Nobody's lying. They're just counting different things.

This happens in every community garden, every farm, every backyard plot. The soil doesn't change. The plants don't care. But the people do. And that's where the trouble starts.

Three Gardeners, Three Truths

Let's break down what each gardener might actually be measuring. The first gardener, let's call her the Sales Gardener, counts every tomato that's been picked and sold at the farmers' market. That's the contract amount—what's been agreed upon, even if payment hasn't landed yet.

The second gardener, the Operations Gardener, counts what customers actually paid for, minus any refunds for spoiled produce. That's the cash that changed hands, not what was promised.

The third gardener, the Finance Gardener, follows accounting rules. She counts revenue only when it's recognized—say, when the tomatoes are delivered and accepted, not when they're picked or sold. That's a whole different number.

All three are right. They're just answering different questions. The real problem isn't the numbers—it's that everyone calls them “harvest.”

Data Isn't the Same as Definition

Imagine a single row in your garden logbook:

• plant_id: 10086
• weight: 999 grams
• status: 3
• picked_at: 2026-07-12T14:30:00+08:00

Technically, that's clear. plant_id is unique. weight is a number. status is an integer. picked_at is a timestamp. But what does status = 3 mean? Is it ripe? Sold? Composted? And does weight include the stem? The database doesn't care. It just stores what you tell it.

So even if you label a field “harvest_weight,” it doesn't tell you whether that's the weight at picking, at sale, or after trimming. A field name is a hint, not a definition. And a real metric—like “marketable yield”—almost never maps to a single field. You need multiple fields, filtered and combined in specific ways.

Even if you've centralized all your garden logs into one neat spreadsheet, the problem doesn't go away. Different people will still pick different columns, different date ranges, different filters. The spreadsheet gives you a single source of data, not a single source of truth.

One Metric, Many Versions

Spreadsheets and garden-tracking apps make it easy for anyone to query the data. That's great for efficiency, but it also means every gardener can build their own version of “harvest.” One might filter by date picked. Another by date sold. A third by date paid. The result? A mess of numbers that all claim to be “harvest.”

The root cause isn't too many reports. It's that the business rules—what counts as a harvest, when you count it, how you handle culls—aren't written down and agreed upon. The tools just amplify the chaos.

So before you dive into fancy analytics, ask yourself: What are we actually trying to measure? What are the specific rules? That's not a data problem. That's a governance problem.

Agree on What “Harvest” Means

You can't just decide that 800, 1,000, and 1,200 are all wrong and pick one. Each number serves a purpose. Sales cares about contracts. Operations cares about cash flow. Finance cares about accounting.

What you need to do is give each concept a clear name, define when to use it, specify the calculation rules, and assign a person to own each definition. Write it down. Track changes. Version it.

For example, you might define “marketable yield” as: the total weight of produce that passes quality checks and is sold, minus any weight that is returned or discarded due to spoilage. That's a definition you can actually use.

But if that definition only lives in a meeting note or someone's head, it's useless. You need to turn it into something machines can follow.

Making Definitions Executable

Your garden log might use codes like harvest.weight_g and harvest.status_code. Your gardeners think in terms like “ripe,” “sold,” “last month.” There's a gap between technical language and business language.

A semantic layer sits in between. It maps your agreed-upon definitions to the underlying data. For “marketable yield,” it would specify which fields make up the measure, which fields are filters, and at what level of detail to aggregate.

It might also enforce rules like: “Only the plot manager can see data for their own plot.” That keeps people from cherry-picking numbers.

But the semantic layer isn't the database itself. You still need a query engine and your data store to run the actual numbers.

From Question to Answer

Say you ask: “What was the marketable yield for the east plot last month?” The system shouldn't guess. It should ask a clarifying question: “Do you mean picked weight, sold weight, or recognized revenue?” Once you confirm, it runs the query.

The result shouldn't just be a number. It should come with context: which metric, which region, which time range, which timezone, when the data was last updated, and what permissions you have. That way, you can trust the number and explain it to others.

Make Your Definitions Reusable

When you've got a semantic layer in place, your garden's metrics become reusable. A report, an AI assistant, or a new volunteer can all use the same definitions. No more rewriting SQL or reinterpreting a spreadsheet. No more relying on one person's memory.

So next time you get three different harvest numbers, don't blame the data. Blame the definitions. And then fix them.