MoLo Logo
MoLo Schrift
Signal from Noise.
scroll to explore
↓
// Insights 02 · Semantic Layer

A Map of Your Business: Understanding the Semantic Layer

/~8 min read

Twelve days of stock can be comfortable or critical. If the next delivery arrives in five days, there may be little to discuss. If the supplier needs three weeks and part of that stock is already promised to a customer, the same number calls for a different conversation.

Some of this information is in the warehouse. Some is in a supplier portal, a contract, or a conversation with the person responsible. A useful description of the business connects these pieces and makes clear which are available, which can be trusted, and which still need to be established.

A satellite map is a useful comparison. From orbit, an image shows that something is there. It becomes a map once the images are aligned, the features named, and the areas no one has surveyed yet marked as such.

This is the role we see for the semantic layer: a shared description of the company and its operating environment, developed and maintained as the business changes.

Reported stock coverage
12 days
  • Reserved quantitiesin view
  • Supplier lead timein view
  • Customer commitmentin view
  • Supplier portalnot imaged
Illustrative example · the coarse view is correct, just not sufficient
01 / From data foundations to business context

From shared definitions to business context

A useful map of the business starts with a reliable account of what is happening. Orders, deliveries, invoices, and stock movements are often recorded in separate systems (ERP, Excel, E-Mail). A data warehouse brings these records together, reconciles identifiers and formats, and preserves the history needed to follow changes over time. That makes it the factual foundation for describing the company’s state. In mapping terms, the warehouse is the corrected imagery: separate captures stitched together, aligned to one coordinate system, and kept over time.

The work of building that foundation already involves business knowledge. Someone must establish whether two customer records refer to the same organisation, which transactions belong together, and how a return affects reported sales. Those decisions give the data a structure that reflects the business.

The semantic layer makes that meaning explicit and reusable. It defines what counts as revenue, how customers relate to orders, and which rules a calculation follows. Definitions include units, time periods, and exclusions, so a dashboard and a question about the same metric can use the same interpretation. Booked orders and recognised revenue remain distinct concepts, with their differences explained. If the warehouse is the imagery, the semantic layer is the legend and the labels that let everyone read it the same way.

We see this as the starting point for a broader description of the company’s operating environment. The recorded facts acquire context through processes, key stakeholders, responsibilities, contractual limits, and external conditions. The description also needs to show the quality and freshness of its evidence, and identify relevant sources that are not yet connected.

The warehouse anchors this map in observable business activity. The surrounding context helps people and agents interpret that activity and understand where their view ends. A supplier agreement can therefore be relevant to the model before every detail of it has been brought into the warehouse.

Start with the foundation: what does a data warehouse cost?
Each layer depends on the one below. The map is the composite.
02 / Horizon + Resolution

Two dimensions: horizon and resolution

Once these pieces begin to come together, a practical question follows: how complete is our picture? Most companies know some parts of their operation in considerable detail and see others only indirectly. Sales may be well documented, while the work required to serve those customers is spread across emails, time sheets, and the experience of a few colleagues.

It helps to think of this picture as a map with two dimensions. The first is its horizon: how much of the business and its environment it takes into account. Adding service operations to a model that previously covered only sales expands that horizon. So does identifying a supplier portal, a contractual dependency, or the person responsible for an exception.

The second is resolution: how much we can distinguish within the area already mapped. A total service cost offers one level of detail. Knowing which customers, products, or recurring issues account for it makes different questions answerable. In the inventory example, the distinction between physical, reserved, and available stock has the same effect. Satellite imagery has the same two properties: how large an area a capture covers, and how small a detail a single pixel can show. One image may cover a region at thirty metres per pixel, another a single site at thirty centimetres.

These dimensions develop independently. A narrowly focused model can be very detailed, while a broad one may still contain areas that are poorly understood. A known but unconnected source is already within the horizon as a possible source of information; its contents are not yet available for analysis.

The aim is to develop the map where it helps the business most. If service effort is changing customer profitability, that may justify more attention than another breakdown of sales already understood. And because greater detail can expose contradictions as well as answer questions, the map must retain the source, freshness, and limitations of what it describes.

One company, two dimensions

Adjust each dimension independently. Inspect the detail and the gaps within the same business.

01

Inventory

Connected · ERP

Stock by product and warehouse

  • Physical stock: 1,200 units
  • Reserved: not yet confirmed

Last extract: today. Availability cannot yet be established.

02

Suppliers

Connected · ERP

Suppliers and recorded lead times

  • Recorded lead time: 21 days
  • Recent commitment: 30 days

The newer commitment needs confirmation with procurement.

03

Customer commitments

Known · contracts

Delivery obligations and reservations

  • Priority account: delivery Friday
  • Reservation owner: sales operations

Contract known; reservation quantities still need to be mapped.

04

Responsibilities

Documented · team

People who can resolve an exception

  • Transfers: warehouse manager
  • Delivery terms: procurement lead

Responsibilities confirmed with the operating team.

05

Supplier portal

Known · not connected

A source outside the warehouse

  • Shipment confirmations available
  • Access and refresh frequency: to assess

Source identified. Its records are not available for this analysis.

06

Transport conditions

Known · external

Routes and delivery restrictions

  • Regional carrier schedules
  • Holiday restrictions: not assessed

Relevant external context; current coverage is incomplete.

A known source is within the model’s horizon even before its data is connected. Greater detail does not automatically mean better evidence.
03 / Company model

A description that develops through use

Consider what happens when the warehouse manager reviews a proposed stock transfer. The report shows enough units, but she knows that a large share is reserved for a customer. The agreement is real; the reservation simply has not found its way into the data used for the analysis. Her response reveals both a missing piece of context and a weakness in the process that records it. Remote-sensing teams call this ground truthing: checking what an image suggests against what is actually on the ground.

After the agreement is checked, the reservation can become part of the shared description, with its source, responsible person, and period of validity. The next analysis can then distinguish stock that is physically present from stock that is actually available. What was known by one person becomes knowledge others can use.

There is also an opportunity to improve the underlying work. The team can agree where future reservations should be recorded, who maintains them, and when they must be updated. Showing the responsible colleagues how this prevents conflicting delivery promises gives the additional data collection a clear purpose.

01 / 05

A proposal

An analysis identifies 1,200 units in Warehouse B and proposes moving part of them to Warehouse A.

02 / 05

An operational response

The warehouse manager explains that 800 units are reserved under a customer agreement.

03 / 05

Verification

Sales operations checks the agreement and confirms the reservation, its scope, and its validity for the period under review.

04 / 05

A more detailed model

The reservation becomes an explicit relationship between the customer commitment, product, and warehouse.

05 / 05

Improving the daily process

The team agrees who records future reservations and where. Subsequent analyses use that shared record, reducing the need to clarify the same issue again.

Company model
01

Physical stock is visible

  • Warehouse B: 1,200 units
  • Reservation status: unknown

The initial description cannot establish how much is transferable.

02

A constraint is reported

  • Reported reservation: 800 units
  • Source: warehouse manager

The statement is recorded as pending verification.

03

The constraint is confirmed

  • Reservation: 800 units, confirmed
  • Evidence: customer agreement

The model keeps the source, reviewer, and applicable period.

04

Availability has a definition

  • Available = physical − reserved
  • 1,200 − 800 = 400 units

Illustrative definition. Other constraints must be included where applicable.

05

A correction becomes a working practice

  • Available for assessment: 400 units
  • Reservation updates: sales operations

Recording reservations at the point of agreement keeps the next analysis better informed.

Illustrative example

Over time, these interactions help identify where effort is best spent. If the same missing information repeatedly delays a decision or causes rework, collecting it deserves attention. If an existing source already contains the answer, connecting it may be enough. This gives managers a practical basis for directing limited time and resources towards the data and processes that matter most. On a satellite map, these are the patches under cloud or beyond the edge of the image: the ground is there, and the data may even exist, but it has not yet been brought together. Meridian, our implementation of the semantic layer, marks these blind spots and ranks them by how often they affect decisions, so the next clarification can be planned where it matters most.

The map develops through this everyday use. Questions add detail, corrections challenge assumptions, and new sources extend its reach. Changes still need to retain their origin and status: a reported constraint may need confirmation, and an old rule may need to be retired when the business changes.

Blind spots

What cannot be seen yet, and what to map next

Meridian marks where data has not been brought together and ranks each gap by its effect on decisions. Map out a gap to see the plan update.

  1. 01 Horizon gap Impact 3 / 3 Effort 1 / 3

    Shipment confirmations in the supplier portal

    The source is known but not connected, so transfer reviews work with estimated delivery dates.

    Next clarificationConnect the existing portal export.

  2. 02 Resolution gap Impact 3 / 3 Effort 2 / 3

    Service effort per customer

    Tickets and time sheets exist, but they are not joined to customer records.

    Next clarificationAgree a shared customer key with the service team.

  3. 03 Resolution gap Impact 2 / 3 Effort 2 / 3

    Lead times by supplier and product

    Recorded lead times and recent commitments disagree (21 vs. 30 days).

    Next clarificationConfirm current terms with the procurement lead.

  4. 04 Horizon gap Impact 1 / 3 Effort 1 / 3

    Holiday transport restrictions

    Relevant external context that has not been assessed.

    Next clarificationRequest carrier calendars from logistics.

Illustrative example · priority reflects how often a gap affects decisions and the effort needed to close it
04 / Describe the state

The description of the state shapes the next action

This brings us back to the twelve days of stock. The calculation may be correct throughout, while our understanding of what it permits changes considerably. Once reservations, delivery commitments, and supplier reliability are visible, the same inventory can support a much better assessment of the available options.

The quality of an action therefore depends in part on the quality of the state description behind it. That description also helps establish when there is enough information to act and when a particular uncertainty needs to be resolved first.

Afterwards, the outcome belongs in the picture too. Did the transfer protect the customer’s delivery? Did recording reservations prevent the same problem from recurring? Reviewing these effects connects the description of the business with the work of improving it. A satellite returns over the same ground on every orbit, and each pass shows what the last decisions changed. Reviewing outcomes gives the company model the same rhythm.

  1. 01

    Describe the state

    Observe what is there, including the gaps.

  2. 02

    Assess and act

    Plan on the best map available.

  3. 03

    Review the effect

    On the next pass: did the transfer protect the delivery?

What changes in the business and what is learned about it both feed the next description.
05 / Your company’s asset

An open implementation, owned by the company

The time spent agreeing definitions, documenting exceptions, and connecting operating knowledge creates something of lasting value. For an SME, this description holds experience that would otherwise remain scattered across systems and individual people. We believe it should be treated as a company asset.

This is the thinking behind Meridian’s open implementation. Customers can inspect their semantic layer: how a figure is defined, which relationships support it, where information comes from, and which gaps remain. They can review and extend that description as their business develops.

The implementation is designed to interoperate with each platform’s definition of a semantic layer, translating existing models into Meridian and company definitions back into the structures supported by other platforms. The business knowledge remains available to the customer as their technology changes. Cartographers keep survey data independent of any one projection, so the same coastline can be drawn for a globe, a nautical chart, or a city plan. Company definitions deserve the same independence.

A business map you can inspect and develop

Explore what ownership means in everyday use.

Your semantic layer

Inspect

Follow a number back to its definition, source, and responsible person. See what is known and where information is missing.

Your semantic layer

Extend

Add a verified constraint, clarify a responsibility, or connect a relevant source. Keep the description aligned with how the business works.

Your semantic layer

Reuse

Bring existing semantic definitions into the model and translate them for other platforms. Preserve the knowledge as systems change.

Business knowledge that stays with the company

An inspectable, evolving description that remains usable across platforms.

Definitions, relationships, and operating context remain part of the company’s knowledge as its technology changes.

A useful semantic layer develops in breadth, detail, and its ability to explain the limits of what is known.

Discuss your company’s data landscape