Modeling in Cameo: what this means for your program
This page is the two-minute version. The full guide, written for the engineers who'll actually do the modeling, is here if you want the detail.
The problem, in one paragraph
For roughly the last ten years, Cameo has only fed one kind of information into Capital: structure, the parts and ports a system is built from. It has never fed behavior, the functions a system performs, downstream at all. That means what a component is for has lived in someone's head or a document, not in the connected model your program relies on.
What changes
A new, more complete modeling standard that carries both structure and behavior across the bridge, consistently. It's not a new tool and not a rewrite; it's a discipline for how your systems engineers already use Cameo.
Why it's worth sponsoring
- Catches broken designs earlier. Both Cameo and Capital have design-rule checks that only work if the model is built correctly; done right, a missing connection is an error on a screen during architecture work, not a surprise during a costly change.
- One standard instead of eleven. Lockheed's own methodology isn't mandatory today, so practice varies program to program. This gives every program the same defensible answer instead of each one improvising.
- Traceability that actually holds. Function-to-component traceability is the whole point of a digital thread; a model that only carries structure can't deliver it.
What it costs to adopt
Less than a full rewrite. Existing models don't need to be redone before they're useful, function-by-function migration is the intended path, not a big-bang conversion. See the full guide's migration section for the specifics your systems engineers will follow.
The ask
Agree that new modeling work on your program follows this standard going forward, and let your systems engineers know it exists. That's the whole first step.