Terminology

Key terms used throughout the PSI project and its architecture documentation.

Project Terms

Sprint: Scrum sprints at ZDFD are two-week development cycles.
Prototype: Small applications built to evaluate technical and UX assumptions. Prototype code is typically not carried forward into the product.
Appliance: One instance of the PSI system configured for a specific consumer/broadcaster.

Architecture Terms

Structure: A type of interactive content in PSI. For example: Question, Profile, Article, Topic. Structures define screens and config slots that features can extend. See design concepts.
Instance: A specific occurrence of a structure. For example, a particular question ("Are cats cute?") is an instance of the Question structure. Some structures are singletons (e.g., Admin Dashboard).
Feature: A modular plugin that extends a structure with additional functionality. Features provide widgets, callbacks, and data via config slots. Example: the Comment Slider feature adds a swipeable comment UI to the Question structure.
Config Slot: An extension point defined by a structure (or parent feature) that features can fill. Slot types include widgets (UI components), callbacks (event handlers), and data (labels, settings, rankers).
Module: An umbrella term for any structure, feature, or server module. Code in a module is isolated so that errors only affect instances the module is enabled on.
Silo: A data partition in PSI, typically one per partner (e.g., zdf, cbc, rc, srg, global). Each silo has its own configuration, language, feature defaults, and user data.
Open Module: A module contributed and maintained by a partner (e.g., ZDF's moderation dashboard, SRG's translation feature). Open modules live in open-modules/{partner}/ directories.
Core Module: A module maintained by the PSI core team. Core modules go through design, product, and engineering review. They may be enabled by default.
Datastore: The client-side data access layer that enforces instance isolation. Provides React hooks like useCollection, useObject, and useModuleData.
ServerStore: The server-side data access layer. Scoped to a specific instance and user per API request. Batches writes until the API function completes.
Adapter: An interface abstraction that allows swapping implementations. PSI uses adapters for authentication (Firebase Auth, better-auth), database (Firebase RTDB, MongoDB), email (Postmark, SendGrid, SMTP), LLM (OpenAI, Azure OpenAI, Perspective API), and translation (LLM, DeepL, TextShuttle, SRG SSR).

Infrastructure Terms

Firebase Realtime Database (RTDB): The primary data store for PSI. A NoSQL JSON database with real-time synchronization to connected clients.
Firebase Cloud Functions: Serverless compute platform where the PSI backend runs in production. Automatically scales based on API request volume.
Hono Standalone: An alternative deployment mode where the same PSI backend code runs as a standalone Hono server (via @hono/node-server) in a Docker container, without Firebase Cloud Functions. Previously used Express; migrated to Hono for improved performance and unified API.
Content Proxy (Demo Proxy): A reverse proxy that rewrites a broadcaster's web page to inject the psi.js script, enabling PSI sidebar and teaser functionality without modifying the broadcaster's actual site.
Structurizr: A tool for creating software architecture diagrams using the C4 model. The PSI architecture is defined in Structurizr DSL (in diagrams/system_context/workspace.dsl) and can be viewed interactively via Structurizr Lite or on-premises. The MkDocs documentation site uses hand-authored Mermaid diagrams that mirror the Structurizr model.