Isadora Martin-Dye
Founder at Isadora $ Co
Culpeper, Virginia, United States
Actions
Isadora Martin-Dye is the founder of Bloom, a venue intelligence platform for the wedding industry, and the owner-operator of Rixey Manor, a Knot Hall of Fame wedding venue in Rixeyville, Virginia. She runs both - a working venue and a software company - from the same desk.
A non-engineer by training, she ships production AI through 2,700+ lines of living architecture doctrine, versioned prompts with dual-provider fallback, and a cross-tier audit framework she designed to stress-test her own work. British-born and Virginia-based, she builds for industries where the transaction is irreplaceable, the customer is emotional, and "the model hallucinated" isn't an acceptable answer.
Area of Expertise
Topics
Stop Writing Tone Instructions. Layer Them.
Tone instructions in a system prompt collapse the moment your AI hits production. "Write in our brand voice" is the prompt-engineering equivalent of writing a comment that says "make it work." It does nothing the model wasn't already going to do, and it breaks the moment a user asks something the example outputs didn't cover.
I built five production AI products on the same technical spine, three of them with strong, distinct brand voices that had to hold under unusual conditions. Couples in the most emotionally loaded purchase of their lives. Families of missing people. Multi-tenant hospitality clients with completely different tones from each other. The four-layer architecture in this talk is what survived contact with all of them.
The four layers, in order: the immutable identity layer (what the brand structurally cannot say), the situational mode layer (what shifts when the user's state shifts), the example-anchored voice layer (where most teams stop, and why it isn't enough on its own), and the post-generation veto layer (the cheap final pass that catches what the other three missed).
Real prompts. The multi-tenant pattern that made it scale. The failure cases that forced each layer into existence. The version I'd build differently if I started today.
Could do a hands-on workshop on prompt building.
Horizontal AI Won't Win Your Market
Horizontal AI products get the press. Vertical AI products take the market. This is the operator's case for going deep into one industry instead of broad across many.
I run five production AI products across five different verticals, all built on the same technical spine. Wedding venues, hospitality CRM, personal life OS, cold-case investigation, and a wearable-driven AI companion. The ones that work and the ones that don't differ by exactly one thing: how deeply the prompt, the schema, and the failure modes encode the actual workflow.
The talk covers what "vertical" actually means in code. The four points where a horizontal AI product breaks contact with a real industry. Why most "AI for X" startups are horizontal products in costume. The specific moats that compound when you're vertical and don't exist when you're not. And the moment in each of my five products where I had to choose between staying generic and getting useful, and what happened when I picked one over the other.
For founders deciding what to build next, AI engineers picking which side of the ecosystem to bet on, and anyone who has shipped a feature for "everyone" and watched it land for no one.
Forbidden Words, Forced Pauses, Locked Modes: Defensive Patterns for High-Stakes LLM Deployments
Most LLM safety work assumes the threat is an adversarial user attacking the system. I ship for the inverse: production AI applications where the threat is the system itself attacking a vulnerable user. The defensive controls turn out to be the same primitives security engineers already use, applied to a non-traditional threat surface.
I build software for three audiences who share one thing: a generic AI response will hurt them. Couples planning their wedding, in the most emotionally loaded purchase of their lives. Families of missing people, in active grief and vulnerable to anything that sounds like false hope. And anyone capturing their own worst moments in a private journal, where a chipper AI cheerleader does real damage. The interesting design work in each of these production systems is not what the AI is allowed to say. It is the words that are forbidden, the pauses that are forced, and the protected modes the system locks itself into when it notices the user isn't okay.
This talk walks through the actual code from three live products. A Claude-powered email agent for wedding venues with a routing layer that pulls high-stakes conversations away from the model entirely. A missing-persons intelligence platform with epistemic disclaimers banning words like "confirmed" and "matched" at the prompt level, plus a post-generation validator that catches them when the deny-list fails. And a personal AI companion that detects emotional-state signals from user input and auto-locks the session into a protected mode where features quietly switch off.
Attendees leave with a portable pattern language for defensive controls in user-harm threat models: when to forbid at the prompt layer, when to route around the model, when to validate after generation, and when to lock the session down entirely. With production code, real metrics, and the failure modes that taught me to add each control in the first place.
Forbidden Words, Forced Pauses, Locked Modes: Defensive Patterns for High-Stakes LLM Deployments
Description:
Most API security work assumes the threat is an adversarial user attacking the system. Production AI in emotionally sensitive contexts inverts that model: the threat is the system itself, and the victim is the user. The defensive controls turn out to be the same primitives API security engineers already know, applied to a non-traditional threat surface.
This talk walks through three production systems with three different defensive architectures. A pre-generation routing layer that classifies high-stakes API inputs and diverts them before the model ever sees them. A two-layer output validation system built for a missing-persons platform where words like "confirmed" and "matched" are functionally hallucinations with real-world consequences: prompt-level deny-list first, post-generation validator second. And a runtime state machine that detects emotional-state signals in user input and locks the session into a protected mode, silently upgrading the model tier and disabling features.
Attendees leave with a defensive-control taxonomy for user-harm threat models: when to filter at the API input layer, when to validate at the output layer, when to route around the model entirely, and when to lock the session at the application layer. Production code, real failure cases, and the metrics that motivated each control.
Designing an API Layer for AI Providers You Can't Trust
Every team shipping production AI eventually faces the same problem: the model API you depend on will fail. It will rate-limit you mid-request, return malformed JSON, deprecate without warning, raise prices, or simply go down on a Tuesday afternoon. If your application treats the model as a hard dependency, your application is as reliable as your weakest provider.
This talk walks through the design of a dual-provider AI abstraction layer in production at Bloom, a vertical AI platform for the wedding industry. We'll cover the API contract that lets a single call route between Claude and GPT-4o without the calling code knowing which provider answered, the cost-routing logic that picks providers based on task class rather than just price, the fallback semantics when the primary fails mid-stream, and the observability layer that tells you which provider you actually paid for at the end of the month.
Attendees leave with a concrete pattern for treating LLM providers the way mature systems treat any other unreliable upstream dependency: with versioned contracts, explicit fallback paths, cost ceilings enforced above the model, and audit trails that survive a postmortem. Useful for any team currently coupled to a single AI vendor and wondering what happens the day that vendor changes the deal.
Doctrine-Driven Development: Shipping Production AI Without Writing the Code
I'm a wedding venue owner who built a production AI platform without writing the code myself. Not because I was coasting on agents - because I wrote the spec so tightly that the code became the easy part.
Bloom is a venue intelligence platform now in active build across four tiers, with prompt versioning, dual-provider fallback, a four-character cross-tier audit framework, and a 2,700-line living architecture doctrine that gets fed to Claude Code at the start of every session. The doctrine isn't documentation. It's the spec, the test plan, the security policy, and the cost ceiling, all in one place, all under version control, all enforced by audit.
This talk is about what I've learned doing it: where doctrine-driven development actually works, where it falls apart, and what the real failure modes look like when the founder is the architect and the model is the contractor.
I'll walk through three specific findings from a recent audit - an AI name leak that was worse than the doctrine tracker indicated, an inquiry-date recomputation gap, and a cost ceiling enforcement hole — and what each one taught me about the limits of writing your way to correctness.
The audience leaves with a concrete framework for treating prompts as governed artifacts: versioned, audited, fallback-protected, and tied to enforceable cost and security boundaries. Useful Monday morning whether you're a non-engineer founder or an engineering lead trying to bring AI work under the same discipline as the rest of your stack.
Why me, why this audience:
I'm not pitching a product. I'm an operator with a build I can show, in a category - vertical AI for a regulated, relationship-heavy industry - that the DC audience will recognize structurally even if the surface domain is unfamiliar. Wedding venues aren't federal agencies, but the constraints rhyme: irreplaceable transactions, low tolerance for AI failure modes, real money on the line, and no appetite for "the model hallucinated" as an answer.
I live in Rixeyville, Virginia. Inside the 100-mile radius.
API World 2026 Sessionize Event Upcoming
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top