How to Use Labels and Search to Find What You Are Looking For?

Published by on July 15, 2015 at 11:56 am.

How to Use Innoslate for Intermediate Users

One of the problems of MBSE at scale is finding a model element. I am sure that many of you reading this have done the dreaded folder walk (opening a seemingly never ending folder within a folder) or scrolling endlessly to find that specific model element. Innoslate has two features that try to combat that problem, Labels and Search. When used together these features can greatly reduce the time, effort, and stress associated with looking for a piece of data within the database. Below is an overview of each feature and how they can be used to move around the model effortlessly.


A Brief History

The idea of labels gained popularity with the release of Google’s Gmail. Email clients before tended to organize emails into a folder structure that is similar to the folder system found on operating systems. Prior to the release of Gmail, Google recognized that there would be an exponential growth in the volume of emails a person would receive in the coming years. From this insight, they chose a label system for Gmail that allowed similar data organization as folders but kept the scalability need to handle emails going forward.

SPEC Innovations has applied the same forward thinking to MBSE in Innoslate. We recognized that in an age of big data and the Internet of Things, a classic folder system would not work at the size Innoslate scales to. At SPEC, we pushed the idea of labels beyond an organizational role into a multipurpose information tool. The primary purposes of labels are organization, typing, and markers.


As mentioned above, Innoslate uses labels to aid in the organizational structure of models. Unlike with a folder system, a single model element can have multiple labels (where as a single model element can not be in multiple folders). In the past, if I wanted to model a single element being used by two subsystems, I would be forced to create a duplicate element and rely on a naming convention to signify that they are the same element. As many of you are aware (and have experienced) this turns into a configuration management nightmare, as updates are commonly only added to one of the elements instead of to both. Resulting in data being out-of-sync and adding confusion.

Using Innoslate’s Label feature, I am able to have one model element (represented as an entity) that has multiple labels. This signifies that that entity is being used in multiple subsystems and there is no worry about a duplicate element becoming out-of-date as the model is updated.


The next purpose of labels is to type a specific entity. Typing is a way to add additional information about a collection of entities that are similar. Within Innoslate, the label “Person” on the Asset class is a typing label. This label signifies to users that this group of entities represent people and not, for example, robots.

I will often use multiple typing labels to provide even more insight into a model. For example, in a radio communication system an Asset entity could represent a solder responsible for relaying information. That Asset entity could have the labels: “Person”, “Solider”, and “Radio Operator”. Each one of those labels adds useful typing information about that specific Asset entity.


The final purpose of labels is to act as a marker or a flag. Similar to how you might highlight a line in a report or star an email in your inbox, labels can act as a way to draw attention/highlight a part of the model. I often use this to mark entities that need review from subject matter exports or to signify that these entities are still in a draft state.

Using a label as a marker is also a good way to generate specific reports, as many of Innoslate’s reports support filtering by label. Doing this on entities with a created marker label “Needs Review”, would allow you to get an export of just those entities or a report of their state.

Useful Documentation

Adding a label to an entity:

Creating a new label:


Innoslate’s Search feature is a powerful way of jumping to specific entities. You can find it in the toolbar under Menu. I have found that when the database is greater than about 150 entities it is easier for me to search for entities than scroll through database view to hunt for them. Below are some of the most common searches you can use:

  • label:LABEL_NAME  This search returns entities that have that label. Often I will use this to see and understand how many entities are of a specific type. For example, searching for “label:Person” would return entities that have the “Person” label.
  • is:orphan This search returns entities that have no relationship to ANY other entity in the database. This search is a great way of finding entities that have no impact on the systems and are candidates for deletion.
  • is:root This search returns entities that do not have a parent relationship (decomposes). This search only checks to see if there is no parent, it does not check to see if a given entity has children (decomposed by). “is:root” is my go to solution to finding entities that are at the top of a hierarchy to view their associated diagrams.
  • ANY_TEXT This search returns entities that contain the text in the name, number, or description.

One of the great things about Innoslate’s Search feature is that these search terms can be combined with simple boolean operations. These boolean operations help increase the relevance of the returned entities. The boolean operations that Innoslate Search supports are:

  • AND  This operation is useful to find entities that meet both search criteria. This is also the default boolean operation if two search queries are done together. (i.e. “class:Action label:Function” is handled as “class:Action AND label:Function”).
  • OR This operation allows for searches with a level of uncertainty. For example, to search for an entity that has the label “Function” or “Activity” the search term of: “label:Function OR label:Activity” would be used. (For all you fans of the boolean truth table, this is an “inclusive or”)
  • NOT This operation is ideal for reducing the size of the returned data set. Similar to computer programming languages, a “NOT” returns entities that do not have/meet the parameter. An example of this is searching for entities that are only Assets but not Resources (the search term “class:Asset” would return entities that are Resources because Resource is a subclass to Asset). The search term for this would be “class:Asset NOT class:Resource”.

More information about the search terms can be found at:


I recommend that as you build your model, you spend the time to think about how you can apply labels to the entities you are creating. This way as the model continues to grow, insight into the model can be gained and time spent navigating the model is reduced. Together, Innoslate’s Label and Search features, can turn an unruly large database into one that you can manage with ease.