Martin Brower · Order Management Knowledge Layer (illustrative)

We built a working slice in Microsoft Fabric on simulated Purple Report and RPO data. Four things decided whether it answered correctly.

RPO order line	OL00255377
Restaurant	#32039 (sim), Joliet DC
Proposed, then edited	6 → 60 cases
RPO check	Quantity spike, accepted

Layer	In the live demo	What it proved	Next for production
Where facts liveThe systems of record.	A notebook generates simulated data shaped like Snowflake, JDE and the FIP/WRIN trackers, straight into a lakehouse	The situations planners deal with, from late trucks to bad edits, can be reproduced and tested on demand	Connect today’s sources: mirror the tables the layer needs into Fabric, in place of the generator
Gold tablesOne table per business entity.	22 Delta tables: one per entity, two link tables and a 6-hourly stock projection; a validation notebook checks them	Every key unique, all 43 foreign keys resolve, and every Purple Report row is explained by the projection	Data-quality rules owned by the business, run on every refresh
IdentityOne record per real-world thing.	Simulated with clean keys; restaurants carry both a store number and a JDE ship-to, and changeovers link old and new WRINs	Changeovers modeled as data with dates let the agent see the old item bridging the new one’s gap	Resolve store numbers, ship-tos and WRINs across real sources before the ontology, with a person for the hard cases
Semantic layerOne definition for reports and agents.	A Direct Lake semantic model over 14 tables, with 16 relationships added in one TMDL script	One model can serve reports and seed the ontology	Certified KPIs per DC: case fill rate, cases cut, time to decision
Entity modelEntity types, relationships, cardinality.	Fabric IQ ontology (preview), generated from the semantic model and finished by hand: 14 entity types, 148 properties, 27 relationships	Relationships bind through mapping tables, many-to-many through link tables; generation is a head start, not the finish	Add dispositions, transfers, order-line changes and planners, so decisions and overrides become part of the record
Instance graph and time seriesWhere multi-hop questions are walked.	Graph in Fabric, rebuilt on refresh; the stock projection as time series on each product at each DC	Answers that cross shortage, inbound, lanes and stock, including when stock goes negative and how far	A refresh schedule tied to each Purple Report run, and an as-of time on every answer
AgentsWho asks the question.	The Fabric IQ ontology Copilot	13 of 16 test questions verified against Gold. Asked with the rule, it finds the right DC; asked plainly, it guesses	A Fabric data agent that carries the disposition rules, reached from Teams, Copilot Studio or Foundry; test questions run as regression tests
Decisions for Martin BrowerNone of these come with a product.	Which Snowflake tables are the record for orders, inventory and inbound Where FIP/WRIN transitions and substitution lists live, and who owns them Which disposition rules are written down, and who signs them off Which KPIs measure the loop from proposal to shortage across DCs How fresh the Purple Report needs to be Who approves an agent’s recommendation, and how overrides are recorded

Identity across systems

The layer only connects what is modeled, so identity across systems has to be designed in.

What we saw in the build

In our build a changeover gave one menu item two WRINs: Clamshell large v2 was 83 cases short at Joliet while v1 still had 186 cases spare. The layer saw that bridge only because the transition was modeled as data, with phase-in and phase-out dates. With real sources the same restaurant is also a store number in the proposal system and a ship-to in JDE. A traversal over unresolved identity doesn’t fail; it returns a confident answer about part of the picture.

We’d ask: Where are FIP/WRIN transitions and substitution lists maintained today, and who owns them?

See it:

Facts are not decisions

The ontology supplies the facts. Decisions need shared, governed rules that every agent applies.

What we saw in the build

Asked which DCs could send beef patties to Columbus in time, the agent approved all three. Asked with the rule spelled out, it found Joliet only: Atlanta has 43 cases spare against 46 needed, and the Dallas lane can’t carry frozen product. The ontology supplies the facts. Disposition rules need a governed home, the rules, thresholds and overrides layer in the proposed design, so every agent applies them the same way.

We’d ask: Which disposition rules are written down today, and which live in planners’ experience?

See it:

RPO and the Purple Report are one loop

Fewer shortages start upstream, when both teams see the same order line and measure the same outcomes.

What we saw in the build

The BBQ sauce shortage at Joliet traces to a single order line edited from 6 to 60 cases. The RPO check flagged it, and it was accepted. Better proposals and earlier checks reduce Purple Report rows, but only if both teams see the same order line and measure the same outcomes across every DC.

We’d ask: Which KPIs should measure the loop from proposal to shortage across DCs, and who owns them?

See it:

Trusting the answer on every run

Trust comes from repeatable tests, a stated as-of time and a person approving the action.

What we saw in the build

Each test question has an expected answer computed from Gold, so they work as a regression suite: 13 of 16 matched exactly, and the misses showed where wording or the model needed fixing. In production they rerun on every model change, every answer states the Purple Report run it comes from, and a planner approves every action in phase one.

We’d ask: How fresh does the Purple Report need to be, and who signs off an agent’s recommendation?

See it:

Simulated data throughout. DC, restaurant, supplier and product names are invented; the model needs validating against Martin Brower’s systems. No Martin Brower data is used.

Explore the ontology

What we built, and what it proved

One order line, two teams

The hero question, answered

Measured against an answer key

Layer by layer

In the live demo

What it proved

Next for production

What we learned building it

Generation is a head start, not the finish

A wrong column creates phantom records

Relationships bind through a mapping table

Avoid reserved words

Projections are a property type

The rule has to travel with the question

Keep the answer key out of the model

Preview features act like previews

The knowledge graph, with data

One knowledge layer for every agent, from proposal to Purple Report

Ask as Martin Brower Pick a team

How it works: your data in, every agent out Select a step to see how it was built

Starts where your data lives

Built once, shared everywhere

Trusted by design

What it takes for a knowledge layer to answer correctly

Identity across systems

Facts are not decisions

RPO and the Purple Report are one loop

Trusting the answer on every run

How the rest of this page fits

How it’s built

Agents and people

Serving

Knowledge (Gold)

Landing (OneLake)

Sources

What it takes to trust an answer

Test questions as regression tests

Evidence behind every answer

An as-of time, stated

People in the loop

Where the rules live

One graph, built from tables

Preview realities

Decisions for Martin Brower