5,400 / 1,620

Values are illustrative, not customer results. The panel on the right is the live Representation Plan for each step, with the invariants checked on the plan and on what was actually rendered. Try the controls inside the object: Choose, Approve v3, Reconcile. Switch to “Dana edits after approval” to see an approval go stale.

The walk, step by step

1 · Compact: records to compare

Not “inventory error found”. There are four records that may relate to one item, and a stated scope for the judgment. Nothing needs you yet, so nothing asks for you. The object stays small.

2 · Compare: a proposal rests on an open claim

Two claims split apart. These four records relate to one physical item is supported: SKU, variant and listing history agree. These four numbers are the same quantity is unknown: the ERP field is called qty and its meaning is not declared. The agent proposes setting both marketplaces to 5,400. Because the proposal rests on the unknown claim, it is shown as not actionable (INV-19). This is a judgment point, so the system opens the object, lights its edge, and says why. It does not move your focus.

3 · Interpretation shifts: fields mean different things

The ERP schema declares qty as Produced Quantity. Shopify’s available is sellable stock. Neither number is wrong. The claim “same quantity” is superseded and stays on screen, struck, so the change in reasoning is visible. The proposal built on it is invalidated. The Interpretation Block states what the new reading rests on and what would change it. Whether the ERP exposes a real Available-to-Sell value is still unknown, so the work is blocked in domain judgment, not in mapping.

4 · Real options

The ERP adapter lists available_to_sell = 1,620. Now there are three real, comparable options, each with its consequence: keep as is, adjust by hand this time, or map available_to_sell to the marketplaces’ Available field. Nothing is pre-chosen. The recommended option is only visually primary.

5 · Approve v3

Choosing the mapping opens the Impact Preview and the Authority Gate. The preview shows what changes and what is preserved: production quantity stays 5,400, Excel is read only, orders and reservations are untouched, no customer is notified. The gate shows all five authority layers and binds the approval to Mapping rule v3 only.

6 · Applying

Two targets, two rows. A spinner appears only while a request is really in flight (MOT-12). You can ask to stop new runs; asking is stop requested, not halted (INV-05).

7 · Amazon outcome unknown

Shopify confirms. Amazon’s response is lost. That is neither success nor failure, and the object says exactly that, per target (INV-06). Resending is not offered while the outcome is unknown: it could double-apply. The first path is to reconcile by reading Amazon back. Restoring the previous mapping would not restore values already written to Shopify, so the panel says so (INV-17).

8 · Reading back

Reconciliation reads the Amazon rule back: v3 is active. Verification is pending until every check has a result. Nothing is called verified yet, and the resolver forbids the word.

9 · Verified, difference kept

The object collapses to 1,620 available to sell · Mapping verified. Production quantity 5,400 is kept: a different field, not a wrong one. Amazon reservations could not be observed, so the verified scope says so instead of passing them. Verified stays open to its premises (INV-12): if the mapping changes, the result re-opens.

The branch: approval goes stale

Between approval and execution, Dana adds Amazon CA to the target. The approval for v3 is spent. The Authority Gate turns the approve control into an explained, disabled control and offers Review changes beside it, never in its place (INV-09, MOT-07). After review, v4 needs its own approval. At execution the action is re-validated against the version you saw; a mismatch never executes (INV-03, INV-04).

What each step must show

Run it yourself

import { resolve, checkPlan } from '@lyotic/core';
import { buildSteps } from '@lyotic/core/fixtures/mapping-case';

for (const step of buildSteps()) {
  const plan = resolve(step.state);
  console.log(step.id, plan.mode, plan.attention.level, checkPlan(step.state, plan).violations);
}

The same walk runs as a test: npm test.