Follow-up Questions — Round 2

Everything still open after the 2026-07-06 interviews. None of these block starting Phase A–B of the build; questions marked ⚠️ block the stage named next to them. Answer inline under each question.

For Lisa

1. ⚠️ (blocks order-editor stage) Terms boilerplate text. Please export/copy the exact current terms text blocks — one for net-30/45/60/75/90 (she said these share the same language below the line) and the due-upon-receipt/prepay variant — so the new system reproduces them verbatim (with "broadcast" removed and advertiser name auto-filled).

Use what's there now. We may have new language before we put this into production. For now, use the existing Due Upon Receipt language for Due Upon Receipt entry. Then use the Net 30 language for all the rest, the only difference between net 30/45/60/75/90 is the due date (30, 45, 60 75, and 90 days respectively. )

2. ⚠️ (blocks catalog stage) The sellable catalog, precisely. For each: opening billboard (a "weekly chunk" = the billboard on all shows that week, or selectable shows? what's on the rate card for it?), newsletter (per issue? per month?), social media posts (per post? bundle?), banners (still just weekly % impressions?). What attributes does each need on an order line (units, dates/weeks, rate, impressions)?

We will have a new rate card before we put this system into production. At that time we will provide a catalog of salable units. For now use midroll (per show based on impressions), billboard (per week), newsletter, (per issue) banner (per impression), social media (per post).

2. Agency commission. For the gross rate card + net-to-TWiT report: is agency commission always the standard 15%, or per-agency? Should commission % live on the agency record?

Agency commissions are specific to the agency. That should be a field in the agency record.

2. Salespeople to provision. Lisa + Ty today — anyone else expected soon? And what is Russell's role? ✅ Russell & Patrick are TWiT's engineers (hosting/infrastructure input, not app users).

That doesn't matter. There will probably be others. We should be able to provision an arbitrary number of people.

2. Softness presentation toggle. You described two client-facing styles: zeroed-out lines inline ("lumped") vs. full-value lines with a below-the-line deduct. Confirm: per-order toggle between the two is what you want?

Depends on the client. Both should be possible. Lisa will choose.

2. Competitor separation. You keep a competitor list in a separate doc. Want the new system to know competitor groupings and warn when a proposal would put competitors on the same episode (never block, just warn)? Or keep that entirely human?

No that's human judgment. But a warning would be useful. The one-sheet has some information about competitors, but that's often specified in the sales order, too.

2. Proposal cleanup. Today you delete losing proposals after a signature. Keep manual delete, or also auto-flag proposals stale after N days for cleanup?

Manual delete only

2. Confirm: v1 order output = print-ready PDF you attach to DocuSign yourself (as today). DocuSign API integration deferred. OK?

Yes, defer DocuSign.

For Debi

1. The checklists. ✅ Received 2026-07-06 — captured in ~/Projects/twit-ads/reference/ (xlsx + checklists.md extraction). They surfaced two things we didn't know (see new questions D9/D10 below): Elroy and AFB.

https://docs.google.com/spreadsheets/d/17oSR2fFA1LyChriNwzANVUuFk6hFR6SIICVqz9t2tl0/edit?usp=sharing

https://docs.google.com/spreadsheets/d/1cVPk5Yqw5TCI5XAID_g8g6q3DDJPQelQV9Bmou8MLNw/edit?usp=sharing

1. Rundown contents, exactly. ✅ Received 2026-07-06 (screenshots in ~/Projects/twit-ads/reference/rundown-*.png): record-day tables (record window, show #ep, TD; advertiser + copy number; promo URL), billboard instruction lines per show, copy-Doc links below, plus the scheduled per-show Slack notes to the TDs with reader constraints ("DO NOTs" / "standard"). Folded into Specification W6 + stage C3. One small follow-up: what do the row colors mean? ✅ Answered 2026-07-06 (Leo): colors are just for emphasis — they carry no meaning. C3 renders a visually similar table; no data model impact.

2. The "ad schedule" doc. You mentioned an ad schedule "only a few of us can touch" that gets updated as new copy comes in and "pulled into the system." What lives there vs. in TwitAds? Should the new system absorb it, or keep it external?

It's in TWiT-Ads - no other schedule exists. TWiT-Ads is canon. We do make a copy in Google Docs - you can do that.

1. Copy assignment rules. We've catalogued three patterns: evergreen (same copy until replaced), date-windowed (Helix Sleep), per-episode. Any others? When copy changes mid-flight, does the old copy ever need to stay on already-aired episodes for the record (we assume yes)?

Once a show airs the ad never changes. All ad copy is for upcoming shows.

2. Fair rotation. If the system suggested a fair arrangement each time an order closes but you always had final manual control (arrows/drag like today), useful — or noise?

Useful.

2. Advertiser aliases. Contract name vs. brand name (Abine/DeleteMe): if each advertiser record listed its brand names and the schedule displayed the brand, does that solve the sorting confusion?

Yes.

2. Episode horizon. How far ahead should episodes exist in the system (rest of calendar year? rolling 12 months)? And who should be able to move/cancel an episode — just you + admin?

The following year gets populated mid-year. So at least 18 months. Make it two years just in case.

2. Non-negotiable terms list. You refuse e.g. 15-day cancellation. What are the other hard limits, so intake checking can eventually be encoded as warnings?

This will all be handled manually. There are no hard rules.

9. What is AFB? ✅ Answered 2026-07-06 (Leo): there is no AFB saleable unit. Ignore it — not in the catalog, not a side-flow the system cares about.

10. Elroy. ✅ Answered 2026-07-06 (Leo): TwitAds is canon; Elroy is the backend for TWiTcast, and Leo already has API access. Phase-2 push of URL/codes/sponsor data from the new system into Elroy stays on the backlog (kills today's triple entry) — unblocked when we want it.

11. Lower thirds. ✅ Answered 2026-07-06 (Leo): lower thirds, banner graphics, etc. are graphical elements generated independently — the system never handles them. (Banners remain a sellable line item per Lisa's catalog; the system just never touches graphics or serving.)

For Leo (decisions / access)

1. Uniblab. ✅ Answered 2026-07-06: Uniblab has a complete API — phase-2 delivery-reporting integration is unblocked. Spotify impressions have no known automated path (true-up/gross-up stays manual) — also phase 2.

2. Google Workspace SSO. Cloud phase wants "sign in with TWiT Google account." Confirm you can create an OAuth client in the twit.tv Workspace when we get there (testbed uses local logins).

We'll decide that after testing. I am not certain we want Google SSO.

1. Cloud target preference. ✅ Answered 2026-07-06, updated with Russell's direction same day: local (Framework) for testing now; production = AWS EC2 + RDS Postgres behind Cloudflare Access zero-trust — AWS keeps it with the rest of TWiT's critical infra, Azure stays the editors' plane. Russell will work with Opus/Fable directly at Phase E. Recorded in Specification §6.

2. Micah/editors access model. Tokenized read-only rundown link (no login) vs. real accounts?

Hosts and editors currently have no access. This system is intended for sales and continuity. But I like the idea of read-only links or web pages for editors and hosts.

1. Legacy data seeding. "Keep nothing" stands, but shall we import names only (active shows, active advertisers, current rate card) from the SQL extract to save re-typing, with Lisa/Debi pruning the list?

I think we will want historic data, so be prepared to import the historic data under the new schema.