Hi folks, everybody can hear me? Okay, cool. So, DevOps days, Philly, right? So, I've lived in Philly for about 21 years now. This is, I consider this to be my hometown. And so, when DevOps days was coming here, I thought it was really important that I submit a really good talk, right? So, you know, I talk to people I know, you know, what should I submit? And a friend of mine said to me, you know, you should talk about culture, right? Rather, you know, because so much of our DevOps discussion is about tools, right? And tools are great, and I love talking about tools. I'll talk about tools all day. But culture's kind of hard, right? It's really easy to like annoy people and say the wrong things. As a technologist, it's very easy for us to say things that are completely tone deaf about culture, right? And we do it all the time. So, you know, there was this whole thing where, you know, is there anything that I can add to a discussion about culture, right? So, tomorrow we're gonna hear from Bridget Cromhow from Cloud Foundry. She's probably gonna tell us that containers won't fix our broken culture. She's completely right. I was at Velocity in New York a month ago, and Catherine Daniels, the author of Effective DevOps, which you should all read, it's an excellent book, told us that tools will not fix our broken culture. She's completely right. So, this is basically the problem we all face, right? We have this embarrassment of riches in tooling, in best practices, but none of it fixes the human problems that we have. In fact, it's not even very good at fixing the technical problems we have, right? So, how do we expect it to fix our cultural problems? And this is because of something called Conway's Law, right? So, this is a book from decades ago now, where, you know, an organization is gonna build systems that reflect that organization, right? So, and the systems don't just mean a technical system, they can also mean our cultural systems. This is also called Shipping the Org Chart. So, in fact, I was just reading this morning a really great, it was the original proposal for the World Wide Web from Tim Berners-Lee, and he's describing, well, you know, our organization here at CERN is like a web of different sub-organizations where things come and go. And he's saying, so we should build a technical solution to this that reflects our organization, right? This is something that it goes back a long time. So, what we're kind of saying here is that culture dictates our technology, right? So, our shared values, our shared beliefs, our shared ways of making decisions influence our technical choices. But culture is kind of a complex artifact, right? So, it's a chaotic system, it's full of feedback. So, in instinctively, we know that bad technology can influence our culture, bad technical choices can influence our culture in bad ways.  We know that if we don't build for self-serviceability that our dev team will in turn hate the ops team.  I particularly like the system in column. But this is kind of the anti-pattern, right? We know that if we're cranky on a Monday morning and we're snipping at each other because we were up all weekend because PagerDuty was giving us the wha, wha, wha, and those of you who use PagerDuty know what I'm talking about. Because we didn't build a reliable software, well, technology's influencing our culture. If we just start ignoring email, right? Because we're sending our bug reports and interteam chatter and our code reviews and alerts and exception reports, which is actually something that I saw a company do once. True story. And they're all going through the same medium. So, you know, and we can't use it effectively, right? Technology's influencing our culture. If instead we're making decisions asynchronously and thoughtfully with a distributed team and we're enabled to have a distributed team that might be working across the globe, right? Technology is influencing our culture, right?  There's this great quote from a discussion from an Etsy engineer on Reddit of all places, where we can see this kind of inherent back and forth between tools and culture, right? They both influence each other. Tools won't fix our broken culture, right? If you're totally broken, you gotta fix the culture first, right? But we can certainly have a positive feedback mechanism. So, I tried to come up with what I'm calling four principles of software-defined culture, right? So, what if we could make technology influence our culture in positive ways? Or at least not make our culture worse, right? Like that would be a good start. So now maybe principles is a little too grandiose for you, so call them paths or considerations for software-defined culture, whatever you want. So I'm gonna go through these. So the first one is building for reliability.  But that's kind of thought-ological. That's the easy case. Failure to build in reliability is going to lead to firefighting. And that firefighting becomes a rut for organizations, right? You do kind of patch-fix work, the problems come back, they grow, they expand. And so everything becomes urgent, and that means you stop focusing on the thing, on new feature development and on whatever your organization's actual mission is. If you reward firefighting, you get a culture of arsonists, right? If we, without a culture of reliability, we've misaligned our incentives, right? And we're at risk of creating a culture where we just lurch aimlessly from crisis to crisis instead of solving problems. And this is gonna lead to burnout, right? So people don't like getting paged, right? They wanna work on whatever it is they came to you to work on. Like all those promises you gave them when you hired them, that's what they wanna work on. They also wanna sleep, that's good, too. And you're gonna lose people to this. And kind of the deep irony is you're gonna lose your best people to this. And you'll be surprised when it happens because they're just gonna one day say, you know what, I'm done. I'm gonna go raise goats in Idaho. And that'll be it for them. So we need to guide our technology choices this way. And one of the ways we can start doing that is by stopping the resume-driven development, right? So new technology isn't battle-tested. It is going to be broken all the time, right? And when you choose new technologies, you're always at risk for doing that. What's more, if you're doing that all the time, you're of normalized risky decision-making, right? So learn Elixir, AerospikeDB, or Vue.js, or whatever the new thing that's on Hacker News this week, like in your own time, that's an option, or in your development tools and in your internal tooling, rather than yoloing that stuff into production all the time. Thanks, folks, that's great. Okay, this has ripple effects in terms of attracting like-minded hires, too, right? People who always wanna work with only the latest and greatest are going to congregate at places where they can get away with that, right? And what's more, and I've seen this at a number of organizations, they're gonna tend to bring along people who like that stuff from their last organization and they'll follow each other around, like a plague of locusts, leaving you with unmaintainable software, right? This is gonna increase your hiring costs and it has no business value to you. Rewriting your front-end every six weeks because you've got the newest React thing or whatever it is, has very little value for your culture as an organization. This also is gonna bias your hiring against experienced engineers, right? And these are the very people who were trying, for many of us, are trying to hire, right? They've already been through a couple of burnout cycles, right? Like they do not wanna, you know, they see this coming a mile away when they look at your job listing and it's like, oh, we've got all these new technologies and they're like, no, no, no, no, no, I'm not gonna work there. I know what I'm in for here. It biases you as an organization against older staff as well. People with families, you know, when little Aiden needs to, you know, go to the band practice or whatever, that's not the time they wanna be doing, debugging your new stuff. It's also harder for kind of our inexperienced but second career types, right? We have a, you know, we've been telling people, learn the code, it's a great way to, you know, bring yourself into the middle class, but these are people who largely are not gonna be wanna be up all night because you decided to switch over to the MongoDB, the new MongoDB storage engine after only testing it for two days in workload, right? So one of the failure modes of trying to solve this is bimodal IT, right? So this is like, and this is like, this is the thing you see at enterprise organizations, right? We're gonna have one group of people who get to be the innovators, right? And we'll do all the new stuff there and we'll self-contain it so they can't screw up the rest of the business, right? And then we'll have the people who are the maintainers, right? And Bridget Cromhill calls this awesome mode versus sad mode, right? And it should be obvious what this does to the morale of your organization, right?  So we should have a bias towards, a default towards choosing boring technology, right? We wanna minimize the unknown unknowns so that we can focus our energy on what matters, right? The mission of our organization and the health and well-being of the people we've hired, right? Save the innovation for when it's gonna have the biggest impact, right? So our second principle is building for operability.  I'm gonna talk about a little bit later. So we're talking about having automated build and test. We're talking about having reliable deployment and easy scaling. Ideally in some kind of self-service way, right? When your development team can self-service and provision the resources that need to do their jobs without kind of like, well, let me do a chain, you know, let me fill out a form to do, you know, to order a VM, you know, and like, it's like, well, we did innovation. Now it's a form on a webpage, right? Like, that's not actually self-service. When we do that, we have a kind of a neat side effect, which is that now everyone gets test and stage environments whenever they need them. And that's going to empower our development teams to take ownership over not only the software, but the infrastructure on which it runs, right? So how this plays out varies. And one of the ways that we've, one of the kind of the notional frameworks around this kind of stuff right now is Giffy, right? Google infrastructure for everyone else, right?  And if you're building a distributed system of market services that only speak HTTP, anybody doing that? Only speak HTTP? Okay. Then maybe Giffy is the right answer for you, right? But like, you're taking on a lot of cultural baggage when you do that, right?  Okay, so what we've done, so let's go back real quick, right? So we were talking about Giffy and about the notion of these kind of like platforms that do all the things for you, right? So what we've done in this case, we've split the application behavior between the application and the platform. And what really ends up happening in that case is between the application developer and the operator who operates that platform, right? And who that operator is is going to vary depending on the organization. Maybe you have an infrastructure team that runs the platform or a platform team or the anti-pattern of a DevOps team, don't do that. So the problem with this is that our application developer can't actually understand the total behavior of their application without understanding what's going on on the platform as well, right? Which isn't managed by them. Largely, these platforms are very heavyweight, which means that the developer is not gonna run the platform in the local development environment and now we have works on my machine, right? Hey, you know, I was working, this worked fine for me locally when I was doing my unit testing and I integration testing that was actually only testing a single service. And now that's going into production, not really tested. A lot of these things have integration code associated them, right? So that code that's written for one orchestration platform isn't gonna be portable to another one, which means that now our operations team, if they wanna make decisions around cost or reliability underlying platform, they can't because the application has been deeply tied to the underlying platform.  So this tight coupling of all the components, the application, the platform, and whatever integration code you have has become its own source of friction and failure, right? And this is really messed up because we've reintroduced all the problems that we were trying to solve by going to this kind of infrastructure in the first place, right? So like, and you know, GIFI is only one solution to this, but if you look at what goes on in larger enterprises, right? We've got, you know, an architect who's created the abstract Singleton proxy factory factory, and we've just made it out of process and we've rewritten it and go, right? Congratulations, folks. We've made, excuse me, congratulations, folks. We've made some real progress here, right? Okay, so instead we should consider an application design that allows for applications to be self-contained, right? So now, and self-operate with a minimal amount of global coordination, right? If we have this kind of platform independent separation of concerns where the application and the scheduler and the infrastructure are their own self-contained entities, then the people who are responsible for them can have ownership of them, right? So ironically to, and so there's this kind of ironic separation of dev, to end the separation of dev and ops, we actually have to separate the components that they're working on. Orchestration needs to be laptop-friendly, right? If you can't run your stack on your laptop, then you are going to have problems that only appear in production, right? We want to eliminate works on my machine to the degree that's possible. So Google infrastructure is probably awesome, but does it solve the problem we actually have? I'm trying to get jibba-jibba-apas-de-apwa to come out, but I think it's like an offensive Welsh word, so I might have to, yeah, okay. So the third principle is building for observability, right? And so this is understanding what happens during incidents, after incidents, and certainly before incidents, right? We know that we have to monitor all the things, like everybody knows the meme that's supposed to be here, like monitor all the things, right? We know that that's what, right? But with the rise of containers and microservice architectures, right, we've built systems that are, we're now all building distributed systems, right? And they are harder to observe and debug than the systems that we were building just 10 years ago when this quote was on, in ACM. And because these systems are distributed, many of the most difficult problems we're going to face are only going to ever happen in production, right? Because they're going to be like networking infrastructure, which means we need to be able to debug our production environments. And debugging in production means you have to have a way to observe them safely, right? So if your observability tooling alters the performance of what you're observing, right? Or worse, causes it to crash, well then you can't use it safely in production and you won't. It's very much time for us to move away from dashboards, right? So dashboards are great for telling you what you already know, like your known knowns or your known unknowns, right? But they're very bad at telling us the things that we haven't figured out yet, right? We should be selecting tools that allow us to explore and discover. And very importantly, I think for modern teams, is those tools should allow us to explore and discover the problems that we're having as teams, not as individuals, right? There's some great tooling that's coming out now, this is honeycomb.io, that where monitoring tooling selection can improve the communication and create durable and shareable processes for exploring and discovering problems that we've had in production, right? When I go through and do my queries here, I can build those up iteratively, I have a record of what I've done and I can share them with my team, which means that I as a senior engineer can actually go on vacation and I have new mentoring and training opportunities out of the debugging work that I've done, right? This also means we should be building for rainy days, right? Like anybody can build a system that works when everything works, right? Like that's kind of technological. If we only build for the everything works case, well then we have actually tied our hands when things go wrong, right? So let's tell a story. So we have a startup and I have skinny jeans on, so of course it's in Node.js and it has a programming bug, right? And so the right way to do this is we're going to, we're gonna abort on encoded exception when we run this and so we have a bug here and we get an error message, which isn't all that useful, it's just a type error and we get a cord up, right? And I can take that cord up and I can move it into my observability tooling, my debugger and I can get the stack that was associated with that, the stack frame and I can look at the functions that are associated with that stack frame and I can get the error and I now get the object that caused the error and I've gone from a single bad request to a solution to the problem just in one request, right? So there's no like, well, we'll monitor it for the next week and figure out what happened, right? This is the good way to do it, right? But Hacker News had this like a really great article on promises this week and so I'm gonna do, so we rewrote our whole stack over the weekend in promises and we have this problem, right? Which is like, there's no automatic abort here, right? So I can get an error message if I get that reason object, I can print out an error message, but there's no abort. So I have to remember to manually abort every time that I've created a programming error. Well, if I could remember to manually abort every time I've created a programming error, maybe I would not make a programming error in the first place, right? But let's assume that we knew how to do that, right? And we get our stack, but now we've mangled our stack and we don't really know what's in it. So we can get the error message out of that, which again, didn't really help us in the first place because it's like, well, it's a no pointer exception, but right, we don't know what. So we have to go and find all the functions that are associated with that file and then we have to go and find all the closures that were associated with the then part of the promise. And then we can go spelunking through the heap like this to find all of the possible objects that have been passed into that function.  But we have kind of an object here that we know, just because I'm cheating. So we don't have to guess. And so we can finally find that object and print it out and we say, ah, okay, now that object doesn't have the attributes that we're getting from it. Whoa, boy, that's an awful lot of work, isn't it? And so now you're telling me, hey, hey, hey, this is, like if I crash, that's fine, right? Like who cares? Because I'm just gonna restart the process again. I mean, when Basecamp came out with Rails, it was like that crashed every five minutes in their internal environment, right? And that was fine, you know? So it's okay if we're losing throughput to these kind of restarts because we're web scale, right? We're just gonna scale it up horizontally and that's fine, maybe, right? But now you're spending more money, right?  And then when the bubble burst because of credit default swaps, people are gonna be out on the street and a lot of that that is coming from foreign, is foreign held and that could even lead us to arm conflict and then it's, and then it's strapped on the power armor, boys and girls, because we've got radioactive zombies, right? Okay, so I'm not saying that promises are gonna lead directly to radioactive zombies, of course. Okay, but what we've done here is we've made a seemingly small technical decision what was really for only for ergonomics and we've ruined our ability to debug and understand what our software is doing in production, right? And if you don't have anybody on your team who can do this, you should probably learn how or hire somebody who does and if you're on a platform where you can't even get access to this stuff, right? You don't have a route, like you can't even show into the box. Well, I'm not saying never use a pass, but I am saying you gotta understand what you're giving up, right? You're definitely giving up something by doing that. So choosing a platform where your engineering team is inevitably going to run over a problem where the very, very smart people you hired, their only solution is, well, better call support may not be the culture that you wanna build, right? Especially given what we know about some of the support. Name names there. All right, so we should bias towards choosing platforms for observability, right? Bias towards throwing money at a problem rather than our brains works great if you have more money than brains. For those of us who don't, maybe not the right solution for you. And a platform isn't just where you're hosting, right? It's also the selection of your tools, right? I'm not saying you shouldn't pick a language that says debugging is hard, let's go shopping, but when you do so, you should recognize what trade-off you're making. We should be getting used to interacting with our observability tooling every day, right? We have a choice to understand what we've built, right? We can build a culture around engineering excellence or we can pretend that we don't need to. I know which culture I'm gonna bet on. Okay, so if you're annoyed at me before, get right, hold on to your butts, okay, so every tool comes with a community, right? And particularly in the open-source world, right? Which, I mean, this has been the great victory of open-source is that we have this like huge number of tools we can use now, right? And some of these communities make it a point to be open and inclusive. This is a quote from the Rust community code of conduct. If you get it, even if you don't care about Rust at all, which is a totally reasonable position to have, this code of conduct is amazing and they've made it a core of how they've built the community around their software from the very beginning, right? This isn't something that somebody imposed on them from the outside later on. Other communities have a well-deserved reputation for kind of some toxic behavior. I'm gonna try to avoid naming them or being combative, right? And so when we choose a tool, we have chosen its community, right? The people on your team are gonna interact with that community every day, right? There's some communities here. They're gonna submit bug reports, they're gonna submit patches. They're gonna read blogs that are about the tool, right? They're gonna attend conferences like this one. The tools you select will affect who you hire too, right? And if you are building a very innovative, bleeding-edge piece of technology where knowing that a monad is a monoid in the category of end of functors, I have no idea what that means, then maybe selecting tooling that is gonna attract people who understand that and who are part of that culture is the right move for you. But if you were building a web crud app, like someone like me would do, then those people are gonna be very unhappy if they come work for you and you will be unhappy with the things that they build, right? So we should make sure that we're picking tools that have the culture that we wanna be associated with. And this goes all the way down to the design of the tools we use, right? So if your programming language is intentionally designed with the idea that you're not smart enough to use a better one, is that the culture that you wanna be associated with? When a community not only tolerates exclusionary behavior, but actually inspires a user revolt that forks the runtime to protect that exclusionary behavior, is that actually the community that you wanna be associated with? I said I wasn't gonna call out communities, but I am. Okay. So at the beginning of the talk, I was talking about the embarrassment of riches we have in terms of tooling, right? And we jokingly talk about JavaScript fatigue, right? There's like, it's been two days since the last JavaScript framework. And that's a real thing. And it's actually great that that's the case, right? This is the victory of open source. But we really thought about why there are so many tools, right? Some of this is the resume driven development, right? Like if you're hiring people and you're like, well, where's your GitHub repo, right? Or where's your GitHub account and how many stars do you have on things? Well, then obviously you're incentivizing people to go after that kind of stuff, right? They're gonna build tools. Whether or not anybody actually uses them. But is the mission of our organization not enough for us as makers, as builders, as creative professionals? Are we not being fulfilled by that mission? So I ask a question and don't raise your hand because your boss might be sitting next to you. But how many of you are working for an organization or working on a product that actually makes the world worse? Just give me like stern eye contact, right? Okay. Now raise your hands for this one. How many of you are working for organizations that are hiring? Okay, like virtually everyone is up and I assume everybody else is looking for work. Okay, so now our profession doesn't have licensing, which is probably right because there's a big difference between the people who are working, real engineers who are working on operating systems versus like dorks like me who don't even have a college education or working on distributed web stuff. So that's probably right that we don't have licensing. But we can learn a lot from our brothers and sisters and other engineering professions, right? Imagine if we had a code of ethics like this. So I'll just read a little bit of it because I think it's really important, right? Engineers shall hold paramount the safety, health, and welfare of the public. Engineers shall act in a manner as to uphold and enhance the honor, integrity, and dignity of the engineering profession. Imagine if software engineers had a code of ethics like that. Imagine if operating engineers, the people in this room had a code of ethics like that. We can individually. So I want everybody from that first group to go find somebody from the second group while you're at this conference, right? And don't tell me like, oh, I've got student loans and mortgages and stuff like that, right? We all do, but right now this is a seller's market, right? They probably had to, the organizers probably had to keep recruiters out at the door, right? They're holding them off with pitchforks, right? Everybody wants to hire us. Our salaries have gone up dramatically over the last few years, right? This is the time that we can actually have control over the kinds of tools, the kinds of projects that we're working on, right? Your work creates the community, right? In a world where software is eating the world, the work you do creates the world around us, right? It reflects our values. It also reflects our blind spot, right? Our blind spot is how you have organizations like Facebook or Google who are demanding the real names of people, like, you know, which means that, you know, they're putting people who are trans or political activists at risk. It's how we end up with mobile sites that, you know, use up, blow away the data plan, that, you know, the cheap data plan of working class folks who just to serve them an ad for a product they can't even afford, right? Inclusivity, excuse me, inclusivity doesn't stop with your team, right? So many of the systems we build are ripe for abuse and we have misaligned our incentives for working on those things and we, and largely just don't care. I think we can do better. I think our software can improve our culture and I'd like to invite all of you to enjoy me in doing that. Thanks a lot, folks.


I'm going to be talking, for better or for worse, something much more conservative, maybe less interesting, but I'm going to be talking about some work that I've been doing over the last few years with a bunch of collaborators listed here. First of all, I'm going to talk about what I call induced electroweak symmetry breaking, and I'll of course explain what that is. As an interesting example, I think, of non-de-coupling physics, then I'll talk about it as an example of improving naturalness in the context of supersymmetric theories, and I'll talk about the phenomenology at the end. So just to set the stage, let's just remember where we are. This is something I think we all know, but it's worth remembering the long journey we've been on. It was actually since the 1930s when Fermi wrote down his theory of weak interactions that we knew that there was an interesting scale of a TEV, and Fermi, literally, if you look historically, he really, literally understood this. Of course, we made huge progress, especially in the 80s with the discovery of the W and Z bosons, but still if we take the theory, including only the degrees of freedom that we know, we still had the same cutoff, this time for WW scattering, and it was only in 2012 with the discovery of the Higgs boson that if we take the theory containing the particles we observed, now suddenly we have a theory that has a cutoff near the plank scale. So this has obviously caused a lot of angst. We've been living with a fixed target for new physics for a long time, and now we don't have one anymore. But in this situation, people have naturally wondered about whether perhaps the standard model is all there is, or perhaps whether we can only see small deviations from it, and in fact this is sometimes enshrined in what's called the Higgs decoupling theorem. And this is not my formulation of it. This is stolen from somebody's slides who you probably know, but I'm not going to tell you who it is. The Higgs decoupling theorem says that suppose the Higgs sector contains additional Higgs bosons, but one of them is the light 125GB particle that's been observed, then necessarily the rest of the Higgs sector just gives you some additional corrections to the standard model which are higher dimension six operators suppressed by mh squared over m squared. And the proof is, well, just go to the Higgs basis where the VEV is all in the one of the Higgs eigenstates. And if you take the other guys out, you get dimension six operators. That's the proof. So this theorem, as it's usually stated and understood, is just not correct because it can be spoiled by non-decoupling effects. In other words, the theorem is true only in as far as it is true, as you assume that there's no decoupling. So let me just remind you a little bit about non-decoupling physics. The canonical example is the top quark. If the top quark mass gets heavy, it leads to effects that are not suppressed by the inverse top mass. And we understand that because the top mass gets its mass from electroweak symmetry breaking. And so, for example, this top loop has a power of m top downstairs from dimensional analysis, a power of y top, so the coefficient ends up being independent of m top. And exactly the same thing can happen with the additional Higgs bosons. Can also get their mass from electroweak symmetry breaking. And just as with the top quark, that will require some of the couplings in the Higgs sector to be somewhat large. But again, like the top coupling, not non-perturbatively large, not 4 pi or not 10 to the 10, just order one, order one large. So rather than try to give a general analysis of this for the Higgs sector, I want to talk about one particular example, which I think is very interesting, very concrete, very simple, and as we'll see later, not just phenomenologically, but also theoretically motivated. Wow, I'm going fast.  Okay, so this is a two-higgs-doublet model. It's a very specific two-higgs-doublet model with a specific structure. I have one-higgs-doublet that has an ordinary quadratic plus quartic term and has a negative quadratic term. Then I have another Higgs sector, which has just a quadratic term plus this linear term. So I'm just writing down the most important couplings. And this mass squared is positive. So you can see what happens very, very simply in the limit where kappa goes to zero, this linear term goes to zero, I just have two decoupled Higgs-doublets, one of which gets a Vab, sigma, and the other one doesn't. Now I'm going to turn on kappa and treat it as a perturbation. In the low energy theory, if m sigma squared is much bigger than mh squared, in the low energy theory the leading effect of this is going to be just the fact that sigma gets a Vab gives a tadpole for the little h. So the potential for this little h here is rather than being quadratic plus quartic, it's linear plus quadratic. And so it looks just like this. It looks like a shifted harmonic oscillator. And the Higgs Vab is just given by some expression like this. Now I want to identify the H field with the excitations of the H field with the 125 gv Higgs that's been observed at the LHC. So that means that I need not only to get the mass right, I also need to get the couplings of the Higgs right. They've been measured to about 10% to agree with the standard model. And the way to guarantee that is that the light field or the H field has to have the dominant share of the Vab. So what I need is I need the Vab f of the sigma field to be small compared to the total Vab v. I need this mass squared of this heavy field to be larger than mh squared. And that requires the quartic coupling of this sigma to be large. When I say much larger than one here in practice, I'm going to be taking numbers of order one. I'm just talking about the parametrics right now, okay? And you can ask whether that's really consistent with treating Kappa as a perturbation. After all, when Kappa goes to zero, then the Vab of the H field is zero. On the other hand, I'm requiring it to be the dominant source of electro-week symmetry breaking. So actually you can check that these conditions are compatible with each other. So if I'm doing the expansion in Kappa, you can work out that the expansion parameter is actually an expansion in this combination of parameters right here, okay? So in order for this tadpole approximation to be valid, I need this combination of parameters epsilon to be small. On the other hand, I need V to be bigger than f, say a few times bigger than f, in order to get the constraints right. And you can actually see that this is perfectly okay. But it does require, at least parametrically, it requires a large quartic for this sigma, okay? So you may be a bit suspicious about having some low energy theory with a linear term. Of course, the reason I don't just write that down in the standard model is it's not gauge invariant. But remember, here I'm integrating out electro-week breaking fields. So that's the first order answer. In a little more detail, you could say the more correct answer, correct way of looking at this is to say that we have a non-linear realization of electro-week symmetry from this sigma. And so there are some goldstone fields here that are the angular modes in sigma that survive below the sigma mass, right? If sigma was all there was, those would be the longitudinal Ws and Zs. Those things, these pseudo scalars pi coming from sigma will mix with the pseudo scalars coming from H. So actually this tadpole is dressed up by these goldstones. And the pseudo scalars mix, okay? And so that's actually an important part of the phenomenology. So let's take a look at those. So I have, I include the excitations of H, the pseudo scalar excitations of H. Those mix with the pseudo scalar excitations from sigma, okay? Which I call pi here. And what you can see is that the physical pseudo scalar is an admixture of these guys, which is mostly the sigma, okay? Mostly because I'm assuming F is smaller than V. VH is the VEV of H, right? So these are mostly sigma and the even goldstones are mostly H, which they have to be because H has most of the VEV, okay? And so what does the spectrum of this kind of theory look like? So there's the usual standard model spectrum down here. And then I have these pseudo scalars here, which are mostly made out of these sigma guys, okay? And they have a mass given parametrically like this. And then I have the sigma fields, and you can see there's a hierarchy of order epsilon between these guys right here, okay? And above, it's only above the sigma scale that I see the full electroweak symmetry being restored. So again, just the parametrics here. The coupling of the Higgs to vectors is given by something like this. Coupling of Higgs to fermions like this. So notice that when F is small, these approach the standard model values, okay? And if I want something like a 10% accuracy, I need something like F to be about a third of V or something like that, right? One of the things that is very interesting phenomenologically and also shows you that this is nothing like the standard model with additional operators is that notice in all of this, I never put in a quartic term for the Higgs. Of course, it wouldn't hurt to put such a thing in, but if I don't have one, if I don't put one in, then the quartic, and also the cubic coupling, is suppressed by this parameter epsilon. Actually, epsilon squared compared to the standard model value, okay? And just remind you that phenomenologically, suppressing the cubic H coupling actually enhances the HH production, because it's usually, it eliminates a destructive interference that's usually there. So in this kind of a model, these additional Higgs bosons definitely do not decouple. They're a very important part of electro-week symmetry breaking. In fact, electro-week symmetry breaking wouldn't break without them. That's why we call it induced electro-week symmetry breaking. And this also means that if you work out the coupling of these heavy states to things like the light Higgs, WZs, tops and so on, they are unsuppressed as opposed to the normal decoupling limit where they are suppressed typically, especially at least the couplings to the Ws and Zs, okay? So far, I've just talked about this as a possible way of having non-decoupling physics in the Higgs sector. But there's also a theoretical motivation for this kind of model in the context of supersymmetry. So in supersymmetry, the problem that I have is that, at least in the MSSM, that the quartic couplings for the Higgs are given by the gauge couplings squared. And therefore, the mass of the Higgs is of order, the quartic times the VEB squared, which is of order MZ squared. And it's not just a parametric thing like this. There's a tree level bound that says that the lightest Higgs has to be lighter than MZ, as we know. So there are various ways of getting around this. One, in the MSSM itself, we can just look at loop corrections. The problem with that is that we need M stop to be large to make this logarithm large. This is the correction to the quartic. But if we make that large, then this should be M stop squared, I apologize. There's a quadratically sensitive contribution to the Higgs mass squared. So this leads to a tuning of at least the 1% level, even in the low-energy MSSM. So if we don't like that, the typical thing that's been tried is to look at new contributions to the quartic. So we can have new tree-level contributions from D terms, from F terms.  These all have in common that they're trying to increase the quartic from this G squared. But based on what I've just said, there's another possibility which is induced electroweak symmetry breaking. Who needs a quartic? So in the MSSM, a quartic is naturally small. That's exactly a natural situation where we could try to do what I've just done here. Okay? Now, do I say this here? I don't know where I... Just a second. Let me just look a look here. I think I should say it here. Yeah. Okay. So let me just say it here. I didn't think I put it on a slide, but you might think that here I'm just postponing the problem one step. Because if you were paying attention before, I said that we needed a large quartic, but now the quartic was for this other field. So we do need a large quartic somewhere else. But the point here is that this other Higgs field doesn't have to have any Yukawa couplings. So the field with the large quartic doesn't have to have any Yukawa couplings. And so it turns out it's easier to give it a large quartic. And I'll give some examples of that. Okay? So the general framework here is that we have the MSSM with its field H up and H down. And H up and H down have the normal Yukawa couplings. Okay? Then in addition, I have some what we call the auxiliary Higgs sector. It includes some Higgs doublets sigma and also some new fields phi, okay, whose role we'll talk about in a second. And there can be couplings like this, phi, sigma, H. Okay? And this auxiliary Higgs sector has to be more strongly coupled than the MSSM Higgs sector. It needs to have bigger quartics in particular, right? And there are two ways that it can do that, at least two ways or two limiting ways it can do that. One is for it to truly be a strongly coupled theory, truly like technicolor, okay? And the other possibility is to write down perturbative models. And I'll talk about both of those. So the first class of models were actually written down by us first, okay, super conformal technicolor, okay? And here the idea is that this auxiliary Higgs sector is really some strongly coupled super conformal sector. And what happens to it, what that means is that it is at a strong fixed point, it is basically strong at all scales, okay? So above the TV scale, far above the TV scale, it is super symmetric and conformal and strongly coupled at all scales. And we definitely have concrete examples of theories like this and we actually analyze concrete examples in this theory. Then we assume that supersymmetry is broken at the TV scale. So back here, supersymmetry breaking feeds into both of these sectors here at the TV scale. And at the TV scale, Susie breaking triggers confinement in electro-week symmetry breaking. This is very plausible. For example, the scalars will get a mass from electro-week symmetry breaking, but the fermions will typically be protected. So you'll end up with some gauge theory with no scalars and fermions that very typically confines and breaks electro-week symmetry breaking and breaks electro-week symmetry. So we can imagine there being some F scale associated with this technicolor of order 80G EV, that turns out to be a good number for all the phenomenological constraints. And then the resonance masses of this sector are then around one TV, right? Because the coupling is so large, it's now non-perturbatively large, the mass of the resonance is very high. And the kinds of couplings that we imagine adding are linear in the elementary Higgs fields, and they are then proportional to some operators in the strongly coupled sector, sort of like side barbed side, right? Where the sort of technicolor is contracted through here. And this VEV induces the tadpole, just as we talked about, okay? Now you may be thinking that I've gone off the wagon because we all know that technicolor died, not once, but at least four times, right? First of all, soon after it was invented, it was realized it had terrible flavor problems. Then in the 1990s precision electro-week, predictions, corrections were too large. The top cork was discovered in 1995, something that was much too large to accommodate in technicolor. And finally, in 2012, the light Higgs was directly discovered. And there was this famous slide by Nima, that many of people have reproduced. But a lot of people haven't really looked carefully at this slide. If you look carefully, you actually see that there may be a chance, okay? That's something. All right, but let me explain to you that actually it's not just that I have four different excuses for all these things. Really, these things are just, they're just completely, this is a completely different sort of beast here, okay? Because first of all, what's really crucial is that flavor, the Yukawa couplings are just done by the ordinary light Higgs, okay? I have the elementary Higgs's, I have the ordinary Yukawa couplings, there are no problems with flavor whatsoever. So forget about those. Precision electro-week, there there's still a worry, there's still some problem. But the fact is that, so first of all, you might think for a millisecond that having F much smaller than V will suppress the electro-week corrections by some power of F over V. Alas, that is not the case. And it's basically because the S and the T parameters are really dimensionless things, okay? So they're not suppressed by that. But the crucial thing is really the S parameter, and it is suppressed because of the fact that in an ordinary technicolor, about half of the contribution from S comes from the heavy vector resonances, and the other half comes from the light technipions. And that comes from the fact that the light technipions are dominantly the longitudinal W and Z. Here they are dominantly not the longitudinal W and Z. So the S parameter is about half of what it is in technicolor. And if you look at a minimal theory of technicolor, not these crazy things with whole technique generations that were needed for flavor, again flavor, they were already sort of marginal with precision electro-week, so this is actually fine. Plus, you can get a positive contribution from the T parameter from the fact that you had different couplings H up and H down. So this can very easily bring you back into the precision electro-week ellipse. Z to BB bar is actually somewhat constraining but actually works. The light Higgs couplings work fine, okay? So I claim that there's really no problem with these theories, and we'll look at some of the details of the phenomenology in just a little bit. However, no matter what I say, most of you won't like non-perturbative physics, okay? So another possibility is to have perturbative models, okay? So here the idea is that these auxiliary Higgs fields are charged under a new gauge group, okay? And the very simplest minimal thing is just some SU2, okay? And because they're charged under a new SU2, they have additional D terms in their quartic. So if this SU2 is somewhat strongly coupled at the weak scale, I mean, you know, stronger than you want hypercharge, basically, or SU2 weak, then they will have additional quartics and that can make this whole mechanism work, okay? So this is conceptually similar to the non-decoupling D terms that have been discussed earlier. And so the basic idea is that we have an SU2S, this extra gauge symmetry. It's broken by the VEV of some five particles at the scale U. Below that scale, we have the electro-week gauge group and then we have these psi particles getting a VEV and these are the induced electro-week symmetry breaking fields. Okay? I'm gonna sort of skip over this slide unless somebody wants to ask a lot of model building questions. There's some nice features of the model building. Actually, unification and precision electro-week work out quite well. And here you can't, you know, we can really just of course calculate precision electro-week and we did and everything is fine. Bottom line, you can ask how well do you do? This is sort of motivated by eliminating the tuning in the MSSM and so how well do you do? And here is the most important parameters in the theory are the gauge coupling of this GS and the VEVF, okay? And in this plane, what you see is that there's a line here and in this line right here, I didn't talk about this limit, but in this limit you actually go back to the standard model. So actually one of the reasons that you sort of know the phenomenology of this model is going to work is it has a limit where it does have a decoupling limit, okay? So in that limit you're guaranteed to get back the standard model. Of course in that limit the Higgs's are also very heavy and you have not solved this tuning problem, okay? But then on the other hand, if you go away from this limit, you eventually get into problems with Higgs couplings. That's the gray region and so what you're left with is this white region which first of all is a pretty big size region and second of all, you can see the tuning contours, you see you're never really tuned in any of the allowed parameter space, right? So I don't know about you, but I never liked these things where people said we scanned 10 million points and we found one that wasn't fine tuned. That looks a little suspicious. Here it's just not tuned, period, end of story. Okay? So let's look at the phenomenology of this, okay? So in general in the phenomenology of this, you have many, you can have any number of additional Higgs bosons. So we wanted to, since we were motivated by supersymmetry, we wanted to look at the minimal thing we could in the context of supersymmetry. That would be a three Higgs doublet model. So in addition to the H up and H down, we have this new field sigma, okay? And then, but then what we assume is that one linear combination of H, U, and H, D does approximately decouple. So we really are left in the end with a two Higgs doublet model, but it's now a type one two Higgs doublet model because only this linear, the light linear combination of H up and H down has Yukawa couplings, okay? You can certainly look at more complicated things, but we think this is a good representation of the phenomenology. So what does the effective theory look like? It has pretty much the potential that we talked about. We actually do include a quartic potential for the Higgs, but the point is that since we don't assume any heavy stops or any other mechanism to beef it up, it's not very important phenomenologically. It's actually only important for the cubic coupling which directly gets a contribution from this, okay? So with this simplified model, we have five parameters here. We can fix the VEVs and the mass, sorry, we can fix the total VV in the mass of the light Higgs. And so we're left with three parameters and we usually look in this plane of F and lambda sigma for some particular value of tan beta. So we looked at all of the current constraints on this model. And here they are plotted in the plane of sigma and mA. We actually don't use F because this shows the different constraints in a better way. And what you can see here is that, for example, the Higgs coupling constraints are here or this vertical line here, I'm sorry, that's a little bit hard to see. But, sorry, yeah, I believe that's right. Yeah, this line right here. But they're actually, the direct searches are actually more constraining. A to ZH in particular is extremely constraining here in this model. But we considered many other things. And one way of saying how non, thank you, how nonstandard this is, is that we can ask, given the experimental constraints, what is the smallest value of the Higgs-Cubic coupling that's still allowed, okay? And what you can see here is that here's, those contours are shown here. Here's 0.4, here's 0.7. So we can have around half of the standard model value in this simplified model. And if you look at what the, I guess it should be the 13 TV LHC, but it doesn't make too much difference. If you look at the 14 TV projections, what we see is that A to ZH and is this purple hatched region and A to TT bar are expected to be the strongest constraints, okay? And here you can see you're now pushing things out so that you need about, you can only have about point, if you don't see anything in the 14 TV LHC with 400 inverse femto barns, you can only have about 0.8 times the standard model value for the cubic coupling, okay? So we'd like to know whether the cubic coupling could perhaps be a discovery mode for new physics, but that will only be done with the high luminosity LHC, right? Now one comment I wanted to make here is if you look at this plot, one thing that if you're following this in detail, which probably nobody is, is that, in fact, you can't really see it very well. I apologize. But if you look at the Higgs couplings, the Higgs coupling constraints have not really improved much compared to the previous plot, okay? So I just want to explain what's going on there. And this just, again, emphasizes the, I think the important complementarity between direct and indirect searches. See the thing is, is that if you look at the present, the present preferred value of the Atlas and CMS bits is already in somewhat intention with the standard model. And in a direction which is bad for our model, right? Our model wants to move things in this way, whereas the standard model lives here, okay? So they're too strong already, too strong if you're a believer in the standard model. So that was incorporated in the initial slide. And we did the only thing we could think of that was sensible for the other slide. We assumed that at the next run, you'll converge on the standard model value. If that's true, you'll get significantly reduced error bars, but because you've removed the tension then, okay? So that explains why the Higgs constraints didn't get stronger. But it doesn't mean these are not important. Tell me to the contrary, obviously, if they were to converge on this value, or something compatible with the present value, it would be extremely constraining, and of course, extremely interesting for everybody, okay? So, but the direct detection bounds are, the direct searches are also incredibly important. In the strongly coupled models, we considered both the, there is the sort of model independent part, which is the A, these extra pseudo scalars, which are parametrically light compared to the strong interaction scale. And there, here I'm showing the present bounds here on those from LHC8, okay? And then this is basically the boundary where your effective field theory breaks down. So you see that as far as the, and here's A to tau tau. So you can see that as far as the present bounds go, it's already very constrained. On the other hand, you can have values over here, which have very, very small values of lambda H over lambda standard model. There's essentially no limit to how small it can be. But if you look at LHC14 with only 20 inverse femto barns, it's gonna completely clobber everything here, okay? So this, basically, if you don't like technicolor, you won't have to wait long, or you'll have to, you'll know, we'll know soon, okay? Whether this kind of model has any chance of being right. And I'm not gonna show it, but we have constraints. There are interesting constraints on the vector resonances, but there's more model dependence and the story is much less clear than here. Lots of, lots of constraints. Okay, so that's it. I hope I've convinced you or made you think that perhaps induced electroweak symmetry baking is an interesting possibility. It's motivated, theoretically, by generating 125 GeV Higgs in supersymmetry without fine tuning. Also, I think just phenomenologically, it's interesting as an example of non-decoupling physics. It's consistent with all bounds. It'll be stringently tested, and in fact, direct searches for new Higgs states really dominate the phenomenology here, okay? Thank you. Okay, so time for a few questions. So as someone who does like strong dynamics, you're talking about some heavy sector that's giving you a small value of F? Well, it's not that small and it's not that heavy. So it's just technicolor scaled down by say a factor of three. And do I have states at the scale four pi F? Yeah. So I do have those states. So it's the standards. It's just normal technicolor scaled down by a factor of three. So that does two things. It makes the states lighter. So you might think that I should be dead because I have strongly coupled states, but it also makes them couple less to electroweak because there's a smaller share of the VEV. So for example, the dominant way to produce, you know, Techni rows or vector resonances in the strong sector is just by mixing with the W and Z. But that mixing is now suppressed actually. So, yeah, so anyway, we really did the phenomenology. And so it is not, you know, there's a lot of, we don't know all the parameters of the technicolor row, but you can see that there are, you know, strong constraints, but not ruled out. Yeah. It's just technicolor scaled down by a factor of three. That's all it is. Four, maybe. Other questions? Your strongly coupled version reminds me something. Warped space, I may know with the, what's the, is it the 4D version or something you? The actual model we wrote down was a version of Suzy QCD. The strong sector is some Suzy QCD model in the middle of the conformal window. Okay. So, but yes, you could definitely make a 5D version of this. You would just have a supersymmetric bulk and I don't see any problem with doing that. Yeah, something I was thinking, I was doing with the Chaco and so on and so forth. Yeah, that's right. I'm sure you could make a model like that. We didn't actually do it, but I think you could definitely do it. And because in the basis of mass science states, then it's like Quoric is coming from your big Quoric coupling times mixing on the 2D force or something, right? There is no big Quoric coupling. No, that's a misconception. So, the potential really is in this limit where this parameter I called epsilon being small, the potential is really dominated by a quadratic plus a linear term. The linear term is of order epsilon. The Quoric is of order epsilon to the fourth. So, the Quoric is completely negligible. It really is a different kind of limit. The other limit is also viable. You might think it sounds like cheating, but it's actually not. You can have an induced Quoric, okay? So, you can be in the different parameters based on the values of the parameters of the original theory. I think you're right, yes. Yeah, but the induced limit, it really is different. We have a shifted quadratic potential for our Higgs. Any other question? All right, so let's thank the speaker and complete the session.