What Are Smart Packages in Cameo and When Should I Use Them?

A smart package is a package whose contents are computed by a query instead of placed by hand. You define criteria — element type, attribute values, relationships, modification date — and the package continuously shows every element in the model that matches, updating itself as the model changes. Use them for living views like “all unsatisfied requirements” or “everything modified this week”; don’t use them as your primary model organization.

Regular packages are folders: an element is in one because somebody put it there. Smart packages are saved searches that look like folders. That one idea, used well, replaces a whole category of manual bookkeeping.

How they work

Create one from the containment tree: right-click a package, and in the create-element options pick Smart Package. In its Specification window you’ll find the content criteria. You can combine:

• Element type — Requirements, Blocks, Activities, whatever you’re hunting.
• Scope — which part of the model to search, recursively.
• Property and attribute conditions — name contains “GPS”, Priority equals High, Text is empty.
• Relationship conditions — has (or lacks) a particular relationship, like an incoming Satisfy.
• Standard filters — including ready-made ones like recently modified elements.

The package then behaves like a live result set. Open it and the current matches are there. Change the model and the membership updates — no refresh button, no stale list. You can also freeze a smart package’s content when you want a snapshot rather than a live query, which is handy for baselining what a review actually covered.

One important mental adjustment: elements appear in a smart package, but they still live wherever they were created. The smart package doesn’t own them — it references them. Deleting an element from your model is real; an element dropping out of a smart package just means it stopped matching.

Three uses that earn their keep

All unsatisfied requirements. Criteria: type = Requirement, no incoming Satisfy relationship. In the drone model this instantly surfaces the camera-payload requirements nobody has connected to a block yet. It’s a permanent, self-updating to-do list, and it hits zero exactly when your traceability is complete. Pairs naturally with the table workflow from How Do I Review Hundreds of Requirements Fast in Cameo? — scope a generic table to the smart package and you’ve got a live gap report you can export.

Elements modified this week. Use the recently-modified filter, scoped to the whole project. Before a team sync, open the package and you’re looking at exactly what changed — who touched the flight controller’s ports, which requirements got reworded. On multi-modeler projects this is the cheapest change-awareness tool you’ll find.

Orphaned or suspicious elements. Blocks with no relationships at all, elements whose documentation is empty, unattached comments. These queries find the debris that accumulates in any model over months — the ESC block someone duplicated during an experiment and forgot. We keep a small Model Health package with two or three of these inside.

When NOT to use them

Smart packages are views, and trouble starts when teams treat them as structure.

• Don’t organize your model with them. Your containment tree should be deliberate, stable, owned structure — real packages, real decisions about where things live. If your primary hierarchy is a stack of queries, then renaming an element or editing an attribute silently reshuffles your “folders,” and nobody can answer the basic question “where does this element live?” Structure is a choice; smart packages are a lens.
• Don’t let them multiply unbounded. Every open smart package is a query the tool keeps satisfied. A handful of well-chosen ones is free; dozens of broad, project-wide queries can noticeably drag on large models. If a query is only needed occasionally, an on-demand search or a table does the same job without the standing cost.
• Don’t build fragile criteria. A query keyed to “name contains ‘FC-‘” breaks the day someone renames the flight controller prefix. Prefer criteria based on types, stereotypes, and relationships — things with semantic meaning — over string matching, which is convention held together with hope.
• Be careful using them as scopes for automation. Anything that iterates “whatever’s in this smart package” — reports, scripts, exports — inherits the query’s volatility. Sometimes that’s exactly what you want; just make it a decision, not an accident.

The rule of thumb we give teams: if you’d describe it as “the set of things that currently…”, it’s a smart package. If you’d describe it as “the place where we keep…”, it’s a regular package.

Start with one

If you’re new to smart packages, don’t design a grand system. Create exactly one — unsatisfied requirements is the best first pick because it’s unambiguous and immediately useful — put it in a Model Health package, and live with it for two weeks. You’ll quickly develop a feel for which questions you ask the model often enough to deserve a standing answer. On a healthy project that’s usually three to five packages, not thirty. And if your containment tree is already a mess of ad-hoc groupings, fix that first — How Do I Keep a Large SysML Model From Becoming a Mess? covers what deliberate structure looks like.

Where to go from here

A Model Health package full of live queries is one of those upgrades that takes an hour to set up and pays off every single week — and it’s the kind of thing we set up with teams constantly, whether in an advisory engagement or hands-on Cameo training for your whole group. If you’d like a second pair of eyes on how your model is organized, CameoMagic offers a free 30-minute model review — bring your project, and we’ll point out the quick wins. Details at cameomagic.com.