Known source → Census → Assets
Three built integrations collect supported external source records. The Connect application runs inside Atlassian Forge and synchronises them into Jira Service Management Assets.
Runtime: Atlassian Forge
Architecture
Two products means two technical paths.
LT Census shares a destination and an operating language. It does not share one runtime or one trust boundary.
Runtime map
LT Census ConnectAtlassian Forge
LT Census DiscoveryLTS operated infrastructure
Product architecture
Keep the runtime visible in every diagram.
The trust boundary sits between the source and Assets. Omitting it makes the family look like one application and produces false security assumptions.
Environment → discovery → Census → Assets
LT Census Discovery collects supported environment inventory, with Google Cloud as its launch scope. It runs on infrastructure LTS operates outside Atlassian, then synchronises the result into Jira Service Management Assets.
Runtime: LTS operated infrastructure
Family relationship
Shared controls do not erase the boundary.
The two implementations can use a consistent vocabulary for the work that prepares records for Assets while remaining separate market applications.
Normalise
Prepare source records for a consistent Assets model.
Compare
Classify records that appeared, changed or disappeared.
Synchronise
Apply the required object changes in Assets.
Record
Keep the execution result visible and explainable.
Repository shape does not define product shape.
Even if the codebases are consolidated later, Connect and the LT Census Discovery remain separate products with separate install decisions, pricing positions and trust boundaries.
LT Census
Choose the product boundary that fits the source.
Evaluate the Forge runtime for Connect and the LTS operated runtime for Google Cloud resources separately.