Service Map

This page gives a plain-language map of service responsibilities based on repository names, current README files, and existing portal structure documentation.

For the code-backed detail view, see Source-Confirmed Mappings.

Service catalog

Service	Role
intt-mobile	Flutter mobile client for field workflows
intt-portal	Main Angular frontend and user entry point
mvp1-authentication-service	Authentication, token exchange, and access-related backend
mvp1-setting-service	Application setting and configuration backend
mvp2-data-service	Dashboard, reporting, and analytics backend
mvp3-ngoss-service	NGOSS-related backend domain
mvp3-nocgrid-service	NOC Grid-related backend domain
mvp3-nocpro-service	NOCPro-related backend domain
mvp3-gsb-service	GSB-related backend domain
mvp3-ticket-service	Ticket module backend domain
mvp3-tmf-service	TMF-related backend domain
mvp6-vital-service	Vital-related backend domain

Queue services

Service	Likely role
mvp3-caution-report-queue-service	background processing for caution report flows
mvp3-changedp-queue-service	background processing for changedp-related flows
mvp3-ctt-queue-service	background processing for CTT-related flows
mvp3-gsb-queue-service	background processing for GSB-related flows
mvp3-kci-queue-service	background processing for KCI-related flows
mvp6-tass-queue-service	background processing for TASS-related flows
mvp6-vital-queue-service	background processing for Vital-related flows

Portal module hints

The existing intt-portal structure documentation references major frontend domains such as:

• CR
• NTT
• RNTT
• CTT
• GSB
• dashboards
• reports
• settings
• user profile

That suggests the frontend is an integration shell over several backend capabilities rather than a thin single-purpose app.

Mobile module hints

The current intt-mobile README lists operational modules such as:

• Change DP
• Reset HSI
• Reset VOBB
• Reset NGTV or IPTV
• Reset PLAYTV
• Bypass LSN
• Sync Speed
• Create NTT
• Caution Report
• History

That suggests mobile is a first-class client surface, not a side utility, and should stay visible in architecture docs.

Shared patterns across backends

• NestJS application structure
• pnpm run start:dev for local execution
• pnpm run build and pnpm run start:prod for production-like execution
• pnpm run test, pnpm run test:e2e, and pnpm run test:cov
• shared share-entity usage in multiple services
• several repos expose db:seed, suggesting local data bootstrapping is common

Integration assumptions to validate

The following areas should be documented in more detail as the team fills gaps:

• which API domains are called by intt-portal
• which services depend on RabbitMQ or other async messaging
• exact DB ownership for each service
• whether gsb-service and ticket-service communicate directly
• which queue worker belongs to which API/domain service
• which services are mandatory for local startup in each workstream

Next documentation step

Once API endpoints and environment configs are reviewed, extend this page with:

• a table of ports and base URLs
• ownership mapping by team or module