Skip to content

liveops-broadcast.boundary-model.md

Latest commit

 

History

History
86 lines (62 loc) · 4.06 KB

liveops-broadcast.boundary-model.md

File metadata and controls

86 lines (62 loc) · 4.06 KB
Raw

Live Event Moderation And Retention Boundary Model

Purpose

This document closes public issue #3: Document moderation, recording retention, and attendance evidence for internal live operations.

It provides concrete agentic-enterprise evidence for LiveOps Broadcast. The repo remains independent: it is not an AAIF project, not a Linux Foundation project, and not endorsed by either organization.

High-Risk Action Boundary

Internal livestream scheduling, audience access, moderated chat, AI-generated event summaries, recording publication, attendance reporting, archive retention, and replay export.

Actors

Actor Responsibility
Event owner Owns audience, schedule, retention, recording policy, and publication intent.
Moderator Reviews chat, questions, abusive content, and escalation decisions.
AI moderation assistant Proposes moderation actions, summaries, and attendance insights.
Streaming provider adapter Handles stream, recording, chat, and archive operations under approved scopes.
Maintainer Reviews moderation, retention, provider fallback, and audit evidence.

Identity Boundary

  • Event ownership, viewer identity, moderator authority, and AI assistant capability must be separate.
  • The AI moderation assistant cannot ban users, publish recordings, widen audience, or change retention.
  • Every recording and chat archive must preserve event owner, audience scope, provider, retention class, and review state.
  • Stream keys, attendee lists, chat content, and private recordings must never be exposed in public examples.

Tool And Action Boundary

Action Boundary
schedule_event Requires event owner, audience scope, recording policy, and retention class.
moderate_chat AI recommendations stay draft until moderator action or policy rule applies.
generate_recap Draft until event owner or moderator reviews sensitive content.
publish_recording Requires owner approval, audience recheck, and retention policy.
export_attendance Requires purpose, authorized requester, and reporting audit event.

Human Approval Gates

  • Before publishing recordings, transcripts, recaps, or attendance reports.
  • Before widening audience after an event is scheduled.
  • Before applying high-impact moderation actions such as bans or escalations.
  • Before changing archive retention, legal hold, or deletion rules.
  • Before changing streaming, chat, archive, or analytics providers.

Audit Event Model

Event Minimum Evidence
event.scheduled event id, owner, audience, recording policy, retention
chat.moderation_recommended message id, rule, assistant reason, reviewer state
chat.moderation_applied moderator, action, reason, affected user
recording.published recording id, approver, audience, retention class
attendance.exported event id, requester, purpose, destination, approver

Local Proof Path

  • npm install to prove dependency resolution.
  • npm run lint to prove static project health.
  • npm run test for event, moderation, attendance, and audit fixtures when available.
  • npm run build to prove the application compiles.
  • Use synthetic events, synthetic attendance lists, and redacted chat fixtures in public proof.

OSS And Self-Hosted Fallbacks

  • Use local or self-hosted streaming/chat adapters for contributor proof where feasible.
  • Use S3-compatible storage such as MinIO for local recording archives.
  • Store moderation, attendance, and publication audit records in PostgreSQL or SQLite fixtures.
  • Keep hosted streaming, chat, recording, and analytics providers behind explicit adapters.

Contributor Follow-Up

Add a small event fixture that maps audience scope, chat moderation recommendation, recording approval, retention class, and attendance export.

Issue Closure Evidence

This document satisfies the issue checklist by separating:

  • identity or actor boundary
  • tool/provider/action boundary
  • human approval or escalation point
  • audit or observability events
  • OSS/self-hosted fallback direction
  • validation and static inspection path