Skip to content

Digital Signage — Capability & AI-Readiness Brief

A capability overview of the Foxtrot November digital-signage offering, written for sales, solutions, and leadership use (e.g. RFP responses and AI-forward event pitches). Grounded in the shipped openstacksignage, Show Admin, and platform code. Client/event names intentionally omitted — swap in the audience's own examples when pitching.

Companion: Streaming, Virtual & Overflow · Repository Reference.

In one line

An AI-ready, browser-based digital signage system built on a Kubernetes-backed, API-first event platform: every on-screen design is a standalone web template, every screen is driven live over a real-time channel, and the whole surface is enumerable and swappable in data — exactly the shape an AI design pipeline plugs into.

1. What it is

Digital signage on this platform is a thin, resilient browser client driving any display — lobby billboards, session/room boards, wayfinding, registration screens, sponsor loops.

  • A screen is just a URL. Point any display's browser at …/<design>#/?summit=<event>&location=<screen>. Those two IDs — the event and the physical location — are the screen's entire identity. No dedicated hardware, no proprietary player: any device with a modern browser (kiosk, media player, smart display, tablet) becomes a managed sign.
  • Each design is a real web page. Signage designs are standalone HTML/CSS/JS templates rendered full-screen. Because a design is just the web, anything expressible on the web — motion, video, live data, brand typography, animation — is expressible as signage.
  • It's live, not static. Screens subscribe to a real-time channel and update themselves: schedule changes flow in automatically, and operators can push commands to any screen instantly.

2. AI-ready by architecture (the headline)

The platform was built so that a signage design is a first-class, data-described, swappable artifact — which is precisely the interface an AI generation system needs. Three shipped properties make this real:

  1. Designs are arbitrary HTML templates. Each is a complete, self-contained web document with its own layout, styling, fonts, and canvas. There is no restrictive "template language" to fight — the output format is the open web. Anything an AI can produce as HTML/CSS becomes a deployable signage design with no format conversion.
  2. The design catalog is machine-readable. At build time the platform automatically discovers every available design and emits a structured manifest (design name → file, organized per event and per tenant). The set of designs a screen can show is data an automated system can read and write against, not tribal knowledge buried in a UI.
  3. Rendering is command- and data-driven at runtime. A single real-time command swaps the design showing on a live screen; a separate real-time feed streams schedule/data changes into it. The render surface is addressable programmatically — you can generate a design and put it on the wall through the same interfaces an operator uses.

Why this matters for an AI-forward event: "brand deck → on-screen signage" is a short path here. Generate a template from a source asset (a slide, a PDF, a prompt, a brand kit), drop it into the per-event design folder, and it's immediately catalogued and assignable to any screen. We have already produced large-format lobby / billboard designs generated directly from a slide deck as a proof of concept — the architecture, not a one-off hack, is what makes that repeatable.

3. Real-time operations at scale

Signage is centrally operated and reacts in real time.

  • One operator console drives every screen. From Show Admin, an operator selects a location, assigns a design to it, and can swap the design, reload the screen, or jump the clock to any time — each action takes effect on the live screen instantly. Design assignments are both persisted (durable, survive reloads) and pushed live.
  • Schedules sync themselves — no polling, no manual refresh. When a session moves, is added, or ends, the change propagates from the platform API through the real-time layer to every affected screen, which applies the update in place without reloading the page. A room's board is always current.
  • Built to scale across a venue. Each screen listens on its own dedicated real-time channel keyed to (event, location), so the model scales cleanly from a handful of displays to a venue full of them — every screen independently addressable, all coordinated from one console.
  • Real-time backbone: the platform's pub/sub messaging layer (with a configurable fallback) carries both the operator commands and the schedule-change feed — the same proven real-time infrastructure behind the platform's live event experiences.

4. Any canvas — any resolution, any orientation

Because every design is bespoke HTML sized to its target, the system renders any resolution and any orientation — a 4K landscape lobby billboard, a 9:16 portrait wayfinding pillar, a widescreen session board — each pixel-perfect for the screen it runs on. Portrait and landscape are first-class (dedicated designs per form factor), and fluid full-viewport layouts are supported where a design should stretch to fit. For an AI pipeline this is a feature: generate the design at the exact dimensions of the wall it's going on.

5. Resilience & enterprise-grade foundation

The sign itself is deliberately simple and hard to break. It's a browser client with a local clock: once a screen has loaded its schedule, it keeps advancing and displaying the correct current/next content on its own, through network interruptions — a dropped connection doesn't blank the wall. When connectivity returns, live updates resume automatically; pushed state (e.g. overflow/redirect URLs) persists across reloads. No single point of on-site failure takes the room's board down.

Behind the sign is an enterprise platform. 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 is declarative and version-controlled; designs and configuration ship as code with a full audit trail and rollback.
  • Horizontal autoscaling + multi-replica services and pod-disruption budgets — capacity scales with load; no single pod is a bottleneck.
  • 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) on every change.

The result: a signage experience that is lightweight and bulletproof at the edge, backed by a platform engineered for reliability and scale at complex, multi-track conferences.

6. Multi-tenant and per-event by design

  • Per-tenant, per-event design libraries. Designs are organized so every event (and every brand/tenant) has its own set — one platform serves many events without cross-contamination.
  • Runtime configuration without redeploys. A platform-wide config service drives per-event branding, display settings, labels, colors, and feature flags as data — so look-and-feel and behavior can change per show without code changes.
  • API-first, composable. Signage consumes the same public event API (schedule, sessions, rooms, locations, banners) that powers the rest of the platform — an "event operating system" whose real-world touchpoints (badging, signage, streaming) are all first-class.

7. Why it fits an AI-forward event

An AI-forward audience wants signage that is itself AI-forward. This platform's signage is:

  • Generation-ready — designs are open web templates, catalogued in data, swappable by command: the exact interface an AI design generator targets.
  • Real-time and operationally effortless — one console, live push to every screen, self-syncing schedules.
  • Any-canvas — every resolution and orientation, rendered exactly.
  • Resilient at the edge, enterprise-grade at the core — Kubernetes-backed platform, browser-simple signs that survive network blips.

The pitch in a sentence: bring us your brand assets, and AI + this platform turn them into live, venue-scale signage — on any screen, updating itself in real time, on infrastructure built to not go down.

Positioning notes — accuracy guardrails (internal)

Keep these straight so we don't overclaim in an RFP or on a call:

  • AI generation is not a shipped product feature. The platform provides the hooks — open HTML templates, a machine-readable design manifest, and runtime command/data-driven rendering. The lobby-billboard-from-a-deck example was a demonstrated build, not a productized flow. Say "AI-ready / the hooks exist," not "AI generates signage automatically today."
  • "Offline" = graceful degradation, not a full offline-first PWA. A screen keeps displaying already-loaded content through a network drop and persists pushed state across reloads, but it cannot cold-boot with no network. "Resilient to network interruptions" is the safe phrasing.
  • Kubernetes is the API/identity backbone (a hybrid migration — not literally every service yet). The signage screen's own static hosting/CDN is servable from any edge and is not claimed to run in the cluster. Frame K8s as the platform backbone, not the sign runtime.
  • Adding a design is a code/build/GitOps step — managed as code, deployed via ArgoCD. Frame it as version-controlled and auditable, not "instant no-deploy design uploads in the admin."
  • Real-time carries the primary pub/sub layer with a configurable fallback; describe as "pub/sub with fallback" rather than a specific vendor unless useful.
  • No client/event names — the codebase's real template names encode past events/sponsors; keep all of them out of external material.