Capital Notes: review and a Teamcenter path
Reviewed 2026-09-26

Capital E/E · Teamcenter 2506

Engineering notes should have one master. Today they have none.

A review of the Capital Note Utility Kit (Capital 2408 build) and a proposal: master notes in Teamcenter, publish released notes into Capital as a read-only library, and send each design's note usage back to Teamcenter.

Capital 2408 kit Teamcenter 2506 Source review, not a run

Bottom line

The authoring experience is worth keeping. Variable notes, templates that autoload notes by drawing type, project scope, flag-note styling and per-object-type note lists are the right features, and designers asked for them.

The storage and synchronization are not. The note library is a Capital design whose notes live as opaque binary blobs, rewritten whole on every edit, with no locking and no link to any PLM system. Nothing outside Capital can read it, so it can never be the authoritative source.

Teamcenter 2506 already ships the missing half. It has a standard note type built on parametric requirements, a custom note type, and a part-to-note relation that already carries per-use properties such as a flag-note flag and parameter values. The kit's data model maps onto it almost one to one.

1How the kit works today

Read from source, not executed

The kit is three NetBeans projects: a shared object model (NoteObjects), the Capital plug-in actions and user interface (NoteUtility_General_Kit), and a library synchronizer over Capital's SOAP web services (NoteUtility_SOAP).

Current kit data flow: a note library design in Capital, copied into project designs by the synchronizer Note library design A Capital design used as a database Master index blob One blob per note type and object type Java-serialized lists of JSON strings Note Synchronizer Exports the library design over SOAP Strips the serialization header Splits records on the text "}t" Rewrites blobs in the project Harness and logic designs Notes numbered and placed Variable values chosen per design Flag notes 1 to 5 as properties Tables and reports No path to or from any PLM system. Release status is a free-text field on each record.
Everything the kit knows lives inside Capital designs, in a format only this plug-in can read.

Storage

  • Each library note is a JSON string. Lists of those strings are serialized with Java object serialization and attached to the library design as attached-data blobs, one per note type and object type, plus a master index blob (AttachedDataNotesWriter, NoteIO).
  • Every add, edit or delete reads the whole list, changes one entry and writes the whole list back. There is no lock or version check, so two librarians saving at the same time lose one edit without any message.
  • Because the payload is Java-serialized, reports, search and any external system see an opaque binary blob.

Synchronization

  • The Note Synchronizer (NoteLibraryPull) exports the library design through Capital's integration web services and then parses the serialized bytes as text: it strips a fixed header string and splits the remainder on the two characters }t. A note whose text contains }t would split into broken records, and any change in Java's serialization framing breaks the parse.
  • The web-service client is the stock Capital sample client with the host, port and a default administrative login compiled into the class. Changing the target means rebuilding the jar.

Lifecycle

  • Library release status is a free-text string on the record, set through a status dialog. There is no approval workflow and no record of who approved what.
  • Ad-hoc custom notes created in a design are stamped Approved automatically (DesignStaticDataClass.createCustomNote).
  • The note-number locking that prevents a retired number being reused is present only as commented-out code in LibraryMap.

2Defects in the source

Read from source, not executed

Each item below was found by reading the shipped source. None was reproduced in a running Capital session, so treat them as strong leads for the Capital team to confirm, not as measured failures.

SeverityFindingWhereEffect
HighConcurrent library edits overwrite each otherNoteIO.addNoteLibNoteStringWhole-list read, modify, write with no lock. The last save wins and the other edit disappears.
HighSynchronizer parses serialized bytes as textNoteLibraryPullRecords split on }t. Note text containing those characters corrupts the pulled library.
HighDefault wildcard search never behaves as a wildcardNoteIO.matchPatternThe mode check uppercases the value and compares it with mixed-case "Wildcard", so it is never true. SN* is then run as a regular expression and does not find SN100. Unescaped input such as ( throws.
HighNote IDs can collideNoteIDCreator, SNote.createnoteidThe ID is the name plus the sum of the revision's character codes, so revisions AB and BA give the same ID.
MediumNote matching uses substring testsSNote.compareSN1 matches SN10 and SN100. DesignNotesRenumbering also compares a note with itself, which is always true.
MediumHand-written JSON loader reads the wrong fieldsSNote(ObjectNode), used by LibNoteList and SNoteListThe name is overwritten with the revision, and variable content and properties are read from the wrong path, so they load empty.
MediumLong values are cut without warningSNote.addRawContent, addNotePropertyAnything over 1024 characters is truncated and the caller is told nothing.
MediumWeb-service endpoint and login compiled inAbstractClientHost, port and the default administrative account live in source. They should come from configuration or a credential store.
MediumFlag notes capped at fiveGetNoteResultsFlagNote1 to 5, and two parallel familiesFifteen near-identical classes. A sixth flag note on one object needs new code.
LowBroad exception handling166 catch blocks across the kitMany log and continue, so a failed read can look like an empty library.
LowKit hygienelib/pluginsThe folder bundles unrelated plug-in jars built for other customers and a personal build of the object model. They should not ship in a general kit.

3What Teamcenter 2506 already provides

Checked on a live 2506 tier

The types below were read from a running Teamcenter 2506 tier through the type-description service, with a deliberately fake type name in the same call as a control; the fake name correctly came back absent. The standard note type is deployed and populated on that tier.

Kit conceptTeamcenter 2506What it carries
Library note (standard note)Ads0StdNote "Standard Note", with revision Ads0StdNoteRevisionBuilt on Fnd0ParamReqment (Parametric Requirement), which is built on Requirement. Rich text in body_text and body_cleartext, plus ads1ParamValues, ads1NoteCategory and ads0OriginalLocationCode (original CAGE code).
Custom note (one design only)Ads0CustomNoteBuilt on Fnd0CustomNote, for notes unique to one part or document.
A note placed on a design, with its flag and chosen valuesRelation Fnd0ListsParamReqments "Standard Notes Lists", part revision to notePer-use properties stored on the link: Ads0flagnote (true or false), Fnd0parameter (text), ads0partslistnote (text), and ads1NoteText, the applied note text, computed when read.
A custom note placed as a flag noteRelation Fnd0ListsCustomNotes "Custom Notes Lists"Ads0flagnote on the link.
Release status and approvalWorkflow release status on the revisionReal approvers, dates and signatures instead of a text field.
Project scopeTeamcenter projects (project_list)Access and visibility enforced by the platform.
Tags and searchClassification and indexed searchNotes can sit in several classes at once, which a flat tag list cannot express cleanly.

The key fit is the relation. The kit's per-design note record (which library note, which revision, flag or not, chosen variable values) is exactly what Fnd0ListsParamReqments stores on each link. Writing Capital's usage back as those links gives Teamcenter a where-used list for every note revision without any custom type.

4Target architecture

Teamcenter masters the note. Capital consumes a published, read-only copy. Capital reports how each design used it.

Target flow: Teamcenter publishes released notes to Capital, and Capital returns note usage to Teamcenter Teamcenter 2506 Standard notes, revisioned Released through workflow Projects and classification Note numbers reserved per lineage Where-used via Standard Notes Lists Change impact on every revision Capital Read-only library cache Variable Manager and templates Flag-note styling and tables Stale-note design rule check Local custom notes, marked unreleased until promoted 1. Publish on release: JSON snapshot uid, revision, status, checksum 2. Usage back when a design publishes note revs, values, numbers, flags The same Teamcenter note can also feed NX drawings, so one note serves every authoring tool.
Two flows replace the synchronizer: a publish from Teamcenter and a usage return from Capital.
  1. Teamcenter owns the library note. Standard notes are Ads0StdNote revisions, released through workflow, assigned to Teamcenter projects and classified. Variable definitions (lists of values, object references) become structured data on the note rather than the kit's delimited expression strings.
  2. Publish, do not synchronize designs. On release, a workflow handler or Dispatcher job writes a versioned JSON snapshot of the released library into Capital. Every record carries the Teamcenter uid, revision, release status and a checksum. The Capital library becomes a read-only cache that can be rebuilt at any time.
  3. Send usage back. When a harness or logic design is published to Teamcenter, it brings the note usage with it: which note revisions, the chosen values, the note numbers assigned and which ones are flag notes. Each use becomes a Fnd0ListsParamReqments link from the design's part revision to the note revision.
  4. Flag stale notes in Capital. The kit already has a design rule check (NoteObjectsDontMatch). Extend it to compare each placed note revision with the latest released revision in the published snapshot.
  5. Reserve note numbers in Teamcenter. Number locking per design lineage belongs with the master, not in commented-out plug-in code.
  6. Keep custom notes local, honestly labelled. Ad-hoc notes stay in the design but are marked unreleased, and can be promoted to Ads0CustomNote or proposed as a new standard note.

5Variable notes and fixed note text

Some programs require note text to be fixed per revision. Their rule is that engineering values are not pulled out of a note into editable fields, and any change to the text gets a new note number, to protect configuration traceability.

The kit's variable notes resolve text per design. That can coexist with the rule if the library note keeps a fixed template and only the chosen values are stored, on the usage link (Fnd0parameter), never on the note itself. The resolved text then becomes an output of the design, not a new version of the note. Programs that forbid variable notes outright can simply publish only static notes.

This decision should be made per program and recorded in the publish configuration, so Capital never offers the Variable Manager for a library that forbids it.

6Improvement path

Now

Fix the kit in place

  • Fix the wildcard check and escape search input
  • Replace the character-sum note ID with name plus revision
  • Exact matching in SNote.compare
  • Fail loudly instead of truncating at 1024
  • Endpoint and login from configuration
  • Remove unrelated jars from the kit
  • Stop auto-approving custom notes
Next

Teamcenter as master

  • Map library notes to Ads0StdNote
  • One-time migration of the existing library, with a round-trip diff
  • Release-triggered JSON publish into Capital
  • Read-only library in Capital, keyed by Teamcenter uid
  • Stale-note design rule check
Later

Close the loop

  • Usage return as Fnd0ListsParamReqments links
  • Change impact: which designs still use an old revision
  • Rules that autoload notes from design content, not only drawing type
  • Duplicate and near-duplicate detection in the library
  • Same notes consumed by NX drawings

7Not verified yet

  • No kit defect was reproduced in Capital. Every item in section 2 comes from reading source. A short test session in Capital 2408 would confirm or retire each one.
  • The usage relation has not been written. The Fnd0ListsParamReqments properties were read from the live type description. No link has been created from a Capital-published part to a note, and whether Capital's own Teamcenter publish can carry these links is still open.
  • How ads1ParamValues and ads1NoteText are computed is not confirmed. Both are computed when read. Siemens documents a provider that extracts parameter values from the note text; the placeholder syntax it expects has not been checked against the kit's variable format.
  • Where-used was only sampled. Two sampled notes had no usage links. With no known-used note as a control, that says nothing about the tier as a whole.