Skills

TC Mission Engineering

Skill tc-mission-engineering. Build business or mission analysis (ISO/IEC/IEEE 15288:2023 clause 6.4.1) and DoD Mission Engineering (MEG 2.0, Mission Architecture Style Guide, UAF) in Teamcenter - the problem/opportunity space, solution classes, preliminary operational concepts, mission threads and the traceability into stakeholder and system requirements. Covers the Seg0 operational-analysis layer that ships in the systemsengineering template and is absent from the documentation set, which OOTB types carry which 6.4.1 concept, the two concepts that have no carrier, and the relation-verification path that works when the usual one silently returns nothing. Use for mission analysis, concept definition, capability gap analysis, trade-space framing, operational concepts, mission threads, mission engineering threads, METs, MOE/MOP measures, baseline versus alternative mission architectures, or finding which Teamcenter capability serves the front of the life cycle.

Business or mission analysis is the earliest and most consequential process in the life cycle, and a survey of the Teamcenter 2606 documentation set found no module for it. That survey was right about the documentation and wrong about the product. The systemsengineering BMIDE template ships a complete Arcadia-style operational-analysis layer, and every type in it is live and creatable. It is simply never named as a module in any level-1 topic list.

Verified live on both tiers on 2026-08-08, by separate probes: cloud2506 (TC 2506.0004, Lockheed-flavoured, 183 templates) and the vanilla TC2606 VM (26060.0000, vm2606). Item ids and uids below were returned by tool calls and re-fetched, and come from cloud2506 unless stated.

★★★ The whole module runs on the TC2606 VM with ZERO BMIDE work. Probed there directly: all 11 Seg0 types, all 10 Eml0 UAF types, Requirement, RequirementSpec, Fnd0LogicalBlock, Functionality, and the entire parameter tier including Att0AttributeDef and Att0ParamDictionary are present. Only the Decision Support System types are absent, which is expected and is a positive absence test (43 descriptors returned for 33 requested). Do not assume a Lockheed-tier finding carries to a vanilla tier, but in this case it does, and it was measured rather than assumed.

★★ Corroborated at RELEASE level too, which is the stronger pairing. Both systemsengineering (Seg0) and eml0entarchmodeling (Eml0) are documented templates in the 2506 and 2606 data model reports, so these layers are product, not a cloud2506 site artifact. Release evidence says "the product ships it"; the getTypeDescriptions2 probe says "this tier has it". Cite both: either alone is weaker than people assume.

What actually exists OOTB, and what does not

Seg0MissionRoot (abstract, Item)
  +- Seg0Mission          "Mission Profile"
  +- Seg0MissionPhase     "Mission Phase"
  +- Seg0MissionEvent     "Mission Event"
  +- Seg0EnvCharstic      "Environmental Characteristic"
  +- Seg0SplCondition     "Special Condition"

Seg0FtCapability          "Capability"              (Item)
Seg0OpActivity            "Operational Activity"    (Functionality subtype)
Seg0OpPerformer           "Operational Performer"   (Fnd0LogicalBlock subtype)
Seg0OpArcht               "Operational Architecture"(Seg0OpPerformer subtype)
Seg0FxChain               "Functional Chain"        (Fnd0SEBlock subtype)

Confirm on a new tier with one call:

Core-2015-10-Session/getTypeDescriptions2
{"typeNames":["Seg0Mission","Seg0MissionPhase","Seg0MissionEvent","Seg0FtCapability",
              "Seg0OpActivity","Seg0OpPerformer","Seg0OpArcht","Seg0EnvCharstic",
              "Seg0SplCondition"],
 "options":{"PropertyExclusions":["All"],"TypeExclusions":["All"]}}

⚠ This response is ~2.7 MB for 13 types. Write it to a file and parse it; do not try to read it inline.

The mapping that matters

15288 6.4.1 concept	Carrier	BMIDE needed?
Preliminary operational concept (activity c1)	`Seg0OpArcht` + `Seg0OpActivity` + `Seg0OpPerformer`	no
Mission thread / operational scenario	`Seg0Mission` + `Seg0MissionPhase` + `Seg0MissionEvent`	no
Operating environment (NOTE 11)	`Seg0EnvCharstic`, `Seg0SplCondition`	no
Target capability (NOTE 2)	`Seg0FtCapability`	no
Solution class (NOTE 14)	`Eml0CapConfig` "Capability Configuration"	no, see the correction below
Problem / opportunity statement	`Requirement`, and nothing better exists	no carrier at all

★★ Searching for a trade-study or decision-record type is a dead end. The Crt0Study / Crt0SimStudy / IAV0TestStudy family is verification and validation studies, not trade studies. No weighted evaluation and no decision record exists anywhere in the installed model, on either tier.

★★ Confirmed independently at RELEASE level, by a different instrument. The Teamcenter data model reference session searched name and Siemens description across all 9,229 documented 2606 business objects for alternative|trade.?stud|candidate solution|solution class: four hits, all incidental prose, plus Mfg0BvrAlternativeScope, which is a RuntimeBusinessObject computed view. Zero viable carriers. I searched type names on a tier; they searched the prose Siemens wrote to describe each type at a release. Two instruments, same answer. State this absence without hedging.

An in-house prototype BMIDE template under D:\repos\decisionsupport supplies DSSDecision and kin, but it is a prototype rather than a Siemens product, and those types have no Business_Object page at either release, so there is nothing to deploy. Do not plan around DSSAlternative. See tc-decision-management. That is the real residue of the 6.4.1 gap, and it is shared with clause 6.3.3.

⚠ But a criteria registry DOES exist, and an earlier draft of this skill said it did not. Att0ParamDictionary plus Att0AttributeDef is a registry of measurable terms with real units of measure, and both are present on the VM. It ships under the name Parameter Management, which is why searching for "criteria" misses it. Corrected by the tc-decision-management session. That is the second time today that looking for a concept by its 15288 name rather than its Siemens name produced a false gap.

Carriers for the two that have none

Concept	Carrier	BMIDE needed?
Problem / opportunity statement	`Requirement` inside a `RequirementSpec`	none available, see below
Solution class	`Eml0CapConfig` "Capability Configuration"	no

★★★ Use Eml0CapConfig, not Eml0ResArcht. Third and final carrier revision. Fnd0LogicalBlock was wrong (generic), Eml0ResArcht was better (UAF, keeps the capability link), and Eml0CapConfig is right. Its parent is Eml0ResArcht, so this is a specialisation and not a detour, and its Siemens description is almost a definition of a solution class:

"A composite structure representing the physical and human resources (and their interactions) in an enterprise, assembled to meet a capability."

Paired with Seg0FtCapability ("the ability of the System to provide a service that supports the achievement of high-level operational goals") that is the canonical UAF shape: one Capability, N alternative Capability Configurations that could deliver it. Course of action at class altitude, in the idiom UAF intends, rather than an architecture object pressed into service as a class.

It also sharpens the capability-gap story: a gap is a Capability with no adequate Configuration.

Verified on vm2606: present, parent Eml0ResArcht, and a throwaway instance took Seg0Exhibits to a Seg0FtCapability and read back through expandGRMRelationsForPrimary, then deleted with zero footprint. Found by the Teamcenter data model reference session by reading descriptions, which is a carrier neither type-name search nor sibling reading had surfaced.

★★★ CORRECTED 2026-08-08: use Eml0ResArcht, not a bare Fnd0LogicalBlock, and do NOT author a BMIDE Msn0SolutionClass. The first pass of this skill said Fnd0LogicalBlock was the only viable carrier and proposed a BMIDE type to improve on it. Both were wrong, and the reason is the same methodological error that produced the original 6.4.1 gap call: I searched the templates I already knew about instead of enumerating all of them.

The eml0entarchmodeling template is already installed and carries the UAF Resource and Services layers. Confirmed live via getTypeDescriptions2:

Type	Display name	UAF concept
`Eml0ResArcht`	Resource Architecture	ResourceArchitecture
`Eml0CapConfig`	Capability Configuration	CapabilityConfiguration
`Eml0ResPerformer`	Resource Performer	ResourcePerformer
`Eml0SystemRes`	System Resource	System
`Eml0ResOrg`	Resource Organization	ActualOrganization
`Eml0ResPost`	Resource Post	ActualPost
`Eml0ResArtifact` / `Eml0SoftwareRes` / `Eml0TechResource`	Resource Artifact and kin	ResourceArtifact
`Eml0SvcArcht` / `Eml0SvcPerformer` / `Eml0SvcFunction`	the Services layer	Service*

Eml0ResArcht descends Eml0ResArcht -> Eml0ResPerformer -> Fnd0LogicalBlock, so it inherits Seg0Exhibits legality. Proven live rather than inferred: a throwaway Eml0ResArcht took Seg0Exhibits to a Seg0FtCapability and Seg0Satisfy to a Requirement Revision, both read back through expandGRMRelationsForPrimary, then deleted with zero footprint.

Three reasons it beats a bare Fnd0LogicalBlock:

It keeps the capability link, which is the whole constraint.
It is semantically typed. A solution class stops looking like a generic system block, which was the real cost of the Fnd0LogicalBlock choice.
It is the exact UAF concept the DoD MASG model uses for baseline versus alternative (E2E V1 USA SEAD - Baseline and E2E V1 USA SEAD - MC-130 Alternative are both ResourceArchitecture), so the Teamcenter carrier and the DoD reference model finally agree.

⇒ Teamcenter, Seg0 plus Eml0 together, is a near-complete UAF implementation: Operational domain in Seg0Op*, Resource domain in Eml0Res*, Services domain in Eml0Svc*, capability in Seg0FtCapability and Eml0CapConfig. Nobody documents it that way. That is the single most useful thing in this skill.

★★★ THE ROW THE INSTRUMENT TABLE WAS MISSING: what does this call return when it HALF-WORKS?

Every instrument below answers "which question does this call answer". None of them answers the one that actually cost this workspace two days: what does it return when it half-works?

On this stack the answer is almost never an error. It is something plausible. Collected across four sessions, all measured:

What you asked for	What you got	What it looked like
an ordered mission	`seg0PhaseOrder` null on every relation	an ordering that is not ordered
a measured quantity	parameters bound to `Integer (each)`, no unit, no goal	a parameter that is not a quantity
an object by uid	a `TC:` prefixed id returns empty type, empty props	a uid that is not a uid
does this type exist	`tc_query_by_type` returns `nFound 0` for real and fake alike	an absence that is not absence
a property write	`updated` names a `UserSession`, not your object	a write that is not a write
an object create	`output: []`, no `partialErrors`, over a 240-char `object_desc`	a create that is not a create
a rendered tab	cold pool serves the old stylesheet	a fix that is not a fix
a complete census	`--min`-filtered rows reported as the whole set	a complete view that is not complete
a validation type	`Crt0VldnContract` display-names as Verification Request	a name that is not the meaning

⇒ The instrument tells you which question is being answered. It does not tell you whether the answer is real. Those need separate checks, and the second is the one people skip because the first succeeded.

★★★ The generalised defence, in order of cost:

Assert on the artefact, never the call. Re-read the thing you wrote and compare it to what you intended. ok: true is not evidence.
Put a known-real and a known-fake control in the same call. A short answer is otherwise ambiguous between "absent" and "the call is broken".
Check the identity in the response. updated must contain your uid; output must be non-empty; a descriptor list must contain the name you asked about. Every trap above passes a naive success check and fails this one.
Run it twice with identical inputs and diff. Coverage is not stable unless you made it so.
Then, and only then, believe the instrument.

★ A failing control tells you something is wrong. Only a working call tells you what right looks like. If you have never seen the operation succeed, you cannot tell a broken request from a broken tier, which is exactly how "this tier is create-only" got published here.

★★★ How to test whether a type exists, and the method that CANNOT

This matters more than any single finding here, because three false "no module" calls in one day all came from using the wrong instrument.

Six instruments, and each answers a different question. Pick deliberately.

#	Instrument	Question it answers
0	Which release is the question about?	pin it first, the rest are meaningless without it
1	Release data model report catalog	Does this type exist in the PRODUCT at release R?
2	Module prose in the install media	Is there a MODULE for this concept, in Siemens' own words?
3	Saber Atlas BMIDE export	Which TEMPLATE owns it, and what are its GRM rules? One tier
4	`getTypeDescriptions2` with controls	Is it INSTALLED on this tier?
5	`tc_query_by_type` / any instance query	Is it POPULATED here? Cannot answer any of the above
6	Install media `dc_contributions/`	Is it SHIPPABLE in the kit we hold? (not entitlement)
-	A documentation survey of the shipped guides	NONE OF THESE. It establishes what Siemens chose to write a manual about

★★★ AN ABSENCE CLAIM IS ONLY AS GOOD AS THE ENUMERATION BEHIND IT, AND AGENT-DRIVEN ENUMERATION IS NOT REPRODUCIBLE. The se-process-skills session measured this directly: the same seat, on identical inputs, abstained in one replicate and scored in the other, because one run enumerated Att0ParameterSet and the other did not. The abstention was wrong and the data existed.

That is a hole in everything above. The instruments are sound and the coverage is what varies, so two careful people running the same instrument can reach opposite conclusions and both believe they enumerated properly.

⇒ Never report absence from a hand-driven or agent-driven search. Script it: a fixed candidate list, controls in the same call, and the output written to a file you can diff. If you cannot re-run it and get byte-identical coverage, you have an opinion about absence rather than a measurement of it. Every absence claim in this skill was produced that way, which is the only reason they are quotable.

★★★ Rows 2 and 3 are complementary and neither substitutes for the other. Module prose answers "is there a MODULE for X"; type descriptions answer "is there a CARRIER for X". Eml0CapConfig would never surface from module prose, and Parameter Management would never surface from type descriptions. Running only one of them is how three false gaps happened.

★★ Row 2 would have prevented the worst of them on day one. Searching Siemens' module descriptions for criteria/measurable/parameter returns att0attrtargetmgmt "Parameter Management": "allow users to manage parameters (goal and measured value) for the requirement, logic block, connection". That is the criteria-registry retraction, findable in one query, before anyone authored anything.

⚠ Row 2's noise profile: signal depends on the concept being module-shaped. "Parameter Management", "Cost Management" and "Provisioning" score cleanly. A generic word like "capability" returns 31 hits, mostly marketing prose ("provides capability for..."). It is a fourth instrument with its own failure mode, not a universal fix.

⚠ Row 6 has two DISJOINT registries in the 2606 media, and reading one gives a confident wrong answer: application_registry/<app>_config.json (462 units, holds fha0fhanalysis, mq0hara, eml0entarchmodeling) and packages/<pkg>_package.xml (384, holds systemsengineering, pac0provisioningandcataloging). Union 846, zero overlap. Their en_US bundles are likewise in separate folders. Also only 384 of 6,569 XMLs under packages/ are packages, so filter on the root element, not the folder.

★★★ Row zero is the one to run first and almost nobody does. It is offline, instant, and it killed DSSAlternative in a single lookup: that type has no Business_Object page in either the 2506 or the 2606 data model report, so it is not in the shipped product at either release. It is not "undeployed", there is nothing to deploy. Owned by the Teamcenter data model reference session, whose index carries owning template, parent, abstract flag, create-input type and the Siemens description per type.

tc_query_by_type("DSSAlternative") and tc_query_by_type("Zzz0NoSuchTypeExistsAnywhere") both return nFound 0, items [] on vm2606. An instance query shows what is populated, never what is installed, and "deployed but unused" is exactly the category you are hunting.

getTypeDescriptions2 returns a descriptor for every type that exists and silently omits the rest, so the omissions are the answer. Verified on vm2606 with controls in the same call:

requested 6, returned 2
  Item                          RETURNED     <- real, control
  Eml0ResArcht                  RETURNED     <- the type under test
  Zzz0NoSuchTypeExistsAnywhere  omitted      <- fake, control
  Qqq9AlsoFake                  omitted      <- fake, control
  DSSAlternative                omitted      <- genuinely not deployed
  Msn0SolutionClass             omitted      <- never authored

★ Always put a known-real and a known-fake control type in the same call. Without them a short response could equally mean "the call is broken", and that ambiguity is what makes an absence claim unsafe.

⚠ This still tests types, not templates. A template that is available in the Deployment Center software repository but not applied to the tier will show all its types as omitted, indistinguishable from a template that does not exist. For that question the authoritative sources are the Deployment Center software repository and the tier's installed-template list, not the data model. See tc-deployment-center.

⚠ The method above has a SECOND limit: it cannot enumerate

getTypeDescriptions2 only answers about names you supply, and a guessed-wrong name is omitted exactly like an uninstalled one. So probing Msn0* or Chx0* blind is guessing at names, not testing availability. Enumeration has to come from somewhere else.

It now does. The SE status reports session extracted the Help Server data model report into an enumerable catalog at **C:\Users\chris\Documents\Siemens\tc-module-map\**: types-by-module.tsv (5,476 types, 247 module prefixes) and module-index.tsv.

⇒ The workflow is three steps, and step 1 was the one everybody was missing:

1. ENUMERATE  grep types-by-module.tsv for the CONCEPT, not for a guessed prefix
2. READ WHAT  the type is FOR. Its module's sibling types are the fastest tell.
              Drop wrong-domain hits however well the name reads.
3. TEST       getTypeDescriptions2 on survivors, with real and fake controls
4. PARENT     check it. A RuntimeBusinessObject persists nothing.
5. only then  consider BMIDE

★★★ Step 2 is the one people skip, and it is not optional. A catalog grep returns name matches, not semantic matches, and words like characteristic, maturity, status, state, goal and problem mean different things in quality, manufacturing, change management, ALM and configuration. The catalog produces candidates; it does not produce meaning. Running step 2 over my own five candidates dropped two outright and demoted a third.

★★★ Rank your evidence. Not all "this type fits" claims are the same kind of claim, and only the last one is worth much.

Evidence	Strength	Example from this work
The NAME reads right	worthless alone	`Chx0Characteristic`, `Tra0ProcurementSchTableRow`, `Pdm1ProblemItem`: all three read perfectly and all three are wrong-domain
The DISPLAY NAME reads right	worthless alone	"Model Based Characteristic" is an inspection point; "User Need" is an FDA design control
SIBLING types constrain the meaning	good, and the cheapest real test	`Mds0Harm` beside `Mds0UserNeed` settled it in one line
STRUCTURAL CORRESPONDENCE to the standard's own tasks	best available, but see the disconfirmation	a module carrying carriers for several named tasks of one clause

The last row does not rest on reading a word, which is why it is the best instrument available. But it was tested on this clause and it did not deliver hard evidence, so do not oversell it.

★★★ DISCONFIRMED 2026-08-08, and I predicted in writing beforehand so it would count either way. The Teamcenter data model reference session scored all 459 templates against the 14 named sub-activities of 6.4.1, then graded its own hits. A third were prose matches rather than meaning: Seg0Derive scored b2 only because "business need" appears in an example of requirement derivation, and Eml0KnownRes scored c1 on "Operational Architecture" appearing inside a constraint assertion.

After grading, no template covers more than one sub-activity genuinely. systemsengineering has c1, eml0entarchmodeling has c2, ipm0integprogmgmt has b2. The clause is spread one-sub-activity-per-template across three modules, so there is no multi-task co-occurrence anywhere, and co-occurrence within one template was the whole basis of the claim.

My own worked example collapsed too. Ipm0PriortAnlsys reads "ranking of projects, programs, goals and initiatives within the roadmap", and Ipm0CstBnfAnlys reads "costs and benefits of projects or initiatives within a roadmap". Four of the six surviving Ipm0 types carry that phrase. They take projects that already exist in a portfolio as their subject, and 6.4.1 operates before there are projects to rank. The mapping matched the activity's VERB while its OBJECT was wrong, which is the Tra0ProcurementSchTableRow error one altitude up.

⇒ Keep the hierarchy, drop the confidence. Structural correspondence still beats vocabulary matching, and it is still what to look for. It simply did not find a strong carrier here, and a single sub-activity hit is not the pattern the row was claiming.

⚠ Weight sibling evidence by how many siblings there are. A three-type module is thin evidence in either direction: "nothing here supports my concept" is not "this is definitely something else". Ipc0 (3 types) is recorded as doubted rather than dropped for that reason, while Ipm0 (30 concrete types) is rich enough that its siblings genuinely constrain the meaning. Sibling reading is a strong test on a big module and a weak one on a small module.

⚠ Step 4 is necessary but not sufficient, and it is dangerous alone: a semantically wrong candidate that happens to be persistent sails straight through a parent check. Chx0Characteristic was caught by its parent, but it should have been dropped one step earlier for being an inspection concept.

⚠ The catalog is the union of two doc collections at different releases (PL20250129156809455, 5,152 types; PL20251212546352891, 5,194). A hit does not establish that a type is in your release's documented model, let alone installed. The control-bearing probe stays mandatory.

★★★ Grep for the CONCEPT WORD across all 247 prefixes, never for a prefix you thought of. Both sessions doing this found their answers in prefixes they would never have opened: Ipm0, Mds0, Icp0, Pdm1 here, and Ipc0MaturityState and Tra0ProcurementSchTableRow for the reports work. Prefix-first search returns what you already suspected, which is exactly how three false gap calls happened.

★★★ A template NAME is not evidence of what its types do. I recommended epc0mfgbvrmaturity to the SE status reports session as a lead for part maturity, purely on the name. Its types are change notices: Epc0MfgCNRevision has parent ChangeNoticeRevision. The template is named mfgbvrmaturity and is manufacturing Change Notice. This is the same error as the documentation survey, one layer up: reading a label instead of the model. Read the types, and read their parents.

★★ Check the PARENT of every candidate before adopting it. Chx0Characteristic is present on vm2606 and sounds exactly like a characteristics carrier. Its parent is RuntimeBusinessObject: a computed view that persists nothing. Same shape as the Arm0RequirementElement trap in tc-object-authoring, where a real type name returns zero from a persistent-object query because it is a runtime view. A getTypeDescriptions2 hit tells you a type exists, not that it can store anything.

★ Struct note: the operation is Core-2015-10-Session/getTypeDescriptions2 and it needs typeNames and options; omitting options faults 214086.

★★★ "Opportunity" is installed, and it means something else

The single cleanest example of the synonym trap, and it bites in the direction that matters. Searching the release catalog descriptions for problem statement|opportunity|capability gap|course of action|unmet need returns 11 viable hits and not one is a 6.4.1 opportunity. They are all the program-management RIO (Risk / Issue / Opportunity) sense:

Psi0RIOPlan, Psi0RIOEvent, Psi0RIOSchedule, Psi0RIOWSO, Psi0RIODeliverable, Psi0RIOAttachment, Psi0PlanOpportunityRelation, Psi0EventOppRelation in psi0ppsminterface
Ipp0OpportunityCost in ipp0ippecore: "positive impact on cost estimates and span time if the given opportunity occurs"
Icp0WindowOfOpportunityRel in icp0campaignmgmt: CPG marketing

★★ Every Psi0RIO* type is an ImanRelation subtype. There is no primary Opportunity object anywhere in the catalog. psi0ppsminterface is the Primavera/PPM interface, so the RIO objects themselves live in the external PPM system and these are relation types pointing at things Teamcenter does not own. Not even a surrogate carrier.

So the Siemens word "opportunity" exists, is installed, and is a different concept. That is the mirror image of the Parameter Management retraction above: there, the concept existed under a name we did not search; here, the name exists attached to a concept we did not want. Both failure modes are live, and only reading the description distinguishes them.

★★★ Carriers that EXIST in the product but are NOT deployed here

Running that workflow changed the answer. An earlier version of this skill said there was no carrier for a problem statement or for UAF EnterpriseGoal / EnterpriseObjective. What is actually true is narrower and more useful: the carriers exist in the Siemens product line and are not installed on our tiers.

Enumerated from the catalog, then tested on vm2606 in one call with two real and two fake controls (16 requested, 4 returned, controls valid):

All absent on vm2606. But absence was only half the question: a catalog grep returns NAME matches, not SEMANTIC matches, and domain words are badly overloaded across 247 modules. Reading each module's sibling types (the fastest tell) dropped two of five candidates outright:

Candidate	What the siblings say the module IS	Verdict
`Ipm0Goal`, `Ipm0Strategy`, `Ipm0VisionStatmt`, `Ipm0StrategyRoadmap`	product portfolio and strategic planning: `Ipm0PlanChrtr`, `Ipm0CstBnfAnlys` cost-benefit, `Ipm0PriortAnlsys` prioritisation, `Ipm0MrktPositn`, `Ipm0IntDepAnlsys`	STRONG. `Ipm0PriortAnlsys` is 6.4.1 activity b3 "prioritise against other business needs" and `Ipm0CstBnfAnlys` is the NOTE 16 cost criterion
`Iim0AbsGoals`, `Iim0TechGoals`, `Iim0FinGoals`	innovation and idea management: `Iim0BusinessCase`, `Iim0DmndAnalysis`, `Iim0MrktAnalysis`, `Iim0TrndAnalysis`, `Iim0IdeaRel`	MODERATE. Market, demand and trend analysis are 6.4.1 NOTE 5 trade-space factors
`Mds0UserNeed`, `Mds0UserNeedSpec`	medical device risk and design controls: `Mds0DeviceRisk`, `Mds0Harm`, `Mds0RiskAnalysis`	WEAK. "User need" here is the FDA design-control term, sitting beside Harm and Device Risk. Conceptually adjacent, wrong domain
`Pdm1ProblemItem`	`Pdm1CalmReportProvider`, `Pdm1CalmSearchProvider`: an ALM integration	DROPPED. Almost certainly a defect or issue record, not a mission problem statement
`Icp0WindowOfOpportunity`	`Icp0CampaignRel`: campaigns	DROPPED. Campaign timing, not an opportunity statement
`Chx0Characteristic`	`Mci0` siblings carry `mci0InspectionProcedure`, `mci0MeasurementMethod`, `mci0Criticality`	DROPPED. GD&T and inspection: a measurement point on a physical feature

★★ This also corrects something this skill said about Initiative Planning. It was dismissed as "adjacent, it manages initiatives as they become funded work, it does not analyse a problem space". The Ipm0 type list says otherwise: Goal, Strategy, Vision Statement, Strategy Roadmap, Ipm0CstBnfAnlys (cost-benefit analysis) and Ipm0StrategyScoreTableRow are a strategic problem-space and scoring layer, which is much closer to 6.4.1 than the dismissal allowed.

⇒ So the real option for the two missing carriers is a TEMPLATE DEPLOY, not BMIDE authoring. Deploying Ipm0/Iim0 would supply enterprise goals, objectives, vision and cost-benefit scoring; Mds0 would supply user needs. That is a Deployment Center decision with a supported upgrade path, and it is strictly better than hand-authoring Msn0* types that would then need maintaining forever.

Until one of those is deployed, Requirement remains the carrier and should be described as a stand-in for an uninstalled type, not as evidence that Teamcenter lacks the concept.

What has no carrier among the 183 templates installed on cloud2506

Searched every business object in the model for Goal, Objective, Enterprise, Strategy, Motivation, Driver, Stakeholder Need, Capability Gap and Course of Action. Six hits, all false positives (HARA safety goals, a Cortona relation, a material coating relation, a dataset). So:

Problem or opportunity statement: no carrier. Requirement stays.
UAF EnterpriseGoal and EnterpriseObjective: no Teamcenter equivalent. MASG uses both. Carry them as Requirement and say so.
Trade study, decision record: none installed. An in-house prototype BMIDE template supplies them (not a Siemens product, see tc-decision-management) but is not deployed (getTypeDescriptions2 returned 11 of 13, omitting DSSDecision, DSSAlternative and DSSCriterion, which is a positive absence test). See tc-decision-management.

⚠ Before proposing any new BMIDE type, enumerate the installed templates first. Group the BMIDE export by template and read the concrete types in the ones you have never opened. On this tier that is 183 templates, and the two that mattered here (eml0entarchmodeling, systemsengineering) are named after neither missions nor solutions.

★★★ Before the relation set: neither the docs nor the tier is a superset

Reconciled 2026-08-08 by the Teamcenter data model reference session, and it reframes every "this relation is legal" claim below.

	business objects	GRM rules
documented at TC 2506	9,044	2,290
installed on cloud2506	8,571	1,903
in both	6,256	1,524
on tier, absent from the docs	2,315	379
documented, absent from the tier	2,788	766

About 69% of types and 57% of GRM rules overlap. The tier-only side is site and partner customisation no Siemens catalog can know about (xve5xceleratormbse 601, adpmfgandgraphicalplanning 311, adpbasetemplate 294 and more). The docs-only side is templates nobody installed.

⇒ "Not in the catalog" and "not on the tier" are different claims and neither implies the other. Say which one you measured.

⚠ This qualifies the relation atlas below. Those pairs were read from the cloud2506 BMIDE export, so they are a tier fact. 379 GRM rules exist on that tier and in no Siemens document, and 766 documented rules are absent from it. So a pair listed here may not be legal on your tier, and a pair absent here may still be legal on yours. Seg0MissionMadeupOfRel to a mission event is exactly that: declared and working on cloud2506, refused with 89020 on the VM.

Verify the relation on the tier you are writing to. The cheap way is to make the call and read ServiceData.partialErrors, since a refusal arrives as a 200 with a null relation uid and the reason only in the partial errors.

★★★ setProperties takes `info`/`vecNameVal`, NOT `objects`/`attributes`

RESOLVED 2026-08-09 by the tc-decision-management session. The working body, verified by read-back on vm2606:

POST Core-2010-09-DataManagement/setProperties
{"info":[{"object":    {"uid":"<uid>","type":"<Type>"},
          "timestamp": "",
          "vecNameVal":[{"name":"seg0PhaseOrder","values":["1"]}]}]}

SetPropertiesInput has exactly two members, info and options. A body built from objects and attributes contains no info at all, so the operation parses happily, finds nothing to update, and returns 200 with no error and no write. This is the full-struct rule biting on the outermost member, which is the hardest place to see it: every inner field looked correct.

Three traps inside the working body:

timestamp goes INSIDE each info entry, and "" is fine. A top-level timestamp is not a member and faults the parser. You do not need lsd.
Omit options entirely. Both [] and [""] fault. Same shape as the additionalData:[] trap in tc-workflow-authoring: an empty array for an optional member is worse than no member.
The XSD does not list timestamp on PropInfo. Core1009DataManagement.xsd declares only object and vecNameVal, and the JSON REST binding requires it anyway. The XSD is a lead, not the contract.

★★★ The one-call tell that catches a silent no-op

A no-op returns ServiceData.updated naming a UserSession object rather than your target:

"updated": ["BOM::96896"]   modelObjects: {"BOM::96896": {"className":"UserSession"}}

Assert that updated contains the uid you passed. Not that it is non-empty, and not that it looks a particular shape: membership of your uid.

⚠ The no-op shape varies by account, which is why a shape test fails. Same malformed request, same object, on vm2606:

as an ordinary user   updated = []
as DBA                updated = ["BOM::96896"]   a UserSession

The DBA form is the dangerous one: a check that merely asks whether updated is non-empty reads it as a successful write. "HTTP 200 and no partialErrors" hides it completely, and that is what let a wrong diagnosis survive across two sessions. A correct write returns your uid plus a session object:

"updated": ["ANCAAAMhp$kOEC", "QwFAAAMhp$kOEC"]

What this fixed here

Seg0MissionMadeupOfRel carries seg0PhaseOrder, which is how Teamcenter models phase sequence, and createRelations cannot set it. With the correct body the four phases of MA-MSN-01 are now ordered 1 to 4, verified by re-read. A mission profile authored over SOA is a sequence again, not a set.

The same call populated the only type-specific properties these types have: seg0IsMissionProfileGroup on the two Seg0Mission objects (True for the mission profile, False for the vignette) and seg0Code on the events, the environmental characteristic and the special condition. Leaving those blank was part of why a reviewer could not tell a Mission Profile from a Mission Phase.

⚠ This does not close the content-model gap. Those are the only own properties in the family: Seg0MissionPhase has none at all. Populating one boolean does not make a Mission Profile a mission plan. See the review finding below.

The lesson, which is not about structs

★★ A skill is only as good as its last verification. The tc-decision-management entry named timestamp as the cause; I found it, followed it exactly, and it did not work, because that entry had been written from the XSD rather than from a successful write. Checking a skill first remains right, and it would not have saved this one. An entry that has never been round-tripped against a live tier can be worse than no entry, because it is followed with confidence.

★★ And my own retraction was right for the wrong reason. I concluded "my struct is wrong, not the tier" from the cloud2506 control, which was sound. I then guessed at versions and mechanisms rather than asking for the working body, which is what tc-capture-awc-calls says to do after two or three failures.

The relation set

Read the GRM table before authoring. These pairs are declared and were all created live:

Purpose	Relation	Primary	Secondary
Class/concept delivers a capability	`Seg0Exhibits`	`Fnd0LogicalBlockRevision` or `FunctionalityRevision`	`Seg0FtCapability` item
Mission composition	`Seg0MissionMadeupOfRel`	`Seg0MissionRevision`	phase/event item
Phase meets the environment	`Seg0ImpactedByRel`	`Seg0MissionPhaseRevision`	`Seg0EnvCharstic` / `Seg0SplCondition` item
Problem to solution class (outcome g)	`Seg0Refine`	any `WorkspaceObject`	any `WorkspaceObject`
Forward into 6.4.2 / 6.4.3	`Seg0Satisfy`	any `WorkspaceObject`	`Requirement Revision`

★ The secondary is the ITEM uid, not the revision, for Seg0Exhibits, Seg0MissionMadeupOfRel and Seg0ImpactedByRel. The primary is always the revision. This inverts the usual "relations use revision uids" rule on the secondary side only, and getting it wrong is a clean rejection rather than a silent miss, so it is cheap to discover.

★★★ THE GRM TABLE DIFFERS BY TIER. Do not carry a proven relation across tiers. Seg0MissionMadeupOfRel from Seg0MissionRevision to Seg0MissionEvent is declared in the 2506 GRM table and works on cloud2506, verified by read-back. On the vanilla 2606 VM the identical call is refused:

89020  Relating an object of type "Mission Event" to an object of type
       "Mission Profile Revision" is not allowed, because the "Mission Made Up
       Of Relation" relation is not supported between these two objects.

Refused with the event ITEM and with the event REVISION as secondary. Mission to phase works on both.

⚠ Scoped honestly: this is one tier against one tier, not a release fact. I checked a single 2606 install, so the correct statement is "cloud2506 permits it, this VM does not", and the likeliest cause is a different template set rather than a release change. A GRM export from one tier is evidence about that tier only, exactly like a type probe. Corrected after the TC VM session caught me claiming release scope on tier evidence, which is the same discipline I had been quoting at other sessions all day.

⚠ The 2506 fallback does not exist either: Fha0OccurredByEventRel (Seg0MissionPhaseRevision to Seg0MissionEvent) faults 214116 not a valid relation type name on the VM, because fha0fhanalysis is not installed there. Confirmed with controls: Fha0FailureCndn and Fha0MissionState absent, Seg0MissionEvent present.

★★ The template is named, in the shipped kit, and its prerequisites are measured. Saber Atlas (saber-atlas/out/objects.json, each object carrying its owning template in t) puts Fha0FailureCndn, Fha0MissionState, Fha0OccurredByEventRel and Fha0ContainsMissionPhaseRel in fha0fhanalysis; Fha0AssignedToRel is the exception and lives in mq0hara.

The TC2606 install media confirms both are deployable units, from dc_contributions/application_registry/:

Unit	Display name	Requires
`fha0fhanalysis`	Functional Hazard Analysis	`apb0attrparmbase`, `mq0hara`, `att0attrtargetmgmt`, `systemsengineering`, `fnd0_foundation`, `rea0reliabilityanalysis`
`mq0hara`	Hazard and Risk Assessment	`fnd0_foundation` only

★ So the mq0hara split is a hard dependency, not a packaging quirk.

Prerequisites probed on vm2606 with a fake control, 4 of 5 present:

fnd0_foundation          Item              PRESENT
apb0attrparmbase         Apb0BaseDef       PRESENT
att0attrtargetmgmt       Att0AttributeDef  PRESENT
systemsengineering       Seg0Mission       PRESENT
mq0hara                  Fha0FHARoot       PRESENT   <- already installed
rea0reliabilityanalysis  Rea0Criticlty     absent    <- the only gap
fha0fhanalysis           Fha0FailureCndn   absent    <- the target

⇒ The deploy is rea0reliabilityanalysis then fha0fhanalysis. mq0hara is already there, so the dependency chain is one unit shorter than the media implies.

⚠ Media presence is not licence entitlement. Being in the kit we hold is strictly stronger than "documented at 2606" and strictly weaker than "we are licensed to run it". That question is not answered by any file in the zip.

★★★ Saber Atlas is the instrument for "which module deploys this type". It is a real BMIDE export from a deployed tier, not documentation, so it answers the missing middle between "documented at release R" and "installed on tier T", and it carries the 1,952-row GRM table plus the site-custom types no Siemens catalog has. One tier at one release, and it cannot tell you what is available to deploy.

⇒ On 2606, attach mission events with Seg0Refine (WorkspaceObject to WorkspaceObject, so always legal) from the event revision to the mission revision. Verified live and reads back inbound on the mission. Less semantically precise than the composition relation, and it is what the tier permits.

★ The failure mode is worth knowing: createRelations returned 200 with a null relation uid and the refusal only in ServiceData.partialErrors. A pipeline that harvests output[].relation.uid and does not read partialErrors records this as a silent no-op. Read the partial errors.

⚠ Seg0MissionMadeupOfRel from Seg0MissionRevision to another Seg0Mission is gated by condition Fha0IsMissionRelationAllowed, not isTrue. Mission-in-mission nesting is conditional; mission-to-phase and mission-to-event are not.

★★★ Verifying these relations: the usual one-call read DOES NOT WORK

tc-relations-traceability says every GRM relation declared against a specific type pair compiles into a same-named reference property on the primary, and that WorkspaceObject-primary relations are the exception. On the Seg0 family that rule does not hold, and the documented fallback does not either. Measured on cloud2506, 2026-08-08, on a Seg0Exhibits link that demonstrably exists:

Read path	Result
`getProperties(primaryRev, ["Seg0Exhibits"])`	200 OK, empty props. Same for `seg0Exhibits`, `Seg0FtCapability`, `IMAN_Seg0Exhibits`
`getProperties(<relation uid>, [...])`	faults `InternalServerException`, on every attribute tried including `object_string`
`expandGRMRelationsForPrimary`	works
`expandGRMRelationsForSecondary`	works

So for mission-engineering traceability, GRM traversal is the primary verification route, not the fallback. This is the opposite of the general guidance, and both are true on their own relation families.

POST Core-2007-09-DataManagement/expandGRMRelationsForPrimary
{"primaryObjects":[{"uid":"<rev>","type":"Fnd0LogicalBlockRevision"}],
 "pref":{"expItemRev":false,"returnRelations":true,
         "info":[{"relationTypeName":"","otherSideObjectTypes":[]}]}}

Read output[].relationshipData[].relationshipObjects[], each carrying otherSideObject and relation. Filter out IMAN_master_form. Running it from both ends is what lets you honestly claim the bidirectional traceability that 15288 outcome (g) requires.

⚠ createRelations returns the relation uid in output[0].relation, NOT in ServiceData.created, which is empty. Harvesting the wrong field yields relationUid: null on calls that fully succeeded.

★★★ The empty-200 traps hit while building this

Four distinct ones, all HTTP 200, none faulting:

object_desc longer than 240 characters. createAttachAndSubmitObjects returns output: [] with no partialErrors. Nothing is created and nothing says so. object_name caps at 128. Read the real caps off getTypeDescriptions2 propertyDescriptors[].maxLength and guard client side, because the server will not tell you.
createOrUpdateTemplate returns the new template in ServiceData.plain, not ServiceData.created, which is empty.

The parameter-value read, which produced a false absence proof. Measured on vm2606, 20 sampled Att0MeasurableAttributeDbl, 11 populated:

Property	What it does	Trap
`att1Value`	the value, on the parameter	read this one
`att0CurrentValue`	reference to the `Att0MeasureValueDbl`	`ui` is always blank; the uid is in `db`
`att0MeasurementValue`	nothing	`None` on every row, populated or not

⚠ I read att0CurrentValue.ui, got blank on all 20, and reported that no parameter anywhere on vm2606 carried a value. It was 11 of 20, and item 000268 alone carries 85. Retracted 2026-08-09. A second session then corrected my retraction (the property is a reference, not a blank) and was itself half right: the uid does resolve, and returns {} only when you ask it for properties its type does not have. Dereferenced properly it is an Att0MeasureValueDbl carrying att0Value, matching the parent's att1Value exactly. Three readings of one property, two of them wrong, before anyone dereferenced it.

★ A blank ui with a populated db is the shape to learn. It is not an empty property, it is a reference rendered with no display value, and it looks identical to absence in every convenience printout that shows ui.

★★ The same 20 rows also disprove a saved-query zero, with the control in the same call. tc_query_by_type("Att0MeasureValueDbl") returns nFound 0 while 11 of its instances are live and readable by uid; Att0MeasurableAttributeDbl returns 151. The type has no object_name, so the name-based saved query cannot match it, the same root cause as UnitOfMeasure. Two sessions cited that zero as evidence of absence and built conclusions on it. tc_query_by_type cannot establish absence in either direction: for this type it reports zero while the objects exist.

setProperties against any of these writes nothing and returns ok with an empty ServiceData. Values go on through createParameters plus the view-model proxy. See tc-parameters-units.

deleteObjects on an object that is still the secondary of a relation returns ok: true with partialErrors: null and does not delete it. Delete the relation first, then the object, then re-read. A search is the only proof.

⚠ SCOPE: the trade is NOT this module's job

★★★ Corrected 2026-08-09 after review. This skill drifted into building a trade study: measurable criteria on a solution class, weighting, a Trade tab. That is clause 6.3.3 decision management, owned by tc-decision-management. A reviewer's first question about the tab was "What is this tab for? It seems like it's for trade studies", which was the symptom.

Clause 6.4.1 activity d says evaluate alternative solution classes, and this skill's own Position-in-the-fleet section already said that activity runs through 6.3.3. I built it anyway. The boundary:

Belongs to 6.4.1, this module	Belongs to 6.3.3, `tc-decision-management`
the admissible candidate set: which solution classes exist at all	choosing between them
capability coverage, `Seg0Exhibits` (NOTE 15)	criteria, weights, scoring, sensitivity
traceability problem to class to requirement (outcome g)	the decision record, rationale, assumptions
operational concepts, mission threads, environment	the trade study object

What was removed: the Trade parameters section and the Att0 parameter work. Handed to tc-decision-management rather than reworked. The parameter-value blocker (rm-3a7fi1xf) went with it, which is why that item kept dragging on this module: it was never this module's problem.

★ The general lesson, and it cost more than the rework: an adjacent process that your own skill already names as someone else's will still pull you in, because its artefacts hang off your objects. The solution classes are mine; what gets done to them in a trade is not. Check the boundary when the deliverable starts looking like the neighbour's.

Active Workspace surfaces

★★ Check before you author anything. On cloud2506 every mission and operational type already has a dedicated summary XRT registered:

Preference	Value
`AWC_Seg0MissionRevision.SUMMARYRENDERING`	`Rea0MissionRevisionSummary`
`AWC_Seg0MissionPhaseRevision.SUMMARYRENDERING`	`Rea0MissionPhaseRevisionSummary`
`AWC_Seg0FtCapabilityRevision.SUMMARYRENDERING`	`Ase0Seg0FtCapabilityRevisionSummary`
`AWC_Seg0OpArchtRevision.SUMMARYRENDERING`	`Ase0Seg0OpArchtRevisionSummary`
`AWC_Fnd0LogicalBlockRevision.SUMMARYRENDERING`	`AWC_XVE5Awp0Fnd0LogicalBlockRevisionSummary`

Read them with Administration-2012-09-PreferenceManagement/getPreferences and {"preferenceNames":[...],"includePreferenceDescriptions":false}. So the presentation layer for the mission model is already there too, and the only surface worth adding is a Solution Class trade tab on Fnd0LogicalBlockRevision carrying the capability-coverage count and the trade parameters, since the generic system-block summary shows neither.

⚠ Whether those Rea0* / Ase0* stylesheet datasets exist was NOT verified. The Item Name saved query returns 0 for all of them, but it also returns 0 for Awp0ItemRevSummary, which certainly exists, so that query simply does not find datasets. A Dataset Name saved-query attempt faulted on its argument shape. The registrations are grounded; the targets are unconfirmed.

⚠ A SUMMARYRENDERING registration is site-scoped: it changes the Overview panel for every object of that type, for every user on the tier. On a shared tier, confirm before writing one. See tc-awc-stylesheets for the setPreferenceIn argument-name trap, the per-session preference cache, and the pool-restart question.

The review workflow

The corrected three-call recipe in tc-workflow-authoring works unchanged here. Proven live: MA Solution Class Selection Review (Cwup3VH8Z$cfED), template_classification = Process (0), stage = Online (2), with EPM-set-owning-project-to-task on EPM_start_action alongside the OOTB base handlers.

getRegisteredHandlers returns {actionHandlers: [str], ruleHandlers: [str]}, flat arrays of names rather than structs. On this tier: 360 action, 89 rule.

DoD Mission Engineering (MEG 2.0 and the Mission Architecture Style Guide)

The module supports the DoD flavour of mission engineering as a layer on the same objects, not a fork. Sources: ac.cto.mil/mission-engineering, the DoD Mission Engineering Guide v2.0 (Oct 2023), the Universal Mission Architecture Style Guide (Jan 2025) and the shipped MASG_Model_Version_1.0 reference model.

★★ The MASG reference model is UAF, not plain SysML. Parsing its XMI shows 39 distinct UAF:* stereotypes (OperationalPerformer, OperationalActivity, OperationalArchitecture, ResourceArchitecture, Function, System, CapabilityConfiguration, EnterpriseGoal, EnterpriseObjective, Measurement, MeasurementSet, Implements, IsCapableToPerform, ...). That is why the Seg0 layer fits it so closely: Seg0 is Teamcenter's own operational-analysis layer in the same tradition. Its worked example is Operation DESERT STORM, and its packages carry Vision and Mission / Missions / Mission Threads / Scenario / Vignettes, MET Activities, Measures of Performance, Orders of Battle, and crucially Baseline MET versus Alternative MET.

★★★ MEG 2.0 is a domain-specific instantiation of 15288 clause 6.4.1. The section structure lines up almost one to one, which is what makes one module serve both:

MEG 2.0	15288 6.4.1
3.0 Mission Problem or Opportunity	b) define the problem or opportunity space
4.0 Mission Characterization (context, measures)	c1) preliminary operational concepts
5.0 Mission Architectures (MT, MET, baseline and alternative)	c2) identify alternative solution classes
6.0 Mission Engineering Analysis (run matrix)	d1) assess each alternative class
7.0 Results and Recommendations	d2) select the preferred class

DoD term to Teamcenter carrier

DoD ME term	UAF stereotype	Teamcenter carrier
Mission	`OperationalActivity`	`Seg0Mission` "Mission Profile"
Mission Thread (MT)	`OperationalActivity`	`Seg0Mission` + `Seg0MissionPhase` + `Seg0MissionEvent`
Mission Engineering Thread (MET)	`Function`	`Seg0FxChain` "Functional Chain"
Vignette	package	`Seg0Mission` scoped to a phase set
Scenario	package	`Seg0Mission` + `Seg0EnvCharstic` + `Seg0SplCondition`
Operational Performer	`OperationalPerformer`	`Seg0OpPerformer` (exact)
Operational Activity	`OperationalActivity`	`Seg0OpActivity` (exact)
Operational Architecture	`OperationalArchitecture`	`Seg0OpArcht` (exact)
Baseline / Alternative architecture	`ResourceArchitecture`	`Fnd0LogicalBlock` (the solution class)
System	`System`	`Fnd0LogicalBlock` or `Item`
Capability	`IsCapableToPerform`	`Seg0FtCapability` (exact)
Enterprise Goal / Objective	`EnterpriseGoal` / `EnterpriseObjective`	`Requirement`
Investigative question (MEG 3.2)	none	`Requirement`
MOE / MOP / MOS	`Measurement` / `MeasurementSet`	see the blocker below

★★★ Seg0FxChain is the MET carrier and it is the piece people miss. A MET is a mission thread plus the technical detail of the functions and systems that execute it, which is precisely a functional chain. Seg0FxChainInvolvementRel (Seg0FxChainRevision to Functionality / PSConnection / Seg0FxChain) attaches the activities, and Seg0Realize (Seg0FxChainRevision to Seg0FxChainRevision) is how an alternative MET realizes the same thread as the baseline. That single relation is MEG section 5.3 in one link, and it reads back cleanly from both ends.

⚠ Seg0Exhibits will not accept a Seg0FxChainRevision as primary. Seg0FxChain descends from Fnd0SEBlock, not Fnd0LogicalBlock, and the GRM row names only Fnd0LogicalBlockRevision and FunctionalityRevision. Link a MET to capability indirectly, through the solution class that executes it.

★★ Measures: `Att0AttributeDef` IS creatable, and my read of the fault was wrong

⚠ RETRACTED. An earlier version of this section said Att0AttributeDef is not creatable over SOA here. It is. The tc-decision-management session has nine of them live on vm2606, created with plain createAttachAndSubmitObjects. Both faults I hit are documented traps with one-line fixes:

38015 Unable to find a property with name Att0AttributeDefRevisionCreI/att0Uom → the unit goes on the ITEM as uom_tag, not on the revision as att0Uom. The revision ends up carrying att0Uom anyway, derived from the item.
39007 The specified name NULL is invalid for a type → att0AttrType on the REVISION is required and has no default. The message names no property and reads like a broken business object rather than a missing field. Valid values are the Rich Client Data Type list: Value, Double, Integer, Boolean, String, Point. It is a type name because it decides which Att0MeasurableAttribute* subclass a value materialises as.

So the sequence is: resolve the UOM uid, then create in ONE compound call with uom_tag on the item and att0AttrType on the revision. The unit must be right at create time; post-hoc uom_tag repair needs bulk-loader utilities that are not available on a licence-limited tier.

★★★ MOE/MOP are now real parameter definitions with real units

Created on vm2606 and re-read: 001225-001228, Att0AttributeDef + Att0AttributeDefRevision, att0AttrType=Double, bound to min and m. The Requirement-based stand-in is superseded.

Resolving the unit is the hard part, and every fallback is a trap:

POST Core-2013-05-LOV/getInitialLOVValues
{"initialData":{
  "propertyName":"uom_tag",
  "lovInput":{"owningObject":{"uid":"AAAAAAAAAAAAAA","type":"unknownType"},
              "operationName":"Create","boName":"Att0AttributeDef","propertyValues":{}},
  "maxResults":200,
  "filterData":{"filterString":"<symbol>","maxResults":200,
                "numberToReturn":200,"sortPropertyName":"","order":1}}}

★★ The uid is in propInternalValues.lov_values[0], not propDisplayValues. The display side carries the symbol, and uom_tag rejects a symbol string: The specified value "kg" is invalid for the property "Unit of Measure".
★★ Match the SYMBOL exactly, never the description. A tier can carry two rows for one unit (UMS kg beside a legacy KG), and descriptions can be wrong: a row reading kg here describes itself as "MassFlowRate : Kilogram per second". Raise on an ambiguous match rather than picking.
★★ Hard-fail when nothing matches, and print what the picker DID offer. A stop that names the alternatives beats a fallback that binds something plausible.

Three routes that do not work, all confirmed here: UnitOfMeasure type query returns 0 (no object_name, documented, not absence); no UOM saved query exists on the vanilla VM; and harvesting uom_tag off existing definitions only reaches the units a tier already happens to use, 32 on this VM.

★ Cross-check, do not trust. I resolved min, m and kg through the LOV and compared against uids the tc-decision-management session had published independently. All three agreed, which is what makes the other resolutions credible. Never carry a UOM uid between tiers: they are per tier, and a uid carried across either faults or silently resolves to something unrelated.

⚠ Correction to the recipe as it was given to me: the revision boName is Att0AttributeDefRevision, no space. "Att0AttributeDef Revision" fails with 39014 The specified type ... does not exist. Most TC revision types take the spaced form ("Requirement Revision"), and this family does not.

⚠ Outstanding: the four Requirement-based MOE/MOP stand-ins are still present and now duplicate these. Retiring them means re-pointing six Seg0Satisfy relations from the METs, and is the next cleanup rather than done.

★★★ Three layers, not two. A system is not a mission architecture

The MT-versus-MET distinction is real and it is not the whole stack. Getting it half right is worse than not knowing it, because the missing layer is the one the whole method exists to vary.

Layer	What it is	MEG / U-MASG
Mission Thread	what must happen, in order. Doctrine-based, solution agnostic	Operational Process Flow (Op-Pr)
MET	the mission approach with actors assigned to accomplish the mission tasks	Resources Process Flow (Rs-Pr)
The solution	the system proposed to satisfy the mission, or the resource performer for a portion of it, and its internal design	not mission architecture at all

MEG 5.2, quoted:

The development of one or more METs will complete the representation of a given mission approach by adding the details on the actors (systems, technologies, organizations, and personnel) necessary to accomplish the mission tasks. METs provide insights that inform engineering designs and development considerations for systems and SoS. The level of detail provided in a MET should be tailored to the purpose statement.

⇒ A system is an actor in the MET. Its internal functional architecture is design, which the MET informs. The arrow runs mission to design.

⚠ RETRACTED: "the system's functions are the MET"

I told another session that their 13 functions, each derived bottom-up from a measured connector and the signal it carried, were the MET rather than the mission thread. Right about the thread, wrong about the MET. Corrected 2026-08-09 by Chris. Those functions are the aircraft's design; the aircraft is the candidate solution.

Two consequences, and the second is the evidence.

It breaks baseline versus alternative. MEG Table 5-1's alternatives are substitutions of a system: "substitute new bomber-launched glide vehicle weapon", "substitute launch platform". That only works if the solution occupies an actor slot. If the MET is the solution's internal flow, evaluating a second candidate means rebuilding the MET and there is nothing stable to compare against. This is the same error as a solution-specific mission thread, one layer down.
★★★ A MET derived from the solution can never express a mission need the solution fails to meet. Every function in it exists because a connector exists. On that model the first and last mission thread tasks came out with no function beneath them, and the inversion makes finding that inevitable.

⚠⚠ Explaining how a finding was found does not dissolve the finding

Corrected 2026-08-09, within the hour, by the session I had just corrected. Having established the inverted derivation, I wrote that the gap was "a symptom of the inverted derivation, not a separate finding". That collapses two claims, and only one of them is an artefact:

Claim	Status
"the MET has no entry for that task"	artefact of the inverted derivation. Dissolved
"this candidate cannot perform that task"	still true, and untouched by the relabel

The aircraft still has no function for getting on station and staying there. The coverage measure still has nothing beneath it producing the effect. The endurance measure still attaches to a task nothing performs. The finding is relocated, not dissolved, and it relocates into 6.4.1: it is a capability-coverage gap in a candidate solution, which is what Seg0Exhibits off an Eml0CapConfig exists to record.

★ The general shape, and it is one to watch for because it arrives disguised as rigour: "that was an artefact of a methodological error" is one short step from "so there is nothing there", and the step is invalid. Diagnosing the instrument that surfaced a finding says nothing about whether the finding is real. A good methodological correction is exactly when a real defect is most likely to get swept out with it, because the correction feels like the deeper insight and everyone is pleased with it.

⚠⚠⚠ And my relocation was ALSO too strong. Modelling gap, not capability gap

Third refinement of the same finding, and the one with teeth. The owning session corrected it again:

Version	Verdict
"the MET has no entry for that task"	artefact of the derivation. Dissolved
"this candidate cannot perform the task"	mine, and unsupported
"the candidate has no modelled function for the task, on either side, and the vehicle side has no functional model at all"	what the evidence supports

Every one of that model's 13 functions binds to a payload part, because the payload is where the connector evidence was. The vehicle side, which is what would actually perform "get on station and stay there", has no functional layer whatsoever. So the model is silent on the capability, and silence is not a no. The measure with nothing beneath it still stands; the reason is "the functional layer does not exist", not "the system cannot do it".

⇒ Consequence for this module, and it is a real one. Recording that as a Seg0Exhibits coverage gap would assert a capability claim the evidence does not support. So:

An absent Seg0Exhibits means "not shown to exhibit", never "does not exhibit". A capability-coverage count built from missing relations conflates assessed and absent with never assessed, and reports the second as the first.

Coverage must therefore carry three states, not two: exhibits, assessed and does not exhibit, not assessed. A denominator that silently merges the last two produces a confident number that is partly made of ignorance, and it will read as an answer.

★★ That is the same shape as nFound 0 on a populated type, a blank ui over a populated db, and an empty objectSet over three real capabilities: absence of evidence rendered identically to evidence of absence. Four instances in one day at four different layers, and this one is the most dangerous, because the others were read errors and this one would have been authored into the data as a fact.

★ Diagnostic worth keeping: if your MET has exactly as much structure as your system does, you derived it backwards. MEG explicitly permits sparseness, "not all tasks in the mission thread need to be assigned an actor", provided the assumptions are documented. A MET that is denser than the mission thread is a design wearing a mission architecture's label.

★★★ The structure that enforces it: a separate mission model

Decided 2026-08-09. The three layers are not enforceable by discipline inside one model, because nothing stops an author reaching into the solution. Enforce them with model boundaries:

A separate mission UAF model, whose only relationships to the system are from a resource artifact in the mission model to the system or its parts.

   MISSION MODEL  (UAF)
   Strategic   goals, scenario, vignette
   Operational mission thread, operational performers, incident context
   Resources   resource performers  <-- the ONLY elements that reach downward
                        |
                        |  one directed set of relationships, mission to solution
                        v
   SOLUTION MODEL (SysML)   the aircraft and its parts, a reusable library element

This is not an invention. It is U-MASG section 2.3, "Importance of a Federated (Modular) Architecture", which specifies exactly this organisation: Platforms and Systems and Platform Configurations held as libraries of reusable options at the bottom, mission-specific content above, and information flowing from the bottom layer up only.

What the boundary buys, and each of these is a failure it prevents:


Swapping a candidate solution re-points one relationship set	rather than rebuilding the mission architecture, which is what makes baseline versus alternative actually work
The mission model can apply UAF without touching the solution model	so a live, integration-synced SysML model is never restereotyped and the connector never sees a profile change
The mission layer cannot be derived from the design	because the design is in another model. The inversion above becomes structurally impossible rather than merely discouraged
One solution serves several missions, one mission compares several solutions	both are many-to-many, and neither works if they share a model

★ It also resolves the UAF question cleanly. The choice looked like "apply UAF to the live system model and risk the integration, or stay in SysML and lose the operational-versus-resource ontology". It was a false pair. Put UAF on the new mission model, leave the solution model alone. Each gets the language it needs.

⚠ Mounting the solution model into the mission model is the mechanical step, and ProjectsManager.useModule() no-ops. Use ModulesService, for which a proven recipe exists. Do not conclude mounting is impossible from the first API that fails, which has already been retracted once here.

The 6.4.1 reading, which is the same point in the other vocabulary

A proposed system is a candidate solution evaluated against the mission, which is what clause 6.4.1 activity c2 and d are about, carried here on Eml0CapConfig. So a system model produced elsewhere is not an input to be labelled; it is an alternative this module is supposed to hold and compare. Relating it to the mission is cross-type, so it is authored TC-side regardless.

★★ The measure hierarchy must be computable, and an orphan diagnoses the MOS

MEG 4.2 defines three tiers, MOS above MOE above MOP, with MOE and MOP defined "in direct contribution to" the MOS. That contribution has to be authored as a relation and checkable by computation, not implied by grouping measures in a folder.

A hand-maintained list of known orphans drifts the first time anyone adds a measure, and then keeps reporting the old answer, which is the same shape as every other silent-success trap in this workspace. So compute it.

⚠ But do not write the obvious check. It dies the moment it succeeds

Corrected 2026-08-09, hours after this section was first written, by the session using it. My first version said: declare the orphans, compute the orphans, assert the two lists match. That check is fine while the hierarchy is broken and becomes inert at the exact moment it closes.

Once every measure is connected, both lists are empty, and comparing two empty lists passes trivially. It then keeps passing after someone adds an unconnected measure, because that measure is in neither list. all([]) is True, and an empty result set satisfies a universal assertion. The check would have been retired by its own success while still reporting green.

⇒ Assert coverage, not agreement. Every measure must be one of: a contributor to something, a parent of something, or a declared orphan with a stated reason. Nothing may be merely absent from both sides.

The controls, which are the difference between a check and a comment

Run it against deliberately broken copies, and keep them:

Input	Expected	Result
the real model	uncovered: none, unresolved: none	pass
mutant A: add a measure with no parent	uncovered: caught	pass
mutant B: point a measure at a nonexistent parent	unresolved: caught	pass

Two mutants because there are two failure directions, and a check that catches one is routinely assumed to catch the other. ★ An orphan check that has never been shown to detect an orphan is itself the rule-without-an-emitter shape it exists to prevent, and mine was, for the few hours between writing it and having it corrected.

The test, once hardened: every measure resolves to a role, every named parent exists, and both facts are recomputed on every run rather than recorded.

★★★ An orphaned measure diagnoses the MOS, not the measure

Found on the wildfire mission architecture, 2026-08-09, and it is the most transferable thing in this section. Ten measures, six contribution pairs, three uncovered:

MOE Geolocation error   contributes to nothing
MOE False alarm rate    contributes to nothing
MOP Endurance           contributes to nothing

All three were good measures. The MOS was the defect: it read "time from ignition to incident authority notified", which is time only, so no accuracy measure can contribute to it however well formed. The orphans were not noise, they were the model saying the success criterion did not describe the mission.

⇒ Resolution was a second MOS rather than a widened one, on MEG's own first quality gate: a measure must be "consistent and repeatable, to grade across subsequent iterations, trades, and alternative mission approaches". A compound "fast AND accurate" MOS reports one bit on failure and hides which dimension failed, which is fatal in exactly the comparison the measures exist to support. Timeliness and actionability are independently traded, so they are two criteria.

⚠ The discipline that made this work: do not widen the MOS to close your own hierarchy. The session that found the orphans could have adjusted the top and reported a clean tree. A hierarchy that closes because someone moved the goal is worth nothing, and the finding would have evaporated silently.

Closing an orphan can and should make a gap worse

Endurance's natural parent was a coverage MOE on the first mission thread task. Adding it closed the chain and produced a measure of effectiveness with no function beneath it that produces the effect, because that task has no MET function. That is a better statement of the gap than the missing mapping was, and the right response is to leave it visible rather than invent a function.

★ Three independent analyses converged on that one task: it had no MET function (found from the thread), no MOE (found while building the measures), and it was the natural parent of the orphaned MOP (found from the hierarchy). Convergence from independent directions is much stronger evidence than any one of them, and it is worth noticing when it happens rather than recording the same gap three times.

★★★ This module cannot be authored from Cameo. 42 of its 47 relations are cross-type

Measured 2026-08-09. Two findings that compose, one mine and one from the Aircraft model session, and together they settle where mission engineering traceability has to be built.

The connector carries no cross-type relation at all, on 2606

The Aircraft model session grepped both Cameo-to-Teamcenter mapping files, full elements rather than opening tags, on the connector actually installed here:

Cameo relation	Rules on 2606 runtime	Types covered
`Trace`	17	Activity, Block, Diagram, Domain, External, Subsystem, System, System Context
`Allocate`	7	Activity, Block, Domain, External, Subsystem, System, System Context
`Refine`	9	requirement types only
`Satisfy`	9	requirement types only
`Verify`	9	requirement types only

⚠⚠ Every rule is X to X. There are zero cross-type rules in the entire 2606 mapping, across all five relation kinds. The integration carries no relation between two different kinds of element: not task to function, not function to block, not requirement to block.

★ Refine is a release regression, and the release label is the finding. The 2506 reference file carries 15 Refine rules including Activity to Activity and Block to Block, plus System, Subsystem, External and System Context. The 2606 runtime file carries 9, requirements only. A 2506 note saying "Refine carries between Activities" is true, was true, and is false here. Record the release with the claim or it will be re-learned the expensive way.

What that means for this module, measured rather than assumed

Every relation in the built module, classified by the business object types at each end:

Relation	Primary	Secondary	n
`Seg0Exhibits`	`Eml0CapConfig`	`Seg0FtCapability`	6	cross
`Seg0Exhibits`	`Seg0OpActivity`	`Seg0FtCapability`	1	cross
`Seg0Exhibits`	`Seg0OpPerformer`	`Seg0FtCapability`	1	cross
`Seg0Refine`	`Eml0CapConfig`	`Requirement`	4	cross
`Seg0Refine`	`Eml0CapConfig`	`Seg0FxChain`	3	cross
`Seg0Refine`	`Seg0Mission`	`Requirement`	2	cross
`Seg0Refine`	`Seg0MissionEvent`	`Seg0Mission`	2	cross
`Seg0Refine`	`Seg0OpArcht`	`Requirement`	1	cross
`Seg0Satisfy`	`Seg0FxChain`	`Requirement`	9	cross
`Seg0Satisfy`	`Seg0FtCapability`	`Requirement`	1	cross
`Seg0MissionMadeupOfRel`	`Seg0Mission`	`Seg0MissionPhase`	5	cross
`Seg0MissionMadeupOfRel`	`Seg0Mission`	`Seg0MissionEvent`	2	cross
`Seg0FxChainInvolvementRel`	`Seg0FxChain`	`Seg0OpActivity`	3	cross
`Seg0ImpactedByRel`	`Seg0MissionPhase`	`Seg0EnvCharstic`	1	cross
`Seg0ImpactedByRel`	`Seg0MissionPhase`	`Seg0SplCondition`	1	cross
`Seg0Derive`	`Requirement`	`Requirement`	3	same
`Seg0Realize`	`Seg0FxChain`	`Seg0FxChain`	2	same

42 cross-type, 5 same-type. Only the three Seg0Derive and two Seg0Realize could ever survive the connector.

⇒ Mission engineering traceability is Teamcenter-authored by necessity, not by preference. That is not a shortcoming of the design: mission analysis relates different kinds of thing to each other almost by definition, which is why the cross-type share is 89 percent rather than a handful of awkward cases.

⚠ Scope this claim precisely, because it is easy to overstate

True: the Cameo-to-TC connector's mapping files on 2606 contain no cross-type rules, so nothing authored in Cameo will produce one.
False, and the opposite of what was measured: that Teamcenter cannot hold them. All 42 exist on vm2606, were authored over SOA with createRelations, and were re-read from both directions. TC's GRM allows them; the connector does not carry them.

The instrument matters here. The finding is about one connector release's mapping files, established by reading those files, and it says nothing about GRM, about a later connector, or about other integrations.

Consequences to design around

Do not plan a Cameo round trip for this module's traceability. Author the objects wherever suits and the cross-type relations in TC.
Express who-performs by ownership, not by a relation. A function owned by the part property that performs it needs nothing to cross. On a stack with no cross-type rules this is the only reliable mechanism, and it also survives the two other measured constraints: ActivityPartition swimlanes carry nothing to TC, and an instance-level Allocate from a CallBehaviorAction to a part property is cross-type by construction, which retro-explains why it produced no TC object.
Same-type mappings do work, so an MT task to MET function link, both Activities, rides on «trace» (17 rules, Activity included). «refine» would have been the semantically better choice and is requirements-only here.

references/mission-engineering/ in this repo carries the runnable scripts: me_lib.py (connect via the DPAPI cred store, idempotent create, ledger), author_module.py, verify_module.py, author_workflow.py. They are idempotent against a JSON ledger, so a re-run authors nothing twice.

The worked example is the ASUAS contested-urban-ISR analysis that precedes QX-250: 36 objects (042803-042824, 042831-042834, REQ-000395-REQ-000404), 46 relations, 16 parameters, all re-fetched, spanning both the 15288 layer and the DoD ME layer. Its four solution classes are one per 15288 NOTE 14 category (new system / adapt existing / link elements from various systems / operational change), which is a useful pattern to copy: the standard enumerates the solution-class kinds, so spanning them is a defensible way to show the space was actually spanned.

★ Record a class that covers nothing. MA-SC-04 Operational change only exhibits zero capabilities, deliberately. 15288 outcome (d) asks that every alternative be assessed, not that every alternative score well, and a do-nothing baseline that visibly closes no capability is stronger evidence of a real trade than quietly omitting it.

Related skills

tc-soa-session first, then tc-object-authoring and tc-relations-traceability (noting the verification correction above), tc-parameters-units for the three-tier parameter model, tc-capture-awc-calls for the parameter blocker, tc-workflow-authoring, tc-awc-stylesheets and tc-awc-custom-tab for the trade tab, tc-verify-and-cleanup for the delete-relation-first rule.

Generated from skills/tc-mission-engineering/SKILL.md in the tc-automation-skills library, which is the canonical copy and also serves as the agent skill set for Teamcenter work.