Tell me how you would prepare a product for a compliance regime that does not exist yet.

Okay, so here's the honest version of this one. Haven Companion is a chat app, you talk to it in the evening about your day, and it talks back like it actually cares. Baran Aydin is the PM on it. A colleague from trust and safety asked him a plain question in a hallway one day, and he didn't have a real answer either.

How to answer this, stage by stage

Seven stages, and honestly, this is the one where sounding like a person matters more than sounding like a slide deck.

Let's learn

Okay, so here's the plain version. Haven Companion is an app you talk to, and people use it in the evening to decompress, to talk through their day, sometimes about genuinely hard stuff.

For a long while, a conversation in the app was one long, continuous thread. That felt right, since a companion is supposed to remember things, and remembering means the thread just keeps growing.

The catch: if the AI said something a little off, a little tone-deaf, in the middle of a genuinely personal conversation, there was no way to fix just that one moment. Your only real option was closing the app and starting over, which meant retyping everything you'd already said that night.

At its worst: someone has a rough night, the AI misreads them at exactly the wrong moment, and the only path forward is to erase three weeks of context and start the whole relationship with the app over from scratch.

What I would leave alone: the crisis-escalation path for genuinely risky content already works and is already logged reasonably well. I wouldn't rebuild that. I'd just make sure it feeds into the same record as everything else.

The lesson: good record-keeping and good compliance readiness turn out to be almost the same list, most of the time. You don't need the law written yet to know what "we can show our work" requires.

Now here is the same thing as a story

Short version's above, that's what you'd say in the room. Here's the actual moment that got Baran there.

Noor Rehman opens Haven Companion most nights around ten, after her shift, and talks through whatever the day handed her. She's good at this, she says exactly what she means, first try, most of the time.

For months, if the AI missed her point, she'd just correct it in the same breath. "That's not quite what I meant, I meant X." And for a long while, that worked fine.

Five steps, and the third one was never really a choice. It was the only door in the room.

Then a few nights where her correction just didn't land right, the conversation had moved on too far by the time she caught it, started to change something quieter in her. She stopped bothering to correct mid-conversation. She just started closing the app and reopening a clean session whenever a response felt off, retyping her whole day from the top.

Nobody on the team saw this as a problem. On a dashboard, it looked like more sessions, which looked like more engagement.

One of these looks like engagement on a chart. It's actually someone giving up on being understood.

What actually surfaced it was a colleague's remark, not a data point. Someone from trust and safety asked Baran, almost in passing, what the team would even show a regulator if one ever asked for a specific user's session history. Baran realized he didn't have a clean answer, because the sessions themselves kept getting thrown away and rebuilt from scratch by the users, not the system.

Four things a single message needs. Haven's messages, at the time, reliably had none of them.

The fix wasn't built as a compliance project. It was built because Noor, and users like her, deserved a way to correct one line without losing everything around it. That feature happens to produce exactly the kind of structured, timestamped, correctable record any future rule is likely to ask for.

Eight weeks, give or take. Cheap, next to what a real retrofit later would have cost.

With it live, the same rough night now goes differently: Noor taps the one message that missed her, types a one-line correction, and keeps going, three weeks of context intact instead of gone.

I let sessions be one continuous, uncorrectable thread because that felt like the natural shape for a companion app, remembering everything. It took a colleague's offhand question, not an incident, to see that "remembering everything" and "being able to explain any of it later" were never actually the same promise.

BOUND, said out loudNot a spreadsheet. BOUND is what keeps an estimate about the future honest instead of just confident-sounding.

Four assumptions, stated out loud, so anyone can push back on the one they disagree with.

The recap, one line per letter: break it down is the four real pieces of readiness, own numbers is each one's sourced estimate, use a range is four to fourteen weeks around an eight-week typical case, nail the sanity check is the GDPR-retrofit comparison, and direction is retroactive scope as the single biggest swing factor.

And if you want to be sure it really works, try it somewhere elseSame five letters, a dev-tools security scanner instead of a companion app. This time the swing factor isn't retroactive scope at all, it's who's actually liable.

Fenwick Security runs an AI tool that scans customer codebases for vulnerabilities before a release ships. Elina Saarinen manages that scanning feature.

Mapped onto BOUND: break it down is readiness equals a versioned record of every scan result, plus a clear statement of what the tool did and didn't check, plus a documented human-review path for anything the tool flags as high severity. Own numbers is two weeks for scan-result versioning, one week for a plain-language "here's what we checked" disclosure, three weeks for the human-review workflow. Use a range is four weeks typical, two weeks best case, ten weeks worst case if a future software-liability rule requires proving exactly which known vulnerabilities the tool was capable of catching at scan time. Nail the sanity check is comparing it to how long financial firms took to build model-risk documentation after banking regulators started asking for it, usually months, not weeks. Direction here isn't about old data at all, it's about liability: whether a future rule holds the tool vendor responsible for what it missed, or only the customer who shipped anyway, and that single question changes what "ready" even means far more than any technical build item does.

A different product, a different swing factor, and the same habit of naming the assumption before betting on it.

Swap the trigger and it still runs.
Speed: an interviewer caps you at a minute. Say "build the record-keeping that's good product design anyway, and name the one assumption that could triple the cost," and stop there.
Cost: leadership says there's no budget for anything not legally required yet. Build just the correction feature first, since it pays for itself in user trust today, regardless of what any future rule ends up saying.
The model gets better, for real: if Haven's conversational quality improves a lot, that's still no reason to skip this. A better model that still can't show what it said, when, and whether it was corrected has the same readiness gap as a worse one.

Where people run it wrong.
They try to guess the actual text of a law that doesn't exist yet, and build for the wrong specifics.
They treat "we don't know the rule" as a reason to build nothing, instead of building the parts that are good regardless.
They estimate a single number with no range, which claims a confidence nobody preparing for an unknown regime actually has.

How to use it live. When this question comes up, don't try to predict the law. Ask what "we can explain what happened here" would require, and build toward that instead. It covers you no matter what the rule ends up being called.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0