Day Four · Overlay services + the automation fabric

SD-WAN & Lifecycle Service Orchestration

Describe SD-WAN architecture and service components per MEF 70.1, then the LSO reference architecture — and drive the Sonata API that automates inter-provider business.

◎

Day objective — the application-aware overlay (SD-WAN), its standard (MEF 70.1) and security context (SASE/Zero-Trust), then LSO's seven reference points and the Sonata POQ → Quote → Order workflow you execute in Lab 4.

4.1

SD-WAN Concept

SD-WAN applies the SDN idea to the WAN edge: a central policy decides, per application, which transport each flow uses — broadband, LTE/5G or MPLS — continuously, based on measured path quality.

Application-aware steering over three transportsconcept view

policy-preferred path alternate transports (per-app)Paths are re-scored continuously; a brown-out re-steers flows in seconds.

Fly it yourself — live path scores, a brown-out, and a mid-call re-steer

Policy: voice ≤150 ms · ≤1% loss · ≤30 ms jitter

MPLS 12ms · 0.1% · 4ms ✓ Broadband 28ms · 0.4% · 9ms ✓ LTE/5G 45ms · 0.8% · 18ms ✓ probes re-score every second

[SD-WAN] Three underlays, one policy. Send the voice call — the edge picks the best compliant path. Then brown-out broadband while a call is up and watch the re-steer happen mid-flow.

Application-aware networking — flows are classified to named applications (DPI/signatures/SNI), not just 5-tuplesclassify → policy → steer → re-evaluatefirst packets identify the app
Policy-driven connectivity — intent like "voice: latency ≤ 150 ms, prefer private transport" compiled to per-edge forwarding behaviorMEF 70.1 Policy Criteriabrown-out → re-steer in seconds
Transport independence — broadband, LTE/5G and MPLS are interchangeable underlays under one encrypted overlayIPsec tunnels · TVC over UCSunderlay can be a MEF service (Day 3)
Why now — cloud-bound traffic made MPLS-only backhaul slow and expensive; SD-WAN uses cheap capacity without losing control

4.2

SD-WAN Architecture & Components

An SD-WAN deployment is a small distributed system with a deliberate split of concerns: a management plane you drive (the orchestrator), a control plane that distributes state (controllers), and a data plane that moves packets (edges) — all over an encrypted overlay kept independent of the underlays it rides. Four roles, three planes. Walk the scenes below: how a site comes online, how it forwards, how it survives a controller outage, and how it reaches the cloud — then drive a single packet through one edge, stage by stage.

The SD-WAN system — three planes, four roles (walk each scene)

Component roles (vendor-neutral) — with failure behavior

Component	Plane	Responsibility	If it fails
`Edge device`	Data	Terminates tunnels; classifies apps; enforces policy per packet; measures path SLA (loss/latency/jitter) with active probes	That site loses service — other sites unaffected (distributed data plane)
`Controller`	Control	Distributes reachability, keys and policy to edges — the overlay's "routing brain"; never touches user packets	Edges keep forwarding on last-known state; only changes pause until it returns
`Orchestrator`	Management	Zero-touch provisioning, policy authoring, monitoring, multi-site/tenant lifecycle — the operator's single pane	You lose visibility & the ability to push changes; the running network keeps running
`Gateway`	Data	Optional on-ramp: interconnects the overlay with cloud providers or legacy MPLS/Internet domains	Cloud/legacy reach via that on-ramp degrades; site-to-site overlay is unaffected

Vendor Rosetta — the same four roles, real product names

Neutral role	Cisco Catalyst SD-WAN (Viptela)	VMware VeloCloud	Fortinet Secure SD-WAN	Versa
Orchestrator · mgmt	`vManage`	SD-WAN Orchestrator (VCO)	`FortiManager`	Director
Controller · control	`vSmart` (OMP)	Controller (VCC)	Security Fabric / ADVPN*	Controller
Onboarding · ZTP	`vBond`	Activation code → VCO	FortiDeploy / FortiZTP	Director-driven
Edge · data	vEdge / cEdge	Edge (VCE)	`FortiGate`	FlexVNF / CSG
Gateway · on-ramp	Cloud OnRamp / SIG	Cloud Gateways (VCG)	FortiGate + SASE	Versa Gateway

*Fortinet centralizes control in FortiManager plus a Security-Fabric / ADVPN control channel rather than a discrete controller appliance — the role still exists, just packaged differently. That is exactly why a vendor-neutral model is worth learning.

Life of a packet at the edge — drive it (classify → policy → path → encrypt → forward)

Inside one edge · pick an app and watch the five stages

tunnels (lat·loss·jit): MPLS 12·0.1·4 ✓ BB 28·0.4·9 ✓ LTE/5G 45·0.8·18 ✓ pick a flow to classify

[edge] This is what happens inside a single SD-WAN edge for every flow. Pick Voice, Video or Bulk — watch it get classified, matched to a policy, steered onto the cheapest compliant tunnel, wrapped in IPsec, and sent. Then brown-out broadband and send again to see the pick change.

The same five stages, as a checklist

Classify

First packets identify the app (signature/SNI/heuristics) → flow tagged e.g. app=voice. The rest of the flow inherits the tag (fast-path).

Policy lookup

The app's policy names performance targets and path preferences (MEF 70.1 calls these Policy Criteria).

Path selection

Edge compares live measurements of each tunnel against the targets; picks the cheapest compliant transport.

Encrypt & forward

Flow is wrapped in IPsec/ESP (encrypted payload + new outer IP); NAT/underlay details are invisible to the app and unreadable to the transport.

Re-evaluate continuously

Brown-out on broadband? Voice re-steers to LTE mid-call. This closed loop is the operational soul of SD-WAN.

Each role, explained & visualized — click a tab to see what it is and what it does

Edge devices — physical or virtual (a VNF/CNF from Day 3!) at sites, DCs and clouds data plane · classify + encrypt + forwardactive probes measure every tunnel ▶ see the edge explained & animated ↑
Controllers — scale-out control plane; edges keep forwarding if it blips (same resiliency logic as Day 2) routes · IPsec keys · policycontrol ⟂ data — an outage ≠ a blackout ▶ see the controller explained & animated ↑
Orchestrators — the management plane; where LSO Presto/Legato attach in provider-managed offers single pane · ZTP · policy authoringthe operator's API surface ▶ see the orchestrator explained & animated ↑
Overlays — encrypted tunnels decouple the service from underlay ownership IPsec/ESP · SPI per tunnelthe underlay can't read the app (4.3 TVC/UCS) ▶ see the encapsulation explained & animated ↑
Centralized policy management — write once, enforce at every edge one intent → many edgesMEF 70.1 Policy Criteria ▶ see one policy fan out to every edge ↑

4.3

MEF 70.1 — The SD-WAN Standard

MEF 70.1 (© MEF Forum 2021), "SD-WAN Service Attributes and Service Framework", is the standard that turns "SD-WAN" from a marketing word into a specifiable, orderable, certifiable service — authored by AT&T, Cisco, Nokia, Fortinet, Orange, Versa, Ciena, Bell Canada and others. It defines an SD-WAN Service verbatim as "an overlay connectivity service that optimizes transport of IP Packets over one or more Underlay Connectivity Services by recognizing applications (Application Flows) and determining forwarding behavior by applying Policies to them." Everything below is pulled directly from the standard — its object model, its Service Attributes, its Application Flow Criteria and Policy Criteria, and a fully-configured example.

MEF 70.1 service components — the five nounsMEF 70.1

Press ▶ Trace an app-flow to watch one flow cross all five nouns — classified at the UNI, bound by a Policy, forwarded by the SWVC, tunneled through a TVC, carried over a UCS.

service layer (SWVC) tunnel/underlay layer⑤ = the Policies (top badge) binding App Flows to behavior — config below.

The MEF 70.1 object model — click an object for its verbatim definition & Service Attributes

Application Flow Criteria — how every packet is matched to an app

Application Flow Criteria · Support Required — the "IP 5-tuple" + APPID + ANYMEF 70.1 Table 7 · §9.11

AFCritName	Layer	Match on	Values (AFCritValue)	Ref
`SAV4`	3	IPv4 Source Address	List of IPv4 prefixes	RFC 791
`DAV4`	3	IPv4 Destination Address	List of IPv4 prefixes	RFC 791
`PROTV4`	3	IPv4 Protocol	Integers 0–255 or IANA keywords	IANA
`SAV6`	3	IPv6 Source Address	List of IPv6 prefixes	RFC 8200
`DAV6`	3	IPv6 Destination Address	List of IPv6 prefixes	RFC 8200
`NEXTHEADV6`	3	IPv6 Next Header	Integers 0–255 or IANA keywords	IANA
`DSCP`	3	Diffserv Code Point	Integers 0–63	RFC 2474
`SPORT`	4	Transport Source Port*	0–65535 or IANA service names	IANA
`DPORT`	4	Transport Destination Port*	0–65535 or IANA service names	IANA
`APPID`	3–7	Custom / heuristic / DPI match	Application Identifier + args (SIP, Microsoft365, Webex…)	SP catalog
`ANY`	1–7	Match any IP Packet	None — MUST be alone in the spec R87	—

*Renamed "TCP/UDP…Port" → "Transport…Port" in MEF 70.1 so it covers SCTP/DCCP. Table 8 adds optional criteria (VLAN ID, 802.1p PCP, IP fragmentation, ICMP type, etc.).

⚙

Matching rules — a packet is assigned to the first Application Flow Specification whose criteria it matches R83; a packet matching none is discarded R84. An Application Flow Specification is the conjunction (AND) of its criteria — use an Application Flow Specification Group to express OR-style alternatives that share one Policy & bandwidth pool.

Policy Criteria — every knob a MEF 70.1 Policy can turn

Policy Criteria — what a Policy specifies about IP-Packet handlingMEF 70.1 Table 4 (R37) · Table 5 (D2)

PCname	Support	I/E	Controls	Allowed values
`ENCRYPTION`	Req'd	Ing	Whether the Application Flow requires encryption	`Required-Always` · `Required-Public-Only` · `Optional`
`PUBLIC-PRIVATE`	Req'd	Ing	May the flow traverse Internet-access (public) UCSs?	`Private-only` · `Either`
`INTERNET-BREAKOUT`	Req'd	Ing	Forward the flow to Internet destinations?	`Enabled` · `Disabled`
`BACKUP`	Req'd	Ing	May the flow use a UCS designated "backup"?	`Enabled` · `Disabled`
`VIRTUAL-TOPOLOGY`	Rec.	Ing	Which Virtual Topology to forward over	a Virtual Topology Name
`ALLOWED-DESTINATION-ZONES`	Rec.	Ing	Which Zones packets may be delivered to	a list of Zone Names
`BILLING-METHOD`	Rec.	Ing	Usage-based vs flat-rate underlay allowed	`Flat-Rate-Only` · `Usage-Based-Only` · `Either`
`PERFORMANCE`	Rec.	Ing	Ordered performance goals → orders the Paths	⟨primary, secondary⟩ of ⟨metric, threshold⟩
`BANDWIDTH`	Rec.	Ing	Committed bandwidth + bandwidth limit for the flow	⟨committed, limit⟩
`AF-SECURITY-INGRESS`	Rec.	Ing	Security functions applied at the Ingress UNI	`None` · a Security Policy Identifier (MEF 88)
`BLOCK-SOURCE`	Rec.	Egr	Disallow specific ingress sources for this egress flow	list of `UNI` and/or `INTERNET`
`AF-SECURITY-EGRESS`	Rec.	Egr	Security functions applied at the Egress UNI	`None` · a Security Policy Identifier (MEF 88)

Performance MetricsMEF 70.1 Table 6

Metric	Definition
One-Way Mean Packet Delay	§15.3
One-Way Mean Packet Delay Variation	§15.4 (jitter)
One-Way Packet Loss Ratio	§15.5

The non-negotiable rules

R37 The SP MUST support the Table-4 criteria; D2 SHOULD support Table 5. R40 every Ingress Policy in an SWVC carries the same set of Policy Criteria (only the values differ) — so there is never a "don't-know" packet. R41 if no UCS (or sequence of UCSs) can meet the Policy, the packet MUST be discarded. The SWVC Performance Time Intervals attribute ⟨evalinterval, arrivalinterval, irduration⟩ sets the look-back windows; irduration SHOULD ≤ 1000 ms.

A MEF 70.1 SD-WAN Service, configured — in the standard's information-model form

SWVC "Corp-SDWAN" · Application Flow Specifications → Policies → SWVC End Point Policy Map (verbatim n-tuple style)# ── SWVC List of Application Flow Specifications (matched in order — R83; ANY last — R87) ── afsVoice = [ ⟨DSCP,[46]⟩, ⟨APPID,[SIP]⟩ ] # EF + SIP signalling/media afsVideo = [ ⟨APPID,[Webex]⟩, ⟨DSCP,[34]⟩ ] # AF41 interactive video afsERP = [ ⟨DAV4,[10.20.0.0/16]⟩, ⟨DPORT,[443]⟩ ] # private data-centre app afsBulk = [ ⟨APPID,[backup]⟩ ] afsDefault = [ ⟨ANY⟩ ] # catch-all — MUST be last # ── SWVC List of Policies (Ingress; every policy carries the SAME criteria set — R40) ── ⟨ipVOICE, [ ⟨ENCRYPTION,Required-Always⟩, ⟨PUBLIC-PRIVATE,Either⟩, ⟨INTERNET-BREAKOUT,Disabled⟩, ⟨BACKUP,Enabled⟩, ⟨BILLING-METHOD,Either⟩, ⟨VIRTUAL-TOPOLOGY,"Full-Mesh"⟩, ⟨BANDWIDTH,⟨2Mbps,4Mbps⟩⟩, ⟨PERFORMANCE, ⟨primary ⟨One-Way-Mean-Packet-Delay,150ms⟩, secondary [⟨One-Way-Mean-Packet-Delay-Variation,30ms⟩, ⟨One-Way-Packet-Loss-Ratio,1%⟩]⟩⟩ ]⟩ ⟨ipERP, [ ⟨ENCRYPTION,Required-Always⟩, ⟨PUBLIC-PRIVATE,Private-only⟩, ⟨INTERNET-BREAKOUT,Disabled⟩, ⟨BACKUP,Enabled⟩, ⟨BILLING-METHOD,Flat-Rate-Only⟩, ⟨VIRTUAL-TOPOLOGY,"Hub-Spoke"⟩, ⟨BANDWIDTH,⟨10Mbps,None⟩⟩, ⟨PERFORMANCE, ⟨primary ⟨One-Way-Packet-Loss-Ratio,0.1%⟩, secondary []⟩⟩ ]⟩ ⟨ipBULK, [ ⟨ENCRYPTION,Optional⟩, ⟨PUBLIC-PRIVATE,Either⟩, ⟨INTERNET-BREAKOUT,Enabled⟩, ⟨BACKUP,Disabled⟩, ⟨BILLING-METHOD,Flat-Rate-Only⟩, ⟨VIRTUAL-TOPOLOGY,"Full-Mesh"⟩, ⟨BANDWIDTH,⟨None,20Mbps⟩⟩, ⟨PERFORMANCE, ⟨None, []⟩⟩ ]⟩ # ── SWVC End Point "Corp" Policy Map (4-tuples ⟨zone, app, ipol, epol⟩ — §10.4) ── ⟨Corp, afsVoice, ipVOICE, None⟩ ⟨Corp, afsVideo, ipVOICE, None⟩ ⟨Corp, afsERP, ipERP, None⟩ ⟨Corp, afsBulk, ipBULK, None⟩ ⟨Corp, afsDefault, ipBULK, None⟩

MEF is explicit that these names describe behavior, not syntax — "no implementation needs a parameter called BILLING-METHOD" — but every conformant product must expose equivalent Policy functionality. Vendor CLIs (Cisco policy/SLA-class, Versa SD-WAN policies, Fortinet SD-WAN rules) map onto exactly these criteria.

How the SWVC handles one packet — the MEF pipeline, animated

SWVC End Point "Corp" · send a packet and watch the spec pipeline

[SWVC] Pick a packet. It is matched to an Application Flow Specification (first-match, R83), placed in its Zone, looked up in the SWVC End Point Policy Map ⟨zone,app,ipol,epol⟩, assigned its Ingress Policy, whose Policy Criteria are evaluated against the candidate Paths (TVCs over UCSs) — then forwarded, or discarded if none comply (R41).

SWVC — the SD-WAN Virtual Connection: the L3 service that forwards IP Packets among SWVC End Points by applying Policies; carries the lists of Policies, Application Flow Specs, Zones, Virtual Topologies, UCSs & Security PoliciesMEF 70.1 §9 · Table 3an overlay IP service
SD-WAN UNI — the User Network Interface: the demarcation between Subscriber Network and Service Provider Network; carries addressing (IPv4 None/Static/DHCP; IPv6 +SLAAC) & routing-protocol attributesMEF 70.1 §11 · Table 10UNI ≠ UCS UNI
SWVC End Point — the attachment of an SWVC to one UNI; holds the Policy Map ⟨zone, app, ipol, epol⟩ and the list of UCS End Points it can useMEF 70.1 §10 · Table 9where Policy meets packet
TVC / UCS — a TVC is a point-to-point forwarding relationship between two SD-WAN Edges over a UCS (the underlay — private IP, Carrier Ethernet, or Internet access); a Path is a TVC or sequence of TVCsMEF 70.1 §12 · Table 11underlay can be a MEF service (Day 3)
Application Flow & Policy — an Application Flow (a Spec = AND of Application Flow Criteria + a Zone) is bound by a Policy (a list of Policy Criteria) that determines its handlingTables 7 · 4 · 5R83 first-match · R84 discard

≡

Layer answer for the exam — per its own definition the SWVC forwards IP Packets between SWVC End Points (UNIs): SD-WAN is a Layer-3 overlay service in MEF's taxonomy — policy-aware and routed, not bridged. It pairs with MEF 88 (SD-WAN security / Security Policies), MEF 82 (SD-WAN performance monitoring), MEF 69 (Internet Access Service) and is orderable over LSO Sonata/Cantata (§4.6–4.7).

4.4

SASE & Zero Trust (MEF 117 / 118)

Once the WAN is software, security joins it in the cloud: SASE converges SD-WAN connectivity with cloud-delivered security functions; Zero Trust removes the assumption that "inside = trusted". MEF standardized both as services.

The two specs in context

Spec	Defines	Core content
`MEF 117`	SASE service attributes & framework	Secure Access Service Edge: SD-WAN connectivity + security functions (SWG, CASB, ZTNA, FWaaS) delivered as one cloud-edge service with common policy
`MEF 118`	Zero Trust framework for MEF services	Identity-based, least-privilege access: authenticate & authorize every actor per session; continuous verification; no implicit trust by network location

SASE in one breath

Users, sites and clouds connect to a nearby service edge; connectivity (SD-WAN) and inspection (SWG/CASB/ZTNA/FWaaS) happen there under one policy — instead of hairpinning traffic to a DC firewall stack.

Zero Trust in one breath

Every session is authenticated, authorized against identity + context, and re-verified continuously. The network's job (and MEF 118's point): make policy enforcement a standard, orderable service behavior.

Watch it work — the SASE edge and a Zero-Trust decision, live

SASE (MEF 117) — convergence of network-as-a-service + security-as-a-service at distributed edgesSWG · CASB · ZTNA · FWaaSinspect at a nearby edge, not a DC hairpinone policy for connectivity + security
Zero Trust (MEF 118) — subject/actor identity, policy end-points, continuous verification within MEF servicesnever trust, always verifyidentity + context, per sessionZTNA ≠ VPN: per-app, not network-wide
Why in this course — they extend the SD-WAN policy model from performance to security — same policy engine, more verbs

4.5

Why Orchestration

Every service you designed this week still needs to be quoted, ordered, activated, assured and billed — across multiple providers. Done by email and swivel-chair, that takes weeks. LSO exists to make it machine-speed.

Design

Product qualification at an address, feasibility, quote. Manual: days of emails. LSO: Sonata POQ + Quote APIs — seconds.

Activation

Order placement, inter-provider ordering, service configuration down the stack. Sonata Order + Legato/Presto/Adagio southbound.

Assurance

SOAM measurements (Day 3), fault tickets, SLA reporting — exchanged provider-to-provider through standardized APIs.

Billing

Usage and settlement data flow over the same fabric — the last mile of NaaS economics.

Design → Activation → Assurance → Billing — the lifecycle LSO orchestrates end-to-end
The swivel-chair problem — humans re-typing between provider portals: slow, expensive, error-prone
Orchestration = NaaS enabler — without LSO APIs, "order connectivity like cloud" is marketing, not engineering

4.6

LSO Reference Architecture

MEF 55.1 names seven interface reference points — musical names, precise meanings. Click any pink label in the diagram to inspect it. Sonata and Interlude cross provider boundaries; the rest run inside one provider or to the customer.

LSO reference points — click a label to inspect, or trace a live orderMEF 55.1

inter-provider (Sonata · Interlude) intra-provider / customer-facing

Sonata — SP Business Applications ↔ Partner Business Applications. The inter-provider business interface: serviceability (POQ), quoting, ordering, inventory, billing, trouble-ticketing between two operators. The star of Lab 4 — full deep-dive in panel 4.7.

All seven, one line each (memorize the endpoints)

Ref point	Connects	Carries
`Cantata`	Customer Business Apps ↔ SP BUS	Customer↔provider business transactions (order, bill)
`Allegro`	Customer App Coordinator ↔ SP SOF	Customer-driven service control (dynamic changes)
`Sonata`	SP BUS ↔ Partner BUS	Inter-provider business: POQ · Quote · Order · Inventory
`Interlude`	SP SOF ↔ Partner SOF	Inter-provider orchestration: control of the partner-side service
`Legato`	SP BUS ↔ SP SOF	Intra-provider: business layer driving orchestration
`Presto`	SP SOF ↔ ICM	Network-domain orchestration (where SDN controllers/TAPI attach)
`Adagio`	ICM ↔ ECM	Element-level control and management

The two cross-domain points — Sonata (business) and Interlude (orchestration) make multi-operator NaaS possible
The vertical stack — Cantata/Allegro in, Legato down, Presto to controllers, Adagio to elements
Where the week connects — Presto is where Day 2's SDN controllers and TAPI meet Day 4's orchestration

4.7

LSO Sonata APIs

Sonata is a family of REST/JSON APIs (OpenAPI-specified, in the MEF-GIT SDK) for inter-provider business automation. Play the exact buyer→seller workflow of Lab 4 below — POQ, then Quote, then Order, then Inventory.

Sonata workflow player

BuyerService Provider
(needs off-net access)

SellerPartner Operator
(owns the access)

The Sonata API set (MEF-GIT SDK)

API	Question it answers	Key objects
`Serviceability (POQ)`	"Can you deliver this product at this address?"	ProductOfferingQualification, qualification result + alternatives
`Quote`	"What will it cost, and how fast can I have it?"	Quote, quoteItem, price, validity period
`Order`	"Build it." — with milestones to completion	ProductOrder, orderItem, state machine (acknowledged → inProgress → completed)
`Inventory`	"What do I have from you, in what state?"	Product records queryable by id/state
`Trouble Ticketing · Billing`	Assurance and settlement post-activation	Ticket, incident, billing objects

Serviceability / POQ — pre-sales feasibility per site; green/yellow/red answers with alternatives
Quote — machine-readable pricing replacing week-long email quotes
Order — transactional ordering with state notifications (webhooks)
Inventory — the buyer's live view of purchased products

Under the hood — Sonata payloads are JSON against OpenAPI schemas derived from TM Forum patterns, published in the MEF LSO Sonata SDK. Lab 4 mocks the seller with Stoplight Prism, which validates your requests against those schemas — schema errors are the lab's favorite teaching device.

LAB

Lab 4 · Define an SD-WAN Policy and Issue an LSO Sonata Request

Goal — apply SD-WAN and LSO concepts through policy creation and API orchestration: author a MEF 70.1 policy, then buy connectivity from a mock partner over Sonata.

Hands-on · Day 4

Lab activities

⚗

1Create an application-aware SD-WAN policy: voice via LTE/5G, bulk via broadband
2Document it using MEF 70.1 attributes (app-flow definitions + policy criteria — template in panel 4.3)
3Clone the MEF LSO Sonata SDK from MEF-GIT
4Deploy a Stoplight Prism mock server from the SDK's OpenAPI specs
5Execute POQ → Quote → Order with Hoppscotch/Bruno (the sequence you just played in 4.7)
6Identify and correct schema-validation errors Prism throws (missing required fields, wrong enums)
7Validate the complete workflow end-to-end and export your collection

Deliverables — documented SD-WAN policy · exported API collection · successful Sonata POQ → Quote → Order workflow

MEF LSO Sonata SDK (MEF-GIT)Hoppscotch / BrunoStoplight PrismSwagger UI / Redocdraw.io

Starter — mock seller in two commands (steps 3–4)$ git clone https://github.com/MEF-GIT/MEF-LSO-Sonata-SDK $ npx @stoplight/prism-cli mock serviceability/productOfferingQualification.api.yaml # seller is now listening on :4010

✓

Pass criteria — your policy names ≥2 app flows with measurable criteria; Prism accepts all three calls with 2xx after you fix at least one schema error; the order response reaches a terminal state in your collection run.

Prove it — the Day-4 mastery quiz (100+ questions, every topic)