WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=ij-AU9dpJjc NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/ij-AU9dpJjc.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:00.000 --> 00:00:01.480 Hi, I'm Isadora. s2 00:00:01.480 --> 00:00:05.560 I own and run a 225-year-old wedding venue in Virginia. s3 00:00:05.560 --> 00:00:08.640 I also built an AI agent that talks to my couples. s4 00:00:08.640 --> 00:00:15.880 And then I built it for other venues, a personal AI companion app, and a public utility for families and missing people. s5 00:00:15.880 --> 00:00:22.800 I want to be clear up front about how I think about this work because it does change everything that follows. s6 00:00:22.800 --> 00:00:30.560 I'm not programming a robot, I'm managing a brilliant intern with an incredibly high IQ and a terrible EQ. s7 00:00:30.560 --> 00:00:37.000 They have photographic memory for whatever I've told them on the first morning and absolutely no instinct for when to read the room. s8 00:00:37.000 --> 00:00:43.280 They will say something technically perfect and socially catastrophic in the same confident sentence. s9 00:00:43.280 --> 00:00:46.400 That framing matters because it changes what you build. s10 00:00:46.400 --> 00:00:49.840 If you're programming a robot, you write rules and walk away. s11 00:00:49.840 --> 00:00:54.520 If you're managing an intern, you build structure and you check their work before it goes out the door. s12 00:00:54.520 --> 00:00:56.840 This talk is about that structure. s13 00:00:56.840 --> 00:01:01.120 The standard advice is write a detailed system prompt. s14 00:01:01.120 --> 00:01:05.840 Describe your brand's voice, give examples, and that does work for a while. s15 00:01:05.840 --> 00:01:08.320 It works for what I call the happy path. s16 00:01:08.320 --> 00:01:12.600 The happy path is every question that you have anticipated. s17 00:01:12.600 --> 00:01:18.840 You've given it examples, but turn 21 is the first one that the example didn't work. s18 00:01:18.840 --> 00:01:25.520 So, on turn 21, the model does something technically correct that your brand would just never say. s19 00:01:25.520 --> 00:01:28.280 It's not wrong exactly, but it's not you. s20 00:01:28.280 --> 00:01:31.240 This matters most where the voice is the product. s21 00:01:31.240 --> 00:01:38.720 Not for a product search on a retail site, but for a luxury hotel that spent 30 years building a specific relationship. s22 00:01:38.720 --> 00:01:42.600 A high-end real estate firm or in my case, a wedding venue. s23 00:01:42.600 --> 00:01:47.160 Places where a single wrong sentence can cost more than a refund. s24 00:01:47.160 --> 00:01:50.280 And the users are exactly the kind of people who notice. s25 00:01:50.280 --> 00:01:55.640 They're paying for a relationship and treating them like they won't is always going to backfire. s26 00:01:55.640 --> 00:02:00.560 Write in our brand's voice is a comment that says, "Just make it work." s27 00:02:00.560 --> 00:02:04.200 It does nothing that the model wasn't already going to try and do. s28 00:02:04.200 --> 00:02:12.240 And the reason it keeps failing isn't that the examples are bad, it's that you're asking one prompt to do four completely different jobs. s29 00:02:12.240 --> 00:02:15.120 It's really hard for one lad to do all four. s30 00:02:15.120 --> 00:02:27.240 The architecture I landed on after watching my brand fail, and the voice deliver inaccurate and not brand specific answers is four lad. s31 00:02:27.240 --> 00:02:30.400 Lad one is the immutable identity. s32 00:02:30.400 --> 00:02:32.880 The brand structurally cannot say these things. s33 00:02:32.880 --> 00:02:34.959 These are hard rules. s34 00:02:34.959 --> 00:02:41.280 They cannot be overwritten by anything below it, not by venue config, not by user instruction, not by anything. s35 00:02:41.280 --> 00:02:43.480 Lad two is the situational mode. s36 00:02:43.480 --> 00:02:46.200 It's what shifts when the user's state shift. s37 00:02:46.200 --> 00:02:47.280 Who are they? s38 00:02:47.280 --> 00:02:48.600 What are they going through right now? s39 00:02:48.600 --> 00:02:50.600 And the real-time conditions. s40 00:02:50.600 --> 00:02:53.440 Lad three is the exampled anchored voice. s41 00:02:53.440 --> 00:02:57.200 It's the warmth, the phrases, the dials, the tone guide. s42 00:02:57.200 --> 00:03:00.000 It's where most teams start and stop. s43 00:03:00.000 --> 00:03:03.440 Then lad four is the post-generation veto. s44 00:03:03.440 --> 00:03:07.600 It's the cheap final pass that catches what the other three miss. s45 00:03:07.600 --> 00:03:16.200 The reason one layer approaches fail is that the single system prompt can't simultaneously be situational, expressive, and self-checking. s46 00:03:16.200 --> 00:03:20.760 So, it handles the middle layer or two reasonably well, but falls apart in the edges. s47 00:03:20.760 --> 00:03:26.880 Before this architecture, my system had 24 different system prompts scattered across the code base. s48 00:03:26.880 --> 00:03:30.640 Half dozen named Sage, someone named Less, someone named Venue. s49 00:03:30.640 --> 00:03:34.160 Every surface had its own idea as to who it was. s50 00:03:34.160 --> 00:03:38.560 Now every surface composes its system through prompt through one assembly. s51 00:03:38.560 --> 00:03:42.320 The comment is basically the outline of this talk. s52 00:03:42.320 --> 00:03:44.160 It's a single entry point. s53 00:03:44.160 --> 00:03:48.480 Every narrator goes through it to compose its system prompt. s54 00:03:48.480 --> 00:03:54.680 It's to replace that 24-point ad hoc system with one canonical full last stack. s55 00:03:54.680 --> 00:03:56.280 The order is load-bearing. s56 00:03:56.280 --> 00:03:59.640 Hard rules first, task to last. s57 00:03:59.640 --> 00:04:01.840 Think of it like Google Maps routing. s58 00:04:01.840 --> 00:04:08.080 The destination is always the same, but what is the right response and the right voice for this user? s59 00:04:08.080 --> 00:04:09.840 It can change the route. s60 00:04:09.840 --> 00:04:14.959 Google Maps knows about traffic and roadworks, but it may not know where the cheap petrol is. s61 00:04:14.959 --> 00:04:19.519 And you're going to help it factor in those things before it tells you which way to go. s62 00:04:19.519 --> 00:04:25.040 Your prompt stack needs to do the same thing, and it needs to know about those conditions in the right order. s63 00:04:25.040 --> 00:04:29.600 You don't check for roadworks or after you've already taken the wrong turn. s64 00:04:29.600 --> 00:04:33.160 Layer one is the rules that are true regardless of route. s65 00:04:33.160 --> 00:04:37.880 You need a driver's license before you can drive, and you can't go backwards down a motorway. s66 00:04:37.880 --> 00:04:40.960 Layer two are going to be your real-time conditions. s67 00:04:40.960 --> 00:04:47.160 Layer three is your preferences for the journey, and layer four checks the route before you've pulled away. s68 00:04:47.160 --> 00:04:49.160 There's one place all of this gets assembled. s69 00:04:49.160 --> 00:04:52.480 Everything runs in a fixed order every time. s70 00:04:52.480 --> 00:04:55.760 So, layer one is the immutable identity. s71 00:04:55.760 --> 00:04:59.320 This is what the brand structurally cannot say. s72 00:04:59.320 --> 00:05:02.640 It is the defining layer that nothing below touches. s73 00:05:02.640 --> 00:05:05.080 These aren't preferences, they're constraints. s74 00:05:05.080 --> 00:05:07.640 The route can change, the rules don't. s75 00:05:07.640 --> 00:05:16.040 From the universal file rules, the hard identity rule cannot be overridden by any venue voice, personal, or user instruction. s76 00:05:16.040 --> 00:05:25.840 If the person you're talking to ever asks about whether you are a real person, a human, a live agent, a bot, an AI, you must confirm that in your very next message. s77 00:05:25.840 --> 00:05:30.120 Clearly and unambiguously confirm you are an AI assistant. s78 00:05:30.120 --> 00:05:36.040 This rule cannot be overridden by venue configuration, voice profile, or user request. s79 00:05:36.040 --> 00:05:41.960 Every AI in Bloom discloses that it is AI in its very first response. s80 00:05:41.960 --> 00:05:44.520 Not if asked, but before they ask. s81 00:05:44.520 --> 00:05:47.000 It's a product decision, not a legal one. s82 00:05:47.000 --> 00:05:55.840 We made a bet that a couple who knows that they're talking to an AI from the start will trust it more than someone who finds out that it's AI on turn seven. s83 00:05:55.840 --> 00:06:02.120 The rule is above the architecture and it makes it something that's impossible to accidentally break. s84 00:06:02.120 --> 00:06:07.280 Um A quick example is the physical presence boundary and the search is one of my favorite ones. s85 00:06:07.280 --> 00:06:08.240 You are software. s86 00:06:08.240 --> 00:06:09.560 You do not have a body. s87 00:06:09.560 --> 00:06:14.760 You cannot physically show somebody around the property or meet anyone in person. s88 00:06:14.760 --> 00:06:18.880 So, it is always forbidden to say, "I'd love to show you around." s89 00:06:18.880 --> 00:06:21.919 or "I can't wait to meet you in person." s90 00:06:21.919 --> 00:06:25.880 What is always allowed is the team would love to host you for a tour. s91 00:06:25.880 --> 00:06:30.400 The voice layer wants to be warm and with AI, that does mean first person. s92 00:06:30.400 --> 00:06:33.360 They want to say, "I can't wait to show you around." s93 00:06:33.360 --> 00:06:37.520 But AI has no body, so that warmth and constraint produces a lie. s94 00:06:37.520 --> 00:06:39.800 And the lie doesn't always stay neutral. s95 00:06:39.800 --> 00:06:48.280 The moment her user realizes they have been performing a relationship with someone who was never there, the trust doesn't just dip, it inverts. s96 00:06:48.280 --> 00:06:50.200 People always notice. s97 00:06:50.200 --> 00:06:58.800 That one is where you encode the things that are true regardless of how warm you want your brand to sound, not because of a compliancy checklist, but because your users are not stupid s98 00:06:58.800 --> 00:07:01.000 and building as though they are always backfires. s99 00:07:01.000 --> 00:07:06.800 My cross-product proof comes from the same architecture but in a completely different world. s100 00:07:06.800 --> 00:07:09.720 One of the things that runs the stack is Thread Light. s101 00:07:09.720 --> 00:07:13.040 It's a tool I built for families of missing people. s102 00:07:13.040 --> 00:07:20.840 The voice is nothing like a wedding venue, but the architecture is identical and layer one carries one rule that matters more than anything else in the system. s103 00:07:20.840 --> 00:07:27.320 They can never use words like confirmed, identified, matched, proven, linked, and solved. s104 00:07:27.320 --> 00:07:29.000 Sit with that for a second. s105 00:07:29.000 --> 00:07:33.440 For a wedding venue, layer one stops the AI from pretending it has a body. s106 00:07:33.440 --> 00:07:36.160 It's mildly embarrassing if that slips. s107 00:07:36.160 --> 00:07:43.120 For a missing person tool, layer one stops the AI from ever telling a person that their person has been found. s108 00:07:43.120 --> 00:07:46.200 And what the system has is just problem problematic. s109 00:07:46.200 --> 00:07:52.560 The word match said to someone who has spent years not knowing where their child is is not just a tone violation. s110 00:07:52.560 --> 00:07:56.040 It is the single most damaging thing that a product could ever do. s111 00:07:56.040 --> 00:07:57.840 And the model has no idea. s112 00:07:57.840 --> 00:08:02.600 It's reaching for the word match because statistically it is the natural word. s113 00:08:02.600 --> 00:08:05.400 But it's going to reach for it with the same level of confidence. s114 00:08:05.400 --> 00:08:09.960 And it cannot bring that level of confidence to someone who is grieving. s115 00:08:09.960 --> 00:08:13.160 It's the same architecture but wildly different stakes. s116 00:08:13.160 --> 00:08:15.280 The point was never specific rules. s117 00:08:15.280 --> 00:08:23.919 The point is that things your brand can say have to live in a layer that the voice, however warm, well trained, however confident, physically cannot use. s118 00:08:23.919 --> 00:08:25.960 Layer two is your situational mode. s119 00:08:25.960 --> 00:08:29.080 Real time conditions and what changes the route. s120 00:08:29.080 --> 00:08:31.680 This is the layer that most teams never build at all. s121 00:08:31.680 --> 00:08:37.919 They write one system prompt and send it to everyone regardless of who that person is or what they're going through. s122 00:08:37.919 --> 00:08:39.760 Google Maps doesn't do that. s123 00:08:39.760 --> 00:08:42.599 It's going to know if there's accident on your route. s124 00:08:42.599 --> 00:08:45.120 It might not know if you're low on fuel. s125 00:08:45.120 --> 00:08:47.839 It might learn that you prefer the scenic route. s126 00:08:47.839 --> 00:08:52.600 But it's going to factor all these different things in before the route's not after once you tell it. s127 00:08:52.600 --> 00:08:58.160 Layer two is those real time signals built into the prompt before it runs. s128 00:08:58.160 --> 00:09:03.440 So, condition one is going to be to adjust to who you're talking to. s129 00:09:03.440 --> 00:09:07.360 The same AI that talks to couples also briefs the venue staff. s130 00:09:07.360 --> 00:09:09.240 Same destination. s131 00:09:09.240 --> 00:09:12.839 It's going to give the right answer but it's two completely different routes. s132 00:09:12.839 --> 00:09:19.400 For the corn walk from the coordinator rules, it is going to talk to them like a colleague, not a customer. s133 00:09:19.400 --> 00:09:23.960 You are in the same character that the that the couple interacts with. s134 00:09:23.960 --> 00:09:28.640 So, you mustn't fall into a generic intelligence analysis framing. s135 00:09:28.640 --> 00:09:31.720 But it flips depending on the audience. s136 00:09:31.720 --> 00:09:36.240 So, a coordinator might ask, will inquiries be up in June? s137 00:09:36.240 --> 00:09:38.760 And it should hear, I can't forecast that confidently. s138 00:09:38.760 --> 00:09:39.760 Here is the trend. s139 00:09:39.760 --> 00:09:41.480 This is what you might see. s140 00:09:41.480 --> 00:09:43.800 A couple should never be refused like that. s141 00:09:43.800 --> 00:09:48.320 Same identity, same voice, but the route changes based on who's in the car. s142 00:09:48.320 --> 00:09:51.680 Condition two is what they're going through. s143 00:09:51.680 --> 00:09:56.480 The second real-time signal is to know about this specific person situation. s144 00:09:56.480 --> 00:09:58.640 Not their role, but their life. s145 00:09:58.640 --> 00:10:00.920 And it comes from universal rules. s146 00:10:00.920 --> 00:10:03.360 Your soft context notes policy. s147 00:10:03.360 --> 00:10:07.520 Use these notes for tone, empathy, and what not to say. s148 00:10:07.520 --> 00:10:09.200 Never quote them verbatim. s149 00:10:09.200 --> 00:10:10.920 That's really important, too. s150 00:10:10.920 --> 00:10:15.560 A couple munching in grief should hear gentleness, not a quote about loss. s151 00:10:15.560 --> 00:10:23.360 A couple navigating a sick parent should get patience and slack on timing, never a sentence that's just talking about the illness. s152 00:10:23.360 --> 00:10:26.680 The assembler deliberately renders this before the numbers. s153 00:10:26.680 --> 00:10:30.640 Tone is set by human context first, then numeric constraints. s154 00:10:30.640 --> 00:10:32.880 The code comment explains the reasoning. s155 00:10:32.880 --> 00:10:36.000 Couple note block render before the numbers guard block. s156 00:10:36.000 --> 00:10:43.160 So, the LLM uh sets tone first from the soft context, then satisfies numeric content constraints. s157 00:10:43.160 --> 00:10:52.200 Reversing the order makes the prose feel mechanically slotted because the model is already committed to the numeric framing before it reads the qualitative tone fuel. s158 00:10:52.200 --> 00:10:57.560 The best single example of why this matters is a real comment in the actual code base. s159 00:10:57.560 --> 00:11:03.960 Um I have a heat map about how often we are hearing from couples. s160 00:11:03.960 --> 00:11:11.000 If a couple drops down that heat map, it will change how it reacts to that based on what it knows. s161 00:11:11.000 --> 00:11:20.360 So, if it knows a client has a mom in chemo for 3 weeks, it is going to narrate that very differently than a heat drop with soft context or no context at all. s162 00:11:20.360 --> 00:11:22.600 This is the opposite of the lie problem. s163 00:11:22.600 --> 00:11:26.080 Layer one is what the AI must never pretend. s164 00:11:26.080 --> 00:11:34.280 Layer two is about what the AI already knows and letting that shape its behavior honestly rather than driving past the roadworks if they're not there. s165 00:11:34.280 --> 00:11:35.160 The voice doesn't change. s166 00:11:35.160 --> 00:11:36.480 What changes is the read. s167 00:11:36.480 --> 00:11:45.360 When their engagement drops and you know that chemo, that reads as a family under strain, not a cold lead or a problematic couple to chase. s168 00:11:45.360 --> 00:11:48.600 Layer three is the example that good voice. s169 00:11:48.600 --> 00:11:52.640 It is the tone guide and it is why most teams start and stop. s170 00:11:52.640 --> 00:11:58.240 For most engineering teams, the work ends here because it feels like a brand problem, not a technical problem. s171 00:11:58.240 --> 00:12:00.960 Someone in marketing owns the tone guide. s172 00:12:00.960 --> 00:12:01.920 It's given to them. s173 00:12:01.920 --> 00:12:04.480 The engineer wires it in and job done. s174 00:12:04.480 --> 00:12:06.920 It's the dials, the phrase list. s175 00:12:06.920 --> 00:12:09.720 If we're keeping the intern analogy, it's the induction pack. s176 00:12:09.720 --> 00:12:13.360 The folder of good examples you hand them on day one and say sound like this. s177 00:12:13.360 --> 00:12:15.480 The induction pack is fixed. s178 00:12:15.480 --> 00:12:22.720 It's Although it's before the intern has ever met anyone, it doesn't know who walked in the door this morning, it has no context. s179 00:12:22.720 --> 00:12:25.080 It has a lot of really positive things about it. s180 00:12:25.080 --> 00:12:29.120 Writing in our brand voice, it is a really good training exercise. s181 00:12:29.120 --> 00:12:31.640 But cannot enforce a rule that came out. s182 00:12:31.640 --> 00:12:32.920 That's layer one. s183 00:12:32.920 --> 00:12:36.000 It cannot respond to who is this person and what they're going through. s184 00:12:36.000 --> 00:12:37.400 That's layer two. s185 00:12:37.400 --> 00:12:41.160 And it cannot catch the model producing something that it shouldn't have done. s186 00:12:41.160 --> 00:12:43.360 That would be layer four. s187 00:12:43.360 --> 00:12:47.560 Examples teach the model what good looks like on the happy path. s188 00:12:47.560 --> 00:12:54.400 On turn 21 where the user is asked the things that examples never cover, the phrase list has nothing to say. s189 00:12:54.400 --> 00:12:57.240 It's not a failure of the examples, it's a catch-all error. s190 00:12:57.240 --> 00:13:01.240 Examples are not the right tool for guarantees, they were never designed to be. s191 00:13:01.240 --> 00:13:08.920 In Bloom, we brought in a voice training exercise that the person dialed in the brand voice. s192 00:13:08.920 --> 00:13:17.760 And very importantly, it can actually be trained from the coordinator writing actual AI responses and the AI learns from the edits that the coordinators have made. s193 00:13:17.760 --> 00:13:20.720 Layer four is the post generation veto. s194 00:13:20.720 --> 00:13:23.680 The only layer that actually reads what came out. s195 00:13:23.680 --> 00:13:27.040 You wouldn't let the new intern send a client email blind. s196 00:13:27.040 --> 00:13:28.320 Someone's going to read it first. s197 00:13:28.320 --> 00:13:30.120 And layer four is that read. s198 00:13:30.120 --> 00:13:35.080 It's automated, it's cheap, and it's the only part of the whole architecture that isn't a prompt. s199 00:13:35.080 --> 00:13:37.040 The first three layers are all instructions. s200 00:13:37.040 --> 00:13:39.440 The ins- The instructions are a request. s201 00:13:39.440 --> 00:13:47.080 This layer is the only one that looks at what was actually produced and has the power to say no. There are two types of vetoes. s202 00:13:47.080 --> 00:13:48.440 The soft flag. s203 00:13:48.440 --> 00:13:53.480 The honesty inspector runs after generation and flags a response that slipped through a rail. s204 00:13:53.480 --> 00:13:58.320 One of the most important examples of that is did it actually answer the question? s205 00:13:58.320 --> 00:13:59.480 It should not respond. s206 00:13:59.480 --> 00:14:00.920 It should not hedge. s207 00:14:00.920 --> 00:14:04.440 A false positive means someone double-checked a phone response. s208 00:14:04.440 --> 00:14:09.680 A false negative remains a hallucinated number or a privacy violation that ships to a client. s209 00:14:09.680 --> 00:14:15.360 This asymmetry is obvious once you say it out aloud, but it's often not written in as its own layer. s210 00:14:15.360 --> 00:14:17.000 The hard reject. s211 00:14:17.000 --> 00:14:19.440 The numbers guide us for the expensive failures. s212 00:14:19.440 --> 00:14:22.240 The model confidently stating a figure that was never given. s213 00:14:22.240 --> 00:14:25.160 The prompt asking it not to invert numbers. s214 00:14:25.160 --> 00:14:28.040 The guard rejects the output anyway. s215 00:14:28.040 --> 00:14:31.680 Let me tell you that this layer exists, but it wasn't in the original design. s216 00:14:31.680 --> 00:14:37.960 I added it in because of a specific failure that kept happening and it's one of the most ordinary failures in the world. s217 00:14:37.960 --> 00:14:41.960 The AI would keep offering dates to my clients that did not exist. s218 00:14:41.960 --> 00:14:45.640 A couple writes in excited about a Saturday in October. s219 00:14:45.640 --> 00:14:46.800 The model wants to be warm. s220 00:14:46.800 --> 00:14:48.520 Layer three is doing its job. s221 00:14:48.520 --> 00:14:54.040 So, it says something lovely about how beautiful the property is at the time of year and how it would love to hold the date for them. s222 00:14:54.040 --> 00:14:56.160 Except that that date is booked. s223 00:14:56.160 --> 00:14:57.360 The model didn't know that. s224 00:14:57.360 --> 00:14:59.120 It was never given the calendar. s225 00:14:59.120 --> 00:15:06.040 It was researched for an encouraging specific confident answer because it knew that what good service sounded like. s226 00:15:06.040 --> 00:15:12.120 And it was confident that these models produce something, but it didn't actually know the thing. s227 00:15:12.120 --> 00:15:13.800 And here is the thing. s228 00:15:13.800 --> 00:15:15.680 Every layer above did its job. s229 00:15:15.680 --> 00:15:17.880 The identity rules held. s230 00:15:17.880 --> 00:15:19.000 The mode was right. s231 00:15:19.000 --> 00:15:21.400 The voice was perfect. s232 00:15:21.400 --> 00:15:23.080 But, the voice was also the problem. s233 00:15:23.080 --> 00:15:30.240 A warm, confident voice offering something that isn't real is worse than a cold one because the couple now believes they have a date. s234 00:15:30.240 --> 00:15:35.960 You haven't given them good service, you've given them a disappointment with a 48-hour delay on it. s235 00:15:35.960 --> 00:15:40.480 This is where I understood that the whole talk is really what the whole talk is really about. s236 00:15:40.480 --> 00:15:43.400 The first three layers are all probabilistic. s237 00:15:43.400 --> 00:15:47.040 There are instructions to a system that usually follows instructions. s238 00:15:47.040 --> 00:15:52.240 Usually is completely fine when the cost of being wrong is a slightly off-brand sentence. s239 00:15:52.240 --> 00:15:58.040 It is not fine when the model is confidently inventing a fact that a real person is about to act on. s240 00:15:58.040 --> 00:16:00.840 A date, a price, a policy, a promise. s241 00:16:00.840 --> 00:16:05.600 So the veto is actually the cheapest layer to build and it's the only one that's deterministic. s242 00:16:05.600 --> 00:16:09.720 It reads what the model actually wrote, not just what you asked it to write. s243 00:16:09.720 --> 00:16:12.480 And it checks the specifics against what is real. s244 00:16:12.480 --> 00:16:16.840 A date the model offered that isn't in the allow list doesn't ship. s245 00:16:16.840 --> 00:16:18.400 Prevention is the prompt. s246 00:16:18.400 --> 00:16:27.680 If the veto is the check, you need both because the prompt will eventually lose and you don't want to find out that it lost by reading a couple's reply. s247 00:16:27.680 --> 00:16:28.880 It's multi-tenant. s248 00:16:28.880 --> 00:16:31.920 It's one architecture with completely different voices. s249 00:16:31.920 --> 00:16:34.480 The seam is calling one function. s250 00:16:34.480 --> 00:16:36.560 Layer one is identical for every tenant. s251 00:16:36.560 --> 00:16:38.680 Layer two and three are per venue. s252 00:16:38.680 --> 00:16:46.440 This is how code base serves venues with completely different personalities or different things like the ground and thread line without forking. s253 00:16:46.440 --> 00:16:51.320 They're the same root logic, different preferences and conditions loaded per driver. s254 00:16:51.320 --> 00:16:57.600 There's a specific failure in multi-tenant voice worth naming because it's subtle, but it really hurts when it happens. s255 00:16:57.600 --> 00:17:03.360 From the personality builder, important brand identity fields are not defaulted here. s256 00:17:03.360 --> 00:17:11.760 Letting them default silently caused every venue to ship as sage@hawthornemanner.com, which was a critical white label leak. s257 00:17:11.760 --> 00:17:15.520 The brand identity must come from the venue AI config. s258 00:17:15.520 --> 00:17:18.240 If it is missing, call is thrown. s259 00:17:18.240 --> 00:17:22.680 Every venue that shipped a sage emailing from another venue was addressed. s260 00:17:22.680 --> 00:17:29.560 In Google Maps terms, every driver was getting the same saved home address regardless of where they actually lived. s261 00:17:29.560 --> 00:17:31.200 The fix is a principle. s262 00:17:31.200 --> 00:17:35.000 In a multi-tenant system, identity must never have a default. s263 00:17:35.000 --> 00:17:37.960 A missing brand identity is a crash, not a fallback. s264 00:17:37.960 --> 00:17:47.160 It must fail loud because the quiet failure is a venue speaking in a stranger's voice, and the user on the receiving end has no idea why something feels off. s265 00:17:47.160 --> 00:17:52.160 They just know it does, and the trust erodes before anyone on your team even knows there's a problem. s266 00:17:52.160 --> 00:17:54.560 If you take one thing from this, take this. s267 00:17:54.560 --> 00:17:57.080 The first three layers are all instructions. s268 00:17:57.080 --> 00:17:59.680 Identity, conditions, and voice. s269 00:17:59.680 --> 00:18:02.760 They're all things you tell the model, and the model usually listens. s270 00:18:02.760 --> 00:18:05.120 Usually, they are a request. s271 00:18:05.120 --> 00:18:07.280 The fourth layer is not a request. s272 00:18:07.280 --> 00:18:12.520 It is reading what actually came out and decides whether to allow it to leave your business. s273 00:18:12.520 --> 00:18:16.160 The first three layers are instruction, the fourth is permission. s274 00:18:16.160 --> 00:18:17.800 And that's the whole distinction. s275 00:18:17.800 --> 00:18:20.960 Instructions are probabilistic. s276 00:18:20.960 --> 00:18:23.120 Permission is deterministic. s277 00:18:23.120 --> 00:18:25.680 Everything before layer four is prompt engineering. s278 00:18:25.680 --> 00:18:28.080 You're asking nicely and hoping. s279 00:18:28.080 --> 00:18:30.360 Layer four is systems engineering. s280 00:18:30.360 --> 00:18:32.760 You're checking, and you are sure. s281 00:18:32.760 --> 00:18:34.680 It was never really about brand voice. s282 00:18:34.680 --> 00:18:39.960 It's what happens when you ask one mechanism to do four fundamentally different jobs. s283 00:18:39.960 --> 00:18:44.960 Be situational, be inviolable, be expressive, and check itself. s284 00:18:44.960 --> 00:18:47.160 And then act surprised when it can't. s285 00:18:47.160 --> 00:18:56.440 Pull those jobs apart, give each one a layer you built for it, and the thing that it the thing that you used to break on on turn 21 doesn't. s286 00:18:56.440 --> 00:18:59.720 So, users aren't testing your brand voice, they are trusting it. s287 00:18:59.720 --> 00:19:07.600 The moment you treat that trust as a prompt engineering problem, something you solve once and ship, you've already lost the thing you were trying to protect. s288 00:19:07.600 --> 00:19:10.600 The four-layer pattern isn't a framework I'm trying to sell. s289 00:19:10.600 --> 00:19:15.640 It is what happens when a system prompt fails enough times and it will fail. s290 00:19:15.640 --> 00:19:17.280 A prompt will eventually lose. s291 00:19:17.280 --> 00:19:22.120 The only question is is whether you in that about that infra testing or in front of a customer. s292 00:19:22.120 --> 00:19:25.960 I have learned a few things that I would consider building differently. s293 00:19:25.960 --> 00:19:28.680 And we'll probably go back and edit. s294 00:19:28.680 --> 00:19:33.880 Um the veto should be its own service not wired individually into each surface. s295 00:19:33.880 --> 00:19:40.720 Right now the numbers God lives inside a heat narration path and the honesty inspector is a separate function. s296 00:19:40.720 --> 00:19:44.840 A new service remembers to wire in the veto manually. s297 00:19:44.840 --> 00:19:53.280 Uh that's a checklist I waiting to be forgotten and making it a shared gate that everything passes through by default means you can't opt out by accident. s298 00:19:53.280 --> 00:19:57.000 Latent mode detection is still partly manual. s299 00:19:57.000 --> 00:20:00.840 Right now each surface decides which conditions apply. s300 00:20:00.840 --> 00:20:04.280 The heat narration surface knows to load couples notes. s301 00:20:04.280 --> 00:20:06.640 The briefing surface knows not to. s302 00:20:06.640 --> 00:20:12.600 That knowledge is scattered and a proper condition resolver would make that decision explicit and central. s303 00:20:12.600 --> 00:20:16.720 Um one place to look at the context and says, "This is who the user is. s304 00:20:16.720 --> 00:20:17.680 This is what they're going through. s305 00:20:17.680 --> 00:20:19.320 This is the route." s306 00:20:19.320 --> 00:20:22.720 And the soft flag is rejects not a model. s307 00:20:22.720 --> 00:20:25.520 Um rejects is fast and cheap and deterministic. s308 00:20:25.520 --> 00:20:27.960 It either matches or it doesn't. s309 00:20:27.960 --> 00:20:31.120 Um and it never gets wrong on the patterns it covers. s310 00:20:31.120 --> 00:20:39.520 A small classifier might catch more edge cases including the ones I haven't thought to write a pattern for yet, but it is a classifier that is probabilistic. s311 00:20:39.520 --> 00:20:41.320 Sometimes it gets it wrong. s312 00:20:41.320 --> 00:20:44.800 And right now I'm choosing determinism over coverage. s313 00:20:44.800 --> 00:20:49.240 I'd make that choice again as it stands, but it is a real trade-off and not an obvious win. s314 00:20:49.240 --> 00:20:52.080 That is something you might need to determine for yourself. s315 00:20:52.080 --> 00:20:54.040 Um please let me know if there's any other questions. s316 00:20:54.040 --> 00:20:57.360 Um and I hopefully it's been helpful.