Ritvik Pandya (JP Morgan Chase) explains modeling each API request as a short-lived execution graph (a DAG of middleware steps) learned from telemetry at over 1,600 requests per second. Comparing actual execution against the learned graph exposes skipped, reordered, or injected steps that traditional monitoring misses. The same graph localizes performance issues to a specific node rather than the whole endpoint — in production it flagged a 41x deviation at a single node invisible to service-level monitoring, reducing root cause analysis from hours to under 30 seconds. The talk distinguishes one-off anomalies from drift (structural, volume, and behavioral/covariate) using per-node baselines and KL divergence, and describes a pipeline from telemetry to gradual rollout, including training, tuning (delayed events, sampling, cold starts), and results. # Channel Presentation Observations: Learned Execution Graphs Talk ## Video Overview - **Format**: Conference-style technical talk (speaker addresses a live audience: *"hope everyone is out of uh the lunch coma"*), ending with a speaker LinkedIn connection prompt. - **Speaker self-identification**: *"myself Ritik I lead the payments team in JP Morgan."* ## Explicit Self-Description Evidence ### Speaker/Channel Claims - The speaker claims leadership of a **payments team at JP Morgan Chase** (from transcript; also stated in the video title). - He frames the talk as **part of a larger system**: *"This whole talk is mostly about statistical... part of the solution. It's part of bigger neuro specific algorithms and system in a way but this is just one of the module which I'm talking about."* ## Observable Presentation Patterns ### Claimed Scope - Topics covered: **execution graphs (DAGs)** for request processing, **anomaly detection**, **drift detection** (structural, scale/volume, covariate), tiered checking, root-cause localization, and **automation with risk-gated rollout**. - Supporting technology stack demonstrated: **OpenTelemetry, Kafka, streaming assessment, benchmark anomaly injection, MMD/KL detection methods**. ### Intended Audience - **Practitioner/engineering audience** with distributed-systems and observability knowledge — the talk assumes familiarity with concepts like ingress layers, gateways, DAGs, Kafka, telemetry, and canary-style rollouts, without introductory explanation. - Audience is implied to work on **high-volume, latency-sensitive services**, e.g., *"in the payments and the real time payment processing we want to keep it very faster."* ### Demonstrated Presentation Style - **Plain-language analogies** used repeatedly to explain technical concepts: - Airport boarding-pass check (tiered checks) - Daily commute time (anomaly vs. drift) - Coffee shop membership question (structural drift) - Doctor's health score (explainability) - **Practical operational guidance** offered directly: reduce alert noise, use per-use-case baselines (*"post for payments for real-time payment or post for wire payments"*), define windows per client, account for cold starts and delayed telemetry events. - Claims of measured outcomes stated as experience: *"mean time to discovery reduced a lot to make it very real time... a single window which we identified helped a lot."* ## Summary for Channel-Level Synthesis - The video demonstrates a channel presentation oriented toward **enterprise fintech engineering talks** — a practitioner from JP Morgan explaining internal-style architecture approaches at a conference, mixing architecture concepts with hands-on tuning advice, and ending with a networking invitation (*"I would like to connect with you all. Here is my LinkedIn"*). - No curated metadata was present; all observations derive from the title and transcript. # Delivery Observation: Ritvik Pandya — Learned Execution Graphs for Anomaly Detection & Drift in APIs ## Overall Tone & Register - **Conversational, informal engineering talk** delivered as a conference session, opening with light humor about the audience: *"hope everyone is out of uh the lunch coma and we'll survive this talk."* - Frequently frames himself as a practitioner sharing lessons rather than lecturing: *"that would help a lot," "this is just one of the module which I'm talking about here."* ## Verbal Fillers & Disfluencies - **Extremely high density of "uh" and "you know"** throughout — a stable, pervasive feature from start to finish: - *"So uh yeah myself Ritik I uh lead the payments team"* - *"one client is local to you and one client is uh you know the request is coming from outside"* - Occasional self-corrections and restarts: *"u uh ordered and simplified u uh simply can be represented"*; *"it's it's uh part of bigger neuro uh specific uh um algorithms."* ## Recurring Phrases - **"So" as a transition marker** — appears repeatedly to open new segments: *"So here is a simple example," "So say you are driving from your home to office," "So once you know the pattern uh you know the solution."* - **"you know"** as a constant connective filler, sometimes twice in one sentence. - **"Here is/Here are"** to introduce examples: *"Here is one of the example uh for benchmark," "Here are a couple of example," "here is the simple uh tag."* - **"One of the…"** as a hedging construction: *"one of the thing," "one of the reason," "one of the category."* - **"right?" and "right so"** used as audience-check tokens: *"let you go so uh now if you…" "one now you know that uh in what order service execution will be happening right."* ## Teaching Habits ### Everyday Analogies A **consistent pattern** — nearly every technical concept is anchored to a daily-life scenario: - Airport security for tiered checks: *"it's like uh going to airport… someone is looking at the boarding pass and let you go"* - Commute time for anomaly vs. drift: *"say you are driving from your home to office every day… took you more time than 1 hour"* - Coffee shop membership for structural drift: *"there is a shop where you like uh drinking coffee and uh one fine day they are ask start asking you about membership"* - Doctor visit for explainability: *"If you go to the doctor and doctor says your health score is 22, it doesn't make much sense to you."* ### Sequential, Formulaic Explanation - Presents workflows as **numbered mental steps**: *"First you uh represent the entire request processing as DAG. You come up with the baseline. You find out the deviation and then you try to find out where exactly the issue is."* - Builds **contrast pairs** (anomaly vs. drift, structural vs. covariate drift, hot path vs. recon path) and works through each branch in turn. ### Concrete Numbers as Illustration - Uses **specific-but-round figures**: *"700 millisecond," "5% or 10%," "60% of local request but uh and 40%," "7 days of the time millions of uh traces."* - Name-drops concrete tools as evidence: *"open telemetry," "Neo4j," "kafka," "MMD or KL."* ## Communication Patterns - **Self-aware scoping**: explicitly limits talk scope — *"This whole talk is mostly about statistical uh uh you know part of uh the solution."* - **Practitioner caveats**: raises open problems rather than presenting a finished system: *"What if one of the system is delaying the event? Should we consider it as a structural change…"* - **Advice-giving mode** near the end, with direct recommendations: *"try to come up with very uh a number which works for you," "don't make it very generic."* - **Brief closing** with a call to connect: *"Uh thanks everyone. Uh I would like to connect with you all. Uh here is my LinkedIn."* ## Stability Assessment - **Stable patterns (high repetition):** filler density ("uh," "you know"), analogy-based teaching, "So"/"Here is" transitions, stepwise explanations. - **Isolated moments:** the opening joke, the closing LinkedIn plug, and the mid-talk apology (*"Sorry here where uh either you need to come up with…"*) appear once each and should not be treated as habits. # Observation Document: Learned Execution Graphs for Anomaly Detection & Drift in APIs ## Video Metadata - **Title:** Learned Execution Graphs for Anomaly Detection & Drift in APIs — Ritvik Pandya, JP Morgan Chase - **Speaker:** Ritvik Pandya (self-identified as leading the payments team at JP Morgan) ## Core Thesis Ritvik Pandya proposes representing end-to-end request processing as a **short-lived execution graph (DAG)** rather than persistent/property graphs (e.g., Neo4j), to detect anomalies and drift, localize issues, and automate responses in payment systems. ## Key Claims & Reasoning ### Execution Graphs vs. Persistent Graphs - Persistent/property graphs (queried via Neo4j and similar products) differ fundamentally from **execution graphs**, which are short-lived. - Representing request processing as a DAG simplifies: - Knowing the **order of service execution** - Tracking **context passed between nodes** - Handling **retries and loops** — each loop modeled as a separate entity for trackability ### Tiered Checking Model - Analogy: **tier one check** is like airport boarding-pass inspection — cheap and quick. - If the end-to-end baseline looks good, no deeper tier-two analysis is needed. - On detected delay, investigate whether it stems from **structural change** (node/step added or removed), then proceed to scale deviations, divergence, and exponential moving averages. - Baselines differ per client (e.g., local vs. foreign clients), which helps **set thresholds and reduce alert noise**. ### Workflow 1. Represent request processing as DAG 2. Establish baseline 3. Find deviation 4. Localize the issue 5. Compare against threshold; alert/automate only if out of threshold - Example: a foreign transaction FX rate service taking longer than usual is localized precisely via the graph. ### Benchmarking - **OpenTelemetry** and **star bench** were used; millions of traces injected over ~7 days, with anomalies injected to train the system before going live. ### Anomaly vs. Drift - **Anomaly:** one-off incident (commute usually 1 hour, one day takes longer due to traffic/accident). - **Drift:** pattern change over time (commute gradually takes 20 minutes longer than a year ago — attributed to more cars in the Bay Area); requires a **new baseline**. ### Drift Categories - **Structural:** new node added/removed (coffee shop adding a membership step); old baselines and alerts must account for the change. - **Volume/performance:** service can't handle increased volume; respond by scaling, adding instances, or making calls asynchronous. - **Co-variate:** e.g., business started ~60% local / 40% international requests; popularity shifts the mix, so reassess baselines — either split into two graphs (local vs. international) or raise the average request-time baseline. ### System Architecture & Rollout - OpenTelemetry feeds data continuously → root cause analysis → classify drift type → determine action → assess **risk** → staged rollout (5–10% of machines first, monitor, then 100%). - **Hot path** (fast decision) vs. **recon path** (slower, more accurate). - Async data feeding to OpenTelemetry, Kafka streaming, and stream assessment used to avoid delaying real-time payment processing. ### Open Challenges (as stated by the speaker) - **Delayed events:** if one of seven nodes delays its telemetry feed, is that a structural change? Needs fine-tuning to avoid false alarms. - Recommends **tail-based** sampling since tracking is on service start/end times per node. - **Cold start:** new endpoints should get their own baseline, not a generic one. - Detection methods: **MMD or KL divergence**; confirm with admin before classifying and automating. ### Reported Results - **Mean time to discovery reduced substantially** — near real-time; a **single window** sufficed instead of multiple time windows. ### Best Practices Listed - Use labels carefully; fine-tune around them. - Avoid one generic baseline (e.g., "all POST requests"); use use-case-specific baselines (real-time payments, wire payments). - Well-defined windows per client for structural-change detection. - **Explainability:** data should be interpretable — analogy: a doctor reporting only "health score 22" is meaningless. - System must be aware of new deployments to inform rollback decisions. ### Scope Qualification - The speaker explicitly notes this talk covers the **statistical module only**, part of a larger neuro-specific algorithms and system. # Video Attribution & Provenance Record ## Video - **ID:** `01a15ca8-6699-78de-8b43-3f57da872564` - **Title:** Learned Execution Graphs for Anomaly Detection & Drift in APIs — Ritvik Pandya, JP Morgan Chase ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | Ritik (Ritvik Pandya) | **Sole speaker / presenter**; self-identified as leading the payments team at **JP Morgan Chase** | Transcript opening: "myself Ritik I uh lead the payments team in uh JP Morgan" | - **Single-speaker talk** (conference-style presentation, references post-lunch audience). No guests, narrators, or other identified speakers. ## Referenced Sources & Tools - **Neo4j** and other products — cited for persistent/property graphs (contrast with execution graphs). - **OpenTelemetry** — telemetry data feeding; also cited in a benchmark example. - **Star Bench** (as transcribed; possibly "Stressbench"-like benchmark name — recorded as spoken) — used with OpenTelemetry in a benchmark injecting millions of traces over 7 days. - **Kafka** — mentioned as streaming option from telemetry. - **MMD and KL** — statistical detection methods mentioned for drift detection. - **LinkedIn** — presenter offers contact via LinkedIn (personal promotion of connection, not flagged as commercial promotion). ## Third-Party Claims - "the solution which we generally use everyone in the industry is asynchronously feeding the data to uh opal [OpenTelemetry] telemetry" — industry-wide claim by the speaker, unverified. ## Promotional Segments - **None identified** — no product marketing or sponsor content. LinkedIn mention is a personal networking invitation, noted above. ## Provenance & Availability Notes - Speaker describes this talk as **one module of a larger internal system** ("part of bigger neuro specific algorithms and system"). - Anecdotes (commute, coffee shop, doctor health score) are **illustrative examples by the speaker**, not sourced data. - **Comment availability:** not stated in transcript or metadata. - **Curated metadata:** none supplied beyond title; title attributes speaker and employer. ## Uncertainty - Transcript is auto-generated with disfluencies; name rendered as "Ritik" in speech vs. "Ritvik Pandya" in title. - "Star bench" and "opal telemetry" are best-effort renderings of spoken terms. Hi. Uh thanks thanks and uh hope everyone is out of uh the lunch coma and we'll survive this talk. So uh yeah myself Ritik I uh lead the payments team in uh JP Morgan and uh today I'll be talking about learn execution graphs how these graphs can help to uh detect any anomaly and uh drifts also how we can automate few things around that and uh you know u uh at the same time if we can reduce the manual you know detection work and uh going on that side uh so whenever we hear about graph uh there are persistence graph and property graphs uh which Neo4j and you know other products uh we use for them we query those uh graphs and get the answers out of it what I'm talking about today is execution graph. It's short-lived graph. Uh and idea here is holistically try to identify how the request processing happens and if there is any deviation on that and how to detect that and how to fix that. So here is a simple example. Uh say we have set of applications. uh you have one edge layer uh the first layer where you know request comes in and then uh you have some gateways uh if k is there you have ingress layer on top of it then authentication authorization happens after that there is some orchestration layer and uh few other systems which could be called in parallel uh once everything is done you are notifying your client that what's the update on that request right So here the idea is representing the uh overall request processing as DAG and using tag simplifies most of the things here. one now you know that uh in what order service execution will be happening right so that's one of the thing the other thing is uh you know the context that in at what node what context will be there and what will be passed to the next node uh in that way it will be very um u ordered and simplified u uh simply can be represented uh there are few other uh use cases could be uh in terms of retries and uh the loops etc. uh the idea here is uh every loop uh to put in the graph as a separate entity itself. So uh in that way it could be tracked uh easily. how we can make this system uh more uh reliable at the same time not using uh most of the resources right so in the tier one check or it's your first check it's like uh going to airport and you you you know it's just boarding pass is some someone is looking at the boarding pass and let you go so uh now if you know the baseline of your request execution end to end if uh everything looks Good. You don't need to go to the tier two uh or next tier of check. Right? Once if you find that there is some delay. So now you need to check that what changed here. One of the uh the drift here could be because of the structural change. So if any new node or new step added which you are not aware of that could be one of the thing or one of the step which is removed that could be the another reason right. Uh once you know about that then further uh further analysis could be done uh in terms of scale deviations uh divergence and uh exponential ma uh so in simpler terms if you know that client A's request is taking this much time normally and uh client B's request could take might take more time than the client A um because of say one client is local to you and one client is uh you know the request is coming from outside and uh there are a few more checks needs to be done. So in in that case the baseline will change client to client and now you know that uh what your threshold it and uh how you can u reduce the noise of such alerts. Uh so here the idea is very simple. First you uh represent the entire request processing as DAG. You come up with the baseline. You find out the deviation and then you try to find out where exactly the issue is. Once you localize that then you compare that based on your system that whether it is uh within the threshold or not. If it is within the threshold yeah you don't need to u you know do the alerts or automate anything but if it is out of the threshold then certain action needs to be taken. Uh coming back to our example here say overall uh request processing from all the different nodes within our system uh is happening but somehow the foreign transaction uh rate service is taking more time than the usual. Now if you represented this whole uh request processing in multiple nodes you know where the problem is or where the issue is and correspondingly you will uh you know now you can uh exactly know where the problem is. So you can solve it uh that what how to uh how FX system or what all different uh cases were there in the past where FX FX rate system was failing. Here is one of the example uh for benchmark uh open telemetry and that star bench were used and say for 7 days of the time millions of uh traces were um you know injected or uh in the system then you inject the problem or uh anomaly there and based on that you train your system before anything goes on live. So uh again uh basic thing here is what is anomaly and what is drift right? So say you are driving from your home to office every day and uh one of and usually it takes 1 hour but uh one fine day it took you more time than 1 hour. Uh the reason might be some traffic or you know um car accident or anything. But uh he this is one of the incidents and uh based on your system and criticality of your system uh you can decide how to address that. The other part is one fine day you are uh taking sip of coffee around 4 p.m. and realized that a year back it used to take one hour for you from your home to office but nowadays it it is taking 20 more minutes right so what happened in Bay Area in number of carc so this is over the time what you are seeing is pattern changed and that's where you might need to come up with uh the new baseline itself so uh that's that's the drift that over the time you start seeing some delays or you know some uh performance deviation then once you know that there is a drift uh you can further categorize it first category is structural uh so say you somehow in the system a new node is added or one of the node is removed as I mentioned earlier for example you like uh again you know there is a shop where you like uh drinking coffee and uh one fine day they are ask start asking you about membership so they added one more uh step in it now every day they might ask you for hey do you have membership with us if you have then there is there are a special discount for you if you don't have membership then the regular prices will be there so in that way uh you know same way in our service processing or a request processing if new node is added that means uh Now you need to consider that step also in your old baselines and new alerts. The other one is uh say because of the volume of request uh one of your service is taking more time or it's not you know u cannot serve the request or the volume which you are expecting now over the time. So yeah, such kind of drifts you might need to treat differently because now you need either you need to scale up those services or instances of those services and or you need to either make it asynchronous call or based on based on the use case you know what whatever uh works there uh co-variate is a different uh one of the category say when you started the business uh you were seeing around 60% of local request but uh and 40% uh request from you know out of the country and that's where you might need to change the currency or you know one extra step is there so you now you know that what is the baseline for your uh request in US dollar but uh what is the baseline for uh any of the other currency over the time what happens is your product is so popular that you started getting more uh request from the outside. So nothing changed. Your system is working fine, right? But now you need to come up with the criteria and reassess your baselines again. Sorry here where uh either you need to come up with two different uh you know uh graphs to compare that one is for local and one is for um outside uh request from outside or what you can do is you can increase your uh average request time baseline. So once you know the pattern uh you know the solution. So uh that's where you need to categorize uh this drifts. One category could be for the same request uh now you are seeing the different behavior itself. Then probably if and when it's needed you might need to roll back such uh changes or either you need to reconsider that. So where I'm going with this is in that way you need to re-evaluate and reassess your system before uh identifying that what action needs to be taken. This whole talk is mostly about statistical uh uh you know part of uh the solution. uh it's it's uh part of bigger neuro uh specific uh um algorithms and system in a way but this is just one of the module which uh I'm talking about here now so once you know the drift or deviation and here is the simple uh tag for how uh this whole system would work. Open telemetry will will keep feeding the data. Once you have that data, uh root cause analysis could be taken based on uh once your system knows about all the data points. Now you know which type of drift it is and what solution could be there. Then you identify what action needs to be taken. Once you know what action needs to be taken further you need to also uh find out that what is the risk if we go with this approach or if we automate this uh solution right so once you know the risk either you can go with uh roll out that system uh um solution for say 5% or 10% of your uh machines monitor it verify everything looks good and then you roll out for your 100% of the nodes Here are a couple of example. uh again uh say generally overall request processing takes 700 millisecond but uh on the left side what you are seeing is u in the graph approach itself how it could help you is uh now you know that uh which specific node is taking more time suddenly you get alert on that or otherwise if you are seeing that uh the delay is all across then something which is common which you need to fix here all these things because in the payments and the real time uh payment processing we want to keep it very faster right so we don't want delay the actual request processing the solution which we generally use uh everyone in the industry is asynchronously feeding the data to uh opal telemetry from there u some kafka could be used and stream assessment uh could be used on top of it. There could be two different paths. One is say hot path where you can take a decision very faster and uh um work on the solution or automate that solution. The other one is more recon kind of solution where it might take some time but more more accurate could it could be few of uh uh other challenges which uh we need to fine-tune here. So all I talked about is hey you have seven nodes in your system and every node is feeding the data to your uh telemetry. What if one of the system is delaying the event? Should we consider it as a structural change because now what you have data in your system is for six nodes and the seven uh uh the data from the seven node is delayed already. So we need to fine-tune that uh that those numbers also that when to consider that uh there is a structural change or not. So basically here we are uh trying to reduce uh any false alarm based on the use cases and here in this use case u we should go with tail by based system because what we are trying to track here is uh or in this specific example is when the service request started and when it ended right so uh for each and every node the other part is the cold start uh if there is a new endpoint consider the new baseline don't make it very generic. So in that way on the detect side any MMD or KL uh could be used uh and once you confirm uh this with admin and then classify uh the problem uh that will give you where what exact solution needs to be done and next step whatever uh if we can automate it we'll automate it. So what we see uh in general here is uh mean time to uh discovery reduced a lot to make it very real time. Instead of comparing or waiting for multiple windows of uh the time duration it was uh a single window which we uh uh you know which we identified uh helped a lot uh to fix the issues fast. uh few of other things which we might need to make sure. One is uh the labels when it comes to uh learnings the labels helps a lot but uh at the same time uh we need to make sure that uh the system is very fine tuned in terms of that. Uh the other part is instead of saying that all the post requests should have you know this is a baseline for all the post request uh try to come up with very uh a number which works for you post for payments for real-time payment or post for wire payments or u based on you know uh your use cases. So that that would help a lot. Um again uh if anything is u um you are considering a structural change or something uh the window uh should be well defined for each and every client. In my previous uh example which I talked about uh if you can come up with the new baseline would really help uh to reduce the noise. Uh explanability uh all the data should be well explained. If you go to the doctor and doctor says your health score is 22, it doesn't make much sense to you. So, uh yeah, the actual uh more data uh can explain you know more things to you and uh can we can take the informative decision on top of it. Uh whole system should be aware of the new deployment. Uh so u u based on that you can take either roll back decision or not. So yeah that's that's about it. Uh thanks everyone. Uh I would like to connect with you all. Uh here is my LinkedIn. I can answer it.