#VM18 and digital signage requirements gate

#Current status

Parked and blocked on product clarification. “VM18” has no authoritative definition in the repository. ADR 0009 prohibits implementation until the decision owner completes this record, and the item must be explicitly restored to the roadmap after that definition is approved.

#1. Define VM18

Select exactly one meaning and attach the authoritative product source:

• age rating / content restricted to adults;
• hardware or device model;
• screen/display format or venue classification;
• another business term, stated unambiguously.

Record who owns the definition, who approves changes, and whether it applies to content, viewers, devices, venues, schedules, or all of them.

If it means age-restricted content, obtain written product/legal direction for:

• target audience and jurisdictions;
• content classification and reviewer responsibility;
• required signage/disclosures;
• whether unattended public display is permitted;
• whether acknowledgement, staff control, verified identity or another gate is legally/product-required;
• audit retention, privacy and deletion obligations;
• fallback behavior when verification or connectivity fails.

Do not store identity documents, biometric data or age-verification evidence in k0smos without a separate approved threat model, lawful-basis/retention design, and specialist provider assessment.

#2. Target deployment

Complete one row per device class or venue:

#3. Content and publication ownership

For every content type record:

• source owner: Page, Widget, Media, Menu, another active module, or external;
• editor, reviewer and publisher roles/permissions;
• draft/approved/published/expired states and rollback expectations;
• locales, fallback rules and accessibility metadata;
• schedule/priority/conflict semantics;
• offline eligibility, maximum staleness and emergency override behavior;
• whether content may contain personal, confidential, licensed, age-restricted or third-party material;
• retention and proof-of-publication requirements.

No active module may push arbitrary HTML or URLs into signage. A future provider contract must contribute approved typed content references; Signage would own layout, publication and device delivery.

#4. Privacy, analytics and security decisions

Answer before architecture approval:

• Are impressions, interactions, device health or audience analytics required?
• Is any identifier tied to a person, session, device or venue?
• What consent, lawful basis, aggregation, retention and deletion apply?
• Can the display load third-party network resources or only packaged assets?
• How are devices enrolled, authenticated, rotated, revoked and wiped?
• What must render after signature failure, clock skew, offline expiry or suspected compromise?
• Which operator receives alerts and how quickly must recovery occur?

Assume a physically reachable kiosk is hostile. Never put tenant admin credentials, API tokens, unpublished content or business authorization logic in the browser bundle. Browser-delivered code and cached manifests are observable.

#5. Approval record

Implementation planning starts only when all fields below are filled:

The approved record must name the smallest pilot: device class, venue, content owners, number of screens, online/offline mode and measurable acceptance. Only then create a threat model and implementation plan. Approval does not automatically authorize analytics, age verification, camera/sensor use, remote device control, or a graph database.