HOW IT'S BUILT

Platform Architecture

Three tiers — a Capital plugin suite, a neutral hub service, and Teamcenter 2506 — connected by one JSON contract. Every mechanism on this page ran live against Capital 2512 and Teamcenter 2506, July 3–5, 2026.

The three tiers

Tier 1 — the Capital plugin suite

Everything on the Capital side ships in one JAR, deployed to <CapitalHome>\plugins\XceleratorTcImport. We build it with Capital's own toolchain — the Eclipse compiler and Java 21 JRE that ship inside the install, plus Capital's own Jackson jars — so there is no JDK, no Maven, and no classloader conflict (build.ps1 -Deploy is the whole pipeline). The jar registers against Capital 2512's documented extension points: publish actions for platform, functional, and logic designs (IXPlatformArchitectureDesignAction, IXFunctionDesignAction, IXLogicAction), the Assign Structure Parent… action, the import/sync action, and Teamcenter Browser panels on all three apps — Systems Architect, Systems Modeler, and Logic Designer — via the design-tree tab and Design Inspector panel interfaces. proven live

Tier 2 — the tc-service hub

The hub is a deliberately boring piece of engineering: a zero-dependency Python stdlib service on port 8080. It has three jobs — a store (one merged head per project plus append-only revision history), an enrichment layer (the "engineers type nothing" machinery, below), and a SOA client that speaks Teamcenter's JSON gateway directly. Its REST surface is the whole integration contract: GET /health, GET /export/bundle?project=, GET /export/spine?under=&depth=, GET /export/capital-xml?project=, POST /import/bundle, plus the Systemscenter views at /map. Anything that can produce or consume the bundle — Capital, NX, a Cameo export, a seed script — plugs in without touching the others.

Tier 3 — Teamcenter 2506

Teamcenter is the configuration-managed master. The hub logs into the JSON SOA gateway at https://<teamcenter-gateway> (CSRF-token handshake, cookie session) and materializes the bundle as real, typed objects: components become Fnd0LogicalBlock items nested as Fnd0LogicalBOMLine occurrences, functions become Functionality items with directed Network_Port pins, allocations become Seg0Allocate relations, conductors become Fnd0LogicConn items, and requirements become Requirement items related via IMAN_requirement. One Logical BOM spans the functional, platform, logic, and fluid layers — that shared tree is the systems center, and Systemscenter is the layer that renders and exchanges it.

The neutral exchange bundle (v1.2)

Every tier speaks one JSON document, defined in docs/exchange-format.md. Eight optional data arrays under a required meta block; every object carries a free-form attributes map for anything without a first-class field. The schema is additive across versions — a v1.0 bundle still imports unchanged.

Trimmed to essentials, a Capital publish of one electrical add looks like this:

{
  "meta": {
    "schemaVersion": "1.2",
    "source": "capital-systems-architect",
    "project": "UAV Platform",
    "effectivity": "unit>=151"
  },
  "components": [{
    "id": "ELEC-IFPCB",
    "name": "Invert Fuel Pump Circuit Breaker",
    "type": "ECU",
    "domain": "ELECTRICAL",
    "parentId": "LOG-ACFSCB",
    "provenance": "elec-add",
    "effectivity": "unit>=151",
    "attributes": { "milStd1808": "24 50" }
  }],
  "functions":   [{ "id": "FN-PUMPCTL", "name": "Control pump outflow" }],
  "allocations": [{ "functionId": "FN-PUMPCTL", "componentId": "LOG-CGMC" }],
  "connections": [{
    "id": "CN-FPPWR", "domain": "ELECTRICAL",
    "fromComponentId": "ELEC-FPP", "toComponentId": "FUEL-PUMP",
    "attributes": { "tcKind": "power" }
  }],
  "requirementLinks": [{
    "requirementId": "REQ-000123", "targetType": "COMPONENT",
    "targetId": "LOG-STGINV", "linkType": "derives"
  }]
}

The hub's store

Every import lands in three places at once. First, the merged head — one bundle per project, upserted by external id, which is what /export/bundle serves and what the Teamcenter push reads. Second, an append-only revision history under store-data\revisions\<project>\: each delivery is snapshotted pristine, as sent — before any enrichment touches it — so we always have the configuration-management trail of exactly what each tool delivered. Third, a content-hash dedup: the Capital plugin delivers every publish twice for resilience (outbox file and HTTP POST), and the store hashes each delivery with SHA-256 so the second arrival is acknowledged but skips both the merge and the Teamcenter push. Dual delivery, single effect. proven live

Hub enrichment — engineers type nothing

The hub's rule is that a publishing engineer supplies exactly one fact — the structure parent of a new element — and everything else is derived or preserved. Six behaviors in store.import_bundle make that true:

Delivery paths — from a Ctrl+S to a nested BOM line

Two namespacing mechanisms keep a shared dev instance sane: runTag prefixes every created id per test round (and must be empty in production — cross-publish parent resolution depends on untagged spine ids), and teamcenter.legacyRunTags lets a production push adopt items minted under an older tag instead of re-minting them.

Closing the loop — Teamcenter back into Capital

The reverse direction is what makes this bi-directional rather than a publish pipe. teamcenter_export.py inverts every relation the push writes: it walks the LBOM structure into components with parentage, reads GDE ports with directions, resolves allocations, carriers, and signal routing, and extracts the logic detail layer — nested devices with their pins, root connectors, and conductors with device endpoints. The extraction was semantically lossless against the Wildfire seed on the first full run: zero diffs.

capital_project_xml.py then renders that bundle as Capital project XML — the same project.dtd format the Cameo bridge writes, loadable on any Capital seat via Project Manager → File → Import, no plugin required. One generated file carries three sections: a <functiondesign> (functions, pins, directed nets), a <platformtopologydesign> (clusters, interfaces, carriers, signal routing, function allocations cross-referenced into the functional section), and — with ?logic=1 — a real <logicaldesign> whose devices carry Element ID = the Teamcenter detail item and Component_Base_ID = the source component, so a publish-back from Capital resolves the exact original items. The generator also emits the OTI section: Capital's per-project property dictionary, giving every engineer a TC_PARENT_ID Quick-Access-Panel dropdown whose legal values are derived from the Teamcenter-backed structure — never hand-typed. One deliberate exclusion: pathway/diagram graphics stay Capital-native (layout is presentation, not data), so the generator defaults to the proven importable shape.

Identity across the loop is the subtle part, because Capital re-keys all baseids when it bootstraps a project from XML — only the Element ID properties survive. So the generator runs two baseid strategies:

Put together, the loop closes in both directions: Teamcenter-authored structure materializes as native, editable Capital designs; Capital-authored elements publish back and nest into the shared spine; and a full re-publish of a materialized design resolves every original object with zero creates. That closed loop — not any single tier — is the architecture. proven live