Skip to content

Speaker Platform — Capability & AI-Readiness Brief

A capability overview of the Foxtrot November speaker/content pipeline — from CFP submission to the deck on the room's production laptop — for sales, solutions, and leadership use. Grounded in the shipped code across call-for-presentations (the speaker portal), track-chairs (the review app, a.k.a. FNreview), summit-api, and dropbox-materializer, plus the operator guides. Client/event names intentionally omitted.

Siblings: Platform brief · Digital Signage · Sponsor Services · Streaming, Virtual & Overflow.

In one line

The full content lifecycle on one platform, one login: speakers submit through a data-driven CFP portal, track chairs review and select with votes, rubrics, and ranked team lists, decisions notify automatically (state-aware emails, registration promo codes), decks flow to the venue — every room's production laptop syncs its own folder, files in running order — with uploads accepted right up to showtime.

1. The pipeline

Speaker submits (CFP portal) → Track chairs review & select (votes/rubric/ranked lists)
  → Admin approves → accept/reject emails + speaker promo codes
  → Speakers upload decks (draft → final upload rounds)
  → Ops verify (spot-check workflow) — incl. the on-site Speaker Support Room
  → Materializer projects finals into per-room folders (running order)
  → The room laptop's synced folder is show-ready

2. Submission — a CFP portal that's pure configuration

The speaker portal's wizard is data-driven end to end: steps appear or disappear per event type and selection plan (uploads only if the type allows media; speakers step only if the type takes co-speakers), every summary field is toggled and locked per plan (allowed_presentation_questions / …_editable_questions), and a seven-type extra-questions engine (text, textarea, checkbox, combo, country, checkbox-list, radio-list) renders whatever the plan defines — mandatory flags, ordering, editability included.

  • Selection-plan windows gate everything against a server-synced clock: submissions open/close on the second, closed plans go read-only, per-user submission caps enforced. Multiple plans run concurrently — each with its own forms, questions, and deadlines.
  • Speaker profiles are first-class (bio, photos, affiliations, expertise, languages) and required before submitting. Co-speaker invites by email — existing speakers attach instantly; new ones get a create-and-attach flow, with an edit-permission request system protecting profiles.
  • Media uploads at submission with per-type constraints (extensions, size, min/max counts, mandatory flags).
  • White-label per tenant and per show: labels, sections, branding, and even languages are marketing-config data — the same portal serves different communities with different vocabularies, no code changes.

3. Review & selection — structured judgment, not spreadsheets

The review app gives each track's chairs a shared workspace:

  • Vote fast: Yes / Interested / No-thanks with single-key shortcuts, free-text and tag search, "needs vote" queues, auto mark-as-read, CSV export.
  • Score rigorously (optional): per-plan weighted rubrics with per-criterion star scoring.
  • Select as a team: each chair keeps a ranked individual list; the track converges on a shared team list (optimistic-concurrency protected) where rank order is the decision — slots above the track's session count are Accepted, the next ones are Alternates.
  • Curate the schedule: a drag-and-drop proposed schedule per track (room/time slots, allowed locations), locked and handed to admins for final publication.
  • Governed exceptions: track-change requests with an approval queue; internal comments and progress flags on every submission.

Decisions flow back automatically: after admin approval, the platform sends state-aware announcement emails — the email family covers every accepted/alternate/rejected combination a speaker can hold, each per-show templated, with duplicate-send protection — and can mint registration promo codes per speaker (shared multi-speaker codes or auto-generated individual codes) as part of the same send.

4. Decks to the stage — the last mile no one else does

This is the platform's signature move: published presentations materialize onto the venue's production machines automatically.

  • When the schedule publishes (or changes), a snapshot event fires and the materializer syncs every in-schedule room: one folder per room, and every deck named YYYY-MM-DDTHHMM_Title_… so the folder sorts itself into running order. The production laptop at the podium just has Dropbox — its room folder is show-ready, no network dependency at session time.
  • Late changes are the design center, not an edge case: uploads are accepted right up to the activity start. A replaced deck syncs on the next snapshot; the superseded version is archived, never destroyed (timestamped rename) — new material lands before old material is retired.
  • The Speaker Support Room workflow: on-site staff take a walk-in speaker's updated deck, find the activity in the admin console (by speaker or title), and replace the Final Presentation Upload — the materializer carries it to the room folder. Pre-show, a documented verification workflow spot-checks uploaded decks (corrupt-file triage before it's ever on a podium).
  • Ops-hardened: per-summit sync locks, content-hash dedup (re-syncs copy nothing), an hourly preflight that emails alerts for missing files, per-room and full rebuild modes, metrics.

5. AI-ready by architecture

  • The entire CFP is data an agent can author: selection plans, event types, question sets, upload constraints, labels — a show's whole submission experience can be composed (from a prior show, a prompt, or a policy doc) by writing configuration, not code.
  • Machine-readable pipeline state: submissions, statuses (received → in-review → accepted/alternate/rejected → published), scores, lists, and media are all OAuth2-scoped API surface — the same interface the apps use, available to any governed agent (see the platform brief: AI gets a badge).
  • Content ops are event-driven: the publish→materialize chain is a message-bus pipeline an agent can observe or extend.

Positioning notes — accuracy guardrails (internal)

  • Materializer curation is spec-stage, not shipped: today the sync is additive/never-delete (a reschedule leaves the old copy in place until a rebuild), and it copies all upload types (the finals-only allowlist + reconcile-to-snapshot purge are approved-direction SDS work in flight, #69). Frame as "additive-safe by design, with automated curation landing next" — do not claim self-cleaning folders today.
  • "FNreview" is the ops name; the app brands as "TrackChairs." Use "the review app" externally.
  • Accepted/Alternate is a rank-threshold on the team list (session_count / alternate_count) — not a separate per-item status field; don't describe a three-bucket UI.
  • Speaker promo codes: multi-speaker + auto-generate-per-speaker strategies ship in the email send; the auto-apply/auto-discover at registration flow is a pending SDS — "codes minted with the acceptance email" is safe, "codes apply themselves" is not yet.
  • Speaker-facing review comments are disabled in the shipped review UI (comments are internal; the public-comment path is dead code). Don't promise reviewer↔speaker messaging.
  • The support-room replace flow is manual delete-then-upload in the admin console — a documented operator workflow, not a dedicated app. (It works precisely because the materializer does the distribution.)
  • Room-laptop sync rides the Dropbox client; the materializer performs server-side Dropbox copies (decks are already in Dropbox storage). Don't imply a custom on-prem agent.
  • No client/event names in external material.