Use cases
Last updated 1 day ago
Four things teams do with Mobioos today. For the end-to-end walkthrough of a customer ticket traced to code, see Connecting Business Intent to Code.
Onboard anyone onto a product nobody can fully explain
The situation. Someone joins and faces a codebase nobody can fully explain. It runs in production, the people who built it have moved on, and the documentation stopped being true two years ago. Ramp-up is measured in weeks, and most of it is archaeology rather than work.
The file tree tells you where things are. It does not tell you what they are for, which rule is deliberate, or where a feature actually lives. Text search finds the word you guessed, not the concept you meant.
How Mobioos is used. Create a Domain Context and feed it what explains the product: specifications, diagrams, recordings, whatever written knowledge exists. Then scan the code with Forge, which forms the Code Parcels that tie each context object to its implementation.
In Fusion, open the Domain Context as a graph, click a business rule, and land on the code that implements it.
In Forge, navigate by business intent without learning the folder structure first. Mapped code is highlighted, so you see at a glance which feature a file serves.
Pull the business context of whatever you are looking at into your editor: quality findings, security alerts, the tickets that shaped it.
The same connections serve the AI agents you work with: they get the business context linked to the code they are examining.
What you end up with. Not one person who has learned the codebase, but a model of it the whole team keeps. Every correction anyone makes is saved and shared, so the tenth person to join starts from everything the first nine understood.
See where the trouble actually is
The situation. Your quality scanner reports two thousand issues and your security scanner three hundred. Both are right, both are unusable. A list of files with problems does not tell you whether the product is at risk, or where to spend next sprint.
How Mobioos is used. Connect the tools, open the Service Connections panel, and project a measure onto your model. The graph colors itself by severity and every element carries its counts.
You are no longer reading a list of files. You are looking at your product with its weak spots lit up. A feature carrying 202 critical findings next to one carrying 2 is a prioritization call that takes seconds.
Open the Data panel on any element and every connector's findings for that part of the domain are aggregated in one place. Neither SonarQube nor Aikido knows what a feature is. Here both are read against the same business concept.
Why it matters. The information already existed, split across tools that each saw a fragment. What was missing was a shared reference telling them which part of the product their findings concerned.
Size the work before you commit to it
The situation. Someone asks how long it will take to change the catalog. Today the answer is a guess, because nobody knows how much code a feature actually represents.
How Mobioos is used. Open the table view of your Domain Context. Each context object carries its Files, Lines of code and Data item counts, straight from its Code Parcel.
On a real project the spread is wide enough to change decisions on its own. One feature at 287 files and 32,000 lines sits next to another at 3 files and 191. The first is a project, the second is an afternoon, and no amount of discussion would have established that.
Add connector data and the picture sharpens: a feature that is large, carries critical findings and has low coverage is a different proposition from one that is large and clean.
Why it matters. Estimation usually runs on the memory of whoever has been there longest. This puts a number on it, per feature, from the code as it exists rather than as anyone remembers it. It is also the groundwork for splitting a monolith along business lines.
Turn a feature into a product
The situation. A capability buried inside an application could stand on its own: a pricing engine, an eligibility check, a catalog service. Other teams, or other customers, would use it. Nobody moves on it, because nobody can say where it starts and stops in the code.
How Mobioos is used. Open the feature's context object and you get its full footprint: the Code Parcel with the files and lines that implement it, across repositories if need be, the findings your tools report on it, and how it connects to the rest of the product. The boundary nobody could draw is now on screen.
Why it matters. That footprint is what turns a buried capability into something you can isolate, package and expose on its own, as a service or as an API. A feature that was only a cost inside a monolith becomes something you can sell.