Foxtrot November — Platform Capability & AI-Readiness Brief¶
The umbrella capability overview of the Foxtrot November platform, written for sales, solutions, and leadership use (RFP responses and AI-forward event pitches). Grounded in
architecture/platform-overview.md, the repository reference, and the code-verified sibling briefs. Client/event names intentionally omitted.
Siblings: Sponsor Services · Digital Signage · Speaker Platform · Repository Reference.
The overview (paste-ready)¶
Foxtrot November is an API-first event operating system built around a deliberately small, hardened core: our own OIDC identity provider, a central event API, and a composable event-site framework. Everything an event needs — registration and ticketing, content submission and review, scheduling, sponsor operations and lead retrieval, digital signage, badging and check-in, streaming and overflow, native attendee apps — runs as a focused client application against that core, authenticated through one identity and a tightly controlled OAuth2 services layer: every endpoint scope-gated, every client granted exactly the access it needs, every attendee, speaker, sponsor, and operator carrying a single login across every touchpoint, online and on the venue floor. We built it because off-the-shelf event tools stop where real conferences begin — they handle registration pages, but not the operational reality of a venue: the room that overflows mid-keynote, the deck that changes twenty minutes before a session, the sponsor scanning leads on a crowded expo floor. Born from running some of the industry's most demanding technical conferences and open-source rooted with commercial extensions, FN is event-operations aware by design — every real-world touchpoint is a first-class, programmable part of the platform, not an integration afterthought. That architecture is the differentiator: client-facing experiences can be built, branded, and replaced freely, because the identity and services layer underneath never moves.
For years, that architecture looked like over-engineering: every capability API-first, every contract published, every behavior data-driven — when a human with a browser only needed the page in front of them. Then AI arrived, and the architecture met its moment. To the platform, an AI agent is simply another OAuth2 client: it reads the same contracts our own apps use, holds only the scopes it's granted, and can generate signage, author sponsor catalogs, drive schedules, or integrate third-party tools with the same governed access as everything else. While legacy event suites bolt chat windows onto page-based products, FN was built composable — waiting for a consumer that could use every seam. AI is that consumer. It doesn't get bolted on; it gets a badge.
1. The identity spine — the part that never moves¶
The platform's signature is its OIDC/OAuth2 control plane:
- Our own identity provider. A long-lived, hardened OIDC IdP (OAuth2 + PKCE, passwordless email OTP, social login via Google/Facebook/Apple/Microsoft, group-based authorization for operational roles). One account follows a person across every show and every surface.
- Every client is an OAuth2 client — including hardware. Web apps, native mobile apps, iPad check-in kiosks, handheld badge scanners, signage screens: each is registered on the IdP with its own credentials and exactly the scopes it needs. The lead scanner a sponsor holds and the admin console an operator uses authenticate the same way.
- A tightly controlled services layer. Every API endpoint is scope-gated and, where warranted, group-gated; service-to-service calls use client-credentials tokens behind circuit breakers. Adding a new client — first-party, third-party, or AI — is a registration and scope grant, not a custom integration project.
2. What runs on it — the capability map¶
| Capability | What ships |
|---|---|
| Registration & ticketing | Multi-tier ticket types, invitation/audience controls, dependent extra questions, promo/discount code hierarchy (member/speaker/sponsor variants), Stripe payments, embeddable "registration lite" flow |
| Content & speakers | CFP submission portal (data-driven wizard), track-chair review & selection app, selection-process email automation, presentation media uploads, on-site deck distribution to room laptops (see the Speaker Platform brief) |
| Schedule & event sites | Composable event-site framework with themed front-ends; full/lite/filterable schedule widgets; real-time schedule sync to every client |
| Sponsors & expo | Self-service sponsor portal (orders, deliverables, booth workflows), lead retrieval with dedicated scanners + open API, organizer console + reports (brief) |
| Digital signage | Browser-based per-room/lobby signage, real-time controlled, any resolution (brief) |
| Badging & check-in | Badge printing app, iPad kiosk check-in, QR badge format with AES encryption, access-control scanning |
| Streaming & overflow | Per-session streaming (HLS/DASH and hosted sources), room-overflow flow: sign flips to "room full" + QR → key-secured public overflow player, real-time kill switch |
| Native attendee apps | Multi-show native app: schedule, tickets, profile, on-site networking (badge-scan connect + chat) |
| Operations | One admin console for the entire program; structured audit trails; observability (OpenTelemetry) |
3. AI-ready by architecture (the headline)¶
The same properties that make the platform composable make it the natural surface for AI:
- An AI agent is just another OAuth2 client. It registers on the IdP, holds scoped tokens, and operates under the same server-enforced tenancy as every app we ship. Governance is built in — not a policy document, an access model.
- Machine-readable contracts everywhere. Services publish OpenAPI schemas; the event model, forms, and configuration are data an agent can read and write — signage designs are open HTML templates in a manifest, sponsor order forms are server-defined records, CFP wizards render whatever the selection plan defines.
- A real event stream. Domain events flow over the platform's message backbone (schedule changes, purchases, permission changes) — push-based integration the services themselves use.
- Per-show behavior is configuration, not code — branding, labels, feature flags, pricing windows, form definitions all live in config services, changeable per event without deploys.
4. Enterprise foundation¶
The API and identity backbone runs on managed Kubernetes (DigitalOcean DOKS) with:
- Cloudflare edge — global DNS, WAF, and TLS at the front door.
- GitOps delivery (ArgoCD) — every deployment declarative and version-controlled, with a full audit trail and rollback.
- Horizontal autoscaling + multi-replica services and pod-disruption budgets.
- High-availability managed database with point-in-time recovery and encrypted off-cluster backups.
- Container security scanning in CI (image linting, CVE scanning, CIS benchmarks).
Payments ride Stripe (hosted fields — card data never touches our servers); email rides a dedicated mailing service; real-time rides the platform's pub/sub layer with a configurable fallback; files ride S3 with pre-signed URLs and Dropbox for on-site sync.
Positioning notes — accuracy guardrails (internal)¶
- Don't quote a big service/repo count. The honest architecture story is small core + focused clients — the repo total (~48, and it includes widgets, themes, email templates, and infra configs) is neither "services" nor all open-source. "Open-source rooted with commercial extensions" is the vault-sanctioned phrasing.
- Kubernetes is the API/identity backbone — a hybrid migration; several services and most front-end hosting are not in-cluster. Same rule as the sibling briefs.
- AI = "another OAuth2 client" / "the hooks exist." No shipped AI product features. The claims are about the access model and machine-readable surface, both real.
- FileStage integration was specced but never implemented — do not cite it. Mux appears only in the streaming/overflow path (signed playback tokens) — cite it only in that context.
- Real-time: say "pub/sub with a configurable fallback"; name vendors only where load-bearing.
- No client/event names in external material.