Reference

Verified Teamcenter relation (GRM) atlas

Every relation below was created live via Core-2006-03-DataManagement/createRelations and read back, unless explicitly marked otherwise.

Two rules apply to all of them:

Use REVISION uids, not Item uids. GRM rules are declared at the revision level. The one documented exception is Mq0ElementToFailureModeRel, whose secondary is the Mq0FailureMode item uid.
Direction is strictly enforced, not just type-pair membership. Reversing a relation is explicitly rejected with a clear fault.

The verifiable column says whether the relation compiles into a same-named reference property on the primary object, readable in a single getProperties call. That held for every relation declared against a specific business-object type pair. It did not hold for relations whose GRM primary is the generic WorkspaceObject.

Architecture and allocation

Relation	Primary	Secondary	Verifiable	Notes
`Seg0Realize`	`FunctionalityRevision`	`FunctionalityRevision`	yes	Self-referential decomposition; same for `Fnd0LogicalBlockRevision`. The practical decomposition relation
`Seg0Allocate`	`Fnd0LogicalBlockRevision`	`FunctionalityRevision`	yes	Logical block allocated to function
`Seg0Allocate`	`Fnd0LogicConnRevision`	`NetworkRevision` / `PSConnectionRevision`	yes	Connector realization
`Seg0Implements`	`Fnd0LogicConnRevision`	`Seg0IntfSpec`	yes	The interface contract a connector implements
`Seg0Implements`	`Network_Port`	`Seg0IntfSpec`	yes	The pin-to-signal join; the ONLY rule producing this from a port
`Seg0ExchangeAllocation`	`Seg0Interface`	`Seg0ItemFlow`	yes	Hop 1 of the flow-property path
`seg0ExchangeItem`	`Seg0ItemFlow`	`Seg0IntfSpec`	yes	Hop 2; a property, not a relation object
`Seg0HasExchangeItem`	`Seg0IntfSpec`	`Seg0ItemFlowExchanges`	yes	Signal to carrier; item-level GRM-readable, not occurrence-scoped
`FND_TraceLink`	almost anything	almost anything	yes	Foundation-level, broadly permissive

Rejected, informative: Seg0Allocate between Fnd0LogicConnRevision and FunctionalityRevision is refused with "Allocate relation is not supported between these two objects", confirming the GRM table's silence on that pair was correct.

FND_TraceLink worked Signal to Fnd0LogicalBlock, HRN_Cable Revision to SignalRevision, and Fnd0LogicConnRevision to SignalRevision, in some cases with no declared GRM row backing it.

Verification lifecycle

Requirement       <--Seg0Derive--    IAV0VerifReqmt
Requirement       <--Seg0Satisfy--   IAV0TestCase
Crt0VldnContract  --IAV0VerificationTL-->  IAV0SimulRequest
Crt0VldnContract  --IAV0VerificationTL-->  IAV0TestRequest
IAV0TestRequest   --IAV0VerificationTL-->  IAV0TestProcedur
IAV0TestProcedur  --IAV0VerificationTL-->  IAV0TestEvent

Relation	Verifiable	Notes
`IAV0VerificationTL`	yes	Multi-value; both request paths can hang off one contract
`Seg0Derive`	NO	GRM primary is generic `Requirement Revision` to `Requirement Revision`, but it does not expose as a property on either endpoint
`Seg0Satisfy`	NO	GRM primary is the maximally generic `WorkspaceObject`; same problem
`IAV0VerifReqAssmFormRel`	not tested	`IAV0TestCaseRevision` and `IAV0VerifReqmtRevision` both attach to `IAV0VerifAssmForm`
`IAV0ReqmtEBOMOccTL`	not tested	Traces a verification/inspection/measurement requirement to a Test EBOM occurrence

Plan around the unverifiable pair. Seg0Satisfy and Seg0Derive create successfully and read back as nothing, on both endpoints, under any attribute name tried. The fallback is getProperties on the relation's own ImanRelation uid, which createRelations returns at create time and which yields a human-readable confirmation naming both endpoints. That requires the authoring pipeline to capture and carry the relation uid, which most pipelines do not.

Any new domain crack that leans on a WorkspaceObject-primary relation should assume this gap and either prefer a type-specific alternative or build the relation-uid capture first. An honest "cannot verify yet" is better than a check that silently fails on genuinely correct work.

Reliability

Relation	Primary	Secondary	Verifiable
`Mq0ElementToFailureModeRel`	`Fnd0SEBlockRevision` family (`FunctionalityRevision` or `Fnd0LogicalBlockRevision`)	`Mq0FailureMode` item uid	yes
`Fha0AnalyzedByFCRel`	`FunctionalityRevision` only (not `Fnd0LogicalBlockRevision`)	`Fha0FailureCndnRevision`	yes

Because the reference property lands only on the PRIMARY, and the assessed element is usually created by an earlier architecture task, a reliability completion check needs the touched assessed-element uid too. createRelations reports it in ServiceData.updated.

Simulation

Relation	Primary	Secondary
`TC_CAE_Source`	`CAEAnalysisRevision`	any assessed `ItemRevision` family
`CAE0Correlation`	`CAE0PhTestResultRevision`	`CAEAnalysisRevision` / `CAEResultRevision`

Program planning

Relation	Primary	Secondary	Verifiable
`Psi0PredecessorWorkElement`	successor `Psi0WorkElement` revision	predecessor revision	yes

Rejected: Wbs0ApplRelatedStruct for Wbs0Root to Wbs0Element containment (code 89020). WBS parent/child is a BOM structure operation, not a GRM relation.

Parameters

Relation	Primary	Secondary	Notes
`Att0HasParamValue`	owner (Block, Requirement, Activity, ...)	parameter	Owner is not a property; read it via `expandGRMRelationsForSecondary`. The relation object's own uid is what Cameo stores as `TC_Object_Stereotype."Project Relation ID"`

Requirements

IMAN_specification is a real relation name, but not always the containment relation. On production Requirement data it points at a FullText dataset (the requirement's rich-content body), not at a parent spec. Spec-to-requirement containment is the BOM/occurrence structure. Confirm what a relation type actually connects on THIS instance, by inspecting a real production object, before using it structurally.

Reading relations

Preferred, one call:

getProperties(<primary revision uid>, attributes: ["<RelationTypeName>"])

GRM traversal operations are less reliable. expandGRMRelationsForPrimary / ForSecondary work on some instances with body:

{"primaryObjects":[{"uid":"<uid>"}],
 "pref":{"expItemRev":false,"returnRelations":true,
         "info":[{"relationTypeName":"","otherSideObjectTypes":[]}]}}

whereReferenced, whereReferencedByRelationName and getRelatedObjects have faulted on multiple unrelated instances. Treat a GRM-traversal fault on a new instance as expected-until-proven-otherwise, not as a struct mistake.

Core-2007-01-DataManagement/loadObjects with a bare {"uids":[...]} faults 214086 "invalid syntax". Use getProperties.

Do not prove absence with the rich client

Impact Analysis at rule "All" and the Details tab both showed nothing for a pin that demonstrably had a Seg0Implements relation, which SOA returned immediately. An empty relation panel means the view is not configured to traverse that relation.

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