Alarm Data Comparison – ONTIC vs. ISS

Chapter 1 – Introduction

  • Team is working on comparative alarm analysis.
  • Two potential scopes under discussion:
    • Evaluate all APU alarms and compare against ONTIC data.
    • Evaluate only alarms that fall within a specific threshold and compare them with ONTIC.
  • Justin (stakeholder) has not yet clarified which scope he wants.
  • ONTIC alarm data contains several sub-results, one of which is GSoft US Alarm (aka "GSOFT EOS Alarm" in transcript).

Chapter 2 – Alarm Categories (1 → 4)

  • ONTIC (and possibly ISS) classify alarms into four nested levels:
    • Category 1
    • Category 2
    • Category 3
    • Category 4
  • Example noted in demo: GSoft US Alarm sits inside Category 1.
  • Familiarity gaps:
    • Not everyone on the call is comfortable with the Category 1–4 hierarchy.
    • Presenter offered a screen-share to walk through the category structure.

Chapter 3 – Data Volume & Feasibility

  • Alarm comparison becomes data-heavy when the full history is included.
    • A summary is still "manageable."
    • Full granularity (all alarms/all time) balloons the dataset.
  • Key question: do we limit by month, by threshold, or by category to stay within performance limits?

Chapter 4 – Key Data Fields & Linking Logic

  • Associated Asset
    • Field example: “Eighteenth Avenue 67.”
    • May be the only reliable linking column between systems.
  • Account / Branch / Store Name
    • ISS holds the branch name one way.
    • ONTIC stores the same branch name in a different style/format.
    • There is no guaranteed 1-to-1 match between the two naming conventions.
  • ID columns
    • Transcript states that no single unique ID exists in the ISS feed that maps directly to ONTIC records.
  • Practical issue: need a mapping table or fuzzy matching logic to bridge naming discrepancies.

Chapter 5 – Comparative Metrics & Reporting

  • Simple counts are feasible:
    • Example: “How many GSoft US Alarms for Category 1 in a month?”
  • ISS daily bug feed (source of truth for operations) is assumed to be smaller than the total ONTIC alarm set.
    • Statement: Daily feed subset is “≈6\approx 6” while total ONTIC count is much higher (exact numbers not given).
  • Desired output: A side-by-side comparison between
    • ONTEC counts (full historical or threshold-filtered), and
    • ISS daily counts (delta feed).

Chapter 6 – Outstanding Questions & Next Steps

  • Scope Clarification: Need Justin to finalize whether analysis covers “all alarms” or “only threshold-qualified alarms.”
  • Category Familiarization: Team members unfamiliar with the 1–4 classification require a walkthrough.
  • Mapping Development: Decide on strategy to match ISS store names to ONTIC store names or use Associated Asset as surrogate key.
  • Performance Planning: Determine acceptable data window (monthly vs historical) to balance accuracy and run-time.
  • Tool Chain: Whether comparison will be done inside the BI layer, dedicated SQL queries, or external scripts remains open.