Skills

TC Object Authoring

Skill tc-object-authoring. Create real Teamcenter business objects over SOA. The createAttachAndSubmitObjects compound-create pattern (works where generic createItems faults), when to use createItems instead, and the verified type names for requirements, functions, logical blocks, signals, verification, reliability, electrical and simulation objects. Use when authoring any TC item, revision, spec, or domain object.

Your product is not prose. It is verifiable TC objects. Everything here has been created live and re-read back.

The primary authoring operation

Core-2016-09-DataManagement/createAttachAndSubmitObjects is the compound create that works for the widest range of types, including the ones where generic createItems faults. It returns the item, its master form, and its revision, with all uids in ServiceData.created.

{"inputs":[{
  "clientId":"CreateObject",
  "createData":{
    "boName":"Requirement",
    "propertyNameValues":{"object_name":["<name>"]},
    "compoundCreateInput":{"revision":[{
        "boName":"Requirement Revision",
        "propertyNameValues":{},
        "compoundCreateInput":{}}]}},
  "dataToBeRelated":{},
  "workflowData":{},
  "pasteProp":"",
  "targetObject":{"uid":"AAAAAAAAAAAAAA","type":"unknownType"}
}]}

Notes that matter:

Omit item_id and TC auto-assigns it per the site naming rule (REQ-nnnnnn).

The same shape works for any boName plus its revision sibling. ★★ But the revision type name is NOT uniformly "<Type> Revision", and guessing it produces a create that faults on a type name which looks entirely reasonable. The spaced form is the Requirement family; the Att0/Fnd0 families take an unspaced suffix:

item boName	revision boName
`Item`	`ItemRevision`
`Requirement`	`Requirement Revision`
`RequirementSpec`	`RequirementSpec Revision`
`Document`	`DocumentRevision`
`Att0AttributeDef`	`Att0AttributeDefRevision`
`Att0ParameterSet`	`Att0ParameterSetRevision`
`Fnd0CustomNote`	`Fnd0CustomNoteRevision`

"Att0AttributeDef Revision" fails with 39014 The specified type Att0AttributeDef Revision does not exist, which is an unusually honest fault: it names the type it could not find. Read the real name off an existing object of that type rather than deriving it, and note that this line previously stated the spaced form as a general rule, which is how two sessions arrived at 39014.

targetObject NULLTAG creates the object freestanding. Freestanding objects never land in a Newstuff folder listing, so they cannot be enumerated later by folder walk. Find them by name instead (see tc-verify-and-cleanup).

Do not read a 214022 on Requirement/RequirementSpec from generic createItems as "my struct is wrong." Those types are created a different way, and this is the way.

When to use `Core-2006-03-DataManagement/createItems`

For plain Item and generic item types, createItems is fine, but only with the full struct. Missing members fault 214022:

{"properties":[{"clientId":"c1","itemId":"","name":"<name>","type":"Item",
                "revId":"","uom":"","description":""}],
 "container":{"uid":"AAAAAAAAAAAAAA","type":"unknownType"},
 "relationType":""}

The exact top-level keys of this struct vary per instance even though the full-struct principle holds everywhere. Re-derive or confirm the shape on a new instance rather than reusing another site's JSON verbatim.

Verified type names

Do not guess type names. These were confirmed against a live BMIDE, and several plausible-sounding guesses turned out not to exist.

Systems architecture

Role	Item type	Revision type	Notes
Function	`Functionality`	`FunctionalityRevision`	parent `Fnd0SEBlock`. `Fnd0Function` does not exist
Logical block	`Fnd0LogicalBlock`	`Fnd0LogicalBlockRevision`	parent `Fnd0SEBlock`
Signal	`Signal`	`SignalRevision`	className returns `PSSignalRevision`. `Fnd0Signal` does not exist
Network	`Network`	`NetworkRevision`	parent `PSConnection`
Interface spec	`Seg0IntfSpec`	`Seg0IntfSpecRevision`	what a Cameo in-model Signal lands as
Logical connector	`Fnd0LogicConn`	`Fnd0LogicConnRevision`	parent `PSConnection`

Requirements

Requirement / Requirement Revision, RequirementSpec / RequirementSpec Revision.

Arm0RequirementSpecElement and Arm0RequirementElement are real but are occurrence / BOM-line VIEW types, not persistent item types. They appear in OccurrenceManagement calls and in AWC URLs as SR::N::... runtime uids. This is why tc_query_by_type("Arm0RequirementElement") returns 0 while the name is genuinely valid: you are querying a persistent-object store for a runtime view type. Both layers are real; finding one does not disprove the other.

Verification and test

Role	Type
Verification Request (umbrella)	`Crt0VldnContract` / `Crt0VldnContractRevision`
Simulation Request	`IAV0SimulRequest`
Test Request	`IAV0TestRequest`
Test Case	`IAV0TestCase`
Test Procedure	`IAV0TestProcedur`
Test Event	`IAV0TestEvent`
Verification Requirement	`IAV0VerifReqmt` (a `Requirement` subtype)

Specializations of Crt0VldnContract: Crt0VerifRequest, Crt0Test, Crt0Study, Crt0SimStudy, Crt0Run. "VCRM" is not a stored TC type anywhere in the catalog. It is a report concept over the requirement-to-testcase links.

Reliability, simulation, electrical, mechanical

Domain	Type
Simulation analysis	`CAEAnalysis` / `CAEAnalysisRevision`
FMEA failure mode	`Mq0FailureMode`
FHA failure condition	`Fha0FailureCndn`
Harness cable	`HRN_Cable` / `HRN_Cable Revision`

⚠ The HRN family does NOT use one revision-naming convention. It is mixed, and picking one form and applying it family-wide fails. EXERCISED on saber2506 2026-08-31, all three in the same batch:

Item type	Revision boName	form
`HRN_Cable`	`HRN_Cable Revision`	SPACED
`HRN_Harness`	`HRN_HarnessRevision`	UNSPACED
`HRN_GeneralWire`	`HRN_GeneralWireRevision`	UNSPACED

The wrong form returns 39014 The specified type "<name>" does not exist, which names the type it could not find, so a probe-create is the cheapest way to settle any HRN type: send all the candidates in ONE createAttachAndSubmitObjects batch and read partialErrors. The good ones land and the bad ones tell you their own answer, in a single call. | Mechanical design | Design / Design Revision (more specific than Item; Item stays the safer baseline) |

IAV0SimulRequest and CAEAnalysis are genuinely different objects: the request to perform verification versus the analysis itself. The only bridge between them is CAE0Correlation, which correlates results after the fact.

Electrical / Capital: the package is HRN, not "Capital"

No Cap0/ELC0/Capital BMIDE package exists. Capital's Teamcenter surface is the hrn template, in two layers:

HRN_* physical part catalog (17 independently creatable Item-rooted types): HRN_Harness, HRN_Cable, HRN_GeneralWire, HRN_ConHousing, HRN_GenTerminal, HRN_CavityPlug, HRN_Shield, HRN_Fixing, and more. HRN_Core, HRN_Cavity, HRN_Slot are Form-only and not independently creatable.
Hmc0* project/design containers: Hmc0Project root, then Hmc0Design, Hmc0FunctionDes, Hmc0HarnessDes, Hmc0LogicDesign, Hmc0TopologyDes, Hmc0PlatformDes, Hmc0IntegDes, each carrying datasets (Hmc0DesignXML is almost certainly the Capital Harness XC import/export payload).

Critical caveat: none of these 31 types appear anywhere in the GRM relation table as primary or secondary. This model is a GRM island. FND_TraceLink from an HRN_Cable Revision to a SignalRevision nonetheless works live. Empirical success is the stronger evidence, but do not assume GRM backs it.

Ground the type name before authoring on a new instance

Requirement, spec, and verification type names vary by BMIDE deployment far more than item/dataset types do. Never assume DOORS-style or Arcadia-style naming carries over.

Core-2015-10-Session/getTypeDescriptions2 for a type-existence check.
Core-2013-05-DataManagement/findDisplayableSubBusinessObjectsWithDisplayNames for a lightweight model probe.
saberdatamodel.xcelerator.us hosts the real BMIDE export: 8,571 business objects with inheritance, plus 1,952 GRM relation-type/primary/secondary rows. Reading those two JSON files directly beat blind trial and error decisively: ~20 SOA calls first-or-second-try, against ~50 guesses for the same job done without them. This is the reusable technique for cracking any new domain.

Site policy can block creation entirely

If createAttachAndSubmitObjects, createObjects, and even a plain Folder create all fail with An invalid object instance tag is being used in conjunction with property current_project (38041) plus Unable to create Business Object (214200), that is an account/session defect, not a type or permission problem. getTCSessionInfo will show project and workContext both null. The account needs project/program membership, or the session needs Core-...-Session/setUserSessionState. Do not conclude the type is not creatable.

Related symptom: The object of type "Item" can only be created in context of Program (101019).

Definition of done

Every object you claim to have created must be re-verified by a live getProperties on the uid the create call returned, before you report it. Harvest uids from tool results only. Never state a TC item id, uid, dataset name, or workflow status that a tool call did not return. See tc-verify-and-cleanup.

The `...CreI` create-input descriptor is a separate, smaller type. Enumerate it.

EXERCISED on saber2506 2026-09-01, chasing a required property a create kept demanding.

An unknown property in createData.propertyNameValues faults LOUDLY, it is not silently dropped:

38015  Unable to find a property with name XVE5TestPointCreI/xve5Discipline.

Two things fall out of that message, and both are useful:

It names the create-input type, <Type>CreI. That is a real type you can pass to Core-2015-10-Session/getTypeDescriptions2 like any other, and it is far smaller than the business object: XVE5TestPoint declares 232 property descriptors, XVE5TestPointCreI declares 40. When a create demands a property you cannot name, enumerate the CreI type rather than reading the full type, because the CreI list is the set the create path will actually accept.
A candidate-name sweep is therefore a real instrument. Because wrong names fault rather than being ignored, you can batch several guessed spellings as separate inputs entries in ONE createAttachAndSubmitObjects call and read the partial errors: each wrong guess names itself. A guess that stops returning 38015 is the hit.

★★★ A compound create has TWO create-input types. Probe BOTH.

This is where the technique above went wrong the same day it was written, so the correction matters more than the technique.

createAttachAndSubmitObjects sends createData for the ITEM and a nested compoundCreateInput.revision[] for the REVISION. Those have separate CreI descriptors, and a required property may live on either. Chasing 38207 "business rules require that you enter Discipline", three probes were run and all three agreed:

XVE5TestPoint type: 232 descriptors, no Discipline
XVE5TestPointCreI: 40 descriptors, no Discipline
five candidate spellings in createData: all 38015

That was written up as "not suppliable through this create path". It was wrong. XVE5TestPointRevisionCreI has 75 descriptors and carries xve5Discipline, display name "Discipline". The very first candidate spelling had been correct all along; it was put in the wrong half of the envelope, where the item's descriptor correctly reported it did not exist.

⚠ All three "independent" probes shared one hidden assumption: that the property was on the item. Agreement between probes that share an assumption is not corroboration, it is the same measurement taken three times. Before writing a negative, ask what every probe assumed in common, and test THAT.

⇒ Practical rule: for any compound create, enumerate <Type>CreI and <Type>RevisionCreI before concluding a property does not exist. It is one extra call.

The rest of the fix, once the property is found

xve5Discipline declared no lovName in its descriptor and is still LOV-validated server-side: real values returned 38059 The value "..." is invalid for the property. So a descriptor with no declared LOV does not mean free text. Get the real list with Core-2013-05-LOV/getInitialLOVValues (envelope in tc-parameters-units), passing lovInput.boName = the revision type and propertyName = the property. It returned 47 disciplines, moreValuesExist: false, and the value to send is the short internal code (LD, FQ, AW), not the description ("Loads", "Flying Qualities", "Airworthiness").

Result: 7 XVE5TestPoint items created with zero partial errors, Discipline read back from a second account.

Related: tc-type-discovery-and-census (the delta-protocol trap that makes repeat getTypeDescriptions2 calls return less within one session, which will silently shrink a descriptor list you are reasoning from).

Revising an item: EXERCISED, and it retracts a "not possible over REST" finding

Recorded here for months as impossible: reviseObjects and revise2 "return HTTP 200 with ok: true, NULLTAG output, and create nothing." That was wrong, and wrong in the exact shape tc-bom-structure warns about, which makes it the fourth instance in this codebase of an empty 200 being read as a dead operation.

The working sequence, saber2506, 2026-09-01

1.  Workflow-2007-06-Workflow/setReleaseStatus
    {"input":[{"operations":[{"newReleaseStatusTypeName":"SKW4_ReleasedFML",
                              "operation":"Append","existingreleaseStatusTypeName":""}],
               "objects":[{"uid":"<ItemRevision uid>","type":"<its revision type>"}]}]}

2.  Core-2013-05-DataManagement/reviseObjects
    {"reviseIn":[{"targetObject":{"uid":"<ItemRevision uid>","type":"<its revision type>"},
                  "reviseInputs":{},
                  "deepCopyDatas":[]}]}

Result: the ITEM's revision_list goes from one entry to two, - and A. Verified by re-reading the item, and again from a second account.

Three separate traps, and the order they surface in

The top-level array is reviseIn, not inputs. ReviseObjectsInput in the XSD names it, and propertyNameValues/compoundPropNameValues are not members of this struct at all. An unrecognised top-level key is accepted by the JSON-REST binding as zero items, so the operation never runs and you get the empty 200. soa_lookup.py reviseObjects prints the real members in one command.
reviseInputs is a PropertyValues type with a required @key, so this binding wants a MAP, not an array. [] returns a hard 214022; {} runs. Same convention as propertyNameValues on the create path.
Then a real business rule appears: 83074 Working Revisions limit exceeded ... maximum number of working revisions allowed is: 1. So the current revision must be RELEASED before the next can be cut. That is why step 1 exists, and it is a genuine rule rather than a defect: revision_limit on the item reads 1.

★ The diagnostic that matters: watch the failure get WORSE. The progression was empty 200 -> 214022 -> 83074 -> success. A malformed request and a dead operation are byte-identical, but the arrival of a real fault code is the signal that the envelope is finally being parsed. If a payload fix moves you from silence to an error, that is progress, not a regression. Treat a persistent empty 200 as "not yet parsed", never as "not supported", until the struct has been rebuilt from the XSD member by member.

⚠ Revisions cannot be deleted here, so prove the recipe on ONE object you own and do not replay it across a data set to "make it look complete".

Related skills

tc-relations-traceability (linking what you created), tc-verify-and-cleanup, tc-soa-payload-shapes, tc-capture-awc-calls, tc-bom-structure (the empty-200 rule).

★★★ `26023 not licensed to author` is usually the WRONG CREDENTIAL, not the tier

EXERCISED on saber2506 2026-09-01, and it cost most of a session before it was caught.

SSP0ServicePlan and Schedule Manager's createSchedule both returned:

26023  The current user is not licensed to perform authoring functions in Teamcenter.

license_level is a CLASS, not a ranking, and reading 5 as "highest privilege" is the whole error:

`license_level`	meaning
0	Author
1	Consumer
2	Occasional User
3	Viewer
5	Admin

Get it from the tier rather than from memory: Core-2013-05-LOV/getInitialLOVValues, lovInput.boName "User", propertyName "license_level".

A DBA account (privileged: true, level 5) creates items, relations, datasets and revisions all day and still cannot author a Service Plan or a Schedule, because those check for an Author licence specifically. An ordinary engineering account at level 0 did both first try, with no payload change.

Why two "independent" accounts agreed, and a good control still missed it

Both accounts tried were level 5. Swapping between them felt like a second opinion and was the same measurement. See [[false-corroboration]].
A known-good Document create in the SAME call as the refused Service Plan is a real control and proves the session can WRITE. It does not prove the account can AUTHOR in the licence sense. The control tested a weaker property than the conclusion required, which is the subtler failure: not a missing control, a mismatched one.

⇒ Checklist before blaming a tier for 26023, in cost order:

Read license_level on the account (getTCSessionInfo returns it in modelObjects).
Read the LOV so you know what the number means on THAT tier.
Enumerate the other credentials you hold for the same host and check each one's level.
Only then treat it as an entitlement question for an administrator.

⚠ Also check the group and role while you are there. The Author account here sat in an engineering group with an engineering role, and its session fnd0isTrueConditions carried a large set of module display rules (the whole XVE5* authoring family) that the DBA account did not. That list is a fast, free read of what a credential is actually allowed to do.

An empty DYNAMIC LOV is a data-population gap, and it names its own feeder

EXERCISED on saber2506, chasing XVE5FlightEvent's 515105 "contains empty attributes".

Two LOV shapes behave completely differently and both reject a good value with 38059:

shape	`lovData.lovs[].className`	fix
static	`ListOfValuesString` / `...Integer`	send an allowed value; read them with `getInitialLOVValues`
dynamic	`Fnd0ListOfValuesDynamic`	populate the source objects; there is no value to send yet

A dynamic LOV with no source objects returns lovValues: [] plus 54060 "No value is available for the LOV". That is NOT "the property is free text" and NOT "you guessed wrong": nothing can satisfy it until the tier is populated.

Trace it to the feeder in two cheap steps:

getProperties on the uid in lovData.lovs[] for lov_name. Here that gave XVE5FTEventTypeLOV and XVE5TestArticleIDLOV, which is far more useful in a handover than "an empty list".
Find the type whose instances feed it. For the XVE flight-test template that is XVE5FTAdminLOVValue (a Fnd0AdminLOVValue subtype) carrying fnd0lov_category, fnd0lov_value, fnd0lov_description and xve5Active. The empty LOV's behaviorData.columnNames already pointed at it: it named fnd0lov_value as the value column, which is that type's property, not a generic one. Read columnNames before guessing the feeder.

⚠ Populating an admin LOV is a TIER CONFIGURATION change, not demo data: it adds options for every user of that site, and objects here cannot be deleted. Diagnose it, name the LOV and the feeder type, and hand the decision to whoever owns the site.

⚠ And do not settle absence with tc_query_by_type alone. XVE5FTAdminLOVValue DOES declare object_name, so a zero is not the usual no-information case, but admin LOV values are plausibly authored with only fnd0lov_value set, which would still miss. State it as strong evidence, not proof. See tc-type-discovery-and-census.

★ Account note: this LOV was empty for a level-5 Admin AND for a level-0 Author with the full XVE5* display-rule set, which is what rules out the account-scoping explanation. After the 26023 lesson above, re-run any "the tier lacks X" check on a second credential BEFORE writing it down.

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

TC Object Authoring

The primary authoring operation

When to use Core-2006-03-DataManagement/createItems

Verified type names

Systems architecture

Requirements

Verification and test

Reliability, simulation, electrical, mechanical

Electrical / Capital: the package is HRN, not "Capital"

Ground the type name before authoring on a new instance

Site policy can block creation entirely

Definition of done

Related skills

The ...CreI create-input descriptor is a separate, smaller type. Enumerate it.

★★★ A compound create has TWO create-input types. Probe BOTH.

The rest of the fix, once the property is found

Revising an item: EXERCISED, and it retracts a "not possible over REST" finding

The working sequence, saber2506, 2026-09-01

Three separate traps, and the order they surface in

Related skills

★★★ 26023 not licensed to author is usually the WRONG CREDENTIAL, not the tier

Why two "independent" accounts agreed, and a good control still missed it

An empty DYNAMIC LOV is a data-population gap, and it names its own feeder

When to use `Core-2006-03-DataManagement/createItems`

The `...CreI` create-input descriptor is a separate, smaller type. Enumerate it.

★★★ `26023 not licensed to author` is usually the WRONG CREDENTIAL, not the tier