Take these to your next vendor meeting. Watch how they answer. The pattern of their answers will tell you more about whether their platform actually handles ephemeral services than any architectural slide deck ever could.
By Shawn Ennis • August 4, 2026 • 8 min read
I spend a fair amount of my week in conversations with CSPs evaluating their OSS roadmap. The pattern that comes up in nearly every one of those conversations is the same: the operator already has a major OSS vendor relationship, they’re being told that “slicing support is on the roadmap,” and they want to know whether to believe it.
The white paper I wrote on this topic includes three diagnostic questions for CSP CTOs to ask their current OSS vendor. They’re short, they’re concrete, and the answers are revealing. But asking the questions is only the first step. The art is in reading the answers — knowing what to listen for when the vendor responds.
This post is the field guide to those answers. Three questions, three response patterns to watch for, and one bonus question that closes the trap.
Question 1: “Can your service catalog instantiate a service that lasts 18 minutes?”
What you’re really asking: can the catalog model ephemeral services as first-class entities, with their own lifecycle, parent relationships, SLAs, and revenue events?
What a good answer sounds like
“Yes. Our catalog supports service templates with configurable lifecycle parameters. A mission-type service can be instantiated via API in under five seconds, registered with a specific SLA, billed against actual duration, and auto-decommissioned on completion. Here’s a demo. Here are the API specs. Here’s a customer in production with this capability.”
What a bad answer sounds like
“We’re enhancing our catalog to support more dynamic service models. We’re working with several operators on slicing pilots and have a roadmap commitment for next year. Let me set up a follow-up call with our product manager.”
Translation: their architecture doesn’t handle ephemeral services natively. They’re trying to bolt the capability onto a static catalog. The implementation will be brittle, slow, and require integration work for every new service type.
The follow-up that closes the trap
If the vendor says yes, ask: “Can you show me a service in production today, on a customer system, that has a lifecycle measured in minutes or hours?” If they pivot back to the roadmap, you have your real answer.
Question 2: “Can your correlation engine scope RCA to a mission context?”
What you’re really asking: can the engine narrow its analysis to the specific service or mission affected, complete the analysis before the service ends, and surface only the impact relevant to active customer commitments?
What a good answer sounds like
“Yes. Our correlation engine takes service context as input — it knows which alarms are associated with which active mission, slice, or session. When a network event affects multiple services, we produce one impact summary per affected service. RCA completes in seconds, not minutes. Here’s a screenshot of a real RCA timeline from production.”
What a bad answer sounds like
“Our correlation engine is highly configurable and can be tuned to consider various contextual signals. With the right policy templates, customers have achieved significant alarm reduction. Our services team can help design the right correlation logic for your environment.”
Translation: the engine is static, the configuration is manual, and “service context” is a flag you set on alarms — not a real-time graph the engine traverses. RCA will take hours or days, not seconds.
The follow-up that closes the trap
“Show me how the correlation engine learns the relationship between a slice and the underlying network resources when the slice is instantiated dynamically.” If the answer involves “data modeling work” or “service definition templates,” the engine doesn’t actually understand ephemeral services — it understands static topology with labels.
Question 3: “Can your topology view update in real time as services move geographically?”
What you’re really asking: does the visualization layer reflect actual service state right now — or is it a periodically-refreshed snapshot of inventory data?
What a good answer sounds like
“Yes. Our topology view streams updates from network telemetry, edge compute telemetry, and application state. Mobile assets show their current GPS location, updated every 60 seconds or faster. Slice anchors visualize their current edge attachment, with live indicators when they re-anchor. Here’s a live link to a customer dashboard.”
What a bad answer sounds like
“Our topology visualization is built on best-in-class graph technology and refreshes from our inventory system. Refresh intervals are configurable from 15 minutes down to several minutes for high-priority services.”
Translation: their topology is a periodic dump of static inventory. Not a streaming view. For ephemeral services that live for less than the refresh cycle, the topology is permanently wrong.
The follow-up that closes the trap
“In your view, when a drone moves from one antenna to another, does the connection visualize the handoff in real time, or does it disappear and reappear at the new anchor on the next refresh cycle?” Disappear-and-reappear is the signal. Real-time platforms render the transition; static platforms render the after-state.
The bonus question — and why nobody asks it
Here’s the fourth question that almost no operator asks and that almost guarantees you learn something real about the vendor:
“Can I see a recorded incident from your production deployment where a slice failed mid-mission, your platform identified the root cause within 30 seconds, and the customer SLA was preserved through automated mitigation?”
This question does three things at once. First, it requires the vendor to produce evidence rather than claims. Second, it forces them to admit whether they have customers actually running slices in production. Third, it scopes the answer to a specific scenario — fast RCA, automated mitigation, SLA preservation — that the platform must actually deliver to operate slicing as a product.
If they have a clean answer, you’re talking to a platform that does the work. If they don’t, you’ve just learned something more important than any architectural diagram could tell you.
The pattern that runs through all four questions
Notice what these questions have in common. None of them ask about technology stack. None of them ask about cloud-native architecture or microservices or AI/ML capability. The marketing-tier vocabulary that floods the OSS conversation isn’t useful for separating real capability from theater.
What these questions ask instead is: can your platform actually do the things ephemeral services require? The architecture buzzwords are downstream of the answer. A platform that handles 18-minute service lifecycles, mission-scoped RCA, and real-time geographic topology probably has the modern architecture story. A platform that can’t do those things doesn’t have the modern architecture, no matter what the slide deck says.
One last suggestion: ask your existing OSS vendor these questions. Then ask your top two competing vendors the same questions. The variance in answers will tell you more about the vendor landscape than any analyst report. The questions cost nothing to ask. The information they surface is worth a budget cycle.
What to do with what you hear
If your incumbent vendor passes all four questions, you’re in great shape. Re-confirm the commitments in writing, ask for production references, and move forward.
If your incumbent vendor fails on one or two questions, decide whether you have time to wait for their roadmap to mature. The slicing revenue window is open now. Every quarter you wait, the addressable market shifts to platforms that can deliver today.
If your incumbent vendor fails on three or four, you have a strategic decision to make about whether the existing OSS relationship is still serving your business case. That’s a hard conversation, but it’s a more honest one than continuing to fund a platform that can’t operate what your network can already sell.
The full diagnostic framework
Plus the four “new tricks” every modern OSS needs to learn and the 6-month adoption roadmap.
About the author Shawn Ennis is the Founder & CEO of Rapax and Citus Technologies. With 25+ years in telecom operations, Shawn previously founded Assure1 (acquired by Oracle in 2021), holds 12 patents in telecom OSS/BSS, and hosts the Transformation Leaders Podcast. Connect on LinkedIn.