Podcasts about failure modes

In this episode, co-hosts Heather Allain and Marc Cook welcome Maria Jose Oestergaard to explore three essential reliability and continuous improvement tools: Failure Modes, Effects, and Criticality Analysis (FMECA), Root Cause Analysis (RCA), and Value Engineering (VE). Maria Jose explains when to use each methodology, how to define the scope of an analysis, and the importance of assembling the right team and documenting findings throughout the process. She also discusses common triggers for implementing these tools, how organizations can leverage the results to improve performance, and when it makes sense to rely on internal expertise versus outside consultants.   This episode is sponsored by Tricor Metals and Rolled Alloys.   Corrosion Chronicles is produced by Association Briefings.

Watch the full episode on YouTube:We first covered Baseten last year when DeepSeek mania was at peak hype. Now they have raised a monster $13B round and become one of the new cohort of AI Infra decacorns that are (with Nvidia, Intel, and the semis complex) chief beneficiaries of the Inference Inflection. We return to Baseten at the peak of the 2026 edition of Open Weights debate. Ali has published a viral breakdown of Kimi K3:And since you last saw him, Philip has spoken at AI Engineer and written the definitive book on Inference Engineering spotted all over SF:Three years ago, inference engineering barely existed as a category.Today, it is one of the most critical disciplines in AI. Inference engineering inherently tackles a different question than standard model training: “How do you turn those weights from training into a product that is fast, reliable, and affordable at scale?” Focusing on these creates an entirely new optimization problem.In one recent GLM-5.2 experiment, quantizing more of the model actually preserved its benchmark quality while increasing throughput by 20%, because the errors introduced in different layers could cancel each other out.Inference is no longer just the final step after training. It is becoming its own engineering discipline, with its own research problems, infrastructure, and increasingly specialized roles.In this episode, Baseten's Philip Kiely and Ali Taha join swyx and Vibhu to explain what actually happens after a new open model is released and what it takes to turn “we generated a token” into a fast, reliable, production-ready API.We go deep on cache-aware routing, disaggregated prefill and decode, quantization, speculative decoding, KV-cache movement, model parallelism, GPU kernels, and the race to make frontier models up to 10× faster. Philip and Ali explain why inference optimizations can still produce gains of 20%, 100%, or even 200%; how quantization errors can cancel one another out; why identical weights can behave differently across clusters; and how Baseten grafted a Kimi vision encoder onto GLM-5.2 without changing the underlying language model.The conversation then expands beyond LLMs into NVIDIA Dynamo, mega kernels, Rubin, AI-specific chips, local inference, video generation, diffusion versus autoregressive models, and the enormous compute barrier to generating coherent long-form video. Finally, we explore the convergence of training and inference, continual learning through persistent KV cache, and the emerging loop where models help optimize the infrastructure that runs them.We discuss:* What happens when a 200,000-token request enters an inference system* Cache-aware routing and reusing previously computed KV cache* Why prefill and decode are increasingly handled by different GPUs* When dedicated deployments become cheaper and more reliable than shared APIs* How speculative decoding uses a smaller model to accelerate a larger one* Tool calling, structured outputs, and what LLMs actually do* What it takes to support a new open model on day zero* Grafting Kimi's vision encoder onto GLM-5.2* Retrofitting inefficient model layers with components from other architectures* Why models sometimes collapse into repeating the same token* How hardware, kernels, and race conditions create nondeterministic failures* Preserving model fidelity while making inference faster* How quantization errors can cancel each other out* Why inference optimizations still deliver gains of 20%, 100%, and 200%* How optimized serving can make a model up to 10× faster* NVIDIA Dynamo, KV-aware routing, and distributed model serving* Speculative decoding the speculative decoder* Why local AI is about making models less dumb while data-center AI is about making them less slow* Tensor, expert, and pipeline parallelism across GPUs* Hardware-aware model design, auto-tuning, and the case against mega kernels* Rubin and why inference is becoming a systems problem* Whether modern GPUs are evolving into programmable AI ASICs* Why enormous models like Kimi K3 require GB300-class hardware* Why open-source video generation still trails Veo, Kling, and other closed models* The quadratic attention bottleneck behind long-form AI video* Autoregressive video, real-time generation, and compounding quality drift* Why future video systems may combine autoregressive and diffusion architectures* Training for inference and inference for training* Continuous post-training, deployment, evaluation, and improvement loops* How GLM-5.2 helped optimize the kernels serving GLM-5.2 itself* Why faster networking could unlock dramatically faster decoding* Continual learning, KV-cache compaction, and persistent model memoryShow Notes* How to build a day-0 API for Kimi K3* 22580: From GPT2 to Kimi3, ExplainedPhilip Kiely* LinkedIn: https://www.linkedin.com/in/philipkiely* X: https://x.com/philipkiely* Inference Engineering: https://www.baseten.co/inference-engineering/Ali Taha* LinkedIn: https://www.linkedin.com/in/aliestaha/* X: https://x.com/waterloointernTimestamps00:00:00 Introduction and the 200K-Token Prompt00:03:18 Dedicated Deployments, Speculative Decoding, and Tool Calling00:11:26 Launching Production-Ready Open Models00:19:06 Model Retrofits, Failure Modes, and Nondeterminism00:28:22 Quantization and Canceling Errors00:32:15 The Race to 10× Faster Inference00:40:48 Dynamo, Speculation, and Local vs. Data-Center AI00:50:18 Model Parallelism, Auto-Tuning, and Mega Kernels01:00:55 Rubin, GPUs vs. ASICs, and Custom AI Chips01:10:03 Giant Models and the Limits of GPU Memory01:12:42 AI Video, Quadratic Attention, and Autoregressive Generation01:21:47 Audio, Images, and Diffusion Models01:27:32 Training, Self-Optimizing Models, and Continual Learning01:40:06 Closing ThoughtsTranscriptIntroduction: Baseten, Waterloo Intern, and Inference EngineeringSwyx [00:00:00]: Okay, we're here in the studio with Philip, old friend from Inference Engineering, the book, as well as Baseten and everything that you've done, you and I have done before, as well as Ali. Welcome.Ali [00:00:15]: Pleasure to meet you.Swyx [00:00:15]: Waterloo intern.Ali [00:00:16]: Waterloo intern, always.Swyx [00:00:17]: When did you get “Waterloo intern” as a handle?Ali [00:00:19]: As a handle? Oh.Ali [00:00:20]: I think the rebranding happened mid-March. When I saw it was open, I was like, “I have to take it. Up for grabs.”Philip [00:00:26]: The problem is that Ali is really good at his job and is not gonna be an intern much longer.Philip [00:00:30]: So we have to figure out who's gonna get the handle.Ali [00:00:33]: Well, I'll pass the torch over to the next intern.Swyx [00:00:34]: Oh, okay. It can be, like, you just pass it to another Waterloo grad.Ali [00:00:37]: To another Waterloo intern. No, bruh.Philip [00:00:39]: Yeah.Ali [00:00:39]: Intern.Swyx [00:00:40]: Intern, yeah.Ali [00:00:40]: And no.Philip [00:00:41]: You gotta get an intern from Waterloo.Ali [00:00:42]: Yeah, I've gotta get an intern from Waterloo.Swyx [00:00:44]: Right.Ali [00:00:44]: But they have to follow the path.Swyx [00:00:45]: Oh, it could, but it could come from Baseten, so it's like whoever Baseten gets from Waterloo.Ali [00:00:48]: Right.Swyx [00:00:49]: Has the title of Waterloo.Ali [00:00:50]: It stays in the ecosystem.Philip [00:00:51]: Exactly.Ali [00:00:52]: Halfway through the internship, you either get it or you're out.Philip [00:00:55]: You should also do, like, a big graduation ceremony where you change the handle.Ali [00:00:59]: Just say it.Philip [00:00:59]: For everybody.Swyx [00:01:00]: You guys are good at ceremonies, clearly. We had a nice launch of the book, very successful. But before we get into all that, I wanna start off with a fun question for you. Okay, you're an expert inference engineer. What happens when I send a long query, say two hundred thousand tokens into Baseten's inference? What's the process of query through GPU model routing, balancing, all that? What is all the stuff that we don't think about?Long Context Requests, KV Cache, and Cache-Aware RoutingPhilip [00:01:26]: With a long query specifically, the first thing that I'm gonna ask is, “Have you sent me this query before, or at least part of it?” and I really hope you have, because it's gonna be a lot easier for me and a lot cheaper for you. So the first thing that we're gonna look at is some cache-aware routing, where we're going to see, we probably have a number of instances, a number of replicas up serving whatever model you're hitting. We want to send this one to something with, number one, available prefill workers, and number two, ideally some cached input already there so that we can skip prefill on at least part of these two hundred thousand tokens. If you're doing two hundred thousand tokens, it's probably coding or a multi-turn agent or something where you would expect to have that cached. If you don't, we're gonna have to send it to a prefill worker. We've at least on certain models disaggregated prefill and decode, so you're going to have one set of GPUs that's solely going to process the input, create the KV cache, and get you your first token, and then that's going to be passed over to a separate set of GPUs, which is going to run decode. We're going to iteratively make those tokens. We're probably going to have some speculator model in front of that. I'm going to assume that you're doing coding, and because of that, our speculator model, which assumes you're doing coding, is gonna have a high draft token acceptance rate. If I'm wrong and you're asking me to summarize every Harry Potter book, it's gonna be slower. And then we stream that output to you and account for it, charge you, a couple of pennies and say, “Hey, would you like to send another one?”Swyx [00:03:04]: Except Baseten doesn't charge by pennies.Philip [00:03:07]: Well, yeah, we charge. I'm assuming that we're talking about the public model APIs. If you are setting up a dedicated deployment, then yeah, it's not pennies.Public APIs vs. Dedicated DeploymentsSwyx [00:03:18]: Yeah, one of the key differentiators when I was talking with Baseten initially was that people who want very high volume just need to rent by the box, ‘cause then it's up to you to figure out how to saturate the box.Ali [00:03:31]: And more often than not, it's, like, way cheaper if you're pushing, like, millions of tokens per hour, if you just pay per hour instead of pay per token.Philip [00:03:37]: Yeah, they do. I think that we've increasingly seen a lot of demand for the pay per token APIs, just because everyone wants to try open models, and then once they find a use case that's really sticky, then they move over to dedicated.Swyx [00:03:51]: Is there a best practice on when it's time to swap over?Philip [00:03:54]: Couple reasons. Yeah, reliability, that's a big one, right?Ali [00:03:57]: Like, if they have a very specific use case, they want you to train something specifically for them, like they want their own spec dec, for instance, for their own traffic.Swyx [00:04:04]: Spec dec is speculative decoding.Speculative Decoding and Custom SpeculatorsAli [00:04:05]: Speculative decoding, yeah.Swyx [00:04:07]: You have to explain.Ali [00:04:07]: Sorry. Like, speculative decoding is like, if you have a huge model, right? And so the model is going to be generating one token at a time every single turn, every single forward pass. So we attach, like, this little, like, parasite, like this layer that goes on top of the model, and this model just has to predict. It does three very fast autoregressive forward passes, and it will predict, like, three certain tokens, and then you do one forward stage over the entire original model in order to see if those predictions were correct or not, and then you accept them or you reject them. Now, this draft model is traffic specific, so if you, like, Philip said, if you're summarizing Harry Potter books, I can train exclusively that draft model on Harry Potter books, and I can guarantee you that I'm gonna accept the three tokens every single time. And so with that case, I increase your decode speed. I wouldn't be able to provide this to you if you're a shared endpointSwyx [00:04:53]: YeahAli [00:04:53]: ‘cause I have no idea if you're doing Harry Potter, if you're doing coding, if you're doing English. We don't know. Also, there was a thing in the book that mentioned that if they really cared about a specific threshold, chapter four, I think. Do you remember that?Philip [00:05:06]: Yeah. The things that you can do is you can set a specific, like, batch sizing, a specific, like, parallelism strategy if you're trying to optimize for, like, throughput versus latency. You can. Maybe a NVFP4 quant doesn't pass your benchmarks and you wanna run a model at higher precision, you could do that. There's just a bunch of reasons why you might wanna have your own endpoint and the biggest one, of course, just being, like, you don't have to deal with someone else doing a hundred million tokens of benchmarking traffic at the endpoint when you happen to be trying to serve your users.Swyx [00:05:40]: Yeah. I think one thing that is. That is a classic journey. Like, it's people is asking the, what happens when you type Google into the browser. Tool calling, is that just, you're generating JSON or is there more complication beyond that?Tool Calling, JSON, and Structured OutputsAli [00:05:58]: Certain customers that we have, they have their own post-trained models, and so they demand a tool calling that's not just, like parse a file or go find the weather. It's something that's very specific and you have to do post-training on this. And if the post-training on the model is not good or if the quantization after the post-training to get the inference to be fast, the model will struggle reading the JSON file and reading the tool calling. But it doesn't require its own like sandbox. It's not like it's going to use that tool calling to like escape a sandbox or like it doesn't have to be contained. It can just be a normal dedicated deployment. The challenge with tool calling more and more seems to be that the companies want certain tool calling which is a very sensitive thing to train. And because you're dealing with all of the JSON outputs, if it doesn't like close the end of the request in a very certain manner, you end up with a model that did the tool calling and like the thinking and so as a result of that, it didn't see the result and just hallucinated the result as it decoded. That seems to be the most challenging thing with tool calling, not really the sandboxes model.Philip [00:06:56]: Yeah, that's a challenge on the training side and then on the inference side, there's work that you can do to scope the possible output. So we published this at this point close to two years ago, the solution to this problem which is you make a state machine and you use that to constrain the output to a specific format. So this is the structured output problem. If you remember backSwyx [00:07:27]: Yeah, the specific grammar is,Philip [00:07:29]: Yeah, exactlySwyx [00:07:30]: GML had this thing.Philip [00:07:31]: Yeah. So it's like the old-school “make sure this is only JSON”, return only JSON orSwyx [00:07:38]: YeahPhilip [00:07:38]: Grandma's gonna die type of prompts.Swyx [00:07:39]: Is it BNF grammar? At some point OpenAI had released a thing that was like, yeah, if you want to constrain your output, write BNF grammar, back as NOR.Philip [00:07:47]: In our inference system, it's just a specified output format. And you get the guarantee that your output's gonna be structured along that format. And so applying that to tool calls can like help cut down on. You can still call the wrong tool or call no tool. It doesn't solve the certainty problem but it at least solves the output structuring problemSwyx [00:08:10]: YeahPhilip [00:08:10]: Within tool calls.Swyx [00:08:12]: And MCP is just another form of tool, right.Philip [00:08:14]: Yeah, exactly.Swyx [00:08:15]: As far as there's no special thing there.Philip [00:08:16]: The thing I'm always like explaining to people is the LLM is not capable of doing anything. It's only capable of making suggestions of what to do and then if those suggestions are formatted in a certain way and applied to a system that knows what to do with them, then an action occurs.Swyx [00:08:32]: Yeah. Part of the fun stuff is, this is solved outside of tool calling too. Like in an agent loop if the output is not correct or you're right, like reasoning, tool calling was done in the reasoning trace, just be like, “Oh, I don't know what to do. Let me just try again.” And it might get there after a few tries. And on your point of training, sometimes this is harder in smaller models, so you don't have the same exact quality outputAli [00:08:56]: Right.Swyx [00:08:57]: When you just swap from a big model, right?Ali [00:08:59]: Yeah. I will say that, before, I think we need to go back to inference engineering proper.Ali [00:09:04]: But, I had expected that something would replace JSON because it's hard to stream JSON ‘cause JSON must be complete and you must have open and close brackets and everything. So it's hard to parse something or validate something while it's being streamed. So people invented all sorts of things that are like, I forget the name of some of these alternatives, but it's something like TOML, something like YAML. But JSON seems to be dominant still.Philip [00:09:30]: The JSON outputs aren't that long, right? Like you could have a long-- ‘cause tool calls also contain the arguments in them and perhaps for a certain tool you might pass like a very long argument. But my impression of the median tool call is that it's a relatively small number of tokens, right? So I would expect that speculators are generally fairly good at something as formatted as JSON. And so you would have like a pretty fast decode step there and that the streaming wouldn't be as valuable, but maybe I'm wrong about that.Ali [00:10:02]: I think you're also bounded by the software or that the model is gonna integrate with if the software is built with JSON for the tool calls or if the company that you'- if your customer says that this is how our software works and our tools are interfaced with JSON, you can ask them to like, change their software and say like, “Yeah, this is gonna be better for the model.” but like with the right training shouldn't be that much of a difference. Also more profitable if it outputs more tokens probably.Swyx [00:10:25]: Depends on your business model.Swyx [00:10:27]: It really depends. But I will say that, as a writer with like experience a lot with generated output, I do try to move from text to JSON text which is very long JSON, right? Like there's paragraphs in every field because I'm trying to structure it, right?Philip [00:10:44]: Right.Swyx [00:10:44]: I want you to first make factual statements, then make opinions then make bullet point summaries, have dates, have entity references have your sources for references, all these things. Anyway, so these are things that like I think people who really experiment with structural output have to really care about. But, let's, let's recurse up the stack a little bit. Before we started recording, you mentioned something really cool, which is that there's a lot of engineering that-- inference engineering that goes on when a new model provider releases a new model, right? So let's call it GLM-5.2, Kimi K3. I had previously assumed, especially if it's like, well, GLM 5 to 5.1 to GLM-5.2, like that you've supported them before. Is it that much work?What It Takes to Support a New Open ModelAli [00:11:26]: It's a lot of work.Swyx [00:11:28]: Yeah. Okay. So like, a lot of people, all you guys, right whenever a new model launch like, people rush to say like, “Oh, Hugging Face supports this, Fireworks supports this, Spacetime supports this,” and I'm like, “Yeah, of course we support it.” But what goes into that? What goes intoPhilip [00:11:40]: I think it's more than just support it too, right? It benefits the consumer a lot. Like I think it was with Kimi K2.5 or GLM-5.2 the latest, there was an inference war, right? X provider is at 90 tokens a second. The next day we're at 150. The nextSwyx [00:11:55]: I kinda kicked that off with the GLM-5.2.Swyx [00:11:58]: I wrote a Twitter article about. It got like half a million views,Ali [00:12:02]: Based on being numberSwyx [00:12:03]: YeahAli [00:12:04]: Or it's for something else.Swyx [00:12:05]: Yeah. Which,Ali [00:12:06]: Oh my GodSwyx [00:12:07]: Which then got everyone really excited about, hey, how can we, bend tracks a little bit further and,Philip [00:12:14]: There's a difference between support the model, as in I can make a token out of this model, and support a model, as in I have a production-ready API from this model.Philip [00:12:26]: Getting to the point of I can make a token out of this model is not that hard because generally the, open source inference engines, vLLM, SGLang of the world oftentimes even receive weights ahead of time, maintainers do, or the people making the model merge PRs to ensure support. So you generally can, just get it working on the standard open source stack without too much pain in most cases. The challenge is, every inference company is gonna have own proprietary stack. Some open source components, some in-house stuff. And for any arbitrary model, there's going to be some new stuff. Sometimes you get lucky, like K, two five to two six was, like, pretty similar.Quantization, Speculators, and Production ReadinessAli [00:13:16]: Yeah. It was pure continued post-trainingPhilip [00:13:18]: YeahAli [00:13:18]: If I remember correctly.Philip [00:13:19]: Even in those cases, there's still stuff you have to do. You have to redo the quantization work. You're taking the model from. Generally, these models are not released in NVFP4, and we want them to be in NVFP4 for maximum Blackwell compatibility. So we have to perform that quantization, and, calibrate the quantization to make sure that we're not causing any regression in the model's intelligence. And then we also have to train the speculator, as we've talked about. Generally, we have. We have ZDR, zero data retention on our model APIs, so we don't know exactly the traffic that people are sending us, but we know what's popular. We know that coding use cases are popular. We know that agents, agentic use cases are popular. So we can get public data sets that are representative of that traffic and train general speculators. Now, with speculators today, you need to train the speculator using the base model itself because you're getting hidden states out of the model from running inference on these specific prompts, and that is the training data you use to create the speculator. So there's that process which you need the real model weights for. And then there's of course just the process of, standing up all the infrastructure behind it, loading all this stuff, testing it. And then when there's a new model with a newer architecture, I think that, like, the DeepSeek models tend to be the most challenging as they have, like, the most novel architectural stuff going on, model after model. But every new model has something. Kimi K2 had. Oh, sorry, GLM-5.2 hadAli [00:14:53]: Sparse attention.Philip [00:14:54]: Yeah,Ali [00:14:54]: YeahPhilip [00:14:54]: the DSA.Ali [00:14:55]: Right. Which is brought from DeepSeek.Philip [00:14:57]: Yeah. AndAli [00:14:59]: So you can copy-paste then?Philip [00:15:01]: It kindAli [00:15:01]: I don't know how this works.Philip [00:15:02]: So, like we had to, like, build support for that into our runtime. And you're right, like it is really interesting the way that all of these open source labs borrow from each other. For example, like GLM-5.2 doesn't have vision. So something that, Haley, a guy on our team, if we could take a look at this, he, like, grafted the Kimi vision encoder onto GLM-5.2.Retrofitting Vision into GLM-5.2Ali [00:15:27]: We'll be training the projector.Philip [00:15:28]: Exactly. So if you think about, like, the encoder, there's the encoder, which is the part that looks at the image and turns it into latent information, and then there's the projector which likeAli [00:15:38]: You can say latent space. It's okay.Philip [00:15:41]: And then there's the projector that maps it onto, the model itself, and then there's the model weights. You don't wanna mess with the model weights because you run a chance of making the model dumber at something else for the purpose of giving it vision. So instead, Haley started with just a projector, which is only a handful of millions of parameters.Ali [00:16:02]: That would be, yeah.Philip [00:16:02]: Yeah.Ali [00:16:03]: Can you show the training one?Ali [00:16:04]: Like the way it groksPhilip [00:16:05]: YeahAli [00:16:06]: Very interesting.Philip [00:16:06]: And maybeAli [00:16:07]: That right therePhilip [00:16:07]: Maybe Ali, you should take it from here. You've got a betterAli [00:16:10]: Ooh, double the sandPhilip [00:16:11]: Understanding of this than I do.Ali [00:16:11]: Yeah. You can see, like, he. The way he trained this is really cool. At the beginning, he was training it using just like, “Here's a picture of a mountain. Can you describe what's in this mountain?” And that caused it just like the first, learning walls. Like here you can see this all we're trying to teach it is to translate the encoded. Like it's already taken the encoder from Kimi K. It's taken the image. It'Philip [00:16:31]: Yeah. FrozenAli [00:16:31]: FrozenPhilip [00:16:32]: With adapter.Ali [00:16:32]: Exactly.Philip [00:16:33]: Yeah.Ali [00:16:33]: So the brain is frozen and the eyes are frozen. It's just we're tryingPhilip [00:16:37]: AlignAli [00:16:38]: Interconnect between the eye and the brain, right? So the projector. And so you take the tokens and then he's like, “Oh, can you describe what's in this image?” And he's like, “Oh, it's a mountain,” or it's a person or it's a human, whatever the case is. But that didn't cause complete understanding. So he changed it such that every image was associated with a data set of questions. Like, does this image have a white male? Does this image have birds in the top corner? Does this image have a scientist in it? All of that stuff. And it would have to answer questions correctly. And using not just training on describing an image, but being able to answer question, another question, answer over time. Like you can see the grokking, which is like genuinely insane, that retrofitting vision into a large LLM can learn to that extent. And even for images that it doesn't perform well on, for instance, if you ask it a picture of like Stephen Hawking, “Who is this?” Maybe it doesn't get it, but it will say something like, “This is Albert Einstein.” Like it still understandsPhilip [00:17:25]: Close enoughAli [00:17:26]: That this is a scientist who is a man who has, some significant achievements, all that stuff. So that's like really cool.Philip [00:17:32]: Yeah. So, we've covered Hao Tian before, who the author of the LLaVA paper that did this, a while ago. And I think that's very foundational work for anyone who hasn't done vision work before.Ali [00:17:41]: Same with the CLIP and MetaCLIP, where you go from just captioning to building out questionsPhilip [00:17:47]: RightAli [00:17:47]: Off the image and how much better you can get performance.Philip [00:17:50]: Right. Right. Right. Yeah. But what's, what's so exciting about this is if you look at a model like this. Now, this is a little bit more of a research project. It's not. It got to 56% on MMLU Pro, I think. So not quite frontier. But if you're running this model, you haven't suffered any loss on your GLM-5.2 quality. If you don't have an image, it'll just behave exactly the way it used to. And ultimatelyAli [00:18:14]: Which in the inference code you literally do not include the other part, right?Philip [00:18:18]: Yeah. You would just skip the encoder if you don't have an image input.Ali [00:18:22]: Okay.Philip [00:18:22]: Just confirming.Philip [00:18:23]: YeahAli [00:18:23]: Does it affect a lot on the overall inference side? Like you're not adding much, you're adding a very small vision encoder. These are typically likePhilip [00:18:30]: They're super fineAli [00:18:31]: Less than a billion parameters, right?Philip [00:18:32]: Yeah. It's, - There's a little bit less standardization among vision encodersSwyx [00:18:37]: YeahPhilip [00:18:37]: So the support matrix can be a little bit, sparser. But overall, yeah, it's a pretty, it's a pretty minor component of the overall system. And ultimately what you get out of the system is all of a sudden you have Kimi Vision, GLM weights, and DeepSeek attention all in one model.Open Source Model Grafting and Franken-MergesPhilip [00:18:56]: And that's, I think, a lot of the power and beauty of open source, is that you can take all of these different components and combine them together into a system that's better than anyoneSwyx [00:19:05]: YeahPhilip [00:19:05]: Can be individually.Swyx [00:19:06]: People used to say that you would also do Franken-merges where you would take likePhilip [00:19:10]: YeahSwyx [00:19:10]: Layers from each model.Swyx [00:19:11]: Does anyone do that anymore?Ali [00:19:13]: Well, to your point previously when you were mentioning like, the work that goes into supporting a model when it first comes out, like GLM-5.2 or MiniMax M3 or whatever the case is. Sometimes you do have to like, you do have to switch out some things. Like, for instance, the MiniMax M3 head uses full attention, and with full attention you end up with this like insane bottleneck in spec dec ‘cause you're doing auto-regressive token generation for three tokens, and you're doing this like N squared over all of the tokens that are in your sequence. Your KV cache is like very large because it's not sparse, it's not top K. So we find it better to like, okay, we're gonna replace this, we're gonna replace this layer with a layer from another model that's using like GQA, for instance. And then just with the right training, you can get it to have the same acceptance rate. So it is very possible to retrofit layers from other models and very much needed. If a layer is like inefficient, the training just becomes the challenge, like how do you ensure that you train it properly? Which again to your earlier point is like the mesh between training and inference. As in like you need very good training in order to do fast inference. That's like, I feel like more and more becoming true.Swyx [00:20:21]: Yeah. Anything else on the support side when you say like get it to fully production ready?Loop Detection, Race Conditions, and Non-DeterminismPhilip [00:20:26]: Yeah. I think that there's also a question of just, we can test a model to a pretty extensive degree, but we're trying to get it out quickly and then you see a bunch of other people test it and you get interesting results. There was an issue with, GLM briefly where we had some like mode collapses where it would just output the same token over and over again for certain prompts on certain temperatures. Like once you expose an endpoint to the real world, there's going to be, so many more varieties of things given to it that you're able to, discover and patch things. So it's not just a, day zero process, it's then like for the first week, for the first month, if a model remains popular, like how do you both fix bugs and then continue to push the envelope on performance?Ali [00:21:21]: What do you mean you don't want your model outputting S?Swyx [00:21:24]: Is there loop detection on that stuff, by the way? It still happens like quite a lot, which is surprising.Ali [00:21:30]: We have like we, in our endpoint, like if a model was to output the same token like four plus times, we just cut the generation. We say like, “Oh, sorry, this-- Like try again,” or like we will reprocess the request. ‘Cause we know then, like if it, like if, yeah, it's four times the same token, it's probably collapsed.Swyx [00:21:45]: Yeah. Is there a way to opt out in case I really want that?Ali [00:21:48]: You want that?Ali [00:21:50]: I think there's a way that we have to handle it. I'm not exactly certain, but I feel like in certain models, like when they output something like you can imagine, like a table for instance, and so they want, they wanna draw like 12 dashes and 12 dashes. Yeah, I think there's a way for that to happen. I think we only do it on certain tokens. Like we exclude certain special characters.Swyx [00:22:07]: Yeah.Ali [00:22:07]: So we only do it on like certain like S is the most common almost. GLM-5.2Swyx [00:22:11]: OhAli [00:22:11]: And I think it was DSV 4 as well. Like you'd just have like looping issues where like you literallySwyx [00:22:17]: ItAli [00:22:17]: Just have like S.Swyx [00:22:18]: Yeah. Is there a special, something special about S? No, just randomlyAli [00:22:21]: It just seems to be the one token involved.Swyx [00:22:23]: Yeah. And it'Philip [00:22:24]: Is thereSwyx [00:22:24]: And it's only temperature 0Ali [00:22:27]: NoSwyx [00:22:27]: Even at other temperaturesAli [00:22:27]: Even at like 0.9 or whatever, it will still, it will still collapse.Swyx [00:22:30]: That's weird, right?Ali [00:22:30]: It's, it is an inference problem to be honest, like a software problem. Like oftentimes, the image you run will-- like NVIDIA will release an image for instance, and if we will upstream the changes from their latest TensorRT-LLM image into our stack, we'll find that it fixes it. Or oftentimes this will only happen in an inference engine that you're using like SGLang. But if you were to switch to vLLM, that isn't the case. So it seems to be like an extremely like deterministic software issue and not really a model issue. It's not like a weights problem. Like I'- we'll say like, “Oh, it's a problem with the quant. We did PTQ wrong,” right? But that isn't, that doesn't make sense because the same weights used with a different inference engine does not repeat the problem. And sometimes it's, the kernels that are being used in the backend have like these very subtle sometimes race conditions, where if you were to use this model hosted on one cluster, you will never get this problem.Swyx [00:23:19]: Oh my God.Ali [00:23:19]: But if you host it on a different cluster, you will. And the reason is the KV cache transfer from a node to node in that one cluster is using a slower interconnect than the node to node in another cluster. So that exposes the race, whereas in another cluster it doesn't. So then you end up just like, okay, this model is not gonna be hosted on this cluster. We're gonna host it on, another cluster because that cluster exposed that problem. But then it ends up with like, okay, is it the software? Is it the model weights or is it the hardware?Swyx [00:23:42]: There is a thing about this with temperature 0 still not being deterministic, right?Ali [00:23:46]: Right.Swyx [00:23:46]: Mostly because of hardware. Even at temperature 0 same model, you won't always get the same output.Swyx [00:23:52]: Even-- But I'm surprised by the race condition one because, I thought PyTorch was a graph that like guarantees that you at least, execute things in the right order.Ali [00:24:02]: Well, yeah, true. Like I'm not, I'm not saying that there is. Like well, you have things like PTL optimizations where like you can start a kernel before the end of the previous kernel, and that's like ‘cause you want to do that because there'sSwyx [00:24:12]: It's like pipeliningAli [00:24:12]: Expense. Exactly.Swyx [00:24:13]: Yeah.Ali [00:24:13]: But it'- But you don't do it cleanly. Like you overlap a little bit of the execution. No, it is very possible that the kernel itself, like that one block that is supposed to be running in this instance of time, that kernel itself has a race condition. For instance, like a missing barrier. Like often if you're designing a kernel and you want it to make it to be very fast, if you don't test it extensively, you'll, you'll have certain threads access data points from registers before they've been written to by other threadsSwyx [00:24:36]: YeahAli [00:24:36]: For example, because like your barrier is wrong or your synchronization was wrong. But yeah, like the testing itself is very difficult in those like, andSwyx [00:24:42]: And there's no like borrow checkerAli [00:24:45]: What does that mean?Swyx [00:24:46]: Like Rust. Like the. If you're trying to have like memory safety It sounds like a comparable problem.Ali [00:24:52]: Well, yes, but you're working in CUDA, right, NVIDIA GPUs. Like- You just need a higher level language like modular Maybe that's what modular is supposed to do. I don't know.Quantization Quality and Vendor FidelityVibhu [00:25:00]: How do you see keeping quality of the model? So you talked about all these steps of, okay, you gotta do quantization, train your own speculative decoderAli [00:25:07]: RightVibhu [00:25:07]: Run on different hardware. Looking at other model providers, okay, you kicked off a inference speed race on the consumer end. What goes into keeping quality the same across them, right? Sure, you can run benchmarksAli [00:25:22]: YeahVibhu [00:25:22]: But, like, how do you determine how much quantization are there standards? What goes intoPhilip [00:25:27]: There's a few things on quality. Most inference optimizations are lossless. KV caching, for example. You are just recomputing or preventing recomputing the same values. Speculation, of course, if a draft token is wrong, it gets rejected. The main lossy optimization is quantization. And that really comes down to, number one, data format, number two, which parts of the model you choose to quantize, which layers, and number three, like doing a lot of calibration on the quantized weights, to ensure that you're preserving all the outliers. There's other tricks that you can do, though. A big one is long context, ‘cause one thing you asked at, right at the beginning is, “Oh, what's gonna happen if I send a 200,000 token request in?” So with a long input sequence, you need to, store a lot more information. You need to process a lot more tokens. And so even if a model has a context of a certain length, you might, as an inference provider, choose to build an API with a shorter context length, and of course a full length one as well. Because if someone doesn't need the full million token context, for example, you can get them better performance. I don't know if that's exactly like quality of the model. The way that I think about quality is to what degree are we faithfully serving the original model? If you think of a golden implementation of a model that performs exactly the way the model is designed to perform, I think of quality as how close are we getting to that, 100% fidelity of the model.Philip [00:27:13]: You can also, of course, think about quality from the training side and how do you push yourself past 100%. But when I think about purely inference optimizations, it's getting faster while staying as close to that 100% fidelity mark as possible. And certainly our standard internally is that, like you should not be able to tell the difference between our API and a, official API. I think Kimi in particular does a good job of vendor benchmarking hereAli [00:27:41]: YesPhilip [00:27:41]: Where they haveAli [00:27:42]: They released an actual vendor benchmark.Philip [00:27:43]: Exactly, yeah.Ali [00:27:44]: ‘Cause they accused, some people, Amazon? There was some provider that was not doing very well on Kimi's benchmark.Philip [00:27:50]: Yeah.Philip [00:27:51]: So, with Reflect we probablyVibhu [00:27:52]: This was a long time ago, right?Philip [00:27:54]: No.Ali [00:27:54]: Yeah, like threeVibhu [00:27:55]: They alsoAli [00:27:55]: Four, five months agoVibhu [00:27:57]: This also happened with, I don't remember which model, but they pulled out quite a few, and then they started a whole chart about this. It might have beenPhilip [00:28:03]: Kimi Vendor Verifier.Ali [00:28:04]: Yeah.Philip [00:28:05]: Yeah.Ali [00:28:05]: Yeah, ‘cause you, ‘cause you'd be pissed, right? Like if you'Philip [00:28:07]: Yeah.Ali [00:28:07]: If like if I'm a consumer and I'm using like Amazon's endpoint for instance, and I've used Kimi and I'm like, “Oh my God, like this is bad,” I'm not gonna say, “Oh, Amazon quantized the model in a bad way.” I'm gonna say, “Oh, Kimi sucks.” Right?Philip [00:28:17]: Yeah.Ali [00:28:17]: So it seems like that makes sense.Philip [00:28:19]: Yeah, they care. They care.Vibhu [00:28:21]: Justifiably.Ali [00:28:21]: Yeah, justifiably.Vibhu [00:28:22]: This is probably a stupid question, but just checking, has anything improved from main quantization?Philip [00:28:28]: Yeah.Vibhu [00:28:28]: Like, is quantization always strictly worse?Ali [00:28:30]: Well technicallyVibhu [00:28:32]: NoAli [00:28:32]: It's a lossy. QuantizationPhilip [00:28:33]: YeahAli [00:28:33]: Is a lossy, it's a lossy implementation.Philip [00:28:36]: Speed improvesVibhu [00:28:36]: Speed improves.Ali [00:28:37]: It the number, likeVibhu [00:28:38]: No, I' always look for inverse scaling laws.Philip [00:28:40]: Yeah.Ali [00:28:40]: Yeah.Vibhu [00:28:40]: This is something I learned from Noam Brown, where like things that normally act in one direction sometimes do.Philip [00:28:45]: Well, technically when you run a benchmark, because these models are deterministic, sometimes your,Ali [00:28:52]: YeahPhilip [00:28:52]: NVFP4 quant is like, two basis points higher than yourAli [00:28:56]: No, it's noise. It's noise.Philip [00:28:57]: Yeah, exactly. I'm like, yeah, it's, it's within. That's why I always say within margin of error.Philip [00:29:01]: And I stopped saying that because everyone assumes that what is, well, within some margin of error, we're barely inside of that to the worst, so we're saying. But yeah, sometimes it's just like, gives you a higher output score. But like Ali said, that's noise. To my knowledge, you're not necessarily making the results better. You're just trying to, again, like keep your fidelity as close to 100% to the original model.Layer Selection, KL Divergence, and Better QuantizationAli [00:29:27]: There is, to your point, research that we did on MP. I don't know if you are able to pullPhilip [00:29:31]: YeahAli [00:29:32]: A tweet we did. One of our research interns, Joshua, I think it's a tweet on how we have 20% better quantized GLM-5.2 than NVIDIA. Essentially what we found throughout like this month research is, okay, quantization is a lossy. It's. You're compressing the data from, occupying 16 bits to occupying, four bits, for instance. And so you're losing some information, and you're trying to minimize that. And so when I say that I'm gonna quantize the model, my job becomes how do I find the layers that I can quantize, and how to find the layers to not. For instance, with image models, I don't quantize modulation layers, and I don't quantize out projections because those two are. Like out projection is what you see as the user. Modulation is what the model sees or understands. Right, exactly. And so to his paper, do you have the. It doesn't have the. Yeah. It's a long paper. I don't know if I can findVibhu [00:30:25]: If there's a part to search or it's probably in the thread.Ali [00:30:28]: It's probably in the thread.Vibhu [00:30:29]: Yeah.Ali [00:30:29]: But the long and the short is it is very possible that quantizing more of the model makes the results. Like if I have a model that I quantize layers one, five, and 10, and another model where I only quantize layers one and It is possible that the model in which I quantized more information is going to perform better because the quantization errors have canceled out. And so what Joshua showed in his mathematical proof where he had like a verifier in, is that you can predict which layers are going to have quantization errors that will cancel out with each other, and you choose to quantize those layers. And so the result of doing this mathematical quantization is you end up with a model that's 20% more quantized than another provider, so you get 20% more throughput of it because there's more layers than running an NVFP4, and your quality is better than that other quant because the layers that you chose to quantize have their errors cancel out, like one layer skewed to the right one layer skewed to the left, one layer skewed to the right. Your final logits distribution is more similar to the original distribution of the model, so you have better fidelity. And so the way we proved this was with KL divergence. So instead of just scoring on the benchmarks, we scored the KL divergence between the logit distribution of the quantized model and the logit distribution of the original full precision model, and we showed that with this technique we get. If your probability distribution on the logits which token it wants to select is more of the same as the original model, you're probably gonna end up staying true to the original model. So yeah, so it seems like previously before this, it seemed like the industry was, well, the more you quantize, the worse it's gonna be, ‘cause the more loss you introduce. That's not exactly, not necessarily true. So yeah, doesn't improve it, but can cancel out.Philip [00:31:57]: I think it might be this, but reminds me a good bit about pruning where you can prune off certain layers.Philip [00:32:03]: But very interesting. Didn't know this was a whole paper you guys put out.Ali [00:32:06]: It's. Fun fact, it was originally 72 pages, this paper, and then we decidedPhilip [00:32:11]: WowAli [00:32:11]: We can't tell. We couldn't release it. So it's now 45.Swyx [00:32:15]: Still 39 pages, so very substantive. We talked about evals and all these things and, like what's possible in terms of speedup? Like it's like probably like the numberInference Speedups and BenchmarkingSwyx [00:32:25]: Thing that people do wanna care about, and it's something that you wrote about in your post. Like official API is 70 tokens per second, and you push it up to 90. Is that like a normal thing?Philip [00:32:36]: So what's cool about working in inference, the reason that I think inference is going to be a useful place to do engineering for a long time, is that if you look at highly optimized domains like, say, finance, if you're in finance, you measure how much better you got in basis points. It's like, “Oh, I got five basis points better, like twentieth of 1% better,” that's huge news because everything is so optimized. When we publish optimizations, it's 20%, it's 100% it's 200%. So there's still probably like a lot further to go, honestly. Like you'll, you'll know that inference is pretty much solved when researchers start publishing about how they got 1% faster at something.Swyx [00:33:19]: Which by the way, because I am from the finance background, in the ‘70s, that was the margin at the time. When you did quantitative finance research, you would findAli [00:33:27]: And like 20%, tens of percent.Swyx [00:33:29]: That's. Yes.Philip [00:33:29]: Yeah.Swyx [00:33:30]: And now it'Philip [00:33:31]: Tiny fractionsSwyx [00:33:32]: For those people interested, look up Andrew Lo's paper. He had a really interesting illustration of quant, stat arb, distribution, narrowing down from like those kinds of 20% differences in the ‘70s, down to nothing today, which is very cool.Philip [00:33:48]: Exactly, and we're at the beginning of the same type of thing. Now benchmarking is hard. I think anyone will tell you that, and benchmarking provider speeds is hard because there's so many variables that go into it. What hardware are you using? How much load do you have on the system? What's the exact nature of the prompts and input and output sequence lengths? All that stuff. But overall, when you start stacking these improvements, you're looking at multiples. You can look at it. The most common form, of course, is TPS, tokens per second, which is bad naming by us in the industry, ‘cause there's two tokens per second. There's tokens per second, the throughput number, and the latency number.Ali [00:34:31]: TTMT, yeah.Philip [00:34:32]: Like total tokens per second out of the, out of the GPU as a throughput number. Most people only care about tokens per second as the latency number, which we should call ITL, intertoken latency, but we don't.Philip [00:34:44]: Anyway, so you can imagine a standard API without many optimizations for a 1 trillion parameter model operating somewhere in the 30 to 50 tokens per second range for reasonable traffic profile. And we generally see the goal of, pushing to 10X that. But, not necessarily day zero, but by stacking enough optimizations, if you have, say like four optimizations, each of which doubles performance. Or sorry, three optimizations, each of which doubles performance, then you stack that up, that's an 8X gain. That's the order of magnitude that we're working with in this space. We're trying to make things substantially faster, not just go from like 70 to 90.Swyx [00:35:38]: Are you saying you've. You have done that?Philip [00:35:40]: So let's say you have as a reasonable baseline, 30 or 40 tokens per second. You can achieve 10X that. So like on GLM-5.2, if you run it unquantized, perhaps on H100s even, and you're just using an off-the-shelf inference engine with no particular optimizations, no speculator, nothing extra around like KV routing, no disaggregation, you're, you're probably, yeah, looking at that like 30 to 40. You think that's like a reasonable baseline?Swyx [00:36:12]: Right. Right.Philip [00:36:12]: To get to something like 10X, there's a lot of trade-offs that you're making. If we're running at more like a 300, 400 tokens per second range, you are using the best hardware possible. You have a optimized speculator. You have done all of your quantization work. You are Seeing a pretty high cache hit rate. You are running with a reasonably small batch size and a parallelism configuration that is tuned for latency versus throughput, but it is possible. So the spreads that you see if you, like, go on artificial analysis or you go on OpenRouter and you look at, the worst provider to the best provider, oftentimes can hit that range. 10X is of course very aggressive. It's oftentimes maybe more of a four to six times improvement. But that's the performance that makes us really excited, is when we can get these huge gains, not just go from 70 to 90 tokens.Stacking Optimizations: NVFP4, Speculation, and DisaggregationAli [00:37:19]: It's also, like, hardware dependent. Like, ifPhilip [00:37:20]: YeahAli [00:37:20]: If you have a thing where you're serving it on just, like, a node of H100s and then you throw, like, you shard the model across, like, four nodes of B200s. Like, you can definitely increase the speed with just throwing more hardware at it. Like, normalizing for the same exact hardware and the same number of GPUs.Philip [00:37:35]: Yeah. Then you're looking at, like, a two to 4X improvementAli [00:37:38]: Right. RightPhilip [00:37:38]: Depending on the inference optimizations. So yeah, it's. Some of it's, what's the call, and some of it's who's the driver.Vibhu [00:37:46]: If you break down the two to 4X, say the example is run GLM-5.2Ali [00:37:51]: YeahVibhu [00:37:51]: On B200sAli [00:37:53]: YeahVibhu [00:37:53]: Single node, right? What's, like, the cost trade-off for effort to get, like, the last bit of juice out versus what should people just think of, right?Ali [00:38:01]: Spectre quantization. Yeah.Vibhu [00:38:03]: Spectre quantization.Ali [00:38:04]: That's, that's, that's like 95%. LikeVibhu [00:38:06]: And how far does that get you? And how easy is that for the average person to do? So say right I wanna throw the weights of GLM-5.2 on a node of B200s, how easy is it to find speculative decoder- decoder model or already quantized model? How much work goes into it?Philip [00:38:23]: If you're doing it up front, it's quite a lot of work. If you're doing it today, there's going to be people who have published things that you can just, you can just grab some NVFP4 weights. You can grab a speculator. Yeah, if we're thinking about, like, what are the 2Xs we're stacking, going from, BF16 to NVFP4 is, it's not quite a 2X, right? It's like. I think it's about, like, 30 to 40%, from 16 to 8, and then another 30 to 40% multiplied from, 8 to 4. So that doesn't quite get you a 2X, but, like, roughly a 2X. Speculator, roughly a 2X. Disagg on top of that if you're able to get enough hardware and put enough traffic through it, another roughly a 2X. And then you add in some, double-digit percent increase from having just a better runtime with, the latest kernels and stuff behind it. And that's how it stacks up.Ali [00:39:21]: YeahPhilip [00:39:21]: So building each of those, like, building the, quantized weights is, for someone who really knows what they're doing, hours to days of work. Building the speculator, again, like, hours to days of work. And the, disagg setup, hours to days. Well okay, but like once you haveAli [00:39:39]: Once set up. Once set up. YeahPhilip [00:39:40]: Yeah, getting disagg working for the first time, I'm saying, of course, is very difficult.Philip [00:39:44]: The marginal implementationAli [00:39:48]: Like, if you're just grabbing, like if you are a person, like just a normal consumer who has access to, like, a node of B200s and you're wondering, “How can I just host it myself?” You don't need to quantize the model yourself. There's always gonna be, like, an open source quantized checkpoint. NVIDIA's gonna push one out if no one else does. You. Usually, the providers will have their own spec dec that they've trained as well. You don't need to train your own spec dec. You can just use that as well.Philip [00:40:09]: Yeah. Like, GLM-5.2 has its own MTP.Ali [00:40:13]: Right. Right.Vibhu [00:40:14]: What's multi token prediction?Philip [00:40:15]: Yes.Ali [00:40:16]: I'm justVibhu [00:40:16]: Can you explain that?Ali [00:40:16]: I'm just an expert.Ali [00:40:18]: I can do it for you in case I get it wrong?Vibhu [00:40:20]: No.Vibhu [00:40:21]: Yeah, you should correct if we're wrong, but their multi-token prediction can be used for self-speculative decoding.Ali [00:40:27]: I'm not sure. I'm not gonna correct that.Vibhu [00:40:28]: Okay. I'm semi-confident in thatAli [00:40:30]: Okay. YeahVibhu [00:40:30]: But someone can check. But it's useful to paint the story of, okay, not just the average person, but say a company wants to switch from serverless inference I wanna throw this up on. I wanna rent some GPUs, throw it up. These are the steps you take to do significantly faster than just put it behind vLLM.Ali [00:40:48]: Right.Vibhu [00:40:49]: I was waiting for a mention of Dynamo.Vibhu [00:40:51]: I feel like, that's supposed to be the baseline that you measure against.Dynamo, KV Routing, and Disaggregation ToolkitsPhilip [00:40:55]: I would think of Dynamo as less of a box system and more of a toolkit for building with. So when we talk about doing aware routing, when we talk about doing KV offloading, when we talk about doing, PD disaggregation, Dynamo fundamentally is. By the way, Dynamo is an open source library from NVIDIA.Ali [00:41:17]: We've done a pod with KylePhilip [00:41:18]: OkayAli [00:41:19]: Kyle Cranin.Philip [00:41:19]: Cool. So then your listeners know then that it supports all the different inference frameworks. And it is multi hardware, which is interesting.Ali [00:41:28]: But it's just a router, it's not like an optimizer layer.Philip [00:41:30]: Yeah. All it does, like, what Dynamo is good at, it is a library for moving information around your cluster, around your hardware. So if you have, KV cache on one place and you need it to be somewhere else, Dynamo coordinates NIXL for you to move that around.Philip [00:41:49]: That doesn't mean that, like, out of the box, you just say, “Pip install Dynamo,” and then you get, like, a massive performance speed up. It's more of a developer toolkit.Ali [00:42:01]: Yeah. I would have said it would. It comes with a set of defaults that you can then swap out.Philip [00:42:06]: It does. If the industry at large, I think, was, like, rolling out all of these deployments, standard, then I think it would be, like, a credible baseline. But, we've got to, we've got to benchmark against, like, what we're seeing in the wild.Speculative Decoding Methods: Medusa, EAGLE, n-Gram, and Spec-SpecVibhu [00:42:23]: I did wanna talk a little bit more about PD disagg, because that is probably, like, number three after quantized and speculative decoding. In your book though, I was just gonna pull out the book.Philip [00:42:31]: Yeah.Vibhu [00:42:32]: Like section 522 on Medusa, 523 on EAGLEPhilip [00:42:35]: YeahVibhu [00:42:36]: 524 on gram.Philip [00:42:37]: It's 55, would be disaggregationAli [00:42:42]: Yeah. Well, no, I just wanted to dwell a little bitPhilip [00:42:44]: YeahAli [00:42:44]: The other. Like, so what do you choose to include? What do you choose to not to include? Because there was all these other techniques.Philip [00:42:51]: Yeah.Ali [00:42:51]: Are these still relevant? Because I think they came out, like, a year and a half ago maybe.Vibhu [00:42:55]: Medusa is quite old.Philip [00:42:56]: Yeah, Medusa's old.Ali [00:42:58]: It was old.Vibhu [00:42:58]: But is it in the book as a good, here'sPhilip [00:43:01]: BaselineVibhu [00:43:01]: Baseline vanilla understand it?Philip [00:43:02]: Like you should know this.Vibhu [00:43:03]: Like I read the paper, I'm like, “ it makes so much sense.”Philip [00:43:05]: Yeah.Philip [00:43:05]: So with the book, I had a couple goals. One was to give people just a working vocabulary for the space as a whole, and the other was to give them some intuition about how each of these techniques works. As I mentioned in my AI Engineer talk, which is the first public addendum to this, the speculation space has moved much faster than everything else. So yeah, even at the time that I wrote the book Medusa, I very much included as a way for people to understand how the space evolved rather than what the most modern technique is. And now of course, there's DFlash, dSpark. There's, there's newer techniques even than EAGLE, although EAGLE is still very commonly used.Ali [00:43:51]: SpecSpecta.Philip [00:43:52]: Yes. Speculative decoding.Vibhu [00:43:54]: What canAli [00:43:56]: Oh, it's a paper by Tri Dao and it's like, it's doing speculative decodingVibhu [00:44:00]: HuhAli [00:44:01]: For the speculative decoder.Philip [00:44:02]: Oh, in spec- oh my God.Ali [00:44:02]: It's literally just an another. It's like, yeah, that's the most simple way to explain it, and it seems like he got trivial speed ups there. But it seems that the complexity with training, it's almost like in our mind at least, it's almost as complex as training GANs. Like it's like a very delicate balance and oftentimes you, it's just but yeah, it's literally speculative decoding on speculative decoding.Vibhu [00:44:21]: Speculative.Ali [00:44:22]: Yeah. We saw this paper.Vibhu [00:44:24]: It's interesting, right?Ali [00:44:24]: Yeah.Vibhu [00:44:24]: I wouldn't even expect it to be very particular to train, I wouldAli [00:44:29]: Right.Vibhu [00:44:29]: The naive part of me is like, okay, train speculative decoder.Ali [00:44:32]: But like, and it makes sense, like the whole idea of speculative decoding is you. It's like, it's like almost like the iPhone auto predict version but for a normal model, right? Like you're just, you're just, generating three tokens and you're like, okay, I'll do prefill on them. And so you save those three turns for your original model. Now your speculative decoder is doing three turns of auto regression, so why not just have an even smaller model?Ali [00:44:53]: The other question there is what are the size of speculators? So say forPhilip [00:44:58]: Right. It's like a billion parameters.Ali [00:45:01]: Like for MiniMax, it's. Yeah. It's like one layer. It's like one 60th of the original model usually.Philip [00:45:06]: Yeah. I think we should do a paper when we get back to the office.Philip [00:45:10]: SpeculativeAli [00:45:11]: SpeculativePhilip [00:45:11]: Decoding.Ali [00:45:13]: No, it's, it does seem like how, when do you stop? But then it also seems like if you're able to train spec-spec decode for instance, right? Like if you're able to have a small model that is accurately predicts what the intermediate speculator is gonna predict, that is able to predict what the original target model's gonna predict, then why not just use that smallest model directly, right?Vibhu [00:45:34]: Yeah. This isAli [00:45:35]: Like it seems likeVibhu [00:45:35]: Adjacent to the routing problem.Ali [00:45:36]: Right.Vibhu [00:45:36]: Yeah.Ali [00:45:36]: Right.Philip [00:45:37]: The thing with speculators is one of the practical constraints on using them is that you do have to run a small model on the same hardware that you're running the big model on. There is a orchestration and resource competition problem inherent in that, and that is one of the constraints on speculation in general, is that draft tokens cost resources to create and cost software complexity to manage. And so if you have like infinitely recursive speculators, you add in quite a bit of that complexity on the actual implementation within the inference engine as well, not just in the training process.Vibhu [00:46:17]: I was gonna say, I would wonder if you could do similar, like distillation and pruning of, it's the same thing, it's just a model. Can we not just distill a lot of the weights, quantize the speculator, out of my domain? The question that also comes up is, this is all for big server workloads, right? How much of this applies to, say I have this MacBook, I wanna run Gemma really efficiently. Similar problems, not the same?Local AI vs. Data Center InferencePhilip [00:46:45]: Pretty different. I talked to Selo, about this on his podcast a couple weeks ago. The difference between inference engineering for the data center and for production workloads versus inference engineering for local AI, is that we start with fundamentally like different constraints and different goals. With local AI, it's how do I fit this model onto my hardware and then make it less dumb? And with data center influence, it's how do I load this model and then make it less slow? And we care about less dumb, and they care about less slow. But the local AI inference engineering ecosystem, I think has a lot for us to learn from in the data center space. They are experts in various forms of quantization, including dynamic quantization that we just don't touch, in the pruning, in the distillation, in the, layer removal. There'Ali [00:47:42]: Layer removal matters less.Philip [00:47:43]: Yeah. There'Ali [00:47:44]: No one loves pruning really.Philip [00:47:45]: Yeah. Well, but the, but they doVibhu [00:47:46]: Which is surprising, right? But that's, that's a whole different thingPhilip [00:47:48]: Just to fit something on the laptop.Ali [00:47:50]: Right.Philip [00:47:50]: So yeah, it's a, it's an interesting, it's an interesting space. Not necessarily that like their techniques make sense for us to do in the data center, because we have different resources and different goals, but more that the process as well as the openness of that field is something to, admire.Ali [00:48:12]: Yeah. Like to your point, like, certain optimizations that would. Like for instance, Turbo Quantum Sharper, like it made such huge hype on that and we did like a whole deep dive on Twitter and like said, what is it? How does it work? Why is it good or not? And it took off and it was implemented on local devices because your memory bandwidth is so slow on like a MacBook, for instance. But try putting the same thing on like an NVIDIA GPU on a B200 Turbo quant would not be. Like, it would not be used. Like, NVIDIA - Like, NVIDIA made it clear that this is not a good optimization, and we've seen it firsthand where the overhead of doing dequantization, quantization of, in the kernel itself with turbo quant kernel, each end is much slower than the time that you save from doing the bandwidth. ‘Cause on the B200s, you have like 3.5 terabytes per second. You don't need decrease the storage that much. You don't need to do, FP4 KV cache. You don't need to use a requant. There's, there's, there's better optimizations to be made. But on Edge devices, it's extremely important, it's extremely useful. So, seems to be, like, different optimizations there, but then they're all uniquely combined with like all you wanna quantize the model, you wanna do speculative decoding, like certain common prefixes with bothPhilip [00:49:18]: Principles.Ali [00:49:19]: Yeah, exactly. Exactly. Exactly.Philip [00:49:20]: They also do a lot of work on, model parallelism, especially over, heterogeneous topology, where you have, some sparks and they are wired together with, Ethernet, DGX sparks.Ali [00:49:35]: Yeah, this is the Exo Labs guys.Philip [00:49:36]: Yeah. You have, a nu

David Smith explains his book “Wokicide,” arguing that “woke” (critical social justice theory rooted in critical theory and postmodernism) persists in universities and schools because education lacks quality control, not because of politics. He proposes applying ISO 9001 and HACCP-style quality assurance to K–12 and universities: validated curriculum specifications, independent expert panels, hazard analysis, audits (scheduled and targeted), corrective action, and continuous improvement. A central Workplace Improvement Notice (WIN) system would let staff and even parents file tracked complaints with guaranteed responses, replacing DEI/unconscious-bias training with “deprogramming” modules and prioritizing evidence and accountability. Smith says QA would stop unvalidated ideological drift and is affordable by redirecting existing DEI-related spending.00:00 Intro and Two-Part Talk00:58 Why Woke Persists01:30 Education Lacks QA02:10 Validation Over Ideology04:53 Defining Woke Origins06:35 From Civil Rights to Overreach07:43 Flawed Woke Reasoning10:02 How Woke Spreads11:16 Equity Outcomes and Activism13:33 Deconstruction Playbook17:50 Woke Hall of Fame21:39 Perfect Storm in Education25:42 QA Solution Framework27:41 ISO 9001 and HACCP29:42 Authority and Adoption30:55 Four Phases Implementation33:35 Validation and Hazard Analysis34:47 Audits Monitoring Corrective Action37:09 Aggressive Feedback Loops39:05 WIN Notice Explained41:41 Curriculum Content Validation43:12 Audits in K-12 Schools44:53 K-12 QA Wrap Up45:47 Universities as the Source47:29 University Validation Hurdles50:30 University Auditing Red Flags51:58 Objections and Pushback57:12 Failure Modes and Fixes59:39 Cost and Staffing Reality01:02:08 Closing Q&A and Next StepsAmazon Kindle version: Wokicide: Pest Control for Education: https://a.co/d/0d0YeApM========Slides, summaries, references, and transcripts of my podcasts: https://tomn.substack.com/p/podcast-summariesMy Linktree: https://linktr.ee/tomanelson1

Ben Lorica speaks with Helen Gu, CEO of InsightFinder AI and professor at North Carolina State University, about why reliability is becoming a central challenge for enterprise AI. They discuss AI incident response, monitoring agents in production, domain-specific small language models, causal inference for operational data, and why the “last 1%” of accuracy and reliability is often the hardest part of deploying AI systems. Subscribe to the Gradient Flow Newsletter

In Elixir Wizards S15E04, Charles Suggs and Emma Whamond are joined by Somtochi Onyekwere, a software engineer at Fly.io and contributor to the Corrosion distributed database project, to talk about distributed systems, infrastructure resilience, and the growing fragility of centralized cloud platforms.   We discuss what recent outages across major providers reveal about modern infrastructure and why more teams are starting to rethink assumptions around reliability, failover, and system design. Somtochi explains how Fly.io approaches geographic distribution, eventual consistency, and replication across nodes, along with the trade-offs that come with building systems this way.   The conversation explores CRDTs (Conflict-free Replicated Data Types), consensus, split-brain prevention, and what actually happens when distributed systems fail in production. We also talk about testing strategies, rollback planning, property-based testing tools, and how teams can reduce blast radius when things inevitably go wrong.   Along the way, we discuss AI infrastructure, sandboxing AI agents, and how newer workloads may add pressure to already centralized systems. The episode closes with practical advice for developers who want to build more resilient applications without over-complicating their architecture. Topics Discussed in this Episode: Corrosion and distributed database replication Centralized cloud fragility and recent outage patterns Distributed systems versus traditional cloud architectures Multi-region deployment strategies for Phoenix applications CRDTs and conflict resolution in distributed systems Eventual consistency versus strict consistency tradeoffs Consensus, leader election, and split-brain prevention Testing failover and recovery scenarios Property-based testing and Antithesis Rollback planning for database schema migrations Reducing blast radius through system isolation Health checks and blue-green deployment strategies Fly Proxy request routing and replay behavior Cross-region synchronization and replication challenges Single points of failure inside “redundant” systems Backup restoration testing and disaster recovery planning Network partitions and failure handling in production Infrastructure monitoring and operational visibility AI infrastructure workloads and operational strain Sandboxing and securing AI agents Sprites and AI workflows at Fly.io Latency improvements from geographic distribution Distributed systems tradeoffs in real-world environments Transitive dependency failures across cloud providers Practical resilience strategies for modern engineering teams Links Mentioned: https://fly.io https://github.com/superfly/corrosion https://docs.gitops.weaveworks.org/ FluxCD https://fluxcd.io/ Fly.io Stateful Sandbox Environments https://sprites.dev/ Cloudflare Workers AI Inference Platform https://www.cloudflare.com/products/workers-ai/ “An AI Agent Just Destroyed Our Production Data. It Confessed in Writing” Twitter post from PocketOS founder: https://x.com/lifeof_jer/status/2048103471019434248 Oct 2025 AWS Outage https://www.theguardian.com/technology/2025/oct/24/amazon-reveals-cause-of-aws-outage Dec 2025 Cloudflare Outage https://www.theguardian.com/technology/2025/dec/05/another-cloudflare-outage-takes-down-websites-linkedin-zoom July 2025 Crowdstrike Outage https://www.ibm.com/think/news/recent-crowdstrike-outage-what-you-should-know March 2026 Stryker Cyber Attack https://www.stryker.com/us/en/about/news/2026/a-message-to-our-customers-03-2026.html https://aws.amazon.com/ https://cloud.google.com/ https://azure.microsoft.com/en-us https://fly.io/docs/elixir/ CRDTs!! https://smartlogic.io/podcast/elixir-wizards/s13-e03-local-first-liveview-svelte-pwa/ https://antithesis.com/docs/resources/property_based_testing/ https://hex.pm/packages/proper

The future of war has been evolving before our eyes in Ukraine, yet the west still plans to fight the last war. In this special episode, guest host Noah Smith (@noahpinion) and Brandon Anderson sit down with Yaroslav Azhnyuk (@YaroslavAzhnyuk), a serial tech founder who went from building PetCube to founding The Fourth Law, one of the world's most advanced AI-guided drone companies. Over two hours we cover the technology, tactics, and geopolitics of drone warfare, and why the modern battlefield has already left the West behind:* Yaroslav's personal history and the Ukraine war [00:01:04 – 00:14:01]* The modern drone tech stack: why FPV drones are the new god of war, the future of the rifleman, fiber optic vs. AI, five levels of autonomy, and the eight dimensions of the autonomous battlefield [00:14:01 – 01:05:13]* The geopolitics and economics of drones: China's manufacturing advantage, the drone race, Western defense readiness, countermeasures, and why the gap is widening [01:05:13 – 01:58:57]For those looking for Noah Smith's commentary, it really gets going around the 00:51:31 mark.Yaroslav Azhnyuk / The Fourth Law:* X: https://x.com/YaroslavAzhnyuk* LinkedIn: https://www.linkedin.com/in/yaroslavazhnyuk/* The Fourth Law: https://thefourthlaw.aiNoah Smith:* Substack: Noah Smith * X: https://x.com/noahpinionTimestamps00:00:00 Cold Open: China's 4 Billion Drones and the Cameras-to-Explosives Pipeline00:01:04 Introduction: Brandon, Noah Smith, and Yaroslav Azhnyuk00:05:41 From Tech Entrepreneur to Defense: PetCube, Brave One, and the D3 Fund00:10:42 The Ethics of Building Weapons: Dual-Use Technology and the Wolf at the Door00:14:01 The Tech Stack: Cameras, Autonomy Modules, Interceptors, and a Semiconductor Fab00:18:47 Fiber Optic vs. AI: The Radio Horizon Problem and $32/km Cable00:25:32 FPV Drones: The New God of War — 70–80% of Frontline Casualties00:28:28 The Five Levels of Drone Autonomy: From Terminal Guidance to Full Autonomy00:41:37 The Eight Dimensions of the Autonomous Battlefield00:45:32 AI Safety and the Morality of Autonomous Weapons00:51:31 The End of the Rifleman? Noah's 2013 Prediction vs. Battlefield Reality01:05:13 China's Manufacturing Advantage and Western Vulnerabilities01:24:21 Policy Advice for Western Defense: Defense Valley and the Widening Gap01:32:54 The Drone Race: Who's Ahead, Category by Category01:41:57 Countermeasures: Shotguns, Jammers, Lasers, and Fishnets01:58:19 The Wedding and Final Takeaway: Be Prepared for WarTranscriptCold Open: China, FPV Drones, and the New Warning SignYaroslav [00:00:00]: Think about this. Last year, Ukraine produced 4 million FPV drones. Ukraine is not the most industrious nation in the world. China can produce 4 billion of these FPV drones.Noah [00:00:10]: Would you say that right now China is now the supreme conventional military power on Earth, given its ability to manufacture and deploy drones in the quantity and quality that you just described?Yaroslav [00:00:20]: I don't think we have all the information to claim that but we cannot count it out, and that alone should be a big warning sign. As I say, at some point in my life I went from making cameras that fling treats to pets to cameras that fling explosives to the occupiers. So that's the short story. And when you think about what your nation, what your patriots are going through, you realize that's the only morally right thing to do is to fight back, and it is immoral not to fight back, and then the choice becomes very clear.Introduction: Yaroslav Azhnyuk, Petcube, and the Last Flight into KyivBrandon [00:01:04]: Welcome to Latent Space. I'm Brandon. I normally do science podcasts, but today we're going to do something a little bit different. I'm joined by Noah Smith of Noahpinion on Substack and Twitter. And he has lots of interesting things to say about drones. And as a guest, we have Yaroslav Azhnyuk, founder of The Fourth Law and several other, drone-related startups. To get started, it is February 23rd, 2022. You are running a pet startup. You're connecting pets with their owners. Let's go in just a little bit of background. How did you get started in tech, and what were you working on before the Ukrainian war started?Yaroslav [00:01:50]: Good to be here. Thank you. On February 23rd, late in the evening, 11:00 PM Kyiv time, my wife and I landed in Kyiv. Actually, then she was a fiance. We came from Lviv, where we were looking at a church, where our wedding should have taken place. And we got into this cab ride from the airport to our home, and the driver was like, “You crazy. Like, everyone's leaving Kyiv. Why do you come?” We're like, “What? Nothing's going to happen. Dude, chill.” And then obviously, eight minutes later, or eight hours later, the bombs fell in the city. It was quite surreal. We probably landed on the last flight that landed in Kyiv, or one of those last flights. My background, I'm a tech guy. Studied applied mathematics in Kyiv Polytechnics, born and raised in Kyiv. My parents are old PhDs from academia, and grandparents too. Like, everything, from linguistics to nuclear physics. And I'm an entrepreneur, so I've built a bunch of companies. Petcube is the one you were referencing. So I lived in San Francisco 2014 to 2020, building Petcube, which is one of the leading, pet device companies in the world, selling lots of pet cameras. And then, yeah, as I say, at some point in my life I went from making cameras that fling treats to pets to cameras that fling explosives to the occupiers. So that's the short story.February 24th: Leaving Kyiv as the Invasion BeginsNoah [00:03:28]: February 24th, I guess a few hours after you, go to check out your wedding chapel, what do you do?Yaroslav [00:03:37]: We had a plan for this situation. So my parents and family live in Kyiv, and we're like, “Okay, this has actually started. The worst has, come true.” And so we basically packed our belongings and got in the car and spent 17 hours driving west. And that was pretty sure most people in our audience watched at least one apocalyptic movie in their life, so that was exactly like that. Like, felt exactly like that. Missiles are falling. Like, there was smoke in Kyiv. Like, my dad and I went, like, to central part of the cities. It's probably, likeYaroslav [00:04:20]: 800 meters from presidential office, to pick some stuff up at his workplace. Because he's, like, the head of an academic institution, so he had to get some of the things with him. And super surreal. Like, the streets are empty. Like, the gas stations are out of gas. Like, we found some gas station. We didn't have, like, spare canisters with us, so we're like, We figured out, like, the car was diesel, so like, we figured out, if it's diesel, you can actually store it in plastic, canisters, and we bought some window wash for the cars. We poured it out of the canisters, and we poured the diesel into that. Yeah, so it was like that. And then, like, helping friends get out, like my friend and his dog. Like, we found Like, my brother was also, like, riding in a separate car. We found a place for my friend who didn't have a car. It was like, yeah, it was like, totally surreal. And we didn't know of course, and you didn't know this will last for so long. You didn't know whether Ukraine will be able to defend Kyiv. And it was like, yeah, very little information and very little insight into future.From Pet Cameras to Defense Tech: Building for Ukraine and the Free WorldNoah [00:05:42]: What are your thoughts with regards to how do you, defend, Ukraine? So you eventually start building drones Like, what is the process to get from there from where you were building, devices that connect owners with pets to building drones, and what other things did you do to help the war effort in the process?Yaroslav [00:06:07]: It's definitely non-trivial, right? Like, I didn't go, to I didn't get any, like, military education when I was a student. Like, normally, in Ukraine, you would, you would go to like, this military school even if you're getting higher education in any other, sphere. I decided to skip that which is like, an unusual way to go. And I never thought that I will be somehow engaged in a war effort. Like, what is war? Of course, wars are over. It's the end of history. So one thing you got to understand about, like, many Ukrainians and like, I guess, it's also true about most of the people I met here in the US, that your who you are in terms of your nationality is a big part of your identity. So when that gets under attack, it's something deeper than just the country you live in gets under attack, right? And I Day one, I figured I'm going to I'm going to fight back with everything I can, right? But I didn't think on day one that I'm actually going to do, weapons. And a bunch of things. We were reaching out to a number of American, congresspeople and senators, and basically advocating for support of Ukraine, for voting for lend lease, which has happened in May 2022, but didn't actually work as expected. We helped start, Brave One, which is now a very important defense innovation cluster, sort of like a DIU here in the US. We helped start, a fund called D3. It's like, it was started or co-started by Eric Schmidt, former CEO of Google. So a bunch of these odd things, but then eventually I was like, “Okay,”by 2023 it was obvious this thing, A is going to last a lot more time, and B, that the whole world is shifting and that there's going to be a new arms race, that the warfare is redefined by drones as platforms. And for the first time in history, you have a platform that is software defined, that can increase your battlefield capabilities, in a in a step change just overnight. So it's like if you were able to push a software update and get all of your Roman legionnaires a new helmet? That has never been possible before. It's the first time in the history of war this is possible. So all of that and many other things like, supply chain fragilization, and the impact that AI is going to have on all of this all these things have become evident to me in 2023, and it's like, “Okay, I should do what I do best, or what I know how to do best, start a tech company, and sort of leverage the global techno capitalist machine, to provide, defensibility to Ukraine and the free world.” So that's literally the mission of the company, increase defensibility of Ukraine and the free world. And then there was some sort of soul-searching and like, asking yourself. It's like, “Okay, am I Actually, I know nothing about weapons. Am I actually, like, ready to make, things that other people use to kill other bad people?”Yaroslav [00:09:36]: When you think about what your nation, what your Compatriots are going through And think about all the terror of places like Bucha, the occupied cities in the east and south, the abducted children, the raped women, all the economic damage that's being done, and the intention to destroy a whole nation, to genocide the people of Ukraine, you realize that's the only morally right thing to do is to fight back, and it is immoral not to fight back. And then the choice becomes very clear. And look, we're just passing the ammunition. We're not doing the actual job. The actual fighters and defenders and heroes are people in the armed forces. We're just support.The Moral Question: Weapons, Responsibility, and Fighting BackNoah [00:10:33]: I have so many questions. Actually, I know you seem to have a question. Do you want to ask anything?Yaroslav [00:10:38]: No, I'm just listening. Go ahead.Noah [00:10:40]: I do want to talk about, some of let's say, the moral issues, like you just said. You endYaroslav [00:10:50]: I think there are no issues there.Yaroslav [00:10:52]: What would an example of a moral question be in this case?Noah [00:10:55]: No, I mean Okay. As you just said, you are creating the tools, but others are using them.Noah [00:11:05]: I was maybe thinking of having this conversation later, but one of the questions is like, is it actually you are going to be building them for your homeland, which you are building it for your homeland, which is I think, very a strong morally defensible position, but this technology is not going to stay with you, right?Noah [00:11:26]: This you will probably be selling these to other people Yeah. So the future is really where the moral issues may come into playYaroslav [00:11:38]: The this question becomes, easier and more complete if we ask this not about a particular technology or particular weapon, if we think that this question actually applies to any kind of technology Right? So -Knife or fire. You can use knife to do surgery and save people's lives, or you can use it as a weapon to take people's lives.Noah [00:12:06]: Cut tomatoes, too.Yaroslav [00:12:08]: Cut tomatoes too.Noah [00:12:09]: Yes, knife.Yaroslav [00:12:09]: That's helpful.Noah [00:12:10]: In Japan, sword and knife, they, call the same word.Yaroslav [00:12:14]: It's like, it's with any technology. Large language models, right? Look at how powerful they are and yet they're available to anyone in North Korea or in Russia.Yaroslav [00:12:29]: That's one side of the argument. The other side is As a maker, what is your responsibility for how the tools you're creating, will be used? There's definitely some responsibility, right? Then How should the decision process look like? Should you, like, try to calculate all the possible scenarios before starting to work on something? Or do you create something that is needed now to save people's lives, and then think about, addressing the unwanted edge cases later? In ideal world where there's like, or okay, it's not ideal world. In a mythical world where there is some one governing party and it gets to decide everything, and there is no other country, that can, decide on their own, you could say, “Well, we need to calculate for all the consequences, and only then, maybe build this building, by replacing this park because, maybe we need this park in the city,”right? So that kind of situation. But when you're in a situation where you're in a forest, in front of a wolf, you first going to deal with the wolf that wants to eat you, and then you're going to go consult Greenpeace. So that's kind of situation that Ukraine is in.The Fourth Law, Odd Systems, and Ukraine's Drone StackNoah [00:13:59]: Enough. Because this is a tech podcast, I did want to spend some time talking about, sort of the tech in that you've developed and what you've been working on. So can you explain, I guess, first of all, like, the problem that you were trying to solve from a technical standpoint? And I think, and then maybe, like, go into some of the solutions and some of the design process that led you from designing, little laser-guided, guiding lasers with a with an iPhone versus Having drones.Yaroslav [00:14:34]: Like, it so happened, that my partners and I, we sort of So I started one company called The Fourth Law, and its goal was and is to Make, massively scalable on-drone autonomy. And then In parallel with that together with my, Petcube co-founders, partners, and friends, we started another company called Odd Systems Which, was focused on making thermal cameras. Cameras, thermal cameras are seeing thermal radiation and are used to see at night. And we're now sort of those companies are getting closer and closer together and we're probably going to merge them. And this group of companies is currently the leading, team in on-drone AI and thermal imaging on the Ukrainian battlefield, and Likely one of the leading, if not the leading in the world. So We have these, like, three sort of business units, which are cameras, drone autonomy, and drones. So the cameras and drone autonomy sell daytime and nighttime cameras and different types of drone autonomous modules to other drone manufacturers, over 200 drone manufacturers in Ukraine. And then the UAV, business unit sells the drones themselves to the armed forces of Ukraine, Ukrainian government. And there are different types of drones. Those are sort of front strike, as we call them, so those are sort of FPV strike drones and the bombers, and then interceptors. And there are different kinds of interceptors. We do Shahed interceptors and we do ISR interceptors. We don't do the deep strike-FPV Drones, Interceptors, and Battery-Powered WarfareNoah [00:16:32]: What's an ISR interceptor?Yaroslav [00:16:33]: ISR is stands for intelligence, surveillance, reconnaissance, and those are basically drones which are which, Russians are using to watch over positions and then communicate where, the targets are coming.Noah [00:16:48]: It's a reconnaissance.Yaroslav [00:16:48]: That's, the ISR is sort of a classical term for a for a reconnaissance drone.Noah [00:16:53]: Are all of these battery-powered drones that you just described? ‘Cause I know that the sort of deep strike drones still have, like Some sort ofYaroslav [00:17:01]: Internal combustion engine?Noah [00:17:02]: Internal combustion engine. Are all the things you're talking about battery-powered?Yaroslav [00:17:06]: What we're working on is all battery-powered, right? We don't do the deep strikes, right? And then in terms of autonomy-Noah [00:17:12]: You can catch a Shahed with a battery-powered thing. It's not Fast to catch.Yaroslav [00:17:17]: No, absolutely. Look, Shahed interceptor, like ours, it's called Zero, it goes up to 326 kilometers per hour.Noah [00:17:26]: For reference, how fast is a Shahed?Yaroslav [00:17:28]: Eight, like, in internal phase it could be 280, but in cruise phase it's, like, 220-ish.Yaroslav [00:17:36]: Yeah. And sorry, I'm not like you can convert that into miles if you're interested.Noah [00:17:41]: No, that's fine.Noah [00:17:41]: Multiply by two thirds or point six or something.Yaroslav [00:17:44]: That's easy. Yeah, I was saying that for autonomy modules, right, we, -We make systems, autonomous systems for frontline, for interceptors and some for deep strikes as well, and then different levels of autonomy. So from terminal guidance, which is like lasts 500 meters, give or take, to autonomous bombing, to autonomous target detection, to autonomous navigation and all of that across day and night, different terrains, different time of the year, different platforms like quadcopters and fixed wing, and maybe some other platforms. So it's quite a wide variety of products. We also have like our own simulation. We have our own training school for the war fighters. And we're about to start construction of two, semiconductor plants to make, sensors for thermal cameras. So that's super exciting for me as a computer science guy is Doing semiconductors. Super cool.Noah [00:18:49]: Like in terms of kind of core drone technologies, you basically are one is an FPV replacement without fiber optics, and the other isYaroslav [00:18:59]: YouNoah [00:18:59]: Signal tracking with interceptorsYaroslav [00:19:00]: With or without fiber optics. Fiber optics Is just like, sort of a communication module.Yaroslav [00:19:05]: You can, you can use classical analog, video link and radio link. Those would be two separate radios. You can do digital, or you can do fiber optic, and then fiber optic Has its own advantages but also adds weight and decreases, the distance and decreases, how fast you can, sort of turn and With a drone. Yeah.Noah [00:19:33]: Do you need AI for fiber optic drones?Yaroslav [00:19:36]: Like you can use AI for fiber optic drones. AI replaces a human, right? Fiber optic is making your communication link more resilient. So those are slightly different goals. Like if you want, you can have, AI controlling hundreds of fiber optic drones instead of having 100 operators for each.Fiber Optics, Radio Horizons, and Terminal GuidanceNoah [00:20:03]: I guess I thought that the key reason that people moved to fiber optic drones was for like electronic, countermeasures. Or I guess to counter those.Yaroslav [00:20:13]: I think that's a correct assessment from sort of a public awareness standpoint. In practice it's somewhat more difficult Because besides electronic countermeasures, you have these issues of a radio horizon For FPV drones, which means that asYaroslav [00:20:36]: I believe Earth is round Some people disagree. But basically if you fly a drone and you have a land station over here and a drone flying over hereYaroslav [00:20:49]: If your drone is flying high, you have good direct radio visibility. If your drone goes low, and usually, Russian infantry and vehicles, they're on the ground and you want to hit them, you need to go low. Lower you go, maybe you'll get behind a hill or behind a forest, and if you're far enough, you'll just get behind the curvature of the earth. You get into what's called a radio shadow. And then That is a real bummer because for the last, be it 60 or 20 meters, you won't be able to see anything and it will be very difficult to hit the target. So to counter that what-- And then the distances that these FPV drones, act on they're, they can be quite large. So for example, here in the US there was this drone dominance program competition, and in drone dominance the furthest distance was about 10 kilometers.Noah [00:21:44]: What was drone dominance? What was that competition?Yaroslav [00:21:47]: Drone, the drone dominance is a is a program started, by the US government, to accelerate the development of drone technology here in the US.Noah [00:21:57]: Got it. And the longest range thing they were using was 10 kilometers.Yaroslav [00:22:00]: Was 10 kilometers, right. In Ukraine, like if your drone doesn't fly at least 20, 25, it just, no one's interested in it, and the usual hits are happening. It was like, okay, many hits are happening between 30 and 40 kilometers, and that's what expected from a regular 10-inch, FPV drone. So at that distance, even at altitudes of like 60 to 100 meters, you might start losing, the link. So some of the earlier AI technology that was fielded in FPV drone was this terminal guidance technology. That was the first product that we ever, launched that helped you as an operator, once you see the target from two, three, 500 meters, you lock onto the target and then, it just, drives the drone towards the target no matter what, even after you lost the visual connection. So optic fiber solves that. However, if you want to go like 20 kilometers with optic fiber, that will add an extra three kilos, of useful weight to your drone. SoNoah [00:23:12]: ‘Cause the cable that you have to unspool as you go weighs.Noah [00:23:15]: It is heavy.Yaroslav [00:23:15]: At first, like the spool is about 800 grams, so a bit less than a kilo, and then, and then think about 10, 10 kilometer optic fiber is another kilo, something like that. That takes away from your useful mass and then now you have like, you need a 15-inch drone and it can only carry maybe one or two kilos of explosives if you want to go, 20 kilometers. If you want to go to 30 or 40, like 30 is probably max. 40 is like very problem problematic on optic fiber. And then the problem with optic fiber is it's actually getting super expensive. So and why? Because of all the data centers for AI. That's literally the same optic fiber-Noah [00:24:01]: We're running out of centersYaroslav [00:24:02]: That's being used there.Yaroslav [00:24:02]: Like when Ukrainians and Russians come to Chinese factories to buy the optic fiber, they're like, “We're out. We sold it out to the Americans.”? That's the craziest thing. So optic fiber went up in price from like, $4 per, kilometer to like, $32 per kilometer in a few months in the beginning of this year. And I'veBrandon [00:24:26]: Claude Code is stopping the Russian drone effort here.Yaroslav [00:24:30]: Ukrainian as well. Yeah.Brandon [00:24:31]: Ukrainian. But I read somewhere that the Russians had grown more dependent on fiber optic drones relative to the Ukrainians, and that's one reason why the Ukrainians have sort of regained the initiative in drones recently.Brandon [00:24:42]: How accurate's that?Yaroslav [00:24:43]: The Russians were the first ones to scale that. I think by as of now, Ukraine has caught up. I think, like, as of maybe three months ago, Ukraine is mostly caught up on fiber optic. Yeah.Brandon [00:24:57]: What percent of damage would you say is in terms of FPV drone damage would you say is now fiber optic versus, like autonomous?FPVs as the New God of War: Tanks, Artillery, and Cost per KillYaroslav [00:25:07]: For our, for our audience, I actually, I cannot answer that question. Like, it's like I know the answer, but I would not disclose that. But for our audience, I think another interesting fact is out of all the casualties on the front line Between 70 and 80% are done by FPV drones.Brandon [00:25:30]: FPV drones are the new weapon of universal weapon of warfare.Yaroslav [00:25:34]: It'sBrandon [00:25:35]: Land warfare, anywayYaroslav [00:25:35]: They used to say that artillery is a god of war because artillery used to cause, like 80% of casualties, and now On that ranking-Brandon [00:25:46]: FPVYaroslav [00:25:47]: FPV drones rule.Brandon [00:25:48]: FPV drones are the god of war.Yaroslav [00:25:51]: Sort of. Dethroned artillery. But it's not to say that artillery is not useful, is not needed. Like, all of these systems are needed. Maybe except cavalry, although Russians still use it. I know, have you seen the videos of Russians using mules and horses?Brandon [00:26:09]: What is the usefulness-Yaroslav [00:26:10]: It'Brandon [00:26:10]: Of a tank in the in the modern-Yaroslav [00:26:11]: That's where we need Greenpeace to say a word, but they're silent. Yeah.Brandon [00:26:15]: What's the use of a tank on the modern battlefield?Yaroslav [00:26:21]: It's diminishing.Brandon [00:26:22]: Diminishing.Yaroslav [00:26:22]: However, I think there might be technologies which will, revive the tank. Look, tank still provides you armor, and armor is important. Like, you still need to armor and firepower, right? Like, you can be an armor personal carrier that provides you, armor. The challenge that currently exists is armor is not very well protected against incoming drones. However, there are ways to do to protect it. We were previously talking about this before the podcast. The CEO of Rheinmetall, recently sort of ridiculed, Ukrainian drone industry, saying that like, there is nothing interesting there, no real innovation, no to stand Compared to like, Rheinmetall or Boeing, and it's all made by housewives. There was like, obviously a ton of memes about this people ridiculing the CEO of Rheinmetall. And one of the best quotes, I heard on this topic is from my friend, Alexey Babenko, who's, the head of and founder of VIARI Drone, which is one of the largest manufacturers of FPV drones. They're our partner. They're using our autonomy. So he said that the drones we manufacture in one day will be more than enough to destroy all the tanks Rheinmetall manufactures in a year.Yaroslav [00:27:52]: Then, yeah, cost-wise, of course, a drone is like, $500 and a Rheinmetall tank is what, probably 5 million-ish or maybe more.Brandon [00:28:00]: Don't mess with those housewives.Yaroslav [00:28:03]: Drone wives.Brandon [00:28:04]: Drone wives.Yaroslav [00:28:06]: That's it.Noah [00:28:06]: There's a classic saying that everyone always fights the last war.Noah [00:28:12]: Yet do How did So from your standpoint, how did we get to the point where tanks became irrelevant in at least for now In a matter of just a few years?Yaroslav [00:28:24]: Look, I think it's the same way, how do we get to the point that calculators become irrelevant?Yaroslav [00:28:31]: Now we have iPhones. Like, why would you need a calculator? Technology progresses and its influence grows non-linearly. It's all exponential. So I can tell you that full autonomy, when you put it on a drone Look, so if you, if you think about a tank and a like, it's not a direct comparison, but even, like, a drone and a artillery shell or like, sort of cost per kill, an artillery shell for 155 caliber, which is a standard NATO caliber Currently market price is about $4,000 per piece. So compare that to say, $400 per drone. That's 10 times more expensive. Account for the amortization of the artillery gun and for how vulnerable it is and what is the sort of tactical, capabilities it gives you as compared to a drone. You'll figure out that an FPV drone is maybe three orders of magnitude, more versatile, more useful, more capable than artillery and many of than a classic artillery. Many of Because there are different types of artillery. Not just, like, one 155. You have mortars, you have all that. But give or take, roughly three orders of magnitude maybe. Again, it doesn't have that firepower. It's not one-to-one comparison still.Yaroslav [00:29:53]: Now, take that FPV drone. When you put full autonomy on that FPV drone, which can be not very expensive, like systems that we're, producing are like, in hundreds of dollars of pure bombFull Autonomy: From Human Pilots to Smartphone-Directed Drone MissionsNoah [00:30:06]: Just interrupt. You said full autonomy Just a second ago you were saying that the autonomy here is guidance, right? It's not decision-making.Yaroslav [00:30:14]: No, I was I was saying that's the f-First and sort of easiest pieces of autonomy that was fielded by us. But if you, if you add full autonomy to a droneBrandon [00:30:24]: He, I think he's asking what does it can you, for the listeners, can you explain What the term full autonomy means?Yaroslav [00:30:29]: Basically, I think a good way to think about an FPV drone is like an iPhone of warfare. It's, like, very inexpensive, very mass producible, very versatile. You don't need a bunch of other things when you have a iPhone in your pocket. You don't have, need an MP3 player, you don't need a calculator, don't need other things. All right? So FPV drone is an iPhone. Or like, okay, Apple please don't sue me, is a smartphone. And then, when you add autonomy to it sort of becomes like Uber or ride sharing. Okay? So what it means is instead of actually being a trained pilot who has this complex remote controller device which requires a couple months of training to actually pilot the drone, and then having to pilot it for 30 minutes, flying towards the target, et cetera, et cetera, now you basically, you have your smartphone, you have a drone, you pick your smartphone, you say, “We are here. The bad guys are here. Go and get them.” And the drone goes up, flies in a given direction, localizes itself on the map, finds the dedicated area where they, the bad guys are supposed to be sees the bad guys, bombs them, return, like, watches, so does a damage assessment, returns back, sits down, and then you can pick it up and watch the video if you didn't have the radio link, right?Noah [00:31:59]: That's a bomber drone.Yaroslav [00:32:00]: That's full autonomy for a bomber drone, right?Noah [00:32:03]: You're saying that no human decision is made in this entire process?Brandon [00:32:06]: That's not, that's not what he's saying.Yaroslav [00:32:07]: A human decision was made at the beginning of the process-Noah [00:32:09]: I get it. I get itYaroslav [00:32:09]: The same way as you would fire an artillery.Yaroslav [00:32:12]: When you fire an artillery, you don't stop at like, 500 meters away from a target and ask it whether, you want to strike or not. That's exactly, a human decision is always made at some point. So when you do that's full autonomy, and such full autonomy is happening as we speak. And such full autonomy increases the capabilities of an FPV drone, which is already, like, three orders more powerful than an artillery shell. Full autonomy increases its capabilities by four orders of magnitude because now you can have 100 times as many people who can use it, because you don't need to train those people, and this is important. You can have 10 times, mission success rate, and you can have 10 times utility per drone because now instead of being one-way kamikaze, it's, it can be a bomber.Brandon [00:33:05]: Now wait, let's, you said 10 times mission success rate, which means that fully autonomous bomber drones succeed in their missions 10 times more often than human piloted bomber drones do. That's an important thing to know.Noah [00:33:17]: Maybe, to push back onBrandon [00:33:19]: They're super, they're superhuman. They're, they' 10X superhuman.Yaroslav [00:33:22]: They're not vulnerable to electronic warfare. They don't care about the radio horizon. They don't lose track during navigation. They are not susceptible to human error when, an artillery shell or other drone blows up besides you and you're like, “Hell no,”like, “I'm getting out of here.” Right? That doesn't happen to an autonomous drone. Like, all of those things. Like, we have, like, one of the brigades that's using our drones with just first level autonomy They literally said that their success rates-Brandon [00:33:53]: What's first level autonomy?Yaroslav [00:33:54]: First level autonomy is just the terminal guidance.Yaroslav [00:33:57]: By the way, we have video of that. We can watch that.Brandon [00:33:59]: Terminal guidance means a human gets it nearby and then the AI takes over.Yaroslav [00:34:03]: The human flies it all the way, like 30 kilometers towards the target, and obviously the target was probably given to that human by someone who's flying some ISR drone, some reconnaissance drone, right? So all the way to the target, and once you see the target from a distance of 500 meters, you do target lock, and from there drone flies autonomous. So just that feature alone, it has increased the guy's, his call sign is Grom, so it has increased his, mission success rate, like precision of mission, yeah, mission success rate from 20% to 71%, and it also increased his kill zone from three kilometers to 10 kilometers, which means there's certain area around the front line which is designated kill zone. Whenever enemy goes into that area, it's almost guaranteed to be to be destroyed by a drone. And then obviously the drones are not launched from like, the zero line. They're usually launched from like, minus 10 kilometer-Mission Success, Failure Modes, and the Five Levels of AutonomyBrandon [00:35:03]: What is a zero line?Yaroslav [00:35:05]: Zero line is sort of an imaginary line of control, of two conflicting forces.Brandon [00:35:14]: It's important to explain these things to a lot of the listeners who areYaroslav [00:35:17]: Thank you for askingBrandon [00:35:18]: Familiar with warfare.Noah [00:35:20]: Myself.Noah [00:35:20]: I'm one of those listeners.Brandon [00:35:20]: You said that level one autonomy, in other words just terminal guidance, just, like, human gets it to the finish line and then it goes over the finish line, increases mission success from 20 something percent to 71%, or something like that.Yaroslav [00:35:33]: Increases the kill zoneBrandon [00:35:34]: Increases the kill zoneYaroslav [00:35:34]: Three kilometers to 10 kilometers.Brandon [00:35:36]: Got it.Yaroslav [00:35:36]: On both parameters-Brandon [00:35:37]: What is full autonomy, dude? AndNoah [00:35:38]: Actually on real quick, can we define mission success and like, maybe in a way, what are the failure modes of missions?Brandon [00:35:44]: I have a guess what mission success is.Noah [00:35:46]: But I couldBrandon [00:35:47]: Get ‘em.Yaroslav [00:35:49]: No, but that's a very good question, in fact, because, even if you fly into the target, well, first the target can be damaged or destroyed. Those are two different modes. Then there can be different targets. A sole infantryman is one kind of target. A dugout where supposed there are some, enemies there is another kind of target, and a some mechanical equipment is another type of target. Radio emitting equipment, which, like, often, like, the targets that the military want to get more than anything else is the some enemy radio tower or something like that or some small radio dish that really makes life difficult in that area, in that combat area. So those are different targets, right? It can be destroyed, can be damaged.Then sometimes, the drone hits but doesn't explode. Like, that happens. And then, there are other failure modes. You didn't even reach the target because you were A jammed by electronic warfare; B, you lost the control over drone because of the radio horizon; C, you were jammed by a different type of electronic warfare that happens way before You hit the target area. It's, impacting your, video receiver. So like jamming on video or jamming on control are two different types of jamming. Then something malfunctioned on a drone, just a mechanical malfunction, maybe like a motor broke or like, whatever. So all of those are different failure modes. Yeah, or maybe you got lost, you're navigate navigating to your, to your target. That happens, too.Noah [00:37:41]: The Level one autonomy, basically you manage to point in a direction.Noah [00:37:49]: You go there, and then the last mile The drone taking over.Yaroslav [00:37:52]: We define this like, I define that but it sort of got picked up by the industry. We define five levels of autonomy. So level one is terminal guidance. It's what we just discussed. Level two is bombing. Level three is autonomous target detection and engagement decision. Level four is autonomous navigation. And level five is autonomous takeoff and landing.Noah [00:38:15]: Those are good things to knowYaroslav [00:38:16]: Those are five levels of autonomy. Now, if youNoah [00:38:19]: I have a question for you.Yaroslav [00:38:19]: Sorry. Like, let me finish withNoah [00:38:21]: SorryYaroslav [00:38:21]: Theoretical part.Noah [00:38:23]: What is Tesla running at right now?Yaroslav [00:38:25]: Tesla?Noah [00:38:25]: No, sorry.Yaroslav [00:38:26]: That's very good point. Like, it's exactly, it was inspired by the levels of self-driving autonomy.Noah [00:38:32]: Waymo's level five, right?Noah [00:38:35]: You just tell it where you want to go, it picks you up, and then you go there.Yaroslav [00:38:36]: I think, like, if you, if you look at the classic definitions of self-driving cars, Waymo is still, like, level four because it still requires even remote, but still, like, human control. It's like if Waymo gets in trouble, there is an operator who takes over and resolves this. So that would still be a level four. It doesn't map directly, but it's also five levels.Brandon [00:38:58]: Can I, can I interject a question here? In terms of an FPV drone that's like a suicide drone that'll just blow itself up killing something, how do what it hit? Like, does it, just transmit back, or do you sort of like, lose track of it and hope it hit? Like, what happens to that?Yaroslav [00:39:16]: That's a great question. SoBrandon [00:39:18]: You need another droneYaroslav [00:39:19]: Like, the current battlefield in Ukraine is saturated with different types of drones. So obviously you have all the FPV drones and last year alone, Ukraine manufactured about 4 million of these, and then Russia's maybe, like, 20% less than that. And for this year, the publicly voiced target was 7 million on Ukrainian side. So it's, like, serious numbers. We're getting in serious numbers here. And then besides those, there are different, reconnaissance drones, ISR as we call them, and there are sort of tactical level ISR where we, both Ukrainians and Russians usually use, Mavic, drone by DJI. And then there are a bunch of locally produced drones, which are sort of fixed wing drones that can stay in the air for much longer than Mavic, maybe, like, half an hour. And then, there are drones that can stay for many hours or even up to a day. And those drones have, are more expensive, have more expensive cameras, et cetera, et cetera. We hunt those drones that Russians launch. The Russians hunt our drones, and so on. But ideally, when you, are a group of soldiers operating an FPV, you'll have someone in your, company, or someone in your platoon who has an ISR asset that will do target designation for you. They'll say, “Oh, like, there's a Russian vehicle over there. Go and get him.”and you go there, you get it, and they're like, “Okay, confirmed.”Battlefield Surveillance and the Eight Dimensions of AutonomyBrandon [00:40:57]: Those guys are watching. They have their own drones in the sky.Yaroslav [00:40:59]: Target destroyed. They have, like, a carousel of drones because One Mavic cannot stay more than 30 minutes. ItBrandon [00:41:06]: They're constantly surveilling the battlefield.Yaroslav [00:41:07]: Almost every spot on the battlefield.Yaroslav [00:41:11]: It's not always the case. Sometimes you will not have a surveillance asset, so then you would launch another FPV just to confirm that there was a hit. Then if you see there was a hit and you're not sure if it completely destroyed, you maybe hit again for good measure.Brandon [00:41:26]: You double tap.Yaroslav [00:41:28]: That's how it works. But I was about to give you another sort of piece of taxonomy. So you have five levels of autonomy, right? Then you have sort of eight dimensions of autonomous battlefield. So what is eight dimensions? It's crucial to understand how autonomy evolves in a modern, battlefield environment. So dimension number one is level of autonomy. What are the capabilities that your asset has? Dimension number two is the platform you're operating on. So it can be a quadcopter, a fixed wing drone, different types of maybe, like, a long range drone or short range drone, but it can also be a missile. You can have autonomy even on an artillery shell or a ground vehicle or a sea vehicle. So all of those are different platforms. Level three would be domain. So it's ground to ground or ground to air as an intersection, or ground to sea or sea to air. They're all, like, all the nuances with different domains. Then level four, would be higher levels of autonomy, such as swarming, drone carriers, drone nests, et cetera.Brandon [00:42:39]: Now when you're saying level, you're talking about dimensions, not about-Yaroslav [00:42:42]: Sorry. YeahBrandon [00:42:43]: Autonomy levels. So dimension four.Yaroslav [00:42:43]: The dimension. Yeah, I used to say I was supposed to say dimension. I say dimension because each of them works with another, right? So you might have, like third level autonomy, fixed wing drone operating in land to air, and stuff like that right? And then operating in a swarm or operating from a nest. Right? Then you have, sort of dimension number five is environment. So is it day or night? Is it summer or winter? Is it, humid, cold, dry? What kind of target is it? Is your target hiding in a forest, or is it, behind a hill or within buildings? So all of that is environment. Then you have, dimension number six is command and control. How are you dealing with or like, tens of thousands of those assets around the battlefield? How are you coordinating that on the higher levels of command? How are you collecting data? All that.Yaroslav [00:43:44]: Dimension number seven would be infrastructure, so things like simulation, data collection tools, security, deployment mechanisms, et cetera. So all those systems have to be developed separately and integrate with all the others. And finally, dimension number eight is sort of distribution. Have you deployed 100 of these systems or 100,000 of these systems? Because those are two very different ballgames. So that now gives you a more broad overview of how autonomy propagates across the battle space.Targeting, Human Responsibility, and Rules of EngagementNoah [00:44:23]: As someone who has done machine learning and had gone out of distribution and had things, go horribly wrong, you were talking several of these, kind of axes of thinking about drone warfare seem like they could be very susceptible to some sort of distribution shift if you start making things autonomous.Yaroslav [00:44:41]: Like what?Noah [00:44:41]: I mean Well, first ofYaroslav [00:44:43]: If the I'm very interested Sort of sort of kinds of scenarios that you're thinking about.Noah [00:44:48]: Like the most obvious one is you, if I assume these are computer vision guided systems for at least the last mile, how do you ensure that oh, well, like you now have some fog roll in or something, and you, the drones just attack the wrong thing? Or maybe, it probably will not turn around and fly back and attack you, but youYaroslav [00:45:10]: Same, the same, the same question, how do you ensure that your mortar fire hits the right thing? Well, it's like mortar fire, give or take half a kilometer could be plus or minus. So maybe you fire one, and then you fire another. So drones are actually, much better in being precise in those scenarios. And I think, to your point, I think five to 10 years from now it will be immoral to use weapons without AI.Yaroslav [00:45:44]: ‘Cause weapons without AI will be more likely to cause, collateral damage or unwanted damage. Same way, it will be immoral to drive your own car manually on a public road because it's more likely to cause, unwanted damage.Noah [00:46:02]: Wow, I never considered that mightBrandon [00:46:04]: Really? That's definitely coming.Yaroslav [00:46:07]: Anyway.Brandon [00:46:07]: No, but that' I don't know, it's an obvious, an obvious thought. I agree with you.Brandon [00:46:12]: I, No, they, obviously they're not going to let you drive once most of the cars on the road are autonomous.Noah [00:46:17]: No, that one, don't I believe.Yaroslav [00:46:19]: No, I think you were you were talking about drones, right?Brandon [00:46:21]: The drones, right. Cool.Yaroslav [00:46:22]: The weapons, right?Brandon [00:46:23]: Friendly fire and collateral damage and stuff like that is all minimized with AI.Brandon [00:46:27]: Here's my question. Take all let's go to level six autonomy. Let's take all of the target selection. Let's take all the battlefield data, integrate it into one big AI, and have that big AI basically be in command of the battlefield And agentically do target selection.Yaroslav [00:46:44]: Be the general, right?Brandon [00:46:44]: It's a general. It's, you've cut humans out of the loop except maybe as dexterous robots, repairing drones and fastening things to drones or maybe something like that because you don't have those robots yet. How soon are we there? AI general.Yaroslav [00:46:58]: The most important thing to ask ourselves is who will be faster to that us or our adversaries?Brandon [00:47:07]: I assume us, but how fast will we be to that? I hope us.Yaroslav [00:47:11]: I hope so too.Brandon [00:47:12]: How fast can we Like when are we looking at that in terms of like horizons years?Yaroslav [00:47:18]: Like technically, it could be done now. The question is of course, there's, some engineering work to be done. The bigger challenge is deployment. Right? So okay, technically Like operation in Iran, right? They, the publicly, it was claimed that I think Palantir system was used for target designation, et cetera, et cetera. So it is not exactly as you say, the AI makes all the decisions, but basically AI goes through all the data you have, gives you these 1,027 different targets and says, “You-- To confirm, please press Okay.” And you look at the targets and you're like, “Yeah, sounds right. Press Okay.”so that's, I think that's where we are now already, or we were a couple weeks ago as we're recording this on April 10th. Another question is how massively deployable it is. Is it, like, every decision being made like that or is it, like, just some of the decisions made like that? And then different levels of command and control. There you have, like, the platoon, the company level, the battalion, et cetera, et cetera, et cetera. But the tricky thing here when we get into that territory, the tricky thing is If your enemy is getting advantage of being Thousand times faster than yourself by deploying such systems What do you do?Yaroslav [00:49:10]: You got to-Brandon [00:49:12]: The if the enemy is a thousand times faster than you at deploying those systems?Yaroslav [00:49:16]: Like, if enemy starts deploying level six autonomy, as you call And you have not started doingBrandon [00:49:22]: You're in troubleYaroslav [00:49:23]: Yes, exactly. So you have to catch up. So my point is that it is very important to think about the safety of these systems, but that thinking should not slow you down in developing them because they are critical for your existential, survival, right? And like, one person who doesn't think, doesn't get to think about the ethics of the war is a dead person. That person surely doesn't get to think about that.Brandon [00:49:52]: What would be the safety risk of such a system?Yaroslav [00:49:55]: Of course-Brandon [00:49:56]: Friendly fire?Yaroslav [00:49:56]: Just wrong decisions, right?Brandon [00:49:59]: I see.Yaroslav [00:49:59]: Maybe, these decisions-AI Command Decisions, Dead Zones, and Complex BattlefieldsBrandon [00:50:06]: Skynet AI decides it's going to useYaroslav [00:50:08]: No, these-Brandon [00:50:08]: Drone army to kill usYaroslav [00:50:09]: Decisions will not only be made about drones. They are likely to made about what the humans should do on your side as well. Then obviously some environments are more like Ukrainian-Russian war, where you haveBrandon [00:50:26]: It will have to choose to risk lives. It will have to choose to sacrifice human lives-Yaroslav [00:50:28]: Of courseBrandon [00:50:29]: On your side.Yaroslav [00:50:29]: Of course. And then some environments are just, like, dead, like, dead zones and there are no civilians there, or virtually no civilians close to the front line because, like, super dangerous. Everyone has evacuated from there. But there are other environments which are more like, okay, there's a counterterrorist operation. There's, like, a group of terrorists or a group of civilians. Or like, it's like the recent operations in Iran, I imagine that the US and Israeli forces do not want to harm civilians. They only targeted the military targets there, right? So in those situations, it's a different level of responsibility for that decision-making as well. And then there is just such a big variety of those military missions, and I'm not even, like, well-informed or well-educated in military science to tell you about all those scenarios. We would need to put some general besides me, and maybe a Ukraine general and American general would have told you very different stories about these things.Brandon [00:51:34]: Got it. Can I ask a few more questions? All right. So in 2013, I wrote one of my first, paid articles ever was about how the era of drones will change human society. I was just sitting around bored thinking about things.Yaroslav [00:51:54]: You were way ahead of your time.Brandon [00:51:55]: I said, I said, “The following will happen.”Yaroslav [00:51:57]: It's, this article is real. I've read it.Yaroslav [00:51:58]: It's actually-Brandon [00:51:59]: I said small autonomous, suicide drones, will cleanse the battlefield of human infantry. Human infantry will not be able to stand against swarms of AI-powered, suicide drones. That was I didn't even know about, like, AlexNet at the time, I think.Yaroslav [00:52:19]: You're just an avid sci-fi reader.Brandon [00:52:23]: I'm an avid sci-fi reader, but also, like, it's not Like, there will be a way to do that. It's a it's a nonlinear multidimensional search problem, and you get enough compute, you'll find some search algorithm that will get you there. And soBrandon [00:52:38]: I, yeah, I think that one sentence describes the bitter lesson right there.Brandon [00:52:41]: It's just like it's a multidimensional search space. You search it somehow. I don't know. Figure out some get a grad student-Yaroslav [00:52:47]: Sooner or laterBrandon [00:52:47]: To make a search algorithm.Brandon [00:52:48]: It's not that hard. Anyway, so but then, but I guess the point is The point is that human infantry on the battlefield will be will be gone at the end. I wrote that in 2013. Many people on social media laughed at me for that called me hysterical, said things like, “Electronic warfare will knock all the drones out of the sky.”like, “You need humans to hold ground.”that's something you still hear from a lot of people on social media today. I feel that this article that I've written has never been directionally wrong. It has gotten more and more right steadily over time, and that we're very reading the battlefield reports from Ukraine, where, human infantry are basically guy, like a few guys hiding in dugouts for months, and I'm not sure what they're doing.Yaroslav [00:53:35]: That's on Ukraine's side. On the Russian side, that's just like a zerg rush.Brandon [00:53:38]: The zerg rush, and then they just die. Then, but they have some guys in dugouts too, right? Like hiding in dugouts for months.Yaroslav [00:53:45]: They have. Yeah.Brandon [00:53:45]: Like, but that like, what are those guys doing in the dugouts? Are providing, like, frontline, like, reconnaissance? Like, what are they doing?Yaroslav [00:53:54]: If there is a guy in a dugout with some bullets and automatic weapon, the other guy cannot come and take the that dugout. That'Brandon [00:54:07]: I seeYaroslav [00:54:08]: They are they're establishing control over territory.Brandon [00:54:10]: I see. So that is so there still is a use for human infantry on the battlefield as of today.Yaroslav [00:54:15]: LikeBrandon [00:54:15]: How long will that last?Yaroslav [00:54:17]: I think it will last for a while. This is funny. There's this whole Layer of the modern culture, a modern Ukraine culture built around the war-related stuff. So there is this -Punk rock band, that is called SZC, I guess in English that would be. Which stands short for like a deserter or something like that. So anyhow, this band has a song titled “2030.” It's basically about the year 2030, and the war still goes on as like the whatever, third world war or whatever. And they basically, they, sang about the AI and like cyborgs and everything, but the simple infantry is still needed, and we're still, like, getting cold in those dugouts, and we're still doing our job. That's sort of the theme of the song. And it seems like that's actually what's going to happen. There areGround Robots, Simulation, and the Limits of World ModelsBrandon [00:55:30]: Ground robots will not replace humans in the dugouts soon.Yaroslav [00:55:34]: I'm very much interested in following the whole humanoid robot theme andBrandon [00:55:39]: What about like a dog robot?Noah [00:55:41]: Or just mobile controlled platforms or something.Brandon [00:55:44]: Spider robot, yeah.Brandon [00:55:45]: Everything evolves into a crab.Brandon [00:55:46]: You build a crab robot.Yaroslav [00:55:47]: A humanoid-Noah [00:55:48]: The carcinization of warfare.Yaroslav [00:55:51]: There is a lot of utility in humanoid robots because the world is designed around humanoids. So I would not, like, 100% disqualify the possibility that sometimes 10 years in the future, humanoid robots, will be actually fighting. So that's an actual Terminator kind of scenario.Brandon [00:56:14]: Yeah, in the first Terminator movie, you look at what they've got on the battlefield, they've got flying bomber drones and humanoid robots.Yaroslav [00:56:20]: Look, the cost of large language models of running them is getting so low, you can have basically an inexpensive computer running, what was a state-of-the-art model a year and a half ago, running it locally on a device with an open source model, which also means that the Chinese can have it, the Russians can have it, the North Koreans can have it, et cetera. So that is already possible. And with when we're looking at the acceleration of the neural nets, I would've, if not the acceleration of the large language models, I would've said that I don't think that humanoid robots will be able to be useful in the battlefield earlier than in 10 years. But if you account for the exponential, it might be five years or so. The problem with all of the autonomous systems, and it's like starts with self-driving cars and even with all the AI, like modern day AI agents, to make them really, useful, you have to solve such a long tail of edge cases, that it's really difficult to make them useful. Like we were promised, self-driving cars, what, like 2007, Sebastian Thrun and Google, and even before that all the challenges, everything. And Elon of course told us it's going to be one year from 2014, and now we still don't have self-driving Teslas everywhere. We have Waymos in SF and some other places, but they're still, like, not perfect. So I think, I expect something similar from self-flying drones and fully autonomous drones, and we saw that firsthand as with each level of autonomy that we're adding, there is a very wide distance between a prototype and something that is ready to be scaled to millions of units and something that has been scaled to millions of units. But the race with like AI coding tools is just insane. So things might accelerate very fast, faster than we can imagine.Noah [00:58:46]: I think your point is that with due to this long tail behavior Level one autonomy as you've defined it, is actually very natural. Like you basically are just solving an image recognition and tracking system.Yaroslav [00:59:02]: It's actually interesting that you say it that way, and I thought about this the very same way, and we have this joke that there are like 200 companies in Ukraine which are trying to solve last mile, targeting or terminal guidance. It seems like we're like the only company that actually solved that because even that problem-Noah [00:59:22]: I'm not saying it's, I'm not saying it's trivial, but it's at least something that you imagine given our current state.Yaroslav [00:59:26]: Like us and Eric Schmidt, like Eric Schmidt's companies are pretty good.Yaroslav [00:59:29]: Like, I actually have lots of respect to what they're doing, and they're, they have been practically influential and helpful on the battlefield, and they have good engineering.Noah [00:59:38]: I wasn't, I wasn't saying it's trivial. I'm just saying this is a something naturally adaptive based upon things that we know work, well. But some of the other domains that where you do have to make decisions and you have a long tail become much harder, and you worry about edge cases more.Yaroslav [00:59:57]: Like the more, the more complex behavior you're trying to simulate, the more edge cases there are right? The more ways to do it wrong there are. And then there are different approaches. It's like if you think about, if you read academic papers about robotics, right? You sort of the robot is represented as something that has the sort of sensor input, and then you have three, levels of sort of logics or decision-making, which are perception, planning, and control, and then you have actuators as output.So pre-neural nets, you would do perception output and control all with classic logics, right? Then, with AlexNet and computer vision, you could do perception with neural nets and the rest with logic. You cannot currently do each of those separately with neural nets, each of those separately with logics, or you can just have one huge neural net that just takes lots of sensory data. It's not just pixels. Could be sound, could be accelerometer, could be everything, as input, and just outputs the controls. And some of the self-driving car companies are doing that or like, experimenting between different ways of doing that. So you can also, like, think about that and the way you implement those features, also influences how much degrees of freedom the system would have, right? Like control, you can do it classical algorithmic control with common filters and PAD filter, PAD controllers, et cetera, or you can do a neural net, that was trained in a gym with a reinforcement learning, et cetera. And those would be two different behaviors of a system.Noah [01:01:53]: I-- Maybe my point was just much more high level. It'Yaroslav [01:01:56]: Or you can If you go even like, if you go high level, you can, you can like train to like have whatever, like Feifei Li and folks who are doing like physical, sortBrandon [01:02:08]: World modelsYaroslav [01:02:08]: World models, right, physical intelligence, they're trying to make these big models and sort of understand the world and then supposedly you have such model and you can tell a drone, “Okay, like, go over that hill and like, find the bad guys and then get them,”or “Make me a video, make me a photo of the guy smiling and get back to me.” Right? That's one way. Another way you have like these subsystems, like one is navigation, another is finding the person, another is like getting to them to take a photo. And those are again, very different behaviors. And then it's not that one is necessarily better than the other, and we might have more technological ability to do one or another. But all of those systems will exist. And then again, you should always keep in mind that it's only the not only the good guys that are developing these systems, the bad guys are developing these systems as well.China's Drone Supply Chain and the West's Manufacturing GapNoah [01:03:00]: I guess where I'm going with this back to Noah's original thought with the end of the end of the soldier. And so in order to replace-Brandon [01:03:10]: Or at least the end of the rifleman.Noah [01:03:11]: Or the end of the rifleman, yeah.Yaroslav [01:03:13]: I'm not seeing that very close, and it was like I'm, as much as I'm a lover of sci-fi and all of that and a technologist, the more I try to beYaroslav [01:03:27]: Like the I try to have certain humility about these things, and like the military, domain and there was just so much human history and blood and tears, dedicated to sort of understanding this art of war and perfecting it and so on. There is so much knowledge in there that I don't feel like I even started to comprehend, a lot of that. But one thing that I really understood is that even though drones are now making eighty percent of the casualties, you go to the actual officers, you talk to the actual, like, brigade commanders, corps commanders, and they explain to you, how all of it fits together, how when you're thinking about an operation that involves a couple thousand people to get this piece of land, out of the enemy's hands, deoccu deoccupy it, how it is so complex, it involves, dozens of different types of drones and then land operations and reconnaissance operations, psychological operations and then aviations and tanks and logistics and all kinds of these different assets. So modern warfare is really very complex, and the fact that the drones are the latest, coolest thing, and then the AI is latest, coolest thing, doesn't mean that now it's that and only that right? So yeah. Whoever's looking into that I think should realize that it's not just what the press talks about, that the reality is much more difficult, much more complex.Brandon [01:05:17]: Let's talk about China and China's manufacturing capabilities. So suppose that someone, like suppose the United States went to war with China. AndYaroslav [01:05:26]: I hope not.Brandon [01:05:27]: I hope not as well. And then but suppose that drones were very essential to that war of all the types of drones that we're talking about here, and that suppose that China said, “All right, well, you need X and Y and Z, to make those drones to fight us, and we control the production of X and Y and Z, so we're just going to cut you right off, and now you have no drones.”Brandon [01:05:47]: I know that a number of countries, including Ukraine and Taiwan, have been making moves to China-proof their drone productions that China couldn't do that. Examples of things they might be able to cut off might include rare earths, fiber optic cable that you were talking about before, various other things that where even if they don't control one hundred percent of the production, they control enough of the production that would be extremely expensive to produce it without relying on Chinese sources. Or the market's fragmented enough, et cetera. What do you see as China's key bottlenecks, and how easy are those to overcome in terms of China-proofing drone production in case of a war against China?Yaroslav [01:06:30]: Let me start with a saying that -Although China does not sell directly to Ukraine and it does sell directly to Russia, a lot of Ukrainian supply chains, they start in China, right?Yaroslav [01:06:49]: We're not in a conflict with China, and we would not want to be in a conflict with China. And we'd hope that China stays a neutral power between Ukraine and Russia and the US as well. That said, the scenario that you're describing, everything is much worse.Yaroslav [01:07:11]: Think about this. Last year, Ukraine produced four million FPV drones. Ukraine is not the most industrious nation in the world.Yaroslav [01:07:19]: China can produce four billion of these FPV drones.Yaroslav [01:07:23]: China can make them not drones with propellers, but fixed-wing drones, which go not forty kilometers far, but maybe two to three hundred kilometers inland.

The Internet Report explores recent disruptions at Anthropic and X, analyzing how architectural differences and deployment cycles impact digital reliability. CHAPTERS 00:54 Anthropic's Claude: Three Early April Events 06:03 The Deployment Hypothesis 08:51 The Reliability Challenge for AI Services 11:24 A Pattern to Disruptions at X 12:45 Outage Trends: By the Numbers 17:59 Get in Touch For additional insights, check out The Internet Outage Survival Kit: https://www.thousandeyes.com/resources/the-internet-outage-survival-kit?utm_source=soundcloud&utm_medium=referral&utm_campaign=fy26q4_internetreport_q4fy26ep135_podcast  ———  Want to get in touch?  If you have questions, feedback, or guests you would like to see featured on the show, send us a note at InternetReport@thousandeyes.com. Or follow us on LinkedIn or X. ———  ABOUT THE INTERNET REPORT  This is The Internet Report, a podcast uncovering what's working and what's breaking on the Internet—and why.   Tune in to hear ThousandEyes' Internet experts dig into some of the most interesting outage events from the past couple weeks, discussing what went awry—was it the Internet, or an application issue?  Plus, learn about the latest trends in ISP outages, cloud network outages, collaboration network outages, and more.  Catch all the episodes on your favorite podcast platform:   - Apple Podcasts: https://podcasts.apple.com/us/podcast/the-internet-report/id1506984526   - Spotify: https://open.spotify.com/show/5ADFvqAtgsbYwk4JiZFqHQ?si=00e9c4b53aff4d08&nd=1&dlsi=eab65c9ea39d4773   - SoundCloud: https://soundcloud.com/ciscopodcastnetwork/sets/the-internet-report   - YouTube: https://www.youtube.com/@theinternetreport_official

The Internet Report explores recent disruptions at Anthropic and X, analyzing how architectural differences and deployment cycles impact digital reliability.For additional insights, check out The Internet Outage Survival Kit: https://www.thousandeyes.com/resources/the-internet-outage-survival-kit?utm_source=wistia&utm_medium=referral&utm_campaign=fy26q4_internetreport_q4fy26ep135_podcast ——— Want to get in touch? If you have questions, feedback, or guests you would like to see featured on the show, send us a note at InternetReport@thousandeyes.com. Or follow us on LinkedIn or X: @thousandeyes ——— ABOUT THE INTERNET REPORT This is The Internet Report, a podcast uncovering what's working and what's breaking on the Internet—and why. Tune in to hear ThousandEyes' Internet experts dig into some of the most interesting outage events from the past couple weeks, discussing what went awry—was it the Internet, or an application issue? Plus, learn about the latest trends in ISP outages, cloud network outages, collaboration network outages, and more. Catch all the episodes on your favorite podcast platform: - Apple Podcasts: https://podcasts.apple.com/us/podcast/the-internet-report/id1506984526 - Spotify: https://open.spotify.com/show/5ADFvqAtgsbYwk4JiZFqHQ?si=00e9c4b53aff4d08&nd=1&dlsi=eab65c9ea39d4773 - SoundCloud: https://soundcloud.com/ciscopodcastnetwork/sets/the-internet-report - YouTube: https://www.youtube.com/@theinternetreport_official

Wie hat dir die Folge gefallen?Gut

Continual Improvement is at the heart of ISO Management, a large part of which is dedicated to ensuring issues don't reoccur. This is more than just putting a plaster on it and calling it a day, it's about finding the root cause. This not only eliminates wasted time, effort and money with firefighting repeated mistakes, but also drives meaningful improvement. Over the years, many techniques have been developed to help with finding cause. In this episode, Ian Battersby explores the need to find the root cause of issues in ISO Management and explains some key techniques for root cause analysis that you can put into practice to help stop recurring issues.   You'll learn ·      What is meant by 'finding cause'? ·      Why do you need to find the cause? ·      Where is finding cause specified in ISO Standards? ·      Finding cause in practice ·      What are the 5 Why's? ·      What is the fish bone / Ishikawa? ·      What is FMEA? ·      What is fault tree analysis? ·      How do these techniques work in practice?   Resources ·      Isologyhub   In this episode, we talk about: [02:05] Episode Summary – Ian dives into finding cause within ISO Management, explaining various techniques to help you prevent recurring issues. [03:15] What is meant by 'Finding cause'? When an output from a process is not what was expected, then it is classed as a non-conformity which will need to be addressed through corrective action. Before you can put that action into place, you need to identify the root cause for the issue. It's about putting right what went wrong. [04:00] Why do you need to find cause? Ian gives an example of a reactive response to resolving an issue, it didn't get to the root of why the mistake happened in the first place.   Finding cause is necessary to stop issues from repeating, rather than simply firefighting issues as they occur. ISO terminology has updated to reflect this over the years. There used to be a term called 'Preventive action', but this has since been changed to 'Corrective action' following on from the 2015 Annex SL update to many ISO Standards. This reflects the new risk-based approach to ISO management. The terms are largely the same in nature, but preventive action was widely misunderstood and so this was renamed and clarified following 2015. [05:55] Where is finding cause specified in ISO Standards? As with many aspects of ISO, the need for finding cause can be found in a few places within a Standard, including: - Clause 6.1.1 Planning: It specifies the need to determine risks and opportunities that need to be addressed. This is because they will affect the desired outcome of your Management System. It's also a good place to start thinking about how to reduce those risks. Evaluating your strengths and weaknesses also gives you the chance to contemplate whether your existing processes are good at delivering what you want. Clause 10 Improvement: The Standard states something to the effect of 'the organisation shall determine and select opportunities for improvement and implement any necessary actions to address those opportunities' These opportunities will focus on improving products and services, which includes correcting, preventing or reducing undesired results. Also included under clause 10 is a subclause that directly addresses non-conformities and corrective action. These specify not only the need to resolve issues as they arise, but to evaluate the need for action to eliminate the root cause. Additional requirements include the need to review these actions and determine if they are actually effective. Ian goes into Clause 10 in more detail in a previous podcast specifically looking at opportunities for improvement. [14:20] Finding cause in practice – Why a methodology is necessary: Ian provides an example where an employee may lack confidence completing a certain activity. Their lack of competence could lead to a process being delivered incorrectly. That adverse quality outcome would then likely end up with the customer who would raise a complaint, in this instance that could be a damaged product. The damaged product is what needs correcting, from your perspective you would be looking at what caused that to prevent recurrence. Without knowing the initial cause, you would need to determine whether it's a production issue or a human error. These types of scenarios can branch out further than the initial quality issue. For example, if that damaged product causes harm, then it turns into a health & safety risk. If products need to be scrapped, then there's an environmental factor. Complaints related to product quality may also not be recorded in a standard non-conformity system, and could easily be missed for a full investigation to find root cause. This is why it's important to have a consistent approach, in both logging issues and evaluating them to determine cause. [18:10] What are the 5 Why's? This is one of the more popular methods that people use to determine cause. It's simply a case of asking why a scenario happened, usually 5 times, though you can ask more or less depending on how long it takes to reach the core issue. It doesn't require much training and all it requires is an open and honest response to the questions. This method can get answers quickly and is often utilised as an early problem solving technique. [19:30] What is the fish bone / Ishikawa? This is a more visual method to find cause. Depicting a fish skeleton that categorises possible causes and groups these accordingly. These causes are then discussed for a few minutes, typically with teams of people in order to gain different perspectives to help pull apart complex problems into their contributing factors. This method is particularly useful in cases where there isn't a single underlying cause. [20:30] What is FMEA? FMEA or Failure Modes and Effects Analysis is a more structured technique and acts like a risk assessment in reverse. It looks at what can go wrong, what the effect of failure is and then how critical that failure is to the outcome of what you're trying to do. It uses risk priorities to decide what's more important. [21:15] What is Fault Tree Analysis? This method utilises a top-down logical approach. It's a diagrammatic representation of what's going wrong. It asks, does this happen? Yes or no or both, and branches down paths that explore the issue. It allows for quantitative measures with a number output that can help determine how likely recurrence will be.   It's a method that is often used in engineering and manufacturing processes. [22:55] Scatter Diagrams:  Scatter diagrams are a good tool to find correlation. They help visualise the relationship between two variables. If you have data rich environments, these can really help you plot out those relationships and make those links that otherwise may have been missed. [23:40] The 5 Why's in more detail:  The 5 Why's is a great starting technique as it requires little training. Ian provides an example of using the 5 Why's, with the scenario of a worker who has injured themselves while cutting some wood. Using the 5 Why's, he asks these questions: ·      Why did the workers hand slip while cutting the wood? – They were holding the material in one had without the use of any clamping device to keep it steady. ·      Why was the material being held by hand instead of using a clamp? Because there was no clamping device available. ·      Why was there no clamping device available on the table? The design of that workstation didn't take into consideration the need for a permanent clamping fixture. ·      Why wasn't that taken into consideration for the workstation? The risk assessment for that workstation was overlooked. From this exercise, you can see how you can get to the root of an issue by simply asking 'Why' a number of times. Again, it can be more or less than 5 times, the name is simply a guideline. [25:40] The Fishbone / Ishikawa method in more detail: Another favoured simple technique for finding cause is the fishbone method. It utilises 6 categories to get to the root of an issue, those being:- ·      Machine: Addressing the equipment or technology that you use to deliver products and services. ·      Method: The way in which you deliver products and services. ·      Material: The raw inputs into your processes. ·      Measurement: The data and metrics that you use to monitor the successful delivery of your products and services. ·      Mother Nature: The environment and conditions in which you're operating.  ·      Man – Although this has now been updated to 'People', addresses the human element of product and service delivery. This is a great method for instances where there may be multiple root issues, so you can categorise and analyse each of them with multiple perspectives involved as this is considered a more collaborative method for root cause. [28:15] Record your findings: We dive more into this in a previous episode, but essentially, it's a requirement of every ISO Standard to address these non-conformities as they occur. Going through the process of root cause and rectifying the issue will need documentation to prove that you are actively addressing these issues, as well as doing as much as you can to prevent recurrence.   There is no defined way to do this in the Standard, so it can be documented via forms, intranets, other digital systems etc. Documenting all the evidence of resolving issues may seem arduous at times, but it will ultimately lead to genuine continual improvement, and will lead to reduced overall error.   If you'd like any assistance with ISO Implementation or support, get in touch with us, we'd be happy to help. We'd love to hear your views and comments about the ISO Show, here's how: ●     Share the ISO Show on Twitter or Linkedin ●     Leave an honest review on iTunes or Soundcloud. Your ratings and reviews really help and we read each one. Subscribe to keep up-to-date with our latest episodes: Stitcher | Spotify | YouTube |iTunes | Soundcloud | Mailing List

You've worked hard to get your solopreneur business off the ground, but what happens when things start to stall, or worse, head in the wrong direction? In this episode of The Aspiring Solopreneur, Carly and Joe dig into the “improving” phase of the Solopreneur Success Cycle. They uncover the seven most common failure modes that can quietly sabotage your progress, from burnout and stagnation to external threats and even your own mindset. Whether your business is thriving or just surviving, these insights will help you spot trouble early, course-correct with confidence, and keep your business aligned with the life you want to live.Popular Questions and Answers From The EpisodeWhat's the first thing solopreneurs should address when improving their business?If there's an existential threat, that has to come first. These are big, business-ending issues—like a major competitor undercutting your prices, new technology disrupting your industry, or a business model that simply isn't working. Before worrying about tweaks or small improvements, solopreneurs need to tackle these threats head-on to ensure survival.What are the “seven failure modes” solopreneurs should watch out for?Joe outlined seven common failure modes:Misalignment – your business no longer matches your goals or interests.Overload – you're working too much and burning out.Money problems – not enough revenue or profit to sustain you.External risks – outside forces like platform changes or new competitors.Stagnation – growth stalls or customers start slipping away.Execution failure – not delivering quality results to clients.Psychological barriers – mindset issues like fear, procrastination, or undercharging.Recognizing which one you're facing is the first step toward fixing it.How do solopreneurs know when it's time to reimagine their business?It's time to reimagine when your business stops serving your life. Even if it's profitable and running smoothly, if you've lost enthusiasm, feel misaligned, or your personal goals have shifted, that's a signal to step back. Sometimes improving your business isn't about fixing broken systems—it's about reshaping it so it supports the life you want today, not the one you wanted years ago. Okay, this might be the craziest offer we've ever made. We're giving away a solopreneur platform that normally costs five hundred dollars a year…For twenty-five bucks. And not for a month, not for a year… forever.All you have to do is pre-order our new book: Solopreneur Business for Dummies.When we first went solo, we thought we could just Google our way through it. But the advice out there? It was built for startups with teams and money, not someone trying to do it all themselves. We kept thinking: “There's gotta be a better way.”So we made one. LifeStarr Premier is the system we wish we had back then: the tools, the strategy, the community, all in one place.Go to book.lifestarr.com to lock it in.This deal goes away when the book drops, October 6, 2025, and it's not coming back.Pre-order the book. Upload your receipt. You're in. For good.

Guest: Diana Kelley, CSO at Protect AI  Topics: Can you explain the concept of "MLSecOps" as an analogy with DevSecOps, with 'Dev' replaced by 'ML'? This has nothing to do with SecOps, right? What are the most critical steps a CISO should prioritize when implementing MLSecOps within their organization? What gets better  when you do it? How do we adapt traditional security testing, like vulnerability scanning, SAST, and DAST, to effectively assess the security of machine learning models? Can we? In the context of AI supply chain security, what is the essential role of third-party assessments, particularly regarding data provenance? How can organizations balance the need for security logging in AI systems with the imperative to protect privacy and sensitive data? Do we need to decouple security from safety or privacy? What are the primary security risks associated with overprivileged AI agents, and how can organizations mitigate these risks?  Top differences between LLM/chatbot AI security vs AI agent security?  Resources: “Airline held liable for its chatbot giving passenger bad advice - what this means for travellers” “ChatGPT Spit Out Sensitive Data When Told to Repeat ‘Poem' Forever” Secure by Design for AI by Protect AI “Securing AI Supply Chain: Like Software, Only Not” OWASP Top 10 for Large Language Model Applications OWASP Top 10 for AI Agents  (draft) MITRE ATLAS “Demystifying AI Security: New Paper on Real-World SAIF Applications” (and paper) LinkedIn Course: Security Risks in AI and ML: Categorizing Attacks and Failure Modes

ABOUT JON HYMANJon Hyman is the co-founder and chief technology officer of Braze, the customer engagement platform that delivers messaging experiences across push, email, in-app, and more. He leads the charge for building the platform's technical systems and infrastructure as well as overseeing the company's technical operations and engineering team.Prior to Braze, Jon served as lead engineer for the Core Technology group at Bridgewater Associates, the world's largest hedge fund. There, he managed a team that maintained 80+ software assets and was responsible for the security and stability of critical trading systems. Jon met cofounder Bill Magnuson during his time at Bridgewater, and together they won the 2011 TechCrunch Disrupt Hackathon. Jon is a recipient of the SmartCEO Executive Management Award in the CIO/CTO Category for New York. Jon holds a B.A. from Harvard University in Computer Science.ABOUT BRAZEBraze is the leading customer engagement platform that empowers brands to Be Absolutely Engaging.™ Braze allows any marketer to collect and take action on any amount of data from any source, so they can creatively engage with customers in real time, across channels from one platform. From cross-channel messaging and journey orchestration to Al-powered experimentation and optimization, Braze enables companies to build and maintain absolutely engaging relationships with their customers that foster growth and loyalty. The company has been recognized as a 2024 U.S. News & World Report Best Companies to Work For, 2024 Best Small & Medium Workplaces in Europe by Great Place to Work®, 2024 Fortune Best Workplaces for Women™ by Great Place to Work® and was named a Leader by Gartner® in the 2024 Magic Quadrant™ for Multichannel Marketing Hubs and a Strong Performer in The Forrester Wave™: Email Marketing Service Providers, Q3 2024.  Braze is headquartered in New York with 15 offices across North America, Europe, and APAC. Learn more at braze.com.SHOW NOTES:What Jon learned from being the only person on call for his company's first four years (2:56)Knowing when it's time to get help managing your servers, ops, scaling, etc. (5:42)Establishing areas of product ownership & other scaling lessons from the early days (9:25)Frameworks for conversations on splitting of products across teams (12:00)The challenges, complexities & strategies behind assigning ownership in the early days (14:40)Founding Braze (18:01)Why Braze? The story & insights behind the original vision for Braze (20:08)Identifying Braze's product market fit (22:34)Early-stage PMF challenges faced by Jon & his co-founders (25:40)Pivoting to focus on enterprise customers (27:48)“Let's integrate the SDK right now” - founder-led sales ideas to validate your product (29:22)Behind the decision to hire a chief revenue officer for the first time (34:02)The evolution of enterprise & its impact on Braze's product offering (36:42)Growing out of your early-stage failure modes (39:00)Why it's important to make personnel decisions quickly (41:22)Setting & maintaining a vision pre IPO vs. post IPO (44:21)Jon's next leadership evolution & growth areas he is focusing on (49:50)Rapid fire questions (52:53)LINKS AND RESOURCESWhen We Cease to Understand the World - Benjamín Labatut's fictional examination of the lives of real-life scientists and thinkers whose discoveries resulted in moral consequences beyond their imagining. At a breakneck pace and with a wealth of disturbing detail, Labatut uses the imaginative resources of fiction to tell the stories of Fritz Haber, Alexander Grothendieck, Werner Heisenberg, and Erwin Schrödinger, the scientists and mathematicians who expanded our notions of the possible.This episode wouldn't have been possible without the help of our incredible production team:Patrick Gallagher - Producer & Co-HostJerry Li - Co-HostNoah Olberding - Associate Producer, Audio & Video Editor https://www.linkedin.com/in/noah-olberding/Dan Overheim - Audio Engineer, Dan's also an avid 3D printer - https://www.bnd3d.com/Ellie Coggins Angus - Copywriter, Check out her other work at https://elliecoggins.com/about/

We are joined by Francois Chollet and Mike Knoop, to launch the new version of the ARC prize! In version 2, the challenges have been calibrated with humans such that at least 2 humans could solve each task in a reasonable task, but also adversarially selected so that frontier reasoning models can't solve them. The best LLMs today get negligible performance on this challenge. https://arcprize.org/SPONSOR MESSAGES:***Tufa AI Labs is a brand new research lab in Zurich started by Benjamin Crouzier focussed on o-series style reasoning and AGI. They are hiring a Chief Engineer and ML engineers. Events in Zurich. Goto https://tufalabs.ai/***TRANSCRIPT:https://www.dropbox.com/scl/fi/0v9o8xcpppdwnkntj59oi/ARCv2.pdf?rlkey=luqb6f141976vra6zdtptv5uj&dl=0TOC:1. ARC v2 Core Design & Objectives [00:00:00] 1.1 ARC v2 Launch and Benchmark Architecture [00:03:16] 1.2 Test-Time Optimization and AGI Assessment [00:06:24] 1.3 Human-AI Capability Analysis [00:13:02] 1.4 OpenAI o3 Initial Performance Results2. ARC Technical Evolution [00:17:20] 2.1 ARC-v1 to ARC-v2 Design Improvements [00:21:12] 2.2 Human Validation Methodology [00:26:05] 2.3 Task Design and Gaming Prevention [00:29:11] 2.4 Intelligence Measurement Framework3. O3 Performance & Future Challenges [00:38:50] 3.1 O3 Comprehensive Performance Analysis [00:43:40] 3.2 System Limitations and Failure Modes [00:49:30] 3.3 Program Synthesis Applications [00:53:00] 3.4 Future Development RoadmapREFS:[00:00:15] On the Measure of Intelligence, François Chollethttps://arxiv.org/abs/1911.01547[00:06:45] ARC Prize Foundation, François Chollet, Mike Knoophttps://arcprize.org/[00:12:50] OpenAI o3 model performance on ARC v1, ARC Prize Teamhttps://arcprize.org/blog/oai-o3-pub-breakthrough[00:18:30] Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, Jason Wei et al.https://arxiv.org/abs/2201.11903[00:21:45] ARC-v2 benchmark tasks, Mike Knoophttps://arcprize.org/blog/introducing-arc-agi-public-leaderboard[00:26:05] ARC Prize 2024: Technical Report, Francois Chollet et al.https://arxiv.org/html/2412.04604v2[00:32:45] ARC Prize 2024 Technical Report, Francois Chollet, Mike Knoop, Gregory Kamradthttps://arxiv.org/abs/2412.04604[00:48:55] The Bitter Lesson, Rich Suttonhttp://www.incompleteideas.net/IncIdeas/BitterLesson.html[00:53:30] Decoding strategies in neural text generation, Sina Zarrießhttps://www.mdpi.com/2078-2489/12/9/355/pdf

 In this Tactics for Tech Leadership podcast episode, Andy and Mon-Chaio explore SWIFT (Structured What If Technique). While traditionally seen as a technical tool for failure analysis, the hosts consider its potential applications in leadership and organizational contexts. Listeners will learn how SWIFT can help anticipate system failures even before they occur, from technical systems like Redis caches to social-technical systems like performance reviews and hiring processes. By the end, you'll understand how to adapt this structured method for diagnosing issues and improving both technical and organizational systems.Transcript: https://thettlpodcast.com/2025/03/18/s3e10-swiftly-understanding-failure-modes/ReferencesSWIFT - https://www.asems.mod.uk/toolkit/swift

# Full transcription available at [heartsofgoldpodcast.com](http://heartsofgoldpodcast.com/)   ## Episode Summary   Makayla Hoefs shares the inspiring story behind her Girl Scout Gold Award project, *"Coding for Cookies."* This innovative initiative bridges Girl Scouts and robotics, offering young girls hands-on STEM experiences through engaging events. Makayla discusses how her project evolved, collaborating with the Minnesota and Wisconsin Lakes & Pines Council, and making the program sustainable for future generations. Listen to hear about the impact she's made, the challenges she faced, and how she encourages girls to explore STEM fields.   ## More from Makayla   My name is Makayla Hoefs from Becker, Minnesota. I am a senior at Becker High School, and I plan on going to a four-year college next fall to get my master's degree in electrical engineering.   I have been a Girl Scout for about ten years. Throughout my time in Girl Scouts, I have earned my Bronze and Silver Awards and have completed many service projects. Last year, I was a Girl Scout delegate for my service unit.   I am also involved in Student Council, National Honors Society, archery, and robotics. This is my fourth year on the Becker Robotics team, *C.I.S. 4607.* I am part of the electrical department and facilitate *Failure Modes and Effects Analysis.* My time in robotics has inspired me to become an engineer and a woman in STEM.   ## What You'll Learn in This Episode   - How *"Coding for Cookies"* introduced over 100 Girl Scouts to robotics   - The collaboration between Makayla's robotics team and the Girl Scout council   - Challenges in creating sustainable robotics kits   - Makayla's advice for Gold Award candidates and key lessons from the process   ## Follow Makayla's Journey   Check out the resources from her project at [Coding for Cookies](https://sites.google.com/frc4607cis.com/cis4607/coding-for-cookies)   ## Connect with Us   Follow *Hearts of Gold* for more inspiring Gold Award stories. Don't forget to follow or subscribe and leave a review!  

Send us a Text Message.Ready to transform your team meetings from chaotic to cohesive? Discover a method used by Six Sigma practitioners, continuous improvement teams, and design sprints to make your meetings more effective and efficient. We'll guide you through the phases of discovery, examination, and prioritization to streamline idea generation and ensure that every team member's input is valued. You'll learn techniques for individual brainstorming, anonymous idea sharing, and collective refinement, making your meetings not just productive but a crucial part of your design process.But that's not all. We dive into the utilization of quality tools for superior team decision-making during design Failure Modes and Effects Analysis (FMEA). Explore how to categorize and evaluate potential failures, assign severity ratings, and use tools like tree diagrams and fishbone diagrams to organize complex discussions. By focusing on collaboration and consensus, you'll be setting your team up for effective failure analysis. Join us to elevate your team meetings and turn them into a powerhouse of creativity and efficiency.Visit the podcast blog for this episode.Other episodes you might like: Brainstorming within Design SprintsWays to Gather Ideas with a TeamProduct Design with Brainstorming, with Emily Haidemenos (A Chat with Cross Functional Experts)Give us a Rating & Review**NEW COURSE**FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Visit the course page for more information and to sign up today! Click Here **FREE RESOURCES**Quality during Design engineering and new product development is actionable. It's also a mindset. Subscribe for consistency, inspiration, and ideas at www.qualityduringdesign.com.About meDianna Deeney helps product designers work with their cross-functional team to reduce concept design time and increase product success, using quality and reliability methods. She consults with businesses to incorporate quality within their product development processes. She also coaches individuals in using Quality during Design for their projects.She founded Quality during Design through her company Deeney Enterprises, LLC. Her vision is a world of products that are easy to use, dependable, and safe – possible by using Quality during Design engineering and product development.

What is an FMEA? When should you use it? Why is it an important step in helping maintenance teams move from a break-fix maintenance state to one that is more proactive? In this episode of Great Queston: A Manufacturing Podcast, Plant Services editor in chief Thomas Wilk spoke with a specialist in the reliability field, Brian Hronchek, to start answering these questions and more about failure modes and effects analyses. Brian draws from his former experience as reliability engineer for U.S. Steel, maintenance manager for Exxon Mobil, and a 16-year veteran of the Marine Corps, in addition to his current work as a principal trainer and consultant at Eruditio.

A couple years ago, my agency asked me to write some guidance on sediment modeling, so, I reached out to the morphological modelers I knew, and particularly the model developers who write the morphological model code other people use.I asked them about the common failure modes they have seen and best practices they teach, and realized we had all essentially spent a decade or two, learning the same principles. So when the US federal agencies held their periodic Federal interagency sediment conference (SEDHYD) last year, I invited three of the model developers I have learned from over the years (Alex Sanchez, Gary Brown, and Blair Greimann), to participate in a panel discussion on their lessons learned.And the panel was much more popular than we expected.  It turns out, there's appetite conversations like this.  So, I turned on the mics and we did a little editing, and we're running it here.Here are brief bios for our guests.:Gary Brown did his graduate work at the university of Florida and works at the Coastal and Hydraulics Lab which is part of ERDC, the Corp's major R&D center in Vicksburg Mississippi.   He's been developing sediment models for 29 years including SEDLIB, a set of sediment algorithms that are called by ERDC's hydraulic model, ADH or Adaptive hydraulics.  Alex Sanchez sits in the office next to me.  For the last 9 years, he has worked here at HEC and spearheaded the work to add 2D sediment to HEC-RAS which includes a novel formulation for the sub-grid approach.  But actually Alex started developing sediment models at ERDC's Coastal and Hydraulics Lab where he worked for 8 years, while working on the Coastal Modeling System which is still used for Corps of Engineers coastal applications.  Blair Greimann got his PhD from the University of Iowa and worked at the Bureau of Reclamation's Technical Service Center in Denver for more than 23 years, before his recent move to Stantec.  While working at the Bureau Blair led the development of SRH-1D and applied this model to a range of projects including the Matilija and and Klamath Dam removals.Finally, we were lucky enough to have Doug Shields moderating this session so you will hear from him in the breaks between the four sub-topics.  Dr. Shields, worked for more than 20 years at the Sedimentation Lab of the Agricultural Resource Center in Oxford MS and 10 years at ERDC and has taught at both Tennessee State and Old Miss and we were fortunate to draw Doug as a moderator.  (Note: I did not mic Doug, but wanted to keep his thoughtful and winsome transitions, so his sound quality is not at the same level as the rest of the recording).After Doug and I introduced the session you will hear from Blair Greimann, Alex Sanchez, me again, and Gary Brown in that order.The conference paper associated with this session is here:https://www.sedhyd.org/2023Program/1/157.pdfThank you to the SEDHYD organizers (including but not limited to ) for hosting this conversationThis series was funded by the Regional Sediment Management (RSM) program.Stanford Gibson (HEC Sediment Specialist) hosts.Mike Loretto edited the episode and wrote and performed the music.Video shorts and other bonus content are available at the podcast website (which was temporarily down but is back up now):https://www.hec.usace.army.mil/confluence/rasdocs/rastraining/latest/the-rsm-river-mechanics-podcast...but most of the supplementary videos are available on the HEC Sediment YouTube channel:https://www.youtube.com/user/stanfordgibsonIf you have guest recommendations or feedback you can reach out to me on LinkedIn or ResearchGate or fill out this recommendation and feedback form: https://forms.gle/wWJLVSEYe7S8Cd248

Quality during Design isn't just an add-on; it's a fundamental aspect that drives innovation, efficiency, and customer satisfaction!Welcome back from our brief hiatus!One of the highlights of this episode is the introduction of an upcoming FMEA course on Udemy, with The Manufacturing Academy. FMEA, or Failure Modes and Effects Analysis, is a systematic method for evaluating our offerings to identify where and how they might fail and to assess the relative impact of different failures.  Dianna's approach to FMEA is not only about adhering to traditional methods but also about addressing the criticisms and limitations often associated with them. This course promises to be a fresh take on risk-based decision-making. You'll hear more about it when it is released!Moreover, the episode touches upon the 'Quality During Design Fast Track' program, which is currently in the works and open to listener feedback. The initiative aims to harness quality tools in novel ways, even before a design concept is fully fleshed out. It emphasizes the importance of early input from cross-functional teams to gather requirements and user needs, thereby making the design process more effective and efficient. This program is system-based and affects how products and services are developed, leading to more thoughtful, user-centric designs.Listeners are invited: please take brief survey to help Dianna with aspects of these upcoming courses and more.  www.qualityduringdesign.com/surveySupport the show**FREE RESOURCES**Quality during Design engineering and new product development is actionable. It's also a mindset. Subscribe for consistency, inspiration, and ideas at www.qualityduringdesign.com. About meDianna Deeney helps product designers work with their cross-functional team to reduce concept design time and increase product success, using quality and reliability methods. She consults with businesses to incorporate quality within their product development processes. She also coaches individuals in using Quality during Design for their projects.She founded Quality during Design through her company Deeney Enterprises, LLC. Her vision is a world of products that are easy to use, dependable, and safe – possible by using Quality during Design engineering and product development.

Welcome to The Nonlinear Library, where we use Text-to-Speech software to convert the best writing from the Rationalist and EA communities into audio. This is: What rationality failure modes are there?, published by Ulisse Mini on January 19, 2024 on LessWrong. How do people fail to improve their rationality? How do they accidentally harm themselves in the process? I'm thinking of writing a post "How not to improve your rationality" or "A nuanced guide to reading the sequences" that preempts common mistakes, and I'd appreciate hearing people's experiences. Some examples: It took me an absurdly long time (like, 1-2yr in the rat community) before I realized you don't correct for cognitive biases, you have to "be introspectively aware of the bias occuring, and remain unmoved by it" (as Eliezer put it in a podcast) More generally, people can read about a bias and resolve to "do better" without concretely deciding what to do differently. This typically makes things worse, e.g. I have a friend who tried really hard to avoid the typical mind fallacy, and accidentally turned off her empathy in the process. The implicit frame rationalists push is logical and legible, and can lead to people distrusting their emotions. And I think it's really important to listen to listen to ick feelings when changing your thought processes, as there can be non obvious effects. E.g. My friend started thinking about integrity in terms of FDT, and this disconnected it from their motivational circuits and they made some pretty big mistakes because of it. If they'd listened to their feeling of "this is a weird way to think" this wouldn't have happened. (I think many people misinterpret sequence posts and decide to change their thinking in bad ways, and listening to your feelings can be a nice emergency check.) Thanks for listening. To help us out with The Nonlinear Library or to learn more, please visit nonlinear.org

Link to original articleWelcome to The Nonlinear Library, where we use Text-to-Speech software to convert the best writing from the Rationalist and EA communities into audio. This is: What rationality failure modes are there?, published by Ulisse Mini on January 19, 2024 on LessWrong. How do people fail to improve their rationality? How do they accidentally harm themselves in the process? I'm thinking of writing a post "How not to improve your rationality" or "A nuanced guide to reading the sequences" that preempts common mistakes, and I'd appreciate hearing people's experiences. Some examples: It took me an absurdly long time (like, 1-2yr in the rat community) before I realized you don't correct for cognitive biases, you have to "be introspectively aware of the bias occuring, and remain unmoved by it" (as Eliezer put it in a podcast) More generally, people can read about a bias and resolve to "do better" without concretely deciding what to do differently. This typically makes things worse, e.g. I have a friend who tried really hard to avoid the typical mind fallacy, and accidentally turned off her empathy in the process. The implicit frame rationalists push is logical and legible, and can lead to people distrusting their emotions. And I think it's really important to listen to listen to ick feelings when changing your thought processes, as there can be non obvious effects. E.g. My friend started thinking about integrity in terms of FDT, and this disconnected it from their motivational circuits and they made some pretty big mistakes because of it. If they'd listened to their feeling of "this is a weird way to think" this wouldn't have happened. (I think many people misinterpret sequence posts and decide to change their thinking in bad ways, and listening to your feelings can be a nice emergency check.) Thanks for listening. To help us out with The Nonlinear Library or to learn more, please visit nonlinear.org

This episode features a conversation between host, Sera Evcimen, and Alan Cohen, author of 'Prototype to Product: A Practical Guide for Getting to Market'. They delve into the complexities, misconceptions and opportunities in medical device development. The discussion includes the importance of generating good requirements, handling regulatory requirements, and conducting risk analysis. They also highlight the value of hiring experts conversant in both engineering and regulatory matters to guide a startup through navigating the FDA and EU approval processes.You can find his consultancy at www.alancohen.com.Rundown of Episode for easy navigation to topics of interest:00:00 Introduction and Host Background00:58 Guest Introduction: Alan Cohen01:32 Alan Cohen's Background and Experience02:37 Challenges in Medical Device Development05:40 Identifying a Hardware Medical Application Need07:48 Understanding Reimbursement and Business Models09:32 Regulatory Bodies and Compliance12:50 Risk Assessment in Medical Device Development21:22 Fault Tree Analysis vs Failure Modes and Effects Analysis27:48 Balancing Documentation and Process in Medical Device Development33:01 Understanding Development Process Standards33:19 Importance of Following Your Process33:42 Inspection and Audit Procedures34:16 Balancing FDA Requirements and Lean Operations35:13 Testing and Validation in Medical Device Development36:43 Navigating FDA and Institutional Review Boards40:02 Challenges in Medical Device Innovation and Funding47:16 Podcast Break47:29 Podcast break56:02 Navigating Supply Chain and Manufacturing Challenges01:04:09 Understanding FDA and EU Regulatory Differences01:07:00 Final Thoughts and Advice for Medical Device StartupsEnding with TLDL!Music by: Tom Stoke (in addition to royalty-free music provided by Descript)DISCLAIMER The content provided in this podcast is for informational purposes only and should not be construed as professional advice. Pratik Development, LLC., the hosts, guests, and producers of this podcast are not engaged in rendering legal, financial, or other professional services. The hosts and guests disclaim any liability for any errors or omissions in the content or for any actions taken based on the information provided. By accessing and listening to this podcast, you acknowledge and agree that the hosts, guests, and producers of the podcast shall not be held liable for any direct, indirect, incidental, consequential, or any other damages arising out of or in connection with the use of the information presented in the podcast. Furthermore, the hosts, guests, and producers of this podcast make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability of the information, products, services, or related graphics contained in the podcast for any purpose. Listeners are advised to independently verify any information presented and consult with appropriate professionals before making any decisions or taking any actions based on the content of this podcast. By continuing to listen to this podcast, you indicate your understanding and acceptance of this disclaimer.

In this special episode of Quality during Design Redux, we're pulling episodes from our archive about test results analysis. In our Season 1 - Episode 93  titled "The Fundamental Thing to Know from Statistics for Design Engineering", we talked about hypothesis testing: how it is used for lots of data analysis techniques. The next 4 episodes of this QDD Redux are taking the next steps._________________________________________If we're not careful with or ignore failure modes, we can choose the wrong reliability model or statistical distribution. If our product performance is close to the required limits and/or we need a very accurate model, this could be a big problem.We talk about the importance of failure modes and step-through a tensile-test example to explore these other topics:competing failure modessuspensionsindependent vs. dependentreliability block diagramsThe podcast blog includes extra useful information/links.Support the show**FREE RESOURCES**Quality during Design engineering and new product development is actionable. It's also a mindset. Subscribe for consistency, inspiration, and ideas at www.qualityduringdesign.com. About meDianna Deeney helps engineers work with their cross-functional team to reduce concept design time and increase product success, using quality and reliability methods. She founded Quality during Design through her company Deeney Enterprises, LLC. Her vision is a world of products that are easy to use, dependable, and safe – possible by using Quality during Design engineering and product development.

Assets Anonymous is a 12-step podcast series designed to help you get grounded in reliability basics and create a culture of continuous improvement with your team. This series will feature interviews with George Williams and Joe Anderson of ReliabilityX. ReliabilityX aims to bridge the gap between operations and maintenance through holistic reliability focused on plant performance. In this episode, George and Joe help you understand how your facility's critical assets fail.

Haley is a geotechnical engineer who recently completed her PhD at the University of Alberta.  Amongst other things, Haley and I discuss her CDA award winning paper titled, "A Failure Modes and Effects Analysis Framework for Assessing Geotechnical Risks of Tailings Dam Closure" which was published in the Journal "Minerals".

In this episode we explore what Condition Based Maintenance (CBM) is (aka On-Condition Maintenance).  We'll talk about :- What CBM is- The biggest trap you can fall into when implementing CBM- And what governs how often you do a Condition Based Maintenance task.As asset managers, we know that most Failure Modes occur randomly, and that can seem a little intimidating or maybe even a little scary, but it doesn't have to be because that's where Condition Based Maintenance can be very helpful. The whole point of Condition Based Maintenance is to detect a Potential Failure Condition and take action before failure occurs.  That interval is called the P-F Interval and that is explained in this episode.Free Reliability Centered Maintenance (RCM) Overview Coursehttps://RCMTrainingOnline.com/OverviewLet's get connected on LinkedIn!https://www.linkedin.com/in/nancyreganrcm/

In this episode, we talk about what a Failure Mode is and why Failure Modes are so important to equipment Reliability.  As responsible custodians, it's up to us to identify the plausible Failure Modes that could occur so that we can figure out if and how we should manage each one.  If we don't, it can end up in disaster. Free Reliability Centered Maintenance (RCM) Overview Coursehttps://RCMTrainingOnline.com/OverviewLet's get connected on LinkedIn!https://www.linkedin.com/in/nancyreganrcm

We continue to explore mechanisms of how our cognitive system can be hijacked, leading to a breakdown and failure of natural intelligence. ======= Produced by Inqwire, a public benefit corporation on a mission to help create a world that makes sense. Inqwire is a technology platform designed to restore, enhance, and protect our natural ability to navigate towards what makes sense, alone and together. Learn more: https://www.inqwire.io/

We explore the core vulnerability of our cognitive system that allows for our natural intelligence to fail. ======= Produced by Inqwire, a public benefit corporation on a mission to help create a world that makes sense. Inqwire is a technology platform designed to restore, enhance, and protect our natural ability to navigate towards what makes sense, alone and together. Learn more: https://www.inqwire.io/

Welcome to The Nonlinear Library, where we use Text-to-Speech software to convert the best writing from the Rationalist and EA communities into audio. This is: ML Systems Will Have Weird Failure Modes, published by jsteinhardt on January 26, 2022 on LessWrong. Previously, I've argued that future ML systems might exhibit unfamiliar, emergent capabilities, and that thought experiments provide one approach towards predicting these capabilities and their consequences. In this post I'll describe a particular thought experiment in detail. We'll see that taking thought experiments seriously often surfaces future risks that seem "weird" and alien from the point of view of current systems. I'll also describe how I tend to engage with these thought experiments: I usually start out intuitively skeptical, but when I reflect on emergent behavior I find that some (but not all) of the skepticism goes away. The remaining skepticism comes from ways that the thought experiment clashes with the ontology of neural networks, and I'll describe the approaches I usually take to address this and generate actionable takeaways. Thought Experiment: Deceptive Alignment Recall that the optimization anchor runs the thought experiment of assuming that an ML agent is a perfect optimizer (with respect to some "intrinsic" reward function R). I'm going to examine one implication of this assumption, in the context of an agent being trained based on some "extrinsic" reward function R∗ (which is provided by the system designer and not equal to R). Specifically, consider a training process where in step t, a model has parameters θt and generates an action at (its output on that training step, e.g. an attempted backflip assuming it is being trained to do backflips). The action at is then judged according to the extrinsic reward function R∗, and the parameters are updated to some new value θt+1 that are intended to increase at+1's value under R∗. At some point, the model is then deployed with final parameters θT, and continues to take actions. The following diagram illustrates this process: Now, let's assume that the model θt is a perfect optimizer whose objective is to maximize the discounted value of an intrinsic reward R≠R∗. That is, θt picks the action at satisfying at=argmaxaE[∑∞s=0γ−sR(at+s)∣at=a]. (I know that this is an unrealistic assumption. We'll examine the assumption in detail in the next section, but for now please grant it even if it requires suspending disbelief.) What action at will θt pick? Let's define aR=argmaxaR(a) and a∗=argmaxaR∗(a)--that is, aR maximizes the (instantaneous) intrinsic reward while a∗ maximizes the extrinsic reward. Assuming that γ is close to 1, the model wants aR to be picked on as many future rounds as possible (including at deployment time). If θt plays myopically, this means it would pick at=aR. However, this is not the optimal non-myopic action: if at=aR, then θt+1 will be updated towards producing outputs less like aR and more like a∗, so outputting aR in the current round leads to fewer aR outputs in future rounds. Instead, I think the optimal non-myopic action is approximately the following: during training time, output a∗ on every time step, so that the training process doesn't update θ (since it's already optimal) and hence θt=θt+1=⋯=θT. This guarantees that the deployed agent is θt, which is now free to output aR on every time step without risk of being modified by the training process.[1] The myopic and non-myopic outcomes are illustrated in the figure below: Myopic and non-myopic agents with an intrinsic reward, R. The myopic agent plays high intrinsic-reward actions during training, but is eventually modified to output action a∗ with high extrinsic reward R∗. The non-myopic agent instead plays a∗ during training so that it can pursue its intrinsic reward at deployment, by playing aR at all post-deployment time steps. To put it another way–the model's behavior will look aligned with R∗ during the training process...

Link to original articleWelcome to The Nonlinear Library, where we use Text-to-Speech software to convert the best writing from the Rationalist and EA communities into audio. This is: ML Systems Will Have Weird Failure Modes, published by jsteinhardt on January 26, 2022 on LessWrong. Previously, I've argued that future ML systems might exhibit unfamiliar, emergent capabilities, and that thought experiments provide one approach towards predicting these capabilities and their consequences. In this post I'll describe a particular thought experiment in detail. We'll see that taking thought experiments seriously often surfaces future risks that seem "weird" and alien from the point of view of current systems. I'll also describe how I tend to engage with these thought experiments: I usually start out intuitively skeptical, but when I reflect on emergent behavior I find that some (but not all) of the skepticism goes away. The remaining skepticism comes from ways that the thought experiment clashes with the ontology of neural networks, and I'll describe the approaches I usually take to address this and generate actionable takeaways. Thought Experiment: Deceptive Alignment Recall that the optimization anchor runs the thought experiment of assuming that an ML agent is a perfect optimizer (with respect to some "intrinsic" reward function R). I'm going to examine one implication of this assumption, in the context of an agent being trained based on some "extrinsic" reward function R∗ (which is provided by the system designer and not equal to R). Specifically, consider a training process where in step t, a model has parameters θt and generates an action at (its output on that training step, e.g. an attempted backflip assuming it is being trained to do backflips). The action at is then judged according to the extrinsic reward function R∗, and the parameters are updated to some new value θt+1 that are intended to increase at+1's value under R∗. At some point, the model is then deployed with final parameters θT, and continues to take actions. The following diagram illustrates this process: Now, let's assume that the model θt is a perfect optimizer whose objective is to maximize the discounted value of an intrinsic reward R≠R∗. That is, θt picks the action at satisfying at=argmaxaE[∑∞s=0γ−sR(at+s)∣at=a]. (I know that this is an unrealistic assumption. We'll examine the assumption in detail in the next section, but for now please grant it even if it requires suspending disbelief.) What action at will θt pick? Let's define aR=argmaxaR(a) and a∗=argmaxaR∗(a)--that is, aR maximizes the (instantaneous) intrinsic reward while a∗ maximizes the extrinsic reward. Assuming that γ is close to 1, the model wants aR to be picked on as many future rounds as possible (including at deployment time). If θt plays myopically, this means it would pick at=aR. However, this is not the optimal non-myopic action: if at=aR, then θt+1 will be updated towards producing outputs less like aR and more like a∗, so outputting aR in the current round leads to fewer aR outputs in future rounds. Instead, I think the optimal non-myopic action is approximately the following: during training time, output a∗ on every time step, so that the training process doesn't update θ (since it's already optimal) and hence θt=θt+1=⋯=θT. This guarantees that the deployed agent is θt, which is now free to output aR on every time step without risk of being modified by the training process.[1] The myopic and non-myopic outcomes are illustrated in the figure below: Myopic and non-myopic agents with an intrinsic reward, R. The myopic agent plays high intrinsic-reward actions during training, but is eventually modified to output action a∗ with high extrinsic reward R∗. The non-myopic agent instead plays a∗ during training so that it can pursue its intrinsic reward at deployment, by playing aR at all post-deployment time steps. To put it another way–the model's behavior will look aligned with R∗ during the training process...

What are Failure Modes and Effects Analysis (FMEA) and inductive safety analysis? With FMEA, you try to induce failure at a higher level. FMEA is a bottom-up approach. Why would we do this? Because we know the effects of the failure. Now, we're trying to understand what is causing the failure. Hear more of Praveen Suvarna explanation here #FuSa #safetyanalysis #FMEA #functionalsafety #functionaltesting #iso26262 #autonomousvehicles #iso21434

In this webinar, John Bernet from Fluke Reliability will discuss best practices for applying root cause analysis and expected failure modes to motor-drive systems. You will learn the simple steps of total condition maintenance, how different inspection techniques from electrical to thermal can help identify different failure modes, and how vibration analysis in particular can find the most common mechanical faults on rotating machines. We will wrap up with a discussion on the obstacles teams may face when starting a reliability program and learn from those who have succeeded. Register for an upcoming webinar at: https://flukereliability.info/bpw-frr Learn more about Accelix at: https://flukereliability.info/accelix

For every action taken to maintain a piece of equipment, a Failure Mode—or cause of failure—is managed. That is why a Failure Modes and Effects Analysis (FMEA) is an essential part of physical asset management. When done properly, an FMEA helps organizations: 1) Define equipment goals, 2) Identify what could cause Reliability to suffer, and 3) Assign criticality. Join Nancy as she shares how to avoid common FMEA pitfalls, and how to use a properly executed FMEA to make effective maintenance decisions. Register for an upcoming webinar here: https://www.accelix.com/best-practice-webinars/ (flukereliability.info/bpw)

In this episode, Corey and I discuss the use of risk analyses for improving the design and operation of tailings and other facilities. We discuss the use of Failure Modes and Effects Analyses (FMEAs) and bowtie analyses.

An asset is a collection of failure modes, manage the failure modes and you manage the asset... This is a quote from our guest this week, Tacoma Zach! In this episode we discuss failure modes, operating context, and a whole lot more. Asset management is one of Tacoma's passions and we were lucky to corner him for an hour to discuss! Connect with our Guest Here: Tacoma Zach - https://www.linkedin.com/in/tacoma-zach-p-eng-0913514/ www.mentorapm.com www.uberlytics.com If your company sells products or services to engaged maintenance & reliability professionals, tell your marketing manager about Maintenance Disrupted. If you'd like to discuss advertising, please email us at maintenancedisrupted@gmail.com Check out our website at www.maintenancedisrupted.com and sign up for the weekly disruption newsletter with bonus content. If you like the show, please tell your colleagues about it and follow maintenance disrupted on LinkedIn and YouTube. Follow Maintenance Disrupted on LinkedIn https://www.linkedin.com/company/maintenancedisrupted Music: The Descent by Kevin MacLeod Link: https://incompetech.filmmusic.io/song/4490-the-descent License: http://creativecommons.org/licenses/by/4.0/

If we're not careful with or ignore failure modes, we can choose the wrong reliability model or statistical distribution. If our product performance is close to the required limits and/or we need a very accurate model, this could be a big problem.We talk about the importance of failure modes and step-through a tensile-test example to explore these other topics:competing failure modessuspensionsindependent vs. dependentreliability block diagramsThe podcast blog includes extra useful information/links.Support the show

Nancy Regan has a degree in Aerospace Engineering and founded The Force, a company focusing on Reliability Centered Maintenance. In addition to being an engineer and entrepreneur, she also holds six patents, is an author and a key note speaker. Episode NotesMusic used in the podcast: Higher Up, Silverman Sound StudioAcronyms, Definitions, and Fact CheckReliability Centered Maintenance (RCM) - A lot of organizations don't get the Reliability they need from their equipment.  That causes chronic downtime, increased costs, and lost production.  Using Reliability Centered Maintenance (RCM), organizations figure out what proactive maintenance to do so they get what they need from their machines (https://RCMTrainingOnline.com).RCM Consists of seven steps:FunctionsFunctional FailuresFailure ModesFailure EffectsFailure ConsequencesProactive Maintenance and IntervalsDefault StrategiesSteps one through four make up the Failure Modes and Effects Analysis (FMEA).  Steps one through five make up the Failure Modes, Effects, and Criticality Analysis (FMECA).  Step six embodies preventive maintenance and Condition Based Maintenance (CBM)."The One Thing" by Gary Keller. The book discusses the benefits of prioritizing a single task, and it also provides examples of how to engage in those tasks with a singular focus.Embry-Riddle Aeronautical University - a private university focused on aviation and aerospace programs with its main campuses in Daytona Beach, Florida. Women make up 27% of enrollment currently. (Wikipedia)Naval Air Warfare Center Aircraft Division (NAWCAD) Lakehurst is the world leader in Aircraft Launch and Recovery Equipment (ALRE) and Naval Aviation Support Equipment (SE). It is part of the Naval Air Systems Command (NAVAIR) and is located on Joint Base McGuire-Dix-Lakehurst (JB MDL) in central New Jersey. As the Navy's lead engineering support activity for ALRE and SE, NAWCAD Lakehurst conducts programs of acquisition management, technology development, systems integration, engineering, rapid prototyping / manufacturing, developmental evaluation and verification, fleet engineering support and integrated logistics support management. NAWCAD Lakehurst is responsible for maintaining fleet support and infusing modern technology across the entire spectrum of equipment needed to launch, land and maintain aircraft from ships at sea and austere expeditionary airfields. (navair.navy.mil)The USS Midway Museum is a historical naval aircraft carrier museum located in downtown San Diego, California at Navy Pier. The museum consists of the aircraft carrier Midway. The ship houses an extensive collection of aircraft, many of which were built in Southern California. (wikipedia)

Using Failure Modes and Effects Analysis to improve special-order implant procurement by AORNJournal

Manufacturers struggle to manage product quality, achieve on-time delivery, and reduce product and process risks. However, one of their most important assets – employees – should also be included in failure modes and effect analysis (FMEA) risk assessment. This webinar will identify key risk areas affecting workers and how FMEA can identify and manage those risks for a safer work environment. You are listening to audio from a webinar in the Safety+Health Webinar Series presented on July 11, 2019, by Kelly Kuchinski, Quality and Document Control Product Marketing Manager, Cority. Watch the archived webinar video to see the presenter's slides at https://www.safetyandhealthmagazine.com/events/143-quality-up-injuries-down-using-failure-modes-and-effect-analysis-fmea-for-a-safer-work-environment

Manufacturers struggle to manage product quality, achieve on-time delivery, and reduce product and process risks. However, one of their most important assets – employees – should also be included in failure modes and effect analysis (FMEA) risk assessment. This webinar will identify key risk areas affecting workers and how FMEA can identify and manage those risks for a safer work environment. You are listening to audio from a webinar in the Safety+Health Webinar Series presented on July 11, 2019, by Kelly Kuchinski, Quality and Document Control Product Marketing Manager, Cority. Watch the archived webinar video to see the presenter's slides at https://www.safetyandhealthmagazine.com/events/143-quality-up-injuries-down-using-failure-modes-and-effect-analysis-fmea-for-a-safer-work-environment

Oil and gas rig performance integrity is an extremely important capability that involves risk analysis, threat analysis, failure mode and effect analysis, safety, health, environmental safety, situational awareness, and last, but not least, software quality. Software quality plays a very important role in rig performance, and one that is not fully appreciated. In this episode Don Shafer discusses the challenges, pitfalls, and successes with software quality in the oil patch.Don Shafer is a cofounder of the Athens Group and technical fellow. Don developed Athens Group’s oil and gas practice and leads engineers in delivering software services for exploration, production, and pipeline monitoring systems for clients such as BP, Chevron, ExxonMobil, ConocoPhillips, and Shell. He led groups developing and marketing hardware and software products for Motorola, AMD, and Crystal Semiconductor. Don managed a large PC product group producing award-winning audio components for Apple. From the development of low-level software drivers to the selection and monitoring of semiconductor facilities, he has led key product and process efforts. You can connect with Don here:Email: donshafer@athensgroup.com LinkedIn: Don ShaferWeb Site: Athens GroupAbout PPQC:Process and Product Quality Consulting (PPQC) helps global executives tackle complex corporate challenges.To learn more about PPQC, visit www.ppqc.netSupport the show (https://ppqc.net)

On this week's episode, I am joined by John Reeve, co-author of Failure Modes to Failure Codes to talk about computerized maintenance management systems (CMMS). We talk about how we can use a CMMS to facilitate chronic failure analysis, how to properly set up a component list and John gives us his top CMMS tips. Thank you for listening and if you enjoy the show, please subscribe to Rob's Reliability Project on your favourite podcast platform and share it with your colleagues. You can also follow Rob's Reliability Project on LinkedIn and Facebook and check out robsreliability.com as well. If you're looking for a shorter tip, subscribe to Rob's Reliability Tip of the Day on your favorite podcast platform or on your Amazon Alexa as a Flash Briefing. Finally, if there are any topics, guests you'd like to hear from, questions you want answered, or if you'd like to appear on the podcast, email me at robsreliabilityproject@gmail.com Follow Rob's Reliability Project on LinkedIn - https://www.linkedin.com/company/robsreliabilityproject/ Follow Rob's Reliability Project on Facebook - https://www.facebook.com/robsreliabilityproject/ Music by XTaKeRuX, Song: White Crow is licensed under a Creative Commons 4.0 Attribution License.

In this episode, we talk with Dr. Alecia Gabriel of P3 Group North America. Dr. Gabriel serves as the Quality Systems Consultant and brings her experience in project management, automotive and aerospace quality assurance, and automotive consulting to our healthcare platform to talk Failure Modes and Effects Analysis (FMEA). In this first installment of our Beyond Healthcare Quality segment, Alecia will share an outsider view of a powerful quality improvement methodology, the potential that it holds for transforming healthcare, and why its appropriate application and execution should be a key part of your organizational high-reliability strategy.

Jason Millar, Social Failure Modes in Technology: Implications for AI by Centre for Ethics, University of Toronto

Developing Failure Codes with Bill Leahy Failures codes help the reliability engineers to make intelligent business decisions regarding the issues with the assets. It is a formula that helps you understand how an asset fails and how can you gather the needed data to mitigate a failure? A good failure code contains a hierarchy of […] The post 142 – Developing Failure Codes with Bill Leahy appeared first on Accendo Reliability.

This week, I welcome Mark Benak on to the podcast. Mark is the VP of Business Ventures at Uptake. We talk about why merging a library of failure modes with artificial intelligence makes stronger predictive analytics. Follow Mark Benak on LinkedIn - https://www.linkedin.com/in/mbenak/ Thank you for listening and if you enjoy the show, please subscribe to Rob's Reliability Project on your favourite podcast platform and share it with your colleagues. You can also follow Rob's Reliability Project on LinkedIn and Facebook and check out robsreliability.com as well. If you're looking for a shorter tip, subscribe to Rob's Reliability Tip of the Day on your favorite podcast platform or on your Amazon Alexa as a Flash Briefing. Finally, if there are any topics, guests you'd like to hear from, questions you want answered, or if you'd like to appear on the podcast, email me at robsreliabilityproject@gmail.com Follow Rob's Reliability Project on LinkedIn - https://www.linkedin.com/company/robsreliabilityproject/ Follow Rob's Reliability Project on Facebook - https://www.facebook.com/robsreliabilityproject/ Music by XTaKeRuX, Song: White Crow is licensed under a Creative Commons 4.0 Attribution License.

On this follow-up deep dive episode of “Leader Dialogue“, CHIME CEO Russ Branzell again joins Ben, Jennifer and Duffie to discuss the two common Strategy Execution failure modes resulting from five (5) commonly held strategy execution myths. (Adapted from the research of: Donald Sull, MIT Sloan School of Management, and Rebecca Homkes fellow at the […] The post LEADER DIALOGUE: Clarifying Strategy Execution Failure Modes & Myths with CHIME – Deep Dive appeared first on Business RadioX ®.

Making FMEAs Work with Fred Schenkelberg In most of the organizations, Failure Modes and Effect Analysis, is taken as a light exercise where people come, argue, and leave without learning a single thing of value for their company. There is a lot going on when you are in need of FMEA because unless your equipment […] The post 81 – Making FMEAs Work with Fred Schenkelberg appeared first on Accendo Reliability.

Microcontroller Failure Modes: Why They Happen and How to Prevent Them by Altium Inc.

00:16 – Welcome to “Diamonds Are For Gender” …we mean, “Greater Than Code!” 00:56 – Origin Story, Superpowers, and Data Science 04:20 – Diversity and Career Paths in Data Science 10:51 – Ethical Debates Within the Data Science Field Weapons of Math Destruction: How Big Data Increases Inequality and Threatens Democracy (https://www.amazon.com/gp/product/0553418815/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&tag=therubyrep-20&camp=1789&creative=9325&linkCode=as2&creativeASIN=0553418815&linkId=0ed7c081ef2baa2e5a6f33a076e2929b) Therac-25 (https://en.wikipedia.org/wiki/Therac-25) FMEA (Failure Mode Effects Analysis) (https://www.greaterthancode.com/2017/06/21/episode-037-failure-mode-with-emily-gorcenski/) 17:21 – Software Development and Engineering; Failure Modes in Software 21:44 – Failure Modes in Democracy; Voting Machine Software 33:37 – Working for a Government Contractor 36:21 – Data Patterns and Tampering 39:00 – Open Data and Open Science 45:59 – Falsifying Data Reflections: Coraline: Considering all the ways something can fail. Sam: The world that I live in and the kind of software development practices that I take for granted are extraordinary niche. Emily: Tech conferences and their decadence vs academic/corporate conferences. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode). To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks! Special Guest: Emily Gorcenski.

In this podcast I will give a simple standardization for your Cabin Check that will increase your knowledge of your systems and add safety and redundancy to your flying. Fly Your Best! Jason