Skip to main content

CTT Verification

This page explains the actual CTT verification flow shown in the team flowchart.

API Endpoints​

  • POST /ticket/verification/ctt

Purpose​

CTT verification checks whether a CTT can be verified from session-related evidence and whether the case should stay open, close, or trigger cleanup actions.

Trigger​

The flow starts from a CTT verification request.

The flowchart shows that the system then:

  1. loops each CTT number in the request
  2. prepares CTT context
  3. decides whether the CTT and its context are valid enough to continue

Main business intent​

This flow is not only about marking a case verified.

It also decides:

  • whether the case has enough context to be checked
  • whether a usable LOGIN_ID exists
  • whether PPOE or Radius evidence shows the line is verified
  • whether the verified result should keep the CTT open or allow closure-related action
  • whether an already-cancelled CTT should be unlinked from NTT

Flow summary​

StepBusiness meaning
CTT verification requesta verification run is requested for one or more CTT items
Loop each CTT numbereach CTT is handled one by one
Prepare CTT contextthe system gathers the data needed for verification
CTT found and context valid?invalid or missing CTT context stops the normal verification path
Extract LOGIN_ID from customerInfothe login identifier is needed for session checks
LOGIN_ID exists?without it, the system cannot continue session-based verification
Check PPOE statusthe system checks one verification evidence source
Check Radius statusthe system checks another verification evidence source
Resolve final verification decisionthe system combines evidence into one result
Verified by PPOE or Radius?if not verified, the CTT stays open
UNIFI source + HSI/all-services-down?extra closure logic only applies to this scenario
Session online?if not online, the CTT stays open even if verification succeeded
CTT already Cancel?if already cancelled, unlink path is used instead of normal close path

Decision path​

1. CTT and context must exist​

First gate:

  • CTT found and context valid?

If no:

  • the item is skipped or failed
  • it does not continue into session verification checks

2. LOGIN_ID must exist​

If the CTT context is valid, the flow extracts LOGIN_ID from customerInfo.

Second gate:

  • LOGIN_ID exists?

If no:

  • no verification action happens
  • audit is still saved
  • the result records no login ID

3. PPOE and Radius are checked​

If LOGIN_ID exists, the flow checks:

  • PPOE status
  • Radius status

Then it resolves one final verification decision.

Third gate:

  • Verified by PPOE or Radius?

If no:

  • save unverified result
  • keep CTT open

4. Extra closure logic applies only for a specific source/scenario​

If verification succeeds, the next gate is:

  • UNIFI source + HSI/all-services-down?

If no:

  • save verified result
  • keep CTT open

This means a verified result does not automatically close every CTT.

If the case is from the UNIFI plus HSI or all-services-down scenario, the next gate is:

  • Session online?

If no:

  • save offline result
  • keep CTT open

6. Cancelled CTT behaves differently​

If the session is online, the next gate is:

  • CTT already Cancel?

If yes:

  • unlink CTT from NTT

If no:

  • set CTT status to Closed
  • resolve CTT if needed

Final outcomes​

The flowchart shows these final outcome buckets:

OutcomeResult
No valid LOGIN_IDno action, but audit notes missing login ID
Unverifiedkeep CTT open
Verified but not in closure scenariokeep CTT open
Verified and closure scenario but session offlinekeep CTT open
Verified, closure scenario, session online, already cancelledunlink from NTT
Verified, closure scenario, session online, not cancelledclose CTT and resolve if needed

All branches end by saving audit + result.

Hidden rules from the flowchart​

The flowchart includes a hidden-rules note box. These are important because they are easy to miss in code review:

  • Radius overrides primary PPOE when both exist
  • verifyCtt(...) routes to runCttForPPOEOnly(...)
  • verification still saves note or result even when there is no auto-close
  • TaaS vs TMF routing depends on cttNo pattern, not source enum

What this means for developers​

  • do not assume verification success means automatic closure
  • do not assume missing LOGIN_ID is a silent no-op; it still creates an audit result
  • do not assume only one evidence source matters; PPOE and Radius both participate
  • do not assume source enum alone decides TaaS vs TMF behavior
  • keep result-saving behavior intact even when no close action happens

What this means for QA and support​

When checking a verification issue, verify these in order:

  1. was the CTT found and was its context valid
  2. was LOGIN_ID present in customerInfo
  3. what PPOE result was returned
  4. what Radius result was returned
  5. whether the final decision was verified or unverified
  6. whether the case matched the UNIFI plus HSI or all-services-down closure scenario
  7. whether the session was online
  8. whether the CTT was already cancelled

Still worth confirming with the team​

The flowchart gives the main path clearly, but these details are still worth confirming in plain language:

QuestionWhy it matters
what exact cases count as "context valid"helps onboarding and troubleshooting
what exact PPOE and Radius states count as verifiedneeded for a full decision matrix
whether "UNIFI source + HSI/all-services-down" has edge-case exceptionsimportant for closure behavior
what user-facing message should appear for each failed gateimproves support and QA clarity