Nautilus SPMS — Requirements & Features Specification

Field	Value
Document	Nautilus SPMS Requirements & Features (v0.16 — draft)
Sources	`NT_Connect_Cruise_SPMS_Platform_Analysis_1.docx` (April 2026); ntmaritime.com product line (GuestApp, CrewApp, Hospitality, Health, Starlink); ntconnect.com Cloud PBX + TALK + PBX App + SIP trunking + E911 Enterprise + impact studies (Cunard Queen Anne, Disney Cruise Line, Princess Lodges/Westmark, NOAA Ship Bell M. Shimada, Wyoming Air National Guard, CSG-4); CallCraft platform (`callcraft.ntlk.co`); deployed Heimdall platform (`heimdall.nooz.ai`) — © 2026 NT Connect Holdings
License	AGPL-3.0 with optional commercial license (see Section 15)
Status	Pre-implementation
Owner	NT Connect Holdings — Quanta Platform Initiative
Last updated	2026-04-18

This document formalizes the requirements and feature set implied by the April 2026 Cruise SPMS Platform Analysis, augmented with the live NT Maritime product line and the deployed Heimdall analytics platform. It is the working requirements baseline for Nautilus; the source analysis remains authoritative on scope. When a requirement here and the analysis document disagree, resolve the conflict and update whichever is wrong.

v0.16 changes (2026-04-20):

OQ-22 resolved (subject to legal sign-off): bus + agent contract → Apache 2.0; Signal-Protocol library → AGPL-3.0-with-linking-exception (libsignal pattern); PSI module → Apache 2.0.

OQ-23 resolved (framework): vendor shortlist Least Authority + Trail of Bits paired primary, NCC Group fallback. Three-phase scope (PSI → Signal-Protocol → multi-tenant + JWT). Realistic total $250–400k (earlier $100–300k estimate was low). ~8–9 months from quote to all audits complete.

§14 Tier-A descriptions updated with specific per-artifact licenses.

New §15.7 Pre-publish specialist audit commitment — codifies the audit scope, budget, partners, and the practice of publishing audit reports alongside releases.

CLAUDE.md licensing section updated to reference Tier-A per-artifact licenses + audit commitment.

v0.15 changes (2026-04-20):

OQ-18 resolved: commercial smart displays (Samsung Tizen / LG webOS) primary; NUC + commercial display for interactive kiosks; BrightSign HTML5-URL mode for retrofits. Roku / RPi / Android-box rejected.

Domain 15.C platform foundation: the existing NT Connect signsync codebase (~/src2/signsync) is extended as the Nautilus signage CMS + device-health platform. CMS core retained; Roku-only coupling, single-tenancy, synchronous pull, Firebase Auth, and zero-test posture rewritten.

10 new features F-D15-81..90 itemizing the signsync extension (player-agnostic device contract, multi-tenant isolation, Zitadel OIDC migration, NATS listener layer, emergency-override priority playlist, Quanta AI slot prioritization, per-zone targeting, offline-first onboard, multi-language rotation, tests + CI + observability).

New §6.16 — Signage platform (NFR-180..186): codifies the signsync extension commitments.

CLAUDE.md NT Connect product list — signsync added as a sibling product being extended for Nautilus.

v0.14 changes (2026-04-20):

OQ-17 resolved: unicast HLS/DASH with per-vessel origin cache as default. Multicast / multicast-ABR remain optional transport-layer optimizations for bandwidth-constrained vessels — not architecturally incompatible with PWA or BYOD (multicast-to-unicast gateways solve both; earlier v0.14 draft language overstated this).

F-D15-22 updated — HLS primary, DASH secondary, per-vessel origin cache, EME DRM.

New §6.15 — Media delivery (NFR-170..178): HLS/DASH primary, per-vessel Nginx+Varnish cache, Shaka Packager pipeline, EME DRM, LL-HLS ~2 s target, 10 Gbps recommended backbone (1 Gbps with optimization layer), multicast-ABR as opt-in optimization, content-provider compatibility requirement, smart-TV renderer path.

v0.13 changes (2026-04-20):

OQ-21 resolved: Topology 4 — shore full Heimdall + onboard quantized SafeSpace tier on every vessel. INT8 DeBERTa on CPU / L4-class small GPU; CSAM + grooming + NSFW + toxicity + URL scan + profanity run onboard regardless of shore link. Narrative flow / influence / sentiment / summaries stay shore-side.

OQ-26 resolved: launch single-region shore; Phase 5+ per-region shore SafeSpace + single consolidation region for Enterprise / Studios with metadata-only cross-border flow.

FR-18 broadened: onboard CSAM detection (not just shore); per-jurisdiction reporting routing (NCMEC / IWF / BKA / eSafety Commissioner / INHOPE) not just NCMEC-only.

New §6.14 — Heimdall deployment topology (NFR-150..159): onboard module, conservative thresholds, signed weights, model-update bus subject, immutable audit trail, re-scoring on reconnect, Celery-to-NATS bridge, hardware floor (8 CPU / 16 GB or L4), regional topology for multi-tenant, per-jurisdiction reporting routing.

CLAUDE.md Domain 13 nudged to reference the Heimdall topology.

v0.12 changes (2026-04-20):

OQ-14 deferred, not resolved. CRS adapter spec is not authored until real CRS API documentation is in hand (Versonix Seaware developer docs or equivalent). Premature design risks baking in wrong assumptions. Phase 1 unblocked via a MockCRSAdapter (F-D2-01a) that generates representative booking / manifest / cabin-assignment events.

F-D2-01 updated to reference the CRSAdapter interface explicitly (authored in Phase 2, not Phase 1); new F-D2-01a ships the mock adapter in Phase 1.

OQ-24 updated to note CRS is explicitly not on the Tier-C authoring queue until unblocked.

v0.11 changes (2026-04-20):

OQ-12 resolved: per-tenant single-region pin (Stance A) + data minimization with crypto-erasure + jurisdiction-aware retention (Stance C), layered. GDPR-grade controls as the global default regardless of tenant region. Multi-region per-tenant deferred to Phase 5+.

New NFR group 6.13 — Privacy, data residency & DSR (NFR-140..149). Region pinning, GDPR-grade baseline, crypto-erasure, per-category retention, cross-border transfer mechanisms (SCCs + adequacy), DPIA at tenant onboarding, DSR API semantics, special-category consent, maritime legal layer as operational pack, no-secondary-use-without-consent.

F-D1-09 expanded into a concrete DSR API surface (access / rectify / erase / port / restrict / object) with audit trails and jurisdictional SLAs.

New OQ-26: Heimdall region strategy (per-region / single-region + SCCs / hybrid); blocks Phase 4.

CLAUDE.md Architecture Pillar 10 added — Privacy by design, GDPR-grade everywhere.

v0.10 changes (2026-04-20):

OQ-10 resolved: vendor-agnostic PaymentProcessor adapter in Domain 3. Ship with Stripe reference adapter (Phase 2 velocity, Apache-2.0 SDK, Connect for multi-tenant). Add Adyen adapter on-demand. Per-tenant sub-merchant model (Stripe Connect / Adyen for Platforms), not platform-as-merchant — keeps Nautilus out of money-transmission licensing.

NFR-21 tightened: no raw PAN / CVV / magstripe / PIN / chip track anywhere in Nautilus; domain code MUST route through the adapter, not vendor SDKs directly.

New Domain 3 features F-D3-11 (embark-auth), F-D3-12 (incremental auth), F-D3-13 (network tokens + account updater), F-D3-14 (chargeback evidence pack).

v0.9 changes (2026-04-20):

OQ-09 resolved: Kong Gateway OSS v3.7+ (Apache 2.0), shore and onboard. DB-less mode onboard; Zitadel OIDC via community plugin; Prometheus + OpenTelemetry plugins; declarative config via decK in GitOps. Kong fronts Heimdall (NFR-125). Cloud-native managed gateways rejected (don't run onboard).

New NFR section 6.12 — API gateway (Kong) (NFR-120..129).

New OQ-25: future evaluation of Cilium Gateway API as a Phase 4–5 consolidation option.

v0.8 changes (2026-04-20):

OQ-08 resolved: no separate service mesh in Phase 1–3. Cilium v1.16+ is the CNI and delivers the mesh's day-one value (WireGuard pod-to-pod encryption, identity-based policy via CiliumNetworkPolicy, eBPF kube-proxy replacement, Hubble flow observability) without sidecar overhead. App-layer observability via OpenTelemetry SDKs (mandatory). Linux kernel 5.15+ required on K3s nodes.

New NFR group 6.11 — Networking, CNI & in-cluster observability (NFR-100..109).

NFR-20 rewritten to reflect Cilium + NATS + Kong + cert-manager architecture instead of presupposing Linkerd/Istio.

Tech-stack row in CLAUDE.md updated from "Service mesh" to "CNI + encryption + policy + observability" (Cilium).

v0.7 changes (2026-04-20):

OQ-07 resolved: Postgres-only (CNPG v17.2 + JSONB), inheriting the r360-infrastructure pattern. No document store in the Nautilus AGPL tree.

New NFR group 6.9 — Data storage & replication topology (NFR-80..88). Tiered replica counts (shore 3-instance sync quorum; onboard safety/revenue-critical 2-instance sync-preferred; onboard operational 1-instance; optional shared onboard cluster with per-service databases). Ship↔shore sync via NATS events, not Postgres streaming. PgBouncer + postgres_exporter mandatory.

New NFR group 6.10 — Secrets management & supply-chain hygiene (NFR-90..94). No secrets in git; Vault + External Secrets Operator; per-tenant overlays in private repos; CI secret-scanning; dependency license audit.

Tech-stack table in CLAUDE.md updated to match.

v0.6 changes (2026-04-20):

New Section 14 — Integration Architecture. Three-tier model codified: Tier A open primitives (NATS + Quanta agent contract; Signal-Protocol crypto library; PSI module) to be open-sourced; Tier B closed services (Quanta application services; ConnectOne; CallCraft; Heimdall) stay commercial; Tier C documented interfaces let third parties integrate legacy systems (ship PBXs, iTV head-ends, signage) without replacing them. Retrofit-first posture matches the real cruise-fleet situation.

New OQs: OQ-22 Tier-A licensing, OQ-23 crypto-audit vendor, OQ-24 interface-spec authoring queue.

First Tier-C spec published: docs/integrations/ship-pbx.md (ship-PBX ↔ Nautilus bus integration).

v0.5 changes (2026-04-20):

Comms product naming clarified. The NT Connect comms platform is ConnectOne (working name — subject to change). ConnectOne is the umbrella: Cloud PBX (Domain 14.E) + maritime specialization (Domain 14.F) + voice/video transport (signaling + media). CallCraft is the AI-voice surface inside ConnectOne — the piece that hosts AI agents, AI Notes, voice ordering, concierge intents, emergency AI-guided mustering. All previous doc references that conflated the two have been split.

Implementation details removed from the public spec. Named third-party media/signaling vendors have been dropped from the requirements doc. OpenSIPS and SIP B2BUA are documented as roadmap for ConnectOne's signaling layer; current-state vendors are treated as implementation detail, not specification.

OQ-01 resolved. Bus = NATS JetStream with Quanta's agent contract (see Section 13).

v0.4 changes (2026-04-18):

Domain 14 expanded with 14.E Cloud PBX Platform (full PBX feature set per NT Connect netTALK PBX — virtual receptionists, ring groups, call recording, advanced forwarding, E911, RoboAgent spam filter, hot-desking, TALK + PBX App, SIP trunking, NIST SP 800-171 compliance) and 14.F Maritime PBX Specialization (4,000+ extension hospitality scale, cabin-as-extension, fleet-wide federation, PA/GA tiers, accessibility handsets, wake-up + DND, folio-bound billing, parental childcare devices, legacy TDM/Avaya bridging via PRI handoff).

Section 15 — Licensing added: source released as AGPL-3.0 with optional commercial license for tenants needing closed distribution / proprietary derivatives.

Companion document docs/marketing-overview.md created from this spec.

v0.3 changes (2026-04-18):

Heimdall rescoped to the actual product surface at heimdall.nooz.ai: 900M-param DeBERTa-v3-large multi-task model with 56 manipulation-technique heads, 16 narrative-flow patterns, 8 stealth-propaganda analyzers, 12 content-safety plugins (toxicity, NSFW, CSAM via PhotoDNA + Thorn with NCMEC reporting, 4-analyzer grooming detection, video moderation, URL scanning), 4 audience tiers (COPPA / Teen / General / Relaxed), Signal-to-Noise score, 5-Pathway Influence score, "At a Glance" summarization (local Gemma 4). See FR-13, FR-17–FR-20, Domains 14/15, integrations, and OQ-02.

Relate-360 reference removed from architecture inspiration — public site (relate-360.com) is a consumer family app, not a CDP/CRM. See OQ-20.

v0.2 changes (2026-04-18):

Message bus is Quanta (not NATS JetStream); see FR-02 / FR-03 / FR-09 and Section 13. Conflicts with current CLAUDE.md Pillar 2 — see Open Question OQ-01.

Domain 14 broadened from CallCraft transport to Unified Crew & Guest Communications (voice, video, messaging, push-to-talk, voicemail, omnichannel federation) — modeled on NT Maritime GuestApp + CrewApp.

Domain 15 extends cabin iTV to first-class video-call endpoint (passenger-to-passenger, passenger-to-crew, telehealth video consults).

New Domain 16 — Telehealth & Location Intelligence (BLE location services, contact tracing, occupancy heatmaps, telemedicine), modeled on NT Maritime Health.

1. Purpose & Scope

1.1 Purpose

Define, at a level sufficient for implementation planning, the functional and non-functional requirements of Nautilus, NT Connect Holdings' next-generation Shipboard Property Management System (SPMS).

1.2 In scope

Shipboard property management across 15 bounded domains (Section 5).
Shore-side administration, fleet management, and HQ intelligence.
Guest-facing digital touchpoints (mobile, iTV, kiosk, signage).
AI-native capabilities via Quanta; voice-native capabilities via ConnectOne (with CallCraft providing the AI-voice surface inside it).
Multi-tenant, white-label operation for multiple cruise operators.

1.3 Out of scope (for v1)

Full replacement of Central Reservation Systems (CRS) — Nautilus integrates with Versonix Seaware / Infor / equivalent, does not replace them.
GDS origination (distribution) — integration only.
Shipboard navigation/bridge systems — Nautilus consumes GPS/marine data but does not control navigation.
Casino game engines — Nautilus interfaces with casino cash management only.

1.4 Competitive context

Nautilus is benchmarked against Oracle Hospitality Cruise (SPMS), MXP / MarineXchange, and Otalio. Feature parity minimums and differentiators are called out per domain.

2. Stakeholders & Primary Personas

Persona	Context	Primary touchpoints
Guest (pre-cruise)	Booked, not yet embarked	Mobile app, web portal
Guest (onboard)	Embarked passenger	Mobile app, cabin iTV, kiosk, board card, cabin phone (ConnectOne, with CallCraft AI-voice)
Guest (post-cruise)	Disembarked, loyalty lifecycle	Email, mobile app, loyalty portal
Crew (hotel / F&B / service)	Service delivery onboard	Waiter tablet, POS, crew app, mobile muster
Crew (gangway / security)	Access control, manning	Gangway tablet/reader, Heimdall dashboards
Officer (safety)	Muster, drills, compliance	Safety dashboard, mobile muster, STCW tracking
Officer (hotel director / F&B mgr)	Operational oversight onboard	Fleet/vessel dashboards, POS admin
Purser / finance	Onboard accounts, settlement	Folio mgmt, cashbook, payment gateway
HR / payroll	Crew lifecycle	Crew, HR & Payroll service
Shoreside ops / HQ	Fleet oversight, config push	Fleet Management & HQ Intelligence
Shoreside revenue / marketing	Recommendations, campaigns	Quanta AI surface + analytics
Port authority / regulator	SOLAS / ENOAD / EU-LISA	Automated compliance feeds
Tenant (cruise operator)	White-label brand	Tenant admin console
Platform operator (NT Connect)	Runs the platform	Observability, tenant mgmt, CI/CD

3. Requirement & Feature Identifiers

FR-XX: Functional requirement (system-wide).
NFR-XX: Non-functional requirement.
F-D{n}-XX: Feature belonging to Domain n (1–15, per Section 5).
Priority (MoSCoW): M = Must, S = Should, C = Could, W = Won't (v1).
Phase: 1–6 per the analysis doc phasing.

4. System-Wide Functional Requirements

ID	Requirement	Priority	Phase
FR-01	The system SHALL be composed of independently deployable microservices aligned to the 15 bounded domains in Section 5; no cross-domain database sharing.	M	1
FR-02	All inter-domain communication SHALL be event-first via the Quanta message bus; synchronous REST/gRPC is permitted only for read-side queries and external integrations. Domain services MUST NOT embed alternative brokers.	M	1
FR-03	Ship↔shore synchronization SHALL ride on the Quanta bus with guaranteed delivery, ordered per-stream semantics, and automatic replay on reconnect; no batch-based sync.	M	1
FR-04	Every onboard domain SHALL function autonomously when shore connectivity is degraded or lost; local state SHALL reconcile on reconnect without manual intervention. The onboard Quanta node SHALL buffer and forward on reconnect.	M	1
FR-05	The system SHALL maintain a single universal guest identity record referenced by all domains; modules MUST NOT persist parallel guest profiles. The identity SHALL include an `omni.username` channel address for unified messaging across SIP, SMS, Viber, Telegram, iMessage.	M	1
FR-06	Authentication and authorization SHALL be centralized in Zitadel (OIDC/OAuth2) for both human and service identities; SSO across all modules.	M	1
FR-07	The system SHALL be multi-tenant from v1, supporting brand isolation (data, config, theming) per cruise operator.	M	1
FR-08	All guest-facing frontends (POS, kiosk, iTV, mobile web) SHALL run from a shared React PWA codebase; native mobile is React Native from a shared codebase. iTV SHALL render the same PWA in cabin-TV form factor.	M	2–3
FR-09	Every domain SHALL publish domain events to the Quanta bus in a schema Quanta itself can subscribe to and reason over without per-domain custom integration; "every event observable to AI by construction" is a design invariant.	M	1
FR-10	Voice and video transport — cabin telephony, AI-voice agent, crew PTT, passenger video calls, telehealth consults — SHALL be provided by ConnectOne (NT Connect's Cloud PBX + signaling + media platform; SIP on the signaling side with B2BUA / OpenSIPS on the roadmap, WebRTC for media). SPMS domains MUST NOT embed separate SIP / WebRTC stacks. AI-voice intents (voice ordering, concierge, AI Notes, AI-guided muster) are delivered by CallCraft, the AI-voice surface inside ConnectOne, which joins ConnectOne calls/rooms as a first-class agent participant via the Quanta bus.	M	2
FR-11	The system SHALL provide full audit trails for all financial postings, access control events, guest profile mutations, and crew/guest communications metadata.	M	2
FR-12	Configuration (menus, pricing, packages, housekeeping rotas) SHALL be managed shore-side and propagated to the fleet via the Quanta bus, not manual per-vessel entry.	M	2–3
FR-13	All guest and crew message traffic (in-app chat, omnichannel, voicemail transcripts, AI Notes call summaries, photos, attachments, URLs) SHALL be screened and scored by Heimdall. Integration pattern: a Heimdall-client agent subscribes to the relevant Quanta bus subjects, invokes Heimdall's REST API per message (dynamic batching where latency allows, per Heimdall's 32-request / 100 ms batch window), and republishes the verdict (scores + detected categories) as a message extra on the bus. Heimdall itself is a synchronous HTTP service, not a bus subscriber, and SHALL be fronted by an API gateway (Kong / Envoy) enforcing authentication, mTLS, and per-tenant rate limits — Heimdall's own HTTP surface has no built-in auth.	M	4
FR-14	The platform SHALL provide an omnichannel guest messaging gateway federating SMS, Viber, Telegram, iMessage, and in-app chat into a single conversation thread keyed to guest identity.	M	3
FR-15	The platform SHALL support BLE/Bluetooth-LE wearable + gateway location services for opt-in passenger and crew location, contact tracing, and anonymized occupancy heatmaps.	S	4
FR-16	The platform SHALL provide telehealth video consultations between guest cabin (mobile, iTV, or in-cabin device) and the onboard medical team or shoreside clinician, integrated with the Safety & Muster medical record.	S	4
FR-17	The platform SHALL classify all addressable user surfaces (kids profiles, family cabin TV defaults, teen-zone signage, general venues, adult-only areas) under one of Heimdall's four audience tiers — COPPA / Teen / General / Relaxed — and apply the matching SafeSpace policy to all content rendered, posted, or transmitted on that surface.	M	4
FR-18	Image and video content uploaded by guests or crew (chat attachments, video calls, photo-sharing, video voicemails) SHALL be screened by Heimdall's CSAM stack (SHA-256 hashing + PhotoDNA + Thorn Safer), running on the onboard quantized Heimdall module (OQ-21 / NFR-150) so detection is not deferred by shore-connectivity loss. Platform SHALL execute the configured CSAM response — at minimum block + immutable audit trail. Per-jurisdiction reporting wired by tenant home region: US → automated NCMEC report per 18 USC 2258A; UK → Internet Watch Foundation (IWF); Germany → BKA; Australia → eSafety Commissioner; EU — per-member-state INHOPE hotline. Reporting pipeline is configured per tenant at provisioning and verified before go-live.	M	4
FR-19	Guest↔guest, crew↔guest, and guest↔crew messaging SHALL be screened by Heimdall's grooming-detection plugin (4-analyzer pipeline); detections SHALL escalate to a designated safeguarding role (purser / security officer) with full conversation context.	M	4
FR-20	Guest sentiment, complaint patterns, NPS-style signals, and social/online-review streams SHALL be analyzed by Heimdall (Enterprise tier — sentiment, narrative-flow, signal-to-noise, 5-pathway influence score) and surfaced to hotel-director, F&B-manager, and shore-side fleet dashboards in near-real-time.	S	4

5. Domain Features (Functional)

Domain 1 — Identity & Guest Profile

Per OQ-20 (resolved 2026-04-18), the data model is designed from scratch (cruise-specific requirements don't fit any off-the-shelf CDP cleanly), but borrows four pillars from Relate-360: Connection Mapping, Relationship Discovery, Story Sharing, and Authentic Identity / no-noise (closed network, no bots, no algorithmic feed in the social surface, no third-party advertising in identity-bound spaces).

1.A — Core identity & profile

ID	Feature	Priority	Phase
F-D1-01	Universal guest identity record (single source of truth across all domains).	M	1
F-D1-02	Passport / MRZ scan + OCR; biometric photo capture; document verification.	M	1
F-D1-03	Loyalty membership (tier, points, enrollment portal per tenant brand).	M	1
F-D1-04	Preferences, dietary restrictions, accessibility, complaint history, amenity/package entitlement.	M	1
F-D1-05	Emergency contacts, travel companions, group / cabin-mate linkage.	M	1
F-D1-06	Full CRUD APIs + event publication on every profile mutation.	M	1
F-D1-07	Visitor / day-pass records (distinct but linkable identity type).	S	2
F-D1-08	Multi-modal identity correlation (voice + text + behavior, via Quanta).	S	4
F-D1-09	Data subject request (DSR) APIs — first-class endpoints on Domain 1 for: access (export all data tied to an identity), rectify (correct), erase (delete or crypto-erase per §6.13), port (structured export to another controller), restrict (suspend processing), object (opt out of specific processing categories). Per-tenant SLAs (GDPR 30-day default). Audit trail of every DSR action. Retention policy service enforces per-category jurisdictional rules (passport / biometric / health / messaging / telemetry / marketing).	M	2

1.B — Relationship graph (Relate "Connection Mapping" / "Relationship Discovery")

ID	Feature	Priority	Phase
F-D1-20	First-class relationship graph: spouse/partner, parent/child, sibling, travel companion, group block member, cabin-mate, returning-with (same companions across past voyages). Edges typed and consent-tagged.	M	1
F-D1-21	Family-on-board view — every relationship of every guest currently aboard rolled up so crew / safety / muster see family units, not isolated cabins.	M	1
F-D1-22	Returning-guest "shared history" surface — when a returning guest checks in, surface (to consenting crew + the guest's own app) prior cruises, prior cabins, prior crew interactions, prior dining/spa/excursion patterns.	S	3
F-D1-23	Crew-side "shared history" — when a returning guest interacts with a crew member who served them previously, surface that history to the crew (consent-gated, two-way).	S	4
F-D1-24	Multi-vessel / multi-tenant identity stitching — same guest across vessels and (where opt-in) across tenant-brands within an alliance, without merging tenant-isolated data stores.	C	5
F-D1-25	Opt-in onboard social discovery — guests can mark themselves discoverable, find friends/family known to be aboard, accept/decline meet-up invites. Off by default, never opt-out.	S	4

ID	Feature	Priority	Phase
F-D1-30	Voyage journal — guest-curated, in-app, photo + note timeline of the cruise (port stops, dining moments, excursion highlights). Pre-populated by milestone events from the bus, editable/deletable by the guest.	S	4
F-D1-31	Memories surface — on returning guests' next pre-cruise flow and onboard welcome, surface their prior journals (with their consent) — "last time you sailed with us…".	C	5
F-D1-32	Selective post-cruise sharing — guest can export the journal, share with named contacts, or keep private. Never auto-published, never used for marketing without explicit opt-in.	M	4
F-D1-33	Group / family memories — shared photo albums for travel companions and groups (consent-driven), stored under group identity not individual.	C	5

1.D — Trust principles (Relate "Authentic Identity / no noise")

ID	Feature	Priority	Phase
F-D1-40	Verified-identity-only social surfaces — every guest profile visible to other guests is passport-backed and check-in-verified; no anonymous profiles, no bot accounts.	M	4
F-D1-41	No third-party advertising on identity-bound surfaces (profile, journal, social discovery, family graph). Tenant promotional content is allowed and clearly labeled; external programmatic ads are forbidden.	M	3
F-D1-42	No algorithmic feed in social surfaces — Quanta's recommendations live on commercial surfaces (Domain 13), not in the guest's view of friends/family/journal.	M	4
F-D1-43	Per-relationship privacy controls — guest can hide journal entries from named relationships (e.g., share with travel companions but not extended family).	S	4

Decision (OQ-20): Domain 1 is designed from scratch; Relate-360 inspiration lives in the four pillars above.

Domain 2 — Reservation & Check-in

ID	Feature	Priority	Phase
F-D2-01	Upstream CRS integration via a pluggable `CRSAdapter` interface — Versonix Seaware is the named first reference adapter, Infor / custom on-demand. Interface authored in Phase 2 once real CRS API docs are available (OQ-14).	M	2
F-D2-01a	`MockCRSAdapter` for Phase 1 — generates representative booking / manifest / cabin-assignment events so Domain 2, Domain 1, and downstream domains can be built, tested, and dry-run against a first vessel without a real CRS connection. Ships in `packages/crs-mock/`.	M	1
F-D2-02	Pre-cruise online check-in via web and mobile app.	M	1
F-D2-03	Pier/terminal offline check-in (passport, photo, card issuance) with deferred sync.	M	1
F-D2-04	Onboard check-in (crew-assisted and self-service) on mobile / tablet.	M	1
F-D2-05	Cabin assignment: availability, upgrades, special needs, group blocks, cabin moves.	M	1
F-D2-06	Board card issuance — RFID/NFC physical card and/or mobile NFC/QR provisioning.	M	1
F-D2-07	Immigration / health / customs / security questionnaire capture.	M	1
F-D2-08	CallCraft + Quanta capture of guest preferences during pre-cruise calls ("AI Notes").	S	4
F-D2-09	Hotel pre-cruise check-in (parity with MXP).	C	3

Domain 3 — Onboard Accounts & Billing

ID	Feature	Priority	Phase
F-D3-01	Real-time guest folio — all revenue centers post synchronously via events.	M	2
F-D3-02	Fully cashless ship — every transaction debits board card / guest account.	M	2
F-D3-03	Package plan management with real-time consumption posting.	M	2
F-D3-04	Onboard credit (promotional, loyalty, service-recovery).	M	2
F-D3-05	Multi-currency with live FX and per-currency cashbook.	M	2
F-D3-06	PCI-compliant payment processing via a vendor-agnostic `PaymentProcessor` adapter interface (Domain 3 library). Stripe adapter is the reference implementation (Phase 2); Adyen adapter ships when a tenant requires it. Domain code MUST NOT import vendor SDKs directly — only the abstraction. No raw PAN / CVV stored in SPMS under any circumstance.	M	2
F-D3-11	Embark-authorization flow: on check-in, authorize a pre-computed hold (default $X/day × voyage length, tenant-configurable); flow captures at end-of-cruise against actual folio balance; excess auth released automatically.	M	2
F-D3-12	Incremental authorizations when folio spend approaches hold ceiling — automated top-up without guest intervention; failure surfaces to purser before guest's next spend event.	M	2
F-D3-13	Network tokens + account updater (where processor supports) — reduces re-authorization failures on cards re-issued during the voyage.	S	2
F-D3-14	Chargeback evidence pack — Nautilus automatically assembles evidence (folio line-items, cabin location timeline from Domain 5, recording / transcript metadata from Domain 14.E, guest signature / tap log) into a downloadable bundle for the processor's dispute portal.	S	3
F-D3-07	Gift card issuance & redemption.	S	2
F-D3-08	End-of-cruise batch settlement and automated invoice generation.	M	2
F-D3-09	Group invoicing, company accounts, employee accounts.	S	3
F-D3-10	Predictive spend alerts and personalized package suggestions via Quanta.	S	4

Domain 4 — Point of Sale (POS)

ID	Feature	Priority	Phase
F-D4-01	Device-independent POS (browser PWA: terminal, tablet, phone, iTV, kiosk).	M	2
F-D4-02	Offline POS with local queue; automatic post on reconnect.	M	2
F-D4-03	Revenue center configuration (bars, restaurants, spa, boutique, casino, shorex desk).	M	2
F-D4-04	Menu management — multi-level categories; pricing rules by type/date/venue/currency.	M	2
F-D4-05	Allergen / dietary surfacing at point-of-order.	M	2
F-D4-06	Kitchen display system (KDS) integration with order routing.	M	2
F-D4-07	Guest-initiated ordering from cabin iTV, mobile app, poolside device.	M	3
F-D4-08	Self-service kiosk ordering for casual venues.	S	3
F-D4-09	EMV + contactless + QR payments; loyalty redemption at POS.	M	2
F-D4-10	CallCraft voice ordering — guest calls; Quanta takes the order; posts to POS.	S	4

Domain 5 — Gangway & Access Control

ID	Feature	Priority	Phase
F-D5-01	Real-time embark/disembark tracking (guests, crew, visitors).	M	2
F-D5-02	RFID/NFC/QR card reading at gangway stations on commodity Android tablets.	M	2
F-D5-03	Offline gangway mode — local queue; resync on reconnect.	M	2
F-D5-04	Tender boat handling (secondary gangway point management).	M	2
F-D5-05	Manning control — rule-based shore-leave approvals for crew.	M	2
F-D5-06	Live headcount dashboard (onboard vs ashore, by category).	M	2
F-D5-07	SOLAS compliance reporting and ENOAD submissions to port authorities.	M	2
F-D5-08	EU-LISA-compatible interface (immigration/border — MXP parity).	S	5
F-D5-09	Hands-free passive RFID at gangway points (Oracle parity).	C	3
F-D5-10	Heimdall anomaly detection on access patterns and card use.	S	4

Domain 6 — Safety & Muster

ID	Feature	Priority	Phase
F-D6-01	Muster list mgmt — station assignment, lifeboat assignment, safety roles.	M	2
F-D6-02	Mobile mustering — crew scans guest RFID/QR at stations.	M	2
F-D6-03	Real-time muster progress dashboard (% accounted per station).	M	2
F-D6-04	Fully offline muster (assumes network is down in an incident).	M	2
F-D6-05	Fire drill scheduling + barcode-scan crew attendance.	M	2
F-D6-06	Medical module — patient record access via card, medication inventory, incident logging.	S	3
F-D6-07	STCW crew certification tracking with expiry alerts.	M	5
F-D6-08	Port authority safety reporting automation.	M	6
F-D6-09	Quanta + CallCraft AI-guided emergency announcements and mustering instructions.	S	4

Domain 7 — Dining & Restaurant

ID	Feature	Priority	Phase
F-D7-01	Table reservations across all dining venues for full voyage.	M	3
F-D7-02	Floor-plan mgmt with visual drag-drop table assignment.	M	3
F-D7-03	Pre-cruise dining reservations from mobile/web.	M	3
F-D7-04	Recipe management — ingredients, allergens, preparation, portions.	M	3
F-D7-05	Menu scheduling with time/venue/cruise rules.	M	3
F-D7-06	Waiter-tablet integration — order, allergen alerts, service tracking.	M	3
F-D7-07	Cover forecasting from historical data (reduces food waste).	S	5
F-D7-08	Unified fine-dining, buffet, casual, and room-service management.	M	3
F-D7-09	Dietary restriction workflow from guest profile → kitchen.	M	3

Domain 8 — Shore Excursions & Activities

ID	Feature	Priority	Phase
F-D8-01	Tour catalog (port-of-call excursions, onboard activities, fitness classes).	M	3
F-D8-02	Inventory, oversell rules, waitlists.	M	3
F-D8-03	Pre-cruise booking (mobile, web, CRS-pushed).	M	3
F-D8-04	Onboard booking at desk + self-service kiosks.	M	3
F-D8-05	AI tour recommendations via Quanta (profile + real-time context).	S	4
F-D8-06	Ticket batch generation by cabin.	M	3
F-D8-07	Manifest generation (by tour, departure, or guide).	M	3
F-D8-08	Vendor management and quality feedback loop.	S	3
F-D8-09	Cancellation / refund / discount with automatic folio adjustment.	M	3
F-D8-10	CallCraft voice booking ("I want to do the snorkeling tour in Cozumel").	S	4

Domain 9 — Spa & Wellness

ID	Feature	Priority	Phase
F-D9-01	Resource-aware booking (room + therapist + equipment).	M	3
F-D9-02	Pre-cruise booking import from CRS.	M	3
F-D9-03	Wellness profile — treatment history, preferences, contraindications.	S	3
F-D9-04	Revenue tracking integrated with onboard accounts.	M	3
F-D9-05	Therapist scheduling and workload management.	M	3
F-D9-06	Automated guest reminders (app / SMS / cabin phone).	S	3

Domain 10 — Crew, HR & Payroll

ID	Feature	Priority	Phase
F-D10-01	Full crew lifecycle (recruit, onboard, schedule, payroll, offboard).	M	5
F-D10-02	Maritime payroll: multi-currency, allotments, deductions.	M	5
F-D10-03	Time & attendance with ILO working-hour monitoring + violation escalation.	M	5
F-D10-04	STCW and certification management with expiry alerts.	M	5
F-D10-05	Crew accommodation / berthing rules.	M	5
F-D10-06	Recruitment-agency portal integration.	S	5
F-D10-07	eLearning integration (safety, compliance training).	S	5
F-D10-08	Performance management & appraisals.	S	5
F-D10-09	Muster / emergency role assignments (ties to Domain 6).	M	2
F-D10-10	Crew mobile app (schedule, timesheet, requests, messages).	M	5

Domain 11 — Materials & Supply Chain

ID	Feature	Priority	Phase
F-D11-01	Ship inventory (F&B, retail, hotel, technical stores).	M	5
F-D11-02	Real-time consumption updates from POS postings.	M	5
F-D11-03	AI demand forecasting (Quanta) — port resupply, waste reduction.	S	5
F-D11-04	Reorder thresholds with auto PO generation.	M	5
F-D11-05	Vendor catalogs, approved supplier agreements.	M	5
F-D11-06	EOQ and min/max stock calculations.	S	5
F-D11-07	Ship↔HQ procurement visibility (fleet-wide spend).	M	5
F-D11-08	Receiving module (goods receipt vs PO).	M	5
F-D11-09	Waste tracking (food waste logging + cost).	S	5

Domain 12 — Fleet Management & HQ Intelligence

ID	Feature	Priority	Phase
F-D12-01	Live fleet-wide KPI dashboard (occupancy, RevPax, ancillary spend).	M	5
F-D12-02	Event-stream sync — HQ sees live ship data, not batch.	M	1
F-D12-03	Revenue-center performance by vessel (bar, restaurant, spa, shorex, casino).	M	5
F-D12-04	Centralized config management — pricing, menus, packages, housekeeping rotas pushed to fleet.	M	2
F-D12-05	Voyage/itinerary mgmt — ports, time zones, fuel consumption.	M	5
F-D12-06	Fleet maintenance (planned maintenance, repair tracking, certificates).	S	5
F-D12-07	Financial consolidation (P&L per vessel, fleet roll-up, GL export).	M	5
F-D12-08	Regulatory compliance dashboard (SOLAS, MARPOL, STCW, ENOAD).	M	6
F-D12-09	Quanta-driven anomaly detection on revenue, inventory, crew scheduling.	S	4

Domain 13 — Quanta AI Services (differentiator)

ID	Feature	Priority	Phase
F-D13-01	AI Concierge — 24/7 multilingual assistant across mobile, iTV, kiosk, voice.	M	4
F-D13-02	Natural-language booking across excursions, dining, spa, activities.	M	4
F-D13-03	Personalized recommendations (shorex, dining, spa, retail) from profile + context.	M	4
F-D13-04	Predictive spend alerts + offers based on folio velocity.	S	4
F-D13-05	Operational intelligence — anomaly detection on revenue, inventory, crew.	S	4
F-D13-06	Sentiment analysis on feedback / complaints / NPS (via Heimdall NLP).	S	4
F-D13-07	Voice-first service requests — cabin phone → Quanta → routed to crew.	M	4
F-D13-08	Multi-modal identity correlation across voice/text/behavior.	C	4
F-D13-09	Post-cruise AI engagement (personalized follow-up, tier/offer recommendations).	S	6

Domain 14 — Unified Crew & Guest Communications (ConnectOne platform)

Modeled on NT Maritime's deployed product line — GuestApp (passenger voice/video/messaging over ship WiFi), CrewApp (role-based PTT/voice/chat — Cunard Queen Anne replacement of DECT), and the Hospitality PBX/PA/signage stack — and delivered by ConnectOne (NT Connect's comms platform; Cloud PBX + voice/video transport; SIP signaling with B2BUA / OpenSIPS on the roadmap). CallCraft is the AI-voice surface inside ConnectOne: it hosts the AI-voice agents that join calls/rooms (AI Notes, voice ordering, concierge intents, emergency AI-guided mustering). All signaling and state events ride the Quanta bus (NATS JetStream) using Quanta's agent contract (AGENT_MESSAGES / AGENT_RESPONSES).

14.A — Crew communications (CrewApp pattern)

ID	Feature	Priority	Phase
F-D14-01	Role-based crew mobile app (iOS/Android) supporting voice calls, push-to-talk, group chat, 1:1 chat.	M	2
F-D14-02	Internal crew SIP network with extension dial, conference, call transfer.	M	2
F-D14-03	Replacement of legacy DECT handsets with smartphone clients on commodity hardware.	M	2
F-D14-04	Role/team channels (e.g., bridge, hotel, F&B, security) with rule-based escalation.	M	2
F-D14-05	Emergency-priority routing — muster events preempt non-critical traffic; ConnectOne PBX-level priority rules enforce the preemption.	M	2
F-D14-06	Integration with safety / SMCS-equivalent for emergency notification dispatch (parity with NT Maritime ↔ Martec SMCS).	S	2
F-D14-07	Crew shift-aware Do-Not-Disturb / on-duty routing.	S	5
F-D14-08	Quanta bus event contract for all comms events (call started/ended, message sent/received, presence changes).	M	1

14.B — Guest communications (GuestApp pattern)

ID	Feature	Priority	Phase
F-D14-10	Cabin SIP endpoint per cabin (physical handset and/or app).	M	2
F-D14-11	Guest-to-guest voice and video calling on the same vessel over ship WiFi.	M	3
F-D14-12	Guest-to-crew service requests via voice and chat (concierge, room service, housekeeping, maintenance).	M	3
F-D14-13	Voicemail with AI-generated transcription and call-summary notes ("AI Notes") backed by Heimdall "At a Glance" (local Gemma 4) — Summary / W5H / Context / Claims / Sources.	S	4
F-D14-14	Push notifications to GuestApp for personalized offers, itinerary changes, activity reminders, reservation confirmations.	M	3
F-D14-15	Per-tenant white-label branding of GuestApp (logo, colors, copy, loyalty rules).	M	3
F-D14-16	AI-voice agent — guest dials a service extension; Quanta answers, intent-routes, can act (booking / order / spend query).	M	4
F-D14-17	Sentiment + content-safety scoring on guest message traffic via Heimdall — sentiment, toxicity (Detoxify), identity-attack hate speech, profanity, URL safety, image NSFW (NudeNet v3), CSAM (PhotoDNA + Thorn), grooming (4-analyzer); negative-sentiment threads surface to hotel director, safety incidents escalate to security/purser.	M	4

14.C — Omnichannel external messaging

ID	Feature	Priority	Phase
F-D14-20	Federated messaging gateway: SMS, Viber, Telegram, iMessage, WhatsApp inbound/outbound stitched to a single guest-identity conversation thread.	M	3
F-D14-21	Pre-cruise comms (booking confirmations, check-in invites, dining/spa/excursion reminders) sent over guest's preferred channel.	M	3
F-D14-22	Onboard channel hand-off — when guest comes onboard, conversation continues seamlessly in GuestApp / cabin TV.	S	3
F-D14-23	Post-cruise channel — feedback collection, loyalty promotions, next-cruise offers.	S	6
F-D14-24	Per-tenant outbound campaign tooling (Omnichannel Marketing Outreach module pattern).	C	5

14.D — Telephony infrastructure (transport)

ID	Feature	Priority	Phase
F-D14-30	VSAT/Starlink SIP trunk for PSTN outbound (shore↔ship calling).	M	2
F-D14-31	Ship-wide PA / announcement (SIP multicast or P-Series integration); PA access from designated phones (e.g., bridge, mess room, XO stateroom).	M	2
F-D14-32	Call recording for compliance and AI-summary use cases.	S	4
F-D14-33	Inbound DID pool per vessel for crew family calling.	S	2

14.E — Cloud PBX Platform (full feature set)

Nautilus ships the full Cloud PBX half of ConnectOne — equivalent in scope to NT Connect's netTALK Business PBX, a feature-rich, customizable, contract-free business phone platform — extended for ship deployment. PBX is delivered as a managed cluster (shore + onboard nodes) and provisioned per-tenant per-vessel. End-user clients are SIP phones, ATAs, the TALK app, the PBX App (iOS + Android), the cabin handset, the iTV (ConnectOne endpoint), and the GuestApp / CrewApp.

ID	Feature	Priority	Phase
F-D14-40	Tenant onboarding flow — quote → order → activate → setup → configure → provision in under one hour (parity with netTALK PBX).	M	2
F-D14-41	Extension management — create, edit, delete, bulk-import; per-extension office hours, time-zone, language, presence.	M	2
F-D14-42	Virtual Receptionist (auto-attendant) — multi-level prompt menus, business-hours / after-hours routing, fallback to operator, multilingual default language.	M	2
F-D14-43	Greeting management — Text-to-Speech for prompts and voicemail, plus custom audio upload.	M	2
F-D14-44	Ring Groups — share inbound call distribution across multiple extensions (linear, parallel, weighted, longest-idle).	M	2
F-D14-45	Call Recording — PSTN + VoIP, on-demand or automatic, playback / store / share / export with retention policy and compliance controls.	M	2
F-D14-46	Advanced Call Forwarding — forward all / busy / no-answer / not-registered to extension, group, voicemail, mobile, external number, virtual receptionist.	M	2
F-D14-47	Voicemail — per-extension box with TTS prompts, advanced options (folders, save/forward), email notification, voicemail-to-text transcription, AI summary via Heimdall "At a Glance".	M	2
F-D14-48	Star codes / feature codes — `46` 3-way, `77` block caller-ID, `98` voicemail, `61` device reset, configurable per tenant.	M	2
F-D14-49	3-way calling, blind / attended call transfer, call park & pickup, call hold with music-on-hold per tenant.	M	2
F-D14-50	RoboAgent — spam-call filter; inbound calls scored 0–100% spam-likelihood, displayed on caller ID; >50% probability auto-routes to RoboAgent (auto-attendant) instead of voicemail.	S	4
F-D14-51	Call Blocking (Blacklist) — per-tenant + per-extension block lists; bulk import (e.g., known telemarketer ranges).	S	4
F-D14-52	Caller-ID display, custom outbound caller-ID per extension, caller-ID block (`*77` or per-call).	M	2
F-D14-53	DID (Direct Inward Dialing) management — DID pool, per-extension DID assignment, batch provisioning, per-vessel DID block.	M	2
F-D14-54	Number porting — inbound and outbound, port-out compliance, port-in workflow with validation.	S	2
F-D14-55	International calling with per-rate-plan billing, fraud throttles, geo-block toggles per tenant.	M	2
F-D14-56	E911 — Kari's Law compliant (no prefix required to dial 911), dynamic E911 routing, per-extension address registration with `933` listen-back, automatic location updates when extension roams.	M	2
F-D14-57	E911 Enterprise — multi-site address management for fleet-scale tenants; per-cabin location resolution.	M	2
F-D14-58	SIP trunking — designed for growth, redundancy for max uptime, federal-compliant (NIST SP 800-171), supports inbound + outbound; per-tenant trunk groups; failover between primary + secondary trunks.	M	2
F-D14-59	Legacy bridging via TDM emulation / PRI handoff — interoperate with existing Avaya PBX or PRI trunks during migration (Wyoming Air National Guard pattern).	S	2
F-D14-60	TALK app (mobile softphone) — iOS + Android, calls over Wi-Fi / LTE / 3G / 4G / 5G, no roaming charges; account top-up; voicemail; messaging.	M	2
F-D14-61	PBX App (mobile business client) — iOS + Android; provision a PBX extension on a phone so the user takes their business line on the go.	M	2
F-D14-62	Hot desking — extension follows user across cabin handset / PBX App / iTV / web client / desk phone via login.	S	3
F-D14-63	SIP phone provisioning — auto-provision any SIP phone or ATA with extension SIP credentials; recommended-device list (Grandstream DP750 DECT, GXP series, Cisco SPA, Sipura SPA, Polycom SoundPoint / SoundStation, Linksys SPA / PAP2, Gigaset C530 IP, Vida DiPhone, etc.).	M	2
F-D14-64	Per-tenant CRM-aware dashboards — call logs, recording archive, voicemails, DID inventory, extension directory, presence, BLF (busy lamp field).	M	2
F-D14-65	Wholesale tier — partner / reseller pricing model, sub-tenant isolation, per-sub-tenant billing roll-up.	C	5
F-D14-66	Encryption — TLS for SIP signaling, SRTP for media, mTLS between PBX nodes, at-rest encryption for recordings + voicemails + transcripts.	M	2
F-D14-67	Operator portal — tenant admin: extensions, ring groups, virtual receptionists, DIDs, recordings, billing; self-service end-user portal: voicemail / call forwarding / DND / caller-ID.	M	2
F-D14-68	No-contract / no-hidden-fee commercial model preserved as a tenant-facing capability (parity with netTALK positioning).	M	2

14.F — Maritime PBX Specialization (ship-specific)

Cruise vessels impose constraints no enterprise PBX handles natively — connectivity over VSAT/Starlink with planned and unplanned outages, room=extension hospitality model, ship-wide PA tiered against general alarms (GA), regulatory PA priority during muster, accessibility handsets, parent↔childcare devices, and fleet-wide federation. 14.F is the layer on top of the Cloud PBX core.

ID	Feature	Priority	Phase
F-D14-80	Cabin-as-extension model — cabin number is the canonical extension; cabin handset, paired mobile, and iTV all register against the same extension; calls ring all endpoints simultaneously per guest preference.	M	2
F-D14-81	Hospitality scale — single-tenant deployment supports 4,000+ extensions per vessel (Princess Lodges / Westmark Hotels Alaska benchmark) with low call setup latency under load.	M	2
F-D14-82	Folio-bound billing — chargeable calls (international, premium PSTN) post directly to Domain 3 guest folio in real time; configurable inclusive minutes per package.	M	3
F-D14-83	PA / GA tiered announcements — three priority tiers: routine PA (background music override), informational PA (program announcements), and General Alarm (GA) for safety which preempts all calls and content fleet-wide. (NOAA Ship Bell M. Shimada modernization pattern.)	M	2
F-D14-84	PA zones — broadcast to specific decks / zones / venues / cabins / crew areas only; bridge / mess room / XO stateroom phones designated as PA-origin endpoints (Cunard Queen Anne case).	M	2
F-D14-85	Bridge / officer priority queues — calls from bridge / safety officer / medical officer extensions preempt non-priority traffic and can interrupt active calls (configurable).	M	2
F-D14-86	Wake-up calls per cabin with confirmation tone, retry logic, and escalation to crew if missed; bookable from iTV / GuestApp / front desk.	M	3
F-D14-87	DND (Do Not Disturb) at PBX level — synced with iTV (F-D15-53) and crew DND state; emergency calls still penetrate.	M	3
F-D14-88	Accessibility handsets — TTY / amplified / visual-alert phones for guests who are deaf or hard-of-hearing; provisioned automatically when accessibility is set on the guest profile (Domain 1).	M	3
F-D14-89	Parent ↔ childcare communication devices — child's location can be reached from parent's cabin extension or mobile; childcare crew can call parent on dedicated devices (Cunard pattern).	S	3
F-D14-90	Fleet-wide federation — extensions and dial plans federated across vessels and shore offices; ship-to-ship and ship-to-shore dialing without external PSTN trunks where IP path exists.	M	5
F-D14-91	Maritime SIP trunk over VSAT / Starlink — bandwidth-aware codec selection (G.711 in port, Opus / G.729 underway), jitter-resilient, automatic re-registration after satellite handover.	M	2
F-D14-92	Offline PBX — onboard PBX node continues operating when shore link is degraded; voicemail, internal calling, ship-wide PA, GA, and crew comms remain functional; outbound PSTN queues or fails-over per policy.	M	2
F-D14-93	Muster integration — when Domain 6 declares a muster event, PBX preempts non-priority traffic, enables emergency-only routing, broadcasts pre-recorded muster announcements per zone, and routes any incoming guest call to a muster-help queue (parity with Cunard / Martec SMCS integration).	M	2
F-D14-94	Health / contact-tracing integration (Domain 16) — PBX exposes presence + cabin location to Heimdall + Health module; quarantined guests are routed to medical / room-service-only number tree automatically.	S	4
F-D14-95	Multi-language IVR — virtual receptionist auto-greets in guest's preferred language (Domain 1 profile) when call originates from cabin extension.	M	3
F-D14-96	Schedule-aware booking via PBX — guest dials a code or speaks an intent (Quanta voice agent, F-D14-16) to book spa / dining / excursion / conference room; falls back to live operator.	S	4
F-D14-97	Mission-critical resilience — dual VoIP SIP lines, 24/7 remote support, 90-day deployment template (CSG-4 / Wyoming Air National Guard playbook); per-vessel SLA targets per Section 6.1.	M	2
F-D14-98	Hospitality-suite white-label — front-desk console, housekeeping check-in/check-out coordination, room-status (clean / dirty / inspected) maintained at PBX level for legacy-PMS interop.	S	3

Domain 15 — Guest Mobile App, Cabin TV & Digital Touchpoints

15.A — Mobile, kiosk, mobile-only

ID	Feature	Priority	Phase
F-D15-01	White-label native mobile app (iOS + Android, shared RN codebase).	M	1 (skeleton) / 3 (full)
F-D15-02	Pre-cruise: booking review, online check-in, shorex pre-book, dining reservations.	M	3
F-D15-03	Onboard: daily program, folio, service requests, messaging, digital board card.	M	3
F-D15-04	AI Concierge chat powered by Quanta (multilingual, NL).	M	4
F-D15-05	Push notifications (offers, reminders, itinerary changes).	M	3
F-D15-06	Digital boarding pass + NFC board card on supported devices.	S	3
F-D15-07	Self-service kiosks — same PWA, kiosk form factor.	M	3
F-D15-08	Post-cruise: feedback, loyalty, next-cruise inspiration.	S	6

15.B — Cabin Interactive TV (iTV) — full-service in-cabin platform

The cabin TV is treated as a first-class Nautilus touchpoint, not a third-party IPTV add-on. It runs the same React PWA as mobile/kiosk in a TV form factor and acts as: entertainment hub, cruise-info portal, transactional surface (folio / ordering / booking), video-call endpoint, and the guest-facing controller for the cabin Guest Room Management System (GRMS). Hardware integration with the cabin GRMS (HVAC, lighting, drapes, safe, minibar, door lock) is via a pluggable adapter — see OQ-16.

15.B.1 — TV / entertainment

ID	Feature	Priority	Phase
F-D15-20	iTV runs the shared React PWA codebase in TV form factor (no separate app stack).	M	3
F-D15-21	Guest auth on iTV via board-card NFC tap or paired-mobile QR — personal state restored on cabin entry.	M	3
F-D15-22	Live linear TV channels delivered as HLS (primary) and DASH (secondary, for Widevine-native Android clients) — multi-language audio tracks, subtitles, EPG, adaptive bitrate. Per-vessel origin cache (Nginx + Varnish) serves all cabin TVs, iTV PWA, kiosk, and mobile clients from a single upstream fetch. DRM via standard EME. (OQ-17 resolution; see §6.15.)	M	3
F-D15-23	On-demand video library — movies, series, kids, documentaries, port-of-call destination content.	M	3
F-D15-24	Music / radio channels and curated audio (relaxation, party, kids) playable through cabin speakers or TV.	S	3
F-D15-25	Per-tenant brand theming: channel lineup, VOD catalog, splash content, idle screensaver.	M	3
F-D15-26	Parental controls / kids profiles — separate kids home screen, PIN protection, Heimdall SafeSpace COPPA tier enforced on all rendered content (TV, VOD, signage feeds, messaging inbox); Teen tier for adolescent profiles; General/Relaxed for adult cabins.	M	3
F-D15-27	Casting / second-screen — push content from mobile to TV; pause-and-resume across devices.	C	4
F-D15-28	Pay-per-view rentals (premium new releases, live events) posted to folio.	C	4

15.B.2 — Cruise info & wayfinding

ID	Feature	Priority	Phase
F-D15-30	Daily program board (per-day activities, dining hours, entertainment, port times) — auto-rendered from Domain 7/8/12 event streams.	M	3
F-D15-31	Today's port-of-call dossier — arrival/departure times, all-aboard, weather, currency, language tips, port map, shorex options with one-tap booking.	M	3
F-D15-32	Live ship position / map / speed / heading / weather / sea state ("bridge view").	S	3
F-D15-33	Voyage tracker — itinerary timeline, days-at-sea vs port days, time-zone changes (with auto-update of cabin clock).	M	3
F-D15-34	Dress code for tonight (formal / smart casual / themed) with venue-specific overrides.	S	3
F-D15-35	Deck plan & wayfinding — interactive deck-by-deck map, "find a venue", route from cabin to venue.	S	3
F-D15-36	Mandatory safety video gating — must be acknowledged before muster; completion logged to Domain 6.	M	3
F-D15-37	In-cabin welcome / orientation flow on first power-up (concierge intro, ship overview, language selection).	S	3

15.B.3 — Transactional & service

ID	Feature	Priority	Phase
F-D15-40	In-cabin folio review, package balance, today's charges; one-tap dispute / inquiry routes to purser.	M	3
F-D15-41	In-cabin room-service ordering with allergen-aware menus; posts to Domain 4 POS and KDS.	M	3
F-D15-42	Booking flows on iTV — dining, spa, shore excursions, activities, fitness classes.	M	3
F-D15-43	Crew quick-call shortcuts on iTV — concierge, butler, housekeeping, room service, reception, medical (24/7).	M	3
F-D15-44	iTV is a video-call endpoint via ConnectOne (WebRTC media) — guest↔guest video, guest↔crew video concierge, telehealth video consult to medical center (Domain 16).	M	4
F-D15-45	Cabin messaging inbox — operator notices, AI Concierge replies, omnichannel threads from Domain 14.C.	S	3
F-D15-46	Express check-out from iTV — review final folio, confirm payment method, schedule disembark slot.	S	3
F-D15-47	Voice control via Quanta — "what's for dinner?", "book the snorkel tour", "set wake-up at 7" — routed through CallCraft + Quanta.	C	4
F-D15-48	iTV PA override — emergency announcements interrupt all TV/VOD/music content (ties F-D14-31, F-D6-09, F-D15-66).	M	3

15.B.4 — Cabin / room control (GRMS via iTV)

ID	Feature	Priority	Phase
F-D15-50	Lighting control — per-zone on/off/dim, scenes (Read / Sleep / Romance / Welcome / All Off).	M	3
F-D15-51	HVAC / climate — temperature setpoint, fan, mode; energy-aware setbacks when cabin unoccupied (door-card / occupancy sensor).	M	3
F-D15-52	Drapes / blinds / blackout control (where motorized).	S	3
F-D15-53	"Do Not Disturb" and "Make Up Room" toggles — propagate to housekeeping crew app and cabin door indicator.	M	3
F-D15-54	Wake-up alarm with optional gradual lighting + curtain-open + soft-music sequence.	S	3
F-D15-55	Mood / scene controller (Goodnight = lights off + DND + alarm set + drapes closed).	S	3
F-D15-56	Electronic safe status / alerts (open-while-locked alert to security).	C	3
F-D15-57	Minibar consumption surfacing (pulled from RFID/weight-sensor minibar where installed) → posts to folio after grace period.	C	4
F-D15-58	Bathroom / floor-heating control where present.	C	3
F-D15-59	"Energy Save while Ashore" — automatic when guest checks out at gangway (Domain 5 ↔ Domain 15).	S	4
F-D15-60	Accessibility profiles — high contrast, large text, voice-first, hearing-impaired (visual alarms, captions on by default).	M	3
F-D15-61	Multi-language UI (parity with Domain 13 / NFR-61); per-cabin language preference persists across logins.	M	3

15.C — Fleet-wide Digital Signage (synced to F&B, activities, excursions, voyage)

A single signage management surface drives every screen on the ship — entrance signs, deck-by-deck wayfinding, restaurant menu boards, activity boards, excursion desks, theater frontages, pool deck displays, gangway boards, and crew areas. Content is event-driven from the source domains (no double entry): when a menu, schedule, or excursion availability changes in Domain 4 / 7 / 8 / 12, every relevant sign updates within seconds via the Quanta bus.

Platform foundation: signsync (extended). Domain 15.C is implemented by extending the existing NT Connect signsync platform (~/src2/signsync — Next.js 15 + Postgres + Drizzle ORM; ~510-commit production codebase with CMS, device health monitoring, schedule filtering, composition generation). signsync's CMS core + device-fleet model are retained; player coupling (currently Roku-only), single-tenancy, and synchronous-pull integration pattern are rewritten. Extension work itemized as F-D15-81 through F-D15-90.

ID	Feature	Priority	Phase
F-D15-65	Centralized signage CMS — define screens, zones, templates, schedules, audience tags; per-tenant brand theming.	M	3
F-D15-66	Signage emergency override — muster / fire / abandon-ship messages preempt all content fleet-wide within seconds; ties to F-D14-31 and F-D15-48.	M	3
F-D15-67	Restaurant menu boards outside each venue — pulled live from Domain 7 menu service; price, allergen, "today's special", time-of-day swap (breakfast/lunch/dinner).	M	3
F-D15-68	Venue wait-time / availability boards — current cover count vs capacity (Domain 7), "now seating" / "30-min wait".	S	3
F-D15-69	Activity boards — current and next activities by venue (theater, lounges, pool deck, kids club, gym) auto-rendered from Domain 8 schedule.	M	3
F-D15-70	Shore-excursion availability boards near the excursion desk — live inventory, waitlist status, "sold out", weather-driven cancellations from Domain 8.	M	3
F-D15-71	Gangway boards — "now boarding" / "all aboard at HH:MM" / countdown / total ashore vs onboard (from Domain 5).	M	3
F-D15-72	Daily program signs — same source as iTV F-D15-30; consistent across TV, mobile, kiosks, and signs.	M	3
F-D15-73	Wayfinding / interactive deck-plan kiosks — "you are here", route to any venue, accessibility paths.	S	3
F-D15-74	Live ship-data overlays — position, speed, course, weather, sea state, sunrise/sunset, time to next port.	S	3
F-D15-75	Promotional / commercial slots — spa offers, retail, premium dining; prioritized by Quanta given time-of-day, audience density (Domain 16 heatmaps), and current revenue gaps.	S	4
F-D15-76	Audience-aware content — kids-zone screens vs adults-only zone vs crew areas; zone tags drive content selection.	S	3
F-D15-77	Multi-language rotation — primary + N translations rotated per dwell-time policy per zone.	S	3
F-D15-78	Crew-facing signage — back-of-house screens with shift schedules, safety briefings, ILO compliance prompts (Domain 10).	S	5
F-D15-79	Per-screen monitoring — heartbeat, content-render proof, last-update timestamp, alert on screen-down (observability NFR-40).	M	3
F-D15-80	Screen takeover for ship-wide events (sailaway party, captain's address, port arrival) — Quanta-orchestrated playlists timed to ship state.	S	4
F-D15-81	Player-agnostic device contract. Generalize signsync's current Roku-only `POST /api/display/[macAddress]` into a player-agnostic device check-in + playlist-pull API. Supported player targets at launch: Samsung Tizen, LG webOS, NUC-class x86 running Chrome kiosk, BrightSign (HTML5-URL mode). Roku deprecated. (OQ-18 resolution.)	M	3
F-D15-82	Multi-tenant isolation. Add `tenantId` + `vesselId` columns to every signsync table; row-level security in Postgres; per-tenant Firebase auth projects (or replace Firebase with Zitadel OIDC — see below). Fleet of 200+ vessels × tenant-isolated.	M	3
F-D15-83	Replace Firebase Auth with Zitadel OIDC. signsync currently uses Firebase Auth; Nautilus standard is Zitadel (FR-06). Migrate auth; keep Firebase Cloud Storage optional (or migrate media to tenant-region S3-compatible object store per NFR-140).	M	3
F-D15-84	NATS listener layer. Subscribe to Nautilus bus subjects (`nautilus.{tenant}.{vessel}.menu.updated`, `activity.schedule.changed`, `excursion.availability.changed`, `pa.broadcast`, `ga.alert`, `voyage.event`) and trigger composition regeneration + playlist-override. Replaces signsync's current pull-only integration model.	M	3
F-D15-85	Emergency-override priority playlist. Hook to ConnectOne `pbx.{t}.{v}.ga.alert` events (ship-pbx spec §5.5). GA preempts all signage content fleet-wide within seconds; restored on clear event. Never dropped; never back-pressured.	M	3
F-D15-86	Quanta AI slot prioritization. Replace signsync's underdeveloped Genkit stub with Quanta agent calls — audience-aware promo-slot selection (time-of-day, zone occupancy from Domain 16 BLE heatmaps, current revenue gaps from Domain 12). Realizes F-D15-75.	S	4
F-D15-87	Per-zone targeting (true spatial model). Replace signsync's string-tag `groups` with a zones relation: deck zone / venue zone / kids zone / crew area. Zone tags drive content selection per F-D15-76.	M	3
F-D15-88	Offline-first onboard operation. Per-vessel signsync node caches content + playlist state; continues operating during shore-link loss; buffers published events in NATS JetStream leaf node; reconciles on reconnect per FR-03 / NFR-84.	M	3
F-D15-89	Multi-language rotation per zone and per item with dwell-time policy. signsync has no i18n today; add language field to compositions + items + playlists (per NFR-61 + F-D15-77).	S	3
F-D15-90	Test coverage + CI + observability. signsync ships zero tests and no CI today. Add Vitest suite (unit + integration), GitHub Actions CI per NT Connect pattern, `postgres_exporter` (NFR-87), Prometheus ServiceMonitor on the signsync service, Hubble flow metrics for player check-ins. Non-negotiable before Phase-3 go-live.	M	3

Domain 16 — Telehealth & Location Intelligence (NT Maritime Health pattern)

Modeled on NT Maritime's Health product (deployed on Disney Cruise Line) and its location-services / contact-tracing platform. Splits cleanly from Safety & Muster (which is regulatory/operational): this domain is the medical-care + location-data product surface.

16.A — Telehealth

ID	Feature	Priority	Phase
F-D16-01	Guest-initiated video consultation with onboard medical team from mobile app, cabin iTV, or in-cabin device.	M	4
F-D16-02	Shore-side / off-vessel clinician video consultations via VSAT/Starlink (specialty consults at sea).	S	4
F-D16-03	Pre-public-space health screening flows (parity with NT Maritime Health: screening before public spaces and crew before guest interaction).	S	4
F-D16-04	Symptom intake and triage chatbot (Quanta) routing low-acuity cases to self-care, mid to telehealth, high to physical exam.	S	4
F-D16-05	Medical record access via board-card tap, integrated with Domain 6 medical module.	M	3
F-D16-06	Medication inventory and prescription dispensing tracking.	M	3
F-D16-07	Crew telehealth (occupational health, mental health, routine consults).	S	5
F-D16-08	Privacy-by-default: medical data segregated, encrypted, jurisdiction-aware retention.	M	3

16.B — Location services & contact tracing

ID	Feature	Priority	Phase
F-D16-20	BLE/Bluetooth-LE wearable + gateway infrastructure for opt-in passenger and crew location.	S	4
F-D16-21	Anonymized contact tracing — given an infected guest/crew, identify recent close contacts within configurable window.	S	4
F-D16-22	Hotspot identification — surface locations the infected guest visited that need enhanced sanitization.	S	4
F-D16-23	Anonymized occupancy heatmaps — venue density for safety (over-capacity alerts) and revenue (under-utilized POS opportunities).	S	5
F-D16-24	Privacy controls: opt-in by default for guests; data aggregation and retention policies enforced; PII separated from location stream.	M	4
F-D16-25	Crew location (manning, drills, missing-person scenarios) with stricter retention and clear consent.	S	4
F-D16-26	Location-aware marketing / recommendations (Quanta) — "guest near pool bar at 4pm" → cocktail-hour offer.	C	5
F-D16-27	Quarantine workflow integration (digital cabin lock, room-service-only ordering) when a guest is medically isolated.	S	4

6. Non-Functional Requirements

6.1 Availability & resilience

ID	Requirement	Target
NFR-01	Onboard domain services SHALL continue operating with shore link down for at least the duration of a single voyage.	≥14 days offline
NFR-02	Shore cluster availability for guest-facing endpoints.	≥ 99.9% monthly
NFR-03	Onboard cluster availability during operating hours.	≥ 99.95%
NFR-04	No single service SHALL be a single point of failure for a voyage-critical capability (check-in, gangway, muster, folio posting, POS).	"Zero-downtime" target
NFR-05	Event replay on reconnect SHALL complete without human intervention for planned outages of up to 72 hours.	Automatic

6.2 Performance / scale

ID	Requirement	Target
NFR-10	Nautilus SHALL support vessels up to 6,000+ passengers + crew at full operational load.	MSC World-class scale
NFR-11	Gangway scan → local "permit/deny" decision latency.	p95 ≤ 500 ms
NFR-12	POS folio posting (local) to confirmation.	p95 ≤ 750 ms
NFR-13	Muster scan → headcount update visible to officer.	p95 ≤ 2 s
NFR-14	Ship→shore event delivery latency (nominal VSAT).	p95 ≤ 10 s
NFR-15	Pre-cruise check-in flow (mobile app) end-to-end.	≤ 5 min

6.3 Security & compliance

ID	Requirement
NFR-20	All inter-service traffic SHALL be encrypted in transit. East-west (pod-to-pod) is protected by Cilium CNI with WireGuard transparent encryption (NFR-100). East-west event bus uses NATS-native TLS + NKey/JWT authentication (per OQ-01 resolution). North-south terminates TLS at Kong with mTLS to upstreams where upstreams support it. Direct service-to-service HTTP/gRPC (where unavoidable) uses mutual TLS with `cert-manager`-issued cluster CA and explicit client-cert verification. No separate service mesh in Phase 1–3 (OQ-08 resolution); Cilium's identity-based network policy + Hubble observability + WireGuard cover the mesh's day-one value.
NFR-21	Payment processing SHALL be PCI DSS Level 1 compliant via tokenization. All vendor interaction MUST go through the Domain 3 `PaymentProcessor` adapter abstraction (F-D3-06); domain code MUST NOT import payment-vendor SDKs directly. Initial adapters: Stripe (reference) + Adyen (on-demand). No raw PAN, CVV, magstripe, PIN, or chip track data in Nautilus data stores, logs, message-bus events, analytics pipelines, or backups — ever. Tokens are the only payment-instrument identifier that crosses the SPMS boundary.
NFR-22	Guest PII SHALL be encrypted at rest and in transit; access audited.
NFR-23	Heimdall anomaly detection SHALL monitor access patterns, financial transactions, and guest communications for abuse/fraud signals.
NFR-24	SOLAS, MARPOL, STCW, ENOAD, EU-LISA, ILO working-hours, and GDPR-equivalent regulatory obligations SHALL be met; compliance reports are generated, not hand-built.
NFR-25	Passport / MRZ / biometric data handling SHALL comply with per-jurisdiction requirements; retention schedules enforced automatically.

6.4 Tenancy & branding

ID	Requirement
NFR-30	The platform SHALL isolate tenant data (logical row-level at minimum; schema- or cluster-level where regulation requires).
NFR-31	Per-tenant branding (logos, colors, copy, loyalty rules, pricing structures) SHALL be configurable without code changes.
NFR-32	A guest identity SHALL NOT be shared across tenants unless explicit cross-tenant alliance is configured.

6.5 Observability

ID	Requirement
NFR-40	Every service SHALL emit structured logs (Loki), metrics (Prometheus), and traces compatible with fleet-wide dashboards (Grafana).
NFR-41	Each vessel SHALL have a local observability stack that buffers and forwards to shore.
NFR-42	SLOs and error budgets SHALL be defined per domain service before v1 go-live.

6.6 Deployability

ID	Requirement
NFR-50	All services SHALL be packaged as Helm charts and deployed via ArgoCD (GitOps).
NFR-51	Fleet rollouts SHALL be staged (canary vessel → cohort → fleet) with automatic rollback on SLO breach.
NFR-52	CI pipelines SHALL build OCI images compatible with the onshore RKE2 and onboard K3s clusters (including ARM where applicable).

6.7 Usability

ID	Requirement
NFR-60	Guest mobile app SHALL meet WCAG 2.1 AA for accessibility.
NFR-61	Guest-facing UIs SHALL support, at minimum, English + top-10 guest languages per tenant. Quanta assistant SHALL be multilingual.
NFR-62	Crew tablets SHALL be usable with gloves / wet hands (touch target sizing, no precision gestures required for critical flows).

6.8 Hardware independence

ID	Requirement
NFR-70	Gangway, POS, and mustering SHALL run on commodity hardware (any Android tablet / iPad / Surface / PC with PWA-capable browser). No vendor lock (Oracle MICROS, specific RFID OEM).

6.9 Data storage & replication topology

ID	Requirement
NFR-80	All Nautilus services SHALL use PostgreSQL v17.2 via the CloudNativePG (CNPG) operator. One database per service (physical sharing permitted onboard per NFR-83; no shared schemas or cross-service foreign keys). (Inherits the NT Connect `r360-infrastructure` pattern.)
NFR-81	Shore cluster: each service CNPG cluster SHALL run 3 instances (primary + 2 standbys) with synchronous quorum replication (`synchronous.method: any`, `synchronous.number: 1`). Anti-affinity across K8s nodes; multi-AZ where available. Tolerates one replica failure without blocking writes.
NFR-82	Onboard cluster — safety-critical (D5 Gangway, D6 Muster, D14 ConnectOne/PBX state) and revenue-critical (D3 Folio, D4 POS, D2 check-in state): 2 instances (primary + sync standby) with `synchronous: preferred` (NOT `required` — standby outage must not block safety writes). PodDisruptionBudget prevents simultaneous planned maintenance on both.
NFR-83	Onboard cluster — operational and read-mostly domains (D7 Dining, D8 Excursions, D9 Spa, D10 Crew, D11 Materials, D12 Fleet mgmt read-side, D13 Quanta state, D15 iTV state, D16 Telehealth records): 1 instance acceptable. To reduce onboard operational footprint, these services MAY share a single CNPG cluster with one database per service — service-level isolation (own user, own database, no cross-database queries) preserves FR-01's no-shared-schema rule while cutting onboard pod count ~60%.
NFR-84	Ship↔shore replication SHALL NOT use Postgres streaming replication. Domain events flow over NATS JetStream per FR-03; the projection of those events is the authoritative cross-location sync mechanism. (Postgres streaming replication over VSAT / Starlink fails due to high RTT, bandwidth limits, and unbounded WAL retention when a vessel goes dark.)
NFR-85	Every CNPG cluster SHALL use Barman + S3-compatible object storage for WAL archiving and scheduled base backups. Shore cluster: daily full, continuous WAL; 30-day retention minimum. Onboard cluster: local backups to onboard MinIO plus WAL shipment to shore when bandwidth permits (vessel-loss DR).
NFR-86	PgBouncer (or equivalent connection pooler) SHALL sit in front of every primary. Transaction-pooling mode by default; session pooling only for services that require session-scoped features.
NFR-87	`postgres_exporter` SHALL be deployed as a sidecar with every CNPG cluster; `pg_stat_statements` enabled; Prometheus `ServiceMonitor` scraping metrics into the shared Grafana. No CNPG cluster goes to production without observable DB metrics.
NFR-88	No document store in the Nautilus AGPL distribution. Flexible-schema data uses Postgres JSONB with GIN / partial indexes as needed. Full-text search on JSONB fields uses `tsvector` where sufficient; a dedicated search service (Meilisearch / Typesense / OpenSearch) may be added per domain only when JSONB FTS demonstrably falls short.

6.10 Secrets management & supply-chain hygiene

ID	Requirement
NFR-90	No secrets in git. Credentials, keys, tokens, certificates, tenant-specific config values, JWT signing keys, payment API keys, CRS API keys, and database passwords MUST NOT be committed to the Nautilus repository in any form (plaintext, base64, encrypted-in-place without an OSS decryption story). This is a hard rule, enforced in CI via secret-scanning hooks (gitleaks / trufflehog).
NFR-91	Secrets management SHALL use HashiCorp Vault with External Secrets Operator (ESO) on Kubernetes. Applications consume secrets as mounted files / env vars materialized by ESO from Vault at runtime. SealedSecrets or SOPS are acceptable transitional alternatives but not the end state.
NFR-92	Per-tenant Helm values, vessel-specific configs, and any operator-specific overrides SHALL live in a separate private overlay repo per operator — never in the public AGPL Nautilus repo. The public repo contains templates and reference values only.
NFR-93	CI pipeline SHALL reject any commit containing strings matching secret patterns (API keys, private keys, JWTs, connection strings with embedded credentials). Pre-commit hooks distributed with the repo help contributors catch issues locally.
NFR-94	Dependency license audit SHALL run in CI; any dependency whose license conflicts with AGPL-3.0 (SSPL, BUSL, non-commercial clauses, proprietary binary blobs) fails the build. Known conflict list maintained in `docs/licenses/incompatible.md`.

6.11 Networking, CNI & in-cluster observability (Cilium)

ID	Requirement
NFR-100	Kubernetes CNI SHALL be Cilium v1.16+ on every Nautilus cluster (shore and onboard). Cilium replaces the default CNI (Calico / Flannel) and provides networking, transparent encryption, identity-based network policy, and flow observability from a single component.
NFR-101	Transparent pod-to-pod encryption SHALL be enabled via Cilium + WireGuard (`enable-wireguard: true`). IPsec is an acceptable alternative only where WireGuard is unavailable in the host kernel. All east-west traffic between pods is encrypted at the CNI layer without application or sidecar involvement.
NFR-102	Identity-based authorization SHALL use `CiliumNetworkPolicy` (CNP) — default-deny at cluster scope; services allowlist callers by Kubernetes identity (ServiceAccount / label selectors) rather than by IP / CIDR. Legacy `NetworkPolicy` may be used where CNP is unnecessary.
NFR-103	`kube-proxy` SHALL be replaced by Cilium's eBPF implementation (`kubeProxyReplacement: true`) for lower latency and reduced iptables churn.
NFR-104	Hubble SHALL be enabled with Relay + UI; Hubble metrics (flow, HTTP, DNS) exported to Prometheus via the Hubble ServiceMonitor; default Grafana dashboards deployed. This covers network-layer observability.
NFR-105	Application-layer observability (distributed traces, request-level metrics, structured logs) SHALL come from OpenTelemetry SDKs in every service — Cilium/Hubble is network-layer only. No service ships without OTel instrumentation. (Supersedes and sharpens NFR-40.)
NFR-106	Cilium Bandwidth Manager SHOULD be used onboard to shape VSAT / Starlink egress per-priority (muster/GA > revenue-critical folio & POS > routine operational > bulk sync). Configurable per vessel.
NFR-107	Node kernel SHALL be Linux 5.15+ to support the full Cilium feature set (WireGuard, eBPF host routing, kube-proxy replacement). This becomes a hardware-qualification requirement for onboard K3s nodes (OQ-13 hardware standards).
NFR-108	Cilium ClusterMesh is NOT used for ship↔shore data replication — NATS JetStream is the authoritative mechanism (NFR-84). ClusterMesh MAY be used shore-side for multi-region federation if one becomes necessary; not in scope for Phase 1–3.
NFR-109	A separate L7 service mesh (Linkerd, Istio, or Cilium Service Mesh L7 add-on) is NOT required in Phase 1–3. Revisit in Phase 4–5 only if direct service-to-service HTTP/gRPC traffic patterns develop observability or traffic-management needs that Hubble + Kong + OpenTelemetry + ArgoCD Rollouts cannot satisfy. If a mesh then becomes necessary, the first option to evaluate is Cilium Service Mesh (continues the same CNI); Linkerd is the fallback.

6.12 API gateway (Kong)

ID	Requirement
NFR-120	The API gateway SHALL be Kong Gateway OSS v3.7+ (Apache 2.0) — identical deployment pattern shore and onboard. Kong Enterprise is not required for Phase 1–3.
NFR-121	Kong SHALL be deployed via the Kong Ingress Controller on Kubernetes with `IngressClass: kong` as the default for Nautilus traffic; CRD-based plugin configuration (no Kong Admin UI dependency).
NFR-122	Onboard Kong runs in DB-less mode — declarative config (`decK` YAML) mounted as ConfigMap; no per-vessel Postgres overhead for Kong itself. Shore Kong MAY use DB-backed mode if multi-operator admin workflows require it, but DB-less is preferred unless driven otherwise.
NFR-123	Authentication at the gateway SHALL use the OIDC plugin (community) with Zitadel as the identity provider (OQ-06). Gateway validates JWTs on every request and injects claims as headers to upstream services.
NFR-124	Rate limiting SHALL be configured per-route and per-tenant via Kong's rate-limiting plugins (Redis-backed for multi-instance gateway clusters shore-side; local in-memory acceptable onboard where one gateway per vessel is the norm).
NFR-125	Heimdall is fronted by Kong (per FR-13) — auth, mTLS to Heimdall, per-tenant rate limits; Heimdall's own HTTP surface has no built-in auth.
NFR-126	Outbound third-party calls (Stripe, Adyen, Versonix Seaware, port-authority ENOAD / EU-LISA submissions) MAY route through Kong as an egress proxy for audit logging and credential injection, or go direct per domain choice. Egress-via-Kong SHOULD be the default for PCI-scope traffic.
NFR-127	Observability: Kong Prometheus plugin enabled on every instance; request logs shipped to Loki; OpenTelemetry plugin for trace propagation into upstream services.
NFR-128	Declarative config via `decK` SHALL be the source of truth for Kong configuration; YAML lives in the service / infra repo and is promoted through the same ArgoCD pipeline as the rest of the stack. Ad-hoc `curl /admin-api` changes in production are forbidden.
NFR-129	Gateway upgrades SHALL be rolling, zero-downtime; DB-less mode reloads are hitless (Kong v3+). Version pins in `versions.yaml` (inheriting the r360 pattern).

6.13 Privacy, data residency & DSR

ID	Requirement
NFR-140	Per-tenant region pinning. Each tenant SHALL select one primary shore region at provisioning. All of that tenant's shore-side data (Postgres clusters, NATS JetStream streams, backups, Heimdall analysis results, media / recordings, logs) lives in that region. Initial region set: EU (Frankfurt / Dublin), UK (London), US (East / West), AU (Sydney), SG (Singapore), BR (São Paulo), LATAM (variable). Additional regions on-demand. Region change post-provisioning requires a data-migration workflow (Phase 5+).
NFR-141	GDPR-grade controls as the global default. Every tenant — regardless of region — gets the same baseline: lawful basis recorded for every processing activity, explicit consent capture for special-category data (biometric / health / location / marketing), right-to-access / rectify / erase / port / restrict / object (F-D1-09), DPO contact on file, breach-notification workflow targeting 72 hours to supervisory authority + data subjects where risk warrants. Tenants in less-strict regimes inherit the stricter defaults; they can opt up (e.g., California CPRA extensions) but not down.
NFR-142	Crypto-erasure SHALL be the erasure mechanism for non-deletable stores (backups, WAL archives, append-only audit logs, cold storage). Per-category encryption keys are managed in Vault (NFR-91) with documented lifecycle; erase-by-key-destruction destroys all ciphertext bound to that key and is legally defensible under GDPR / UK GDPR / CPRA / LGPD / most comparable regimes. Records where crypto-erasure is insufficient for local regulation (e.g., strict data-localization jurisdictions) are flagged at ingestion and handled via row-level delete where possible.
NFR-143	Per-category retention policy service. Retention rules are codified per data category (passport, biometric, health, messaging, call recording, transcript, payment-token, marketing, telemetry, audit) × jurisdiction (EU, UK, US-state-by-state, BR, AU, SG, …). The policy service runs on a scheduler against every data store; expired records are crypto-erased or row-deleted. Extends NFR-25 (previously passport-only) to the full PII + sensitive-data surface.
NFR-144	Cross-border transfer mechanisms SHALL be documented per deployment. EU→non-adequate: Standard Contractual Clauses + Transfer Impact Assessment. EU↔UK, EU↔CH, EU↔adequacy-decision countries: adequacy. Ship↔shore: treated as a controlled transfer with documented legal basis (tenant operator's region is the destination); TLS-in-transit + region-pinned storage on receipt.
NFR-145	Data Protection Impact Assessment (DPIA) at tenant onboarding. Every new tenant produces a DPIA before go-live — processing purposes, data categories, lawful bases, retention periods, cross-border flows, risk analysis, DPO sign-off. Nautilus provides a DPIA template as an operational artifact (not in the AGPL source tree).
NFR-146	DSR API endpoints (F-D1-09) SHALL be rate-limited and authenticated; DSR requests are audit-logged; automated identity verification required before any erase or port; deadline-tracked against jurisdictional SLAs (GDPR 30 days, CPRA 45 days, etc.); Heimdall-side DSR propagation (for content already analyzed) is part of the workflow.
NFR-147	Special-category data (biometric photo, medical records, telehealth consultations, BLE location, communications content) SHALL be processed only with explicit consent captured at check-in (Domain 2) and re-verifiable at any time via the guest mobile app. Consent revocation triggers a Domain 1 DSR workflow.
NFR-148	Maritime legal layer is out of Nautilus code but in the tenant-onboarding operational pack: flag-state law governs data created onboard at sea; port-state law applies during port calls; tenant-region law governs post-sync shore data. Vessels' flag states SHALL be recorded on the tenant's vessel configuration so legal bases are auditable.
NFR-149	No secondary-use-without-consent. Data collected for operational purposes (folio, gangway, muster, comms) MUST NOT be used for ML model training, marketing targeting, third-party sharing, or analytics beyond operational scope without specific renewed consent per purpose. Applies to Quanta AI agents and Heimdall analysis equally.

6.14 Heimdall deployment topology

ID	Requirement
NFR-150	Onboard Heimdall module. Every vessel SHALL run a closed-source Tier-B onboard Heimdall module that serves the SafeSpace subset of the API: CSAM (SHA-256 + PhotoDNA + Thorn Safer), grooming 4-analyzer, NudeNet v3 NSFW, Detoxify toxicity, profanity, URL scanning. Runtime: INT8-quantized DeBERTa-v3-large on CPU or small GPU (NVIDIA L4-class or equivalent). Nautilus domain services reach the onboard module through the published Tier-C Heimdall API spec (OQ-24) — no direct SDK dependency.
NFR-151	Conservative onboard thresholds. The onboard module SHALL run with stricter (more conservative, higher false-positive rate) thresholds than the shore module. Ambiguous classifications SHOULD escalate to shore re-scoring when shore is reachable, and SHALL block-with-audit when shore is unreachable. False-positive-then-release is acceptable; false-negative-then-publish is not.
NFR-152	Signed model weights. Onboard module weights SHALL be signed by NT Connect's model-release signing key. Vessels verify signatures before loading. Weights are hot-swappable without dropping verdict processing.
NFR-153	Model-update bus subject. Shore publishes `heimdall.model.update.{version}` on the Quanta bus; onboard modules pull signed weights over HTTPS through Kong (NFR-125), verify signature, stage, and hot-swap. No forced upgrade during muster or other safety-critical windows.
NFR-154	Immutable onboard audit trail. Every onboard verdict (item screened, tier applied, classification result, action taken) SHALL be logged immutably onboard (append-only store) and synced to shore via NATS JetStream on reconnect. Evidence chain must survive vessel-disconnection scenarios for legal defensibility on CSAM / grooming escalations.
NFR-155	Re-scoring on reconnect. Content that received an "ambiguous → hold" onboard verdict SHALL be re-scored by shore Heimdall (full model) on reconnect; discrepant verdicts are flagged to the safeguarding role for review.
NFR-156	Heimdall ingest async pipeline. Heimdall's ingest service (which uses Celery) SHALL be bridged to the Quanta NATS bus via a Nautilus-side adapter so Nautilus doesn't operate a parallel RabbitMQ cluster. Celery tasks remain an implementation detail inside Heimdall; Nautilus sees only bus events.
NFR-157	Onboard hardware floor. Vessels SHALL meet minimum Heimdall-module hardware: 8 CPU cores, 16 GB RAM dedicated to the module, OR NVIDIA L4 (24 GB) / equivalent small GPU. Feeds OQ-13 hardware-SKU standards. Vessels not meeting the floor cannot run the onboard module and are not Phase-4-deployable.
NFR-158	Regional topology (Phase 5+ multi-tenant). Shore SafeSpace analysis SHALL run in-region per tenant — an EU tenant's SafeSpace verdicts are computed in EU shore Heimdall; a US tenant's in US shore Heimdall. Shore Enterprise / Studios / narrative-flow / sentiment analytics MAY consolidate into a single region under an SCC + Transfer Impact Assessment, exchanging metadata only (hashes, embeddings, classification results, aggregated metrics — not raw content). Per-region shore Heimdall is added as each new tenant region comes online.
NFR-159	Per-jurisdiction reporting routing. CSAM + child-safety reports SHALL be routed to the correct hotline per tenant home region (NCMEC / IWF / BKA / eSafety Commissioner / INHOPE member). Configured at tenant provisioning; verified in a go-live checklist; tracked in the Nautilus tenant registry.

6.15 Media delivery (IPTV + VOD)

ID	Requirement
NFR-170	Media delivery SHALL use HTTP adaptive streaming — HLS as the primary packaging, DASH as secondary (for Widevine-native Android and some smart-TV platforms). No native multicast / RTP / proprietary IPTV protocols in the app-layer stack.
NFR-171	Per-vessel origin cache — Nginx + Varnish (or functional equivalents) deployed onboard; cache serves all cabin TVs, iTV PWA, kiosks, and mobile clients from a single upstream fetch per segment. Shore backhaul scales with distinct content requested, not with viewer count per channel.
NFR-172	Packaging pipeline — ffmpeg for transcoding + Shaka Packager (or Bento4) for DRM encryption and segment generation. ABR ladder configurable per tenant; default 240p / 480p / 720p / 1080p / 4K profiles.
NFR-173	DRM via standard EME — FairPlay (Safari / iOS / tvOS), Widevine (Chrome / Firefox / Android / most smart TVs), PlayReady (Edge / Xbox / some European smart TVs). No Verimatrix / Irdeto / NDS / other proprietary IPTV DRM in the Nautilus tree.
NFR-174	Target latency — LL-HLS ~2 s end-to-end for live channels where the content source supports it; standard HLS 4–10 s acceptable for non-time-critical content (recorded entertainment, destination content, archived programming). Safety-critical announcements (PA / GA / muster) do NOT ride the IPTV path — they go over the ConnectOne PA/GA channel (Domain 14.F) which has sub-second latency.
NFR-175	Minimum vessel backbone capacity — 10 Gbps per-vessel backbone recommended for unicast-only deployments; 1 Gbps minimum acceptable with a multicast / multicast-ABR fallback layer (see NFR-176). Feeds OQ-13 hardware-qualification requirements.
NFR-176	Multicast / multicast-ABR as optional transport optimization. Vessels with constrained LAN backbone MAY deploy: (a) native multicast delivery with a per-vessel mcast-to-HLS gateway, or (b) multicast-ABR products (Synamedia, Broadpeak, or OSS equivalents) that preserve HTTP semantics at the app layer while using multicast at the transport layer. Neither changes Nautilus app code; both are infrastructure optimizations chosen per-vessel at install time.
NFR-177	Content-provider compatibility — HLS/DASH + EME DRM is the hard requirement for content licensing (coordinates with OQ-19). Legacy-broadcast-only partners (DVB satellite feeds, some older IPTV headend vendors) must re-encode to HLS through the Nautilus packaging pipeline before distribution; pure multicast-to-cabin pipelines are not supported for licensed content.
NFR-178	iTV / cabin smart TV renderer — uses native HLS (on tvOS / webOS / Tizen / Android TV where supported) or HLS.js / dash.js via MSE where native support is absent. No proprietary smart-TV runtime required; the Nautilus PWA renders on any commercial smart TV supporting HTML5 + MSE + EME.

6.16 Signage platform (extended signsync)

ID	Requirement
NFR-180	Domain 15.C signage is delivered by an extended signsync codebase (originating at `~/src2/signsync`; Next.js 15 + PostgreSQL + Drizzle ORM; pre-existing production platform). The CMS core, device-fleet health model, schedule filtering, and composition generation are retained; the Roku-only player coupling, single-tenancy, synchronous-pull integration model, Firebase Auth dependency, and zero-test posture are all rewritten as part of the Nautilus extension (F-D15-81..90).
NFR-181	Signage players SHALL render the Nautilus PWA — no separate bespoke per-player app. Player targets per OQ-18: Samsung Tizen, LG webOS, NUC + Chrome kiosk, BrightSign HTML5-URL mode. The same PWA also renders on cabin iTV (Domain 15.B) and kiosks (Domain 15.A.F-D15-07) — one codebase, three form factors.
NFR-182	Event-driven content, not manual CMS polling. signsync's device-pull model is retained for playlist delivery to screens; upstream, the Nautilus NATS listener layer (F-D15-84) consumes domain events (menu updates, activity schedule, excursion availability, PA/GA alerts, voyage events) and auto-generates / reorders compositions. Operators author templates and rules, not individual static items, for event-driven zones.
NFR-183	Emergency-override priority playlist — GA alerts from ConnectOne (`pbx.{t}.{v}.ga.alert`, ship-pbx spec §5.5) preempt all signage content fleet-wide. Never dropped, never back-pressured (mirrors NFR-154 audit-trail requirements).
NFR-184	Per-vessel signsync deployment onboard (plus optional shore cluster for HQ / multi-vessel coordination). Vessel deployment survives shore-link loss per NFR-88; reconciles on reconnect.
NFR-185	Auth + storage migrated off Firebase to NT Connect stack — Zitadel OIDC (NFR-123) for auth; per-tenant-region object storage (NFR-140) for media; removes external-vendor dependency.
NFR-186	Quality bar before Phase-3 go-live — Vitest unit + integration suite covering the extended functionality, GitHub Actions CI, `postgres_exporter` + Prometheus ServiceMonitor, Hubble flow metrics, per-screen health dashboard in Grafana. signsync's current zero-test, no-CI posture is not acceptable for cruise deployment.

7. Integrations

External system	Direction	Notes
Versonix Seaware / Infor CRS	inbound bookings, profile enrichment	Pluggable adapter per tenant.
Stripe / Adyen	outbound payment authorization & settlement	PCI tokenization; no card data in SPMS.
Port authorities (ENOAD, EU-LISA, national)	outbound compliance submissions	Automated, per-port routing.
GDS (distribution)	outbound (view-only in v1)	No origination.
VSAT / Starlink	transport	SIP trunk + Quanta bus leaf node; Starlink as primary high-throughput tier where available.
Quanta	the bus + AI fabric	All domains publish/subscribe; Quanta both transports events and reasons over them. Replaces NATS JetStream from v0.1.
ConnectOne	bidirectional via Quanta bus	NT Connect comms platform: Cloud PBX (Domain 14.E) + maritime specialization (Domain 14.F) + voice/video transport. SIP signaling with B2BUA / OpenSIPS on the roadmap; WebRTC for media.
CallCraft	AI-voice agents on the Quanta bus (`AGENT_MESSAGES` / `AGENT_RESPONSES`)	AI-voice surface inside ConnectOne — joins calls/rooms as a first-class agent for AI Notes call summaries, voice ordering, concierge intents, AI-guided emergency mustering, telehealth triage.
Heimdall (`heimdall.nooz.ai`)	synchronous REST (sub-second, dynamic batching up to 32 requests / 100 ms per GPU); not a bus subscriber. Bus integration via a Nautilus-side Heimdall-client agent (subscribes to Quanta subjects, calls the REST API, republishes verdicts). Must be fronted by an API gateway (Kong / Envoy) for auth, mTLS, and per-tenant rate limits — Heimdall has no built-in auth.	900M-param DeBERTa-v3-large multi-task model: 56 manipulation techniques, 7 emotion classes, intensity regression, 7 hierarchical categories, document-level propaganda score. Plugins: 8 stealth-propaganda analyzers, 16 narrative-flow patterns, 12 content-safety plugins (Detoxify toxicity, NudeNet v3 NSFW, CLIP violence, CSAM via SHA-256 + PhotoDNA + Thorn Safer with NCMEC reporting, ffmpeg+Whisper+EasyOCR+CLIP video, 4-analyzer grooming detection, Google Safe Browsing URL). 4 audience tiers (COPPA / Teen / General / Relaxed). "At a Glance" summarization (local Gemma 4 — Summary / W5H / Context / Claims / Sources). Signal-to-Noise + 5-Pathway Influence scores. LRU cache 10K / 168h. Optional LLM augmentation (Ollama / OpenAI / Gemini / Claude). Productized lines reused: SafeSpace (single-API content safety), Enterprise (corporate sentiment / crisis), Studios (story-arc analysis for entertainment programming).
Zitadel	OIDC/OAuth2	All services integrate.
~~Relate-360~~	—	Removed as guest-identity inspiration; public site is a consumer family app. See OQ-20 for replacement decision.
Omnichannel messaging providers	bidirectional	SMS, Viber, Telegram, iMessage, WhatsApp via NT Maritime Omni (`*.omni.nettalkmaritime.com`-style addressing); federated to single guest-identity thread.
Martec SMCS or equivalent SMCS	outbound emergency dispatch	Parity with NT Maritime ↔ Cunard Queen Anne integration for crew emergency notification.
BLE wearable + gateway vendor	inbound location stream	Opt-in passenger / crew location, contact tracing, occupancy heatmaps.
Telehealth clinician network	bidirectional video	For shore-side specialty consults beyond onboard medical team.
Cabin GRMS (lighting/HVAC/drapes/safe/minibar/door lock)	bidirectional via per-vessel gateway	KNX / BACnet / DALI / vendor-proprietary; abstracted behind a Domain 15.B.4 adapter. See OQ-16.
IPTV / VOD content (e.g., Swank Maritime or equivalent)	inbound content + license metadata	Linear-channel feeds, on-demand catalog, EPG. See OQ-19.
Digital signage players	downstream	Primary: commercial smart displays (Samsung Tizen / LG webOS); secondary: NUC-class x86 + commercial display for interactive kiosks; tertiary: BrightSign retrofits via HTML5-URL mode. All render the Nautilus PWA. Roku / RPi / Android-box rejected. Managed via extended signsync (§6.16; F-D15-81..90). See OQ-18.

8. Constraints

Technology choices are partially pre-committed by the NT Connect stack — Quanta (bus + AI fabric), Zitadel, ConnectOne (PBX + voice/video transport), CallCraft (AI-voice inside ConnectOne), Heimdall, RKE2/K3s, Harvester HCI, Starlink/VSAT.
Frontends are PWA-first — POS/kiosk/iTV must share the React PWA codebase. Native mobile is React Native. No separate per-form-factor apps.
Offline must not be an afterthought. Every onboard design review asks "what happens with no shore link?" before approval.
No shared schemas between domains. Domain services own their data.
Phasing gates are real. Phase 1 foundation (NATS, Zitadel, K8s, CI/CD, Identity, Reservation) precedes all revenue-producing domains.

9. Assumptions

Quanta, ConnectOne, CallCraft, and Heimdall are available for integration in line with the phasing plan — their teams are NT Connect stakeholders, not external vendors.
At least one cruise operator will serve as launch tenant / anchor customer; their real operational data is the validation case.
Shipboard hardware refresh (tablets, readers, smart TVs, cabin SIP endpoints) is funded per-vessel as part of onboarding each ship.
VSAT bandwidth is sufficient for nominal ship↔shore event streaming; design targets assume degraded/intermittent rather than zero connectivity as the common case at sea.
Regulatory reporting formats (SOLAS, ENOAD, EU-LISA) are stable enough to codify; changes are handled via release, not per-vessel patching.

10. Out of Scope (v1, revisit later)

Native bridge/navigation integration beyond consumption of GPS.
Replacement of upstream CRS.
Full native casino game-engine integration (Nautilus handles cashbook only).
Third-party integrations beyond those listed in Section 7.
Advanced BI / data-warehouse product (analytics are operational, not a separate BI suite).

11. Phasing Summary

Phase	Months	Primary scope	Go/No-go signal
1 — Foundation	1–6	NATS, Zitadel, K8s onshore + first vessel onboard, API gateway, CI/CD, Domains 1–2, mobile skeleton	First ship can do pre-cruise & pier check-in end-to-end
2 — Operations Core	4–9	Domains 3, 4, 5, 6; ConnectOne cabin telephony	First full-vessel go-live with cashless POS + gangway + muster
3 — Revenue Services	7–12	Domains 7, 8, 9; full mobile app; kiosk; iTV	Guest revenue flywheel operational
4 — AI Differentiation	10–15	Quanta Concierge, voice ordering, recommendations, Heimdall sentiment, predictive spend	First AI-native features live with real guests
5 — Enterprise & Fleet	13–18	Domains 10, 11, 12; multi-tenant hardening	Second tenant onboarded on same platform
6 — Scale & Optimization	16–24	Fleet-wide rollout, 5000+ pax tuning, CRS/GDS, regulatory automation	Fleet-scale SLOs met; regulatory reporting automated

12. Competitive Differentiators (targets, not features)

These are the outcomes that justify building Nautilus at all. If a design choice would weaken one of these, reconsider the choice.

Differentiator	Why it matters
AI voice interface native to SPMS	No incumbent has it. Guest speaks, Quanta acts.
Microservices from day one	Legacy monoliths can't match release velocity or partial upgrades.
Commodity hardware, PWA frontends	Kills Oracle MICROS hardware lock-in; lowers TCO significantly.
Integrated security/threat intel (Heimdall)	Unique in SPMS market.
AI as fabric, not plugin	Every domain's events are Quanta inputs, by construction.
Continuous ship↔shore event streaming	Real-time fleet visibility; no batch lag.
Multi-tenant / white-label from v1	Every additional tenant is a config exercise, not a fork.
Unified comms (ConnectOne + CallCraft AI-voice) + SPMS	Emergency, muster, AI voice service requests all coherent.
Post-cruise AI engagement	Extends revenue window; no incumbent does this well.

13. Open Questions

These need resolution before the relevant phase begins.

~~OQ-01 — Quanta bus protocol & contract.~~ Resolved 2026-04-20. Bus = NATS JetStream (NATS v2.10+, -js enabled) — exactly as used in production by Quanta, Related, and ConnectOne / CallCraft. Agent integration follows Quanta's contract as documented at ~/src2/experimental/quanta/chat/05-nats-messaging.md: AGENT_MESSAGES (workqueue retention) + AGENT_RESPONSES (ingest) streams, cross-account JetStream sourcing for tenant isolation, agent JWT carrying type: 'agent', capability validation. Wire protocol, throughput, durability, and ship↔shore federation semantics are whatever NATS JetStream gives us — no custom transport.
OQ-02 — Heimdall API contract. Public marketing surface at heimdall.nooz.ai (© 2026 NT Connect Holdings) documents the engine and plugin set. Need: actual API endpoints, auth model, per-tenant rate limits, latency SLOs at expected Nautilus volumes, schema for content-safety verdicts vs sentiment vs influence scores, GPU footprint required for the 900M-param model (shore-only? per-vessel for offline? quantized fallback?), and onboard / offline behavior when the shore Heimdall is unreachable. Blocks Phase 4 (FR-13, FR-17–FR-20).
OQ-03 — Omnichannel messaging federation. NT Maritime exposes sms / viber / telegram / apple channels via *.omni.nettalkmaritime.com-style addressing. Need: which providers Nautilus reuses vs re-implements, per-channel cost model, regulatory implications (10DLC, sender ID, regional bans), and unified-thread merging rules. Blocks Phase 3 (FR-14).
OQ-04 — BLE wearable + gateway vendor. NT Maritime Health uses BLE wearables + strategically placed gateways (Disney deployment). Need: vendor SKU choice, per-vessel hardware budget, opt-in UX, GDPR posture, retention policy. Blocks Phase 4 (FR-15).
OQ-05 — Telehealth clinician network. Onboard medical is in-house; shore-side specialty consults need a clinician-network partner with maritime / multi-jurisdiction licensing. Blocks Phase 4 (FR-16).
OQ-06 — Cabin TV form factor & input. Choose: COTS smart TV running PWA in browser, smart TV + STB, or smart TV + paired mobile-as-remote. Affects hardware standard NFR-70 and Domain 15.B feature set. Blocks Phase 3.
~~OQ-07 — Document store.~~ Resolved 2026-04-20. Postgres-only for Nautilus. PostgreSQL v17.2 deployed via CloudNativePG (CNPG) operator (inheriting the NT Connect pattern proven in production for Related and Quanta per ~/src2/experimental/related/r360-infrastructure). JSONB handles flexible-schema needs (voyage journal, preferences, menus, excursion catalogs, tenant configs). No document store in the AGPL Nautilus distribution. (Note: MongoDB Atlas is used elsewhere in the NT Connect stack — specifically by Heimdall's article-ingest service for deeply-nested versioned analysis documents — but Heimdall is closed-source, so its SSPL/Atlas licensing doesn't contaminate Nautilus.)
~~OQ-08 — Service mesh.~~ Resolved 2026-04-20. No separate service mesh in Phase 1–3. Cilium v1.16+ is the CNI and carries WireGuard transparent encryption (NFR-101), identity-based CiliumNetworkPolicy authorization (NFR-102), eBPF kube-proxy replacement (NFR-103), and Hubble flow observability (NFR-104) — covering the mesh's day-one value without sidecar tax. App-layer observability comes from OpenTelemetry SDKs (NFR-105). Revisit in Phase 4–5 only if direct service-to-service HTTP/gRPC develops needs Hubble + Kong + OTel + ArgoCD Rollouts cannot satisfy; first option then is Cilium Service Mesh (continues the same CNI), Linkerd as fallback (NFR-109). See §6.11.
~~OQ-09 — API gateway.~~ Resolved 2026-04-20. Kong Gateway (OSS, Apache 2.0) — shore and onboard. Inherits the NT Connect r360 pattern; AGPL-clean; Zitadel OIDC integration via community plugin; DB-less mode onboard to minimize vessel footprint; decK declarative config fits the GitOps pattern. See §6.12. Cloud-native managed gateways (OCI / AWS / Azure) were rejected because they do not run onboard — Nautilus needs one gateway that works shore and onboard, and cloud-managed options only cover shore. A future evaluation of Cilium Gateway API (Envoy-based, already part of the Cilium CNI) is tracked as OQ-25; revisit in Phase 4–5 once Cilium Service Mesh L7 features mature and if consolidation becomes attractive.
~~OQ-10 — Payments.~~ Resolved 2026-04-20. Vendor-agnostic payment-adapter abstraction. Domain 3 (Onboard Accounts & Billing) defines a PaymentProcessor interface; adapters implement it per vendor. Ship with Stripe as the reference adapter (developer experience accelerates Phase 2 velocity; Stripe Connect covers multi-tenant sub-merchant flows; AGPL-compatible Apache-2.0 SDKs). Add an Adyen adapter when a tenant requires it (enterprise cruise lines, APAC-heavy operations, or existing Adyen relationships). Per-tenant adapter choice at provisioning time; Nautilus does not mandate one processor. Payment orchestration layer (Primer / Basis Theory / Spreedly) deferred unless multi-processor routing emerges as a concrete need. Tenant contract model: each tenant is a sub-merchant under its own merchant-of-record relationship (Stripe Connect / Adyen for Platforms), not platform-as-merchant — keeps Nautilus out of money-transmission licensing.
OQ-11 — Launch tenant. Who is the anchor customer? All Phase 1–3 scope decisions are easier with a real operator's data and calendar.
~~OQ-12 — Data residency.~~ Resolved 2026-04-20. Per-tenant single-region pin (Stance A) + data minimization with crypto-erasure + jurisdiction-aware retention (Stance C), layered. Each tenant picks one primary shore region at provisioning (EU / UK / US / AU / SG / BR / LATAM as initial set; more on-demand). GDPR-grade controls as the global default (highest common denominator). Crypto-erasure as the defensible mechanism for non-deletable stores (backups, audit logs, WAL archives). Per-category retention policy service extends NFR-25's passport-only scope to all PII categories. Cross-border transfers use SCCs + adequacy decisions; ship↔shore is a documented controlled transfer. Multi-region per single tenant deferred to Phase 5+ — architecture builds the region-pinning primitive in Phase 1, exercises it single-region until tenant demand justifies otherwise. Maritime legal layer (flag-state law at sea, port-state law in port, tenant-region law post-sync) is documented in a per-tenant onboarding legal pack — not Nautilus code. Detailed requirements in §6.13.
OQ-13 — Hardware standards. Tablet / reader / smart-TV / SIP-endpoint / wearable / gateway SKUs.
OQ-14 — CRS adapters at launch. Deferred 2026-04-20: a CRS adapter interface spec is not authored until real CRS API documentation is in hand (Versonix Seaware developer-portal access, sample anonymized booking payloads from a willing operator, or OpenTravel Alliance OTA_Cruise schemas as a floor). Premature design risks baking in wrong assumptions from general hospitality knowledge that won't survive contact with a cruise-specific API. Unblocking strategy: Domain 2 scaffolds against a MockCRSAdapter (F-D2-01a) that generates representative booking events for development, CI, and first-vessel dry-run testing. The real CRSAdapter interface and first reference adapter (almost certainly Versonix) get authored in Phase 2 once one of the information sources above is available. Promoted to Tier-C spec (docs/integrations/crs-adapter.md) at that point. Related to OQ-24 (interface-spec authoring queue).
OQ-15 — Regulatory reporting depth. Which jurisdictions' reports are v1 vs later?
OQ-16 — Cabin GRMS integration. Domain 15.B.4 assumes cabin lighting / HVAC / drapes / safe / minibar / door lock are reachable from the iTV via a Guest Room Management System adapter. Need: vendor / protocol choice (KNX, BACnet, DALI, vendor-proprietary), per-cabin retrofit cost, whether new-build vessels and existing vessels share the same adapter, and the abstraction the PWA renders against. Blocks Phase 3 (Domain 15.B.4).
~~OQ-17 — IPTV transport.~~ Resolved 2026-04-20. Unicast HLS / DASH with per-vessel origin cache as the Nautilus default. Chosen for operational simplicity, standard EME DRM (FairPlay / Widevine / PlayReady), and single-pipeline-matches-PWA-pillar — not because multicast is architecturally incompatible with PWA or BYOD (multicast-to-unicast gateways solve both). Vessels with constrained backbones MAY deploy multicast or multicast-ABR (Synamedia / Broadpeak / OSS equivalents) as a transport-layer optimization without changing the app layer. Default ABR ladder + LL-HLS target latency ~2 s for live content (standard HLS 4-10 s acceptable for most cruise content). See §6.15. Coordinates with OQ-19 (VOD / IPTV content licensing) — content partners must support HLS/DASH + EME.
~~OQ-18 — Signage hardware standard.~~ Resolved 2026-04-20. Primary: commercial smart displays running the Nautilus PWA natively (Samsung Tizen, LG webOS, Philips). One unit per screen (display + runtime combined); commercial-grade warranty; vendor fleet management (Samsung MagicInfo / LG SuperSign) or direct PWA URL. Secondary: NUC-class x86 + commercial display for interactive kiosks where touch + heavy JS + full Chrome matters (wayfinding, guest-service interactive). Tertiary: BrightSign retained for retrofits where already deployed — point at Nautilus PWA URL; do not buy new. Rejected: Raspberry Pi (not fleet-commercial), Android signage boxes (quality variance too high for 200-vessel operations), Roku (consumer-oriented; signsync's current coupling is a liability). Platform: extended signsync (see §6.16, F-D15-81..90) hosts the CMS + device-fleet-health model across all primary/secondary/tertiary player targets.
OQ-19 — VOD / IPTV content licensing. Maritime film/TV licensing is not the same as consumer streaming — confirm content partner (Swank Maritime / equivalent) and whether catalog is fleet-wide or per-tenant.
~~OQ-20 — Guest-identity / CDP baseline.~~ Resolved 2026-04-18: option (c) — design Domain 1 from scratch, with inspiration drawn from the four Relate pillars (Connection Mapping, Relationship Discovery, Story Sharing, Authentic Identity / no-noise). Realized as Domain 1.B (relationship graph), 1.C (voyage journal & memories), 1.D (trust principles). Confirmed 2026-04-20 by code review of ~/src2/experimental/related/related-backend — the real relatedlabs-api (v1.9.36) is a genealogy + family-social product (deep FamilySearch integration, only friend / block edges, single-tenant, consumer-grade privacy). Not suitable as a direct baseline; the pillar-level inspiration remains the right framing. Reusable patterns: Postgres + Sequelize schema discipline, Circle + role + membership model (adaptable for crew/guest hierarchy), NATS cross-pod pub-sub, Helm + ArgoCD deployment boilerplate.
~~OQ-21 — Heimdall onboard / offline strategy.~~ Resolved 2026-04-20. Topology 4: shore full + onboard quantized-safety-tier. Shore runs the full 900M-param DeBERTa-v3-large FP16 + all plugins + narrative-flow engine + Gemma-4 "At a Glance" + Enterprise / Studios tiers. Onboard runs an INT8-quantized SafeSpace-only module (CSAM, grooming 4-analyzer, NSFW, toxicity, URL scanning, profanity) on CPU or small GPU (NVIDIA L4-class, ~$2-3k per vessel vs ~$15-20k for A100). CSAM and grooming (FR-18, FR-19) run onboard regardless of shore link — legally defensible. Everything else (narrative flow, influence, sentiment, summaries) runs shore-side on reconnect. Onboard module is closed-source Tier B; Nautilus calls it through a published Tier-C interface. See NFRs 150–157 (§6.14). Celery-broker question for ingest's async pipeline: resolved by bridging to NATS via a Nautilus-side adapter — no separate RabbitMQ in the Nautilus tree.
~~OQ-22 — Tier-A licensing finalization.~~ Resolved (subject to legal sign-off) 2026-04-20. Per-artifact licenses for the Tier-A open-source releases: Bus + agent contract (and SDK helpers) → Apache 2.0 (matches NATS upstream, Kong, cloud-native ecosystem default; explicit patent grant; trademark clause covers Quanta / ConnectOne marks). Signal-Protocol library + reference SDKs → AGPL-3.0-with-linking-exception (the libsignal pattern — crypto-community consensus; strong copyleft on library, permissive on linked apps; matches the reference implementation to avoid gratuitous divergence). PSI contact-discovery module → Apache 2.0 (matches Google's private-set-intersection reference; standard for crypto primitives; patent grant essential for PSI). Nautilus-the-application remains AGPL-3.0 (Section 15); Tier-C specs CC BY 4.0; conformance harnesses Apache 2.0 (Section 14). Still required: licensing-attorney sign-off on the AGPL-linking-exception wording + CLA alignment before first publish.
~~OQ-23 — Crypto-audit vendor & budget.~~ Resolved (framework) 2026-04-20; vendor selection remains operational. Vendor shortlist: Least Authority (NL) + Trail of Bits (US) paired as primary; NCC Group (UK/US) fallback. Least Authority leads PSI (EU jurisdiction helps GDPR posture; prior Zcash / MobileCoin / Signal work); Trail of Bits takes Signal-Protocol + integration (larger capacity; strong C++ review). Cure53 considered but declined on capacity; boutique Web3-chasing auditors rejected (specialist bias mismatch). Three-phase scope: (1) PSI module — timing / cache / protocol correctness, 4–6 wk audit + 2 wk remediation, ~$60–120k; (2) Signal-Protocol library — Double-Ratchet / X3DH / key-derivation / session-store atomicity / test-vector compliance, 6–8 wk + 2–3 wk, ~$100–180k; (3) multi-tenant isolation + agent JWT lifecycle (10-year token lifetime flagged for review) — cross-account JetStream boundary, 3–4 wk + 2 wk, ~$50–100k. Plus ~20–30% remediation-reaudit contingency. Realistic total: $250–400k (earlier $100–300k estimate was low). Timeline: ~8–9 months from quote-request to all three audits complete. Bus + agent contract (Apache 2.0) can publish on a general code-review basis without specialist crypto audit. Operational next steps: source quotes from all three vendors; negotiate SOW; execute Phase 1 (PSI) first. Blocks Tier-A #2 and #3 publishes; does not block Tier-A #1.
OQ-24 — Interface-spec authoring queue (Tier C). Ship-PBX spec drafted (docs/integrations/ship-pbx.md). Next candidates in priority order: (i) Heimdall content-safety API; (ii) CallCraft agent contract (extends the Quanta agent contract with voice/video-session semantics); (iii) ConnectOne E911 + PA-GA + muster signaling; (iv) Tier-B Quanta keys-service protocol; (v) iTV GRMS adapter contract (OQ-16). Each spec takes 1–2 weeks to author + review. Publish as ready; no blocking dependencies. CRS adapter spec is explicitly NOT on this queue (see OQ-14) — deferred until real CRS API docs are available to validate against.
OQ-25 — Future evaluation of Cilium Gateway API as Kong replacement. Kong is the Phase 1–3 gateway (OQ-09). Cilium Gateway API (Envoy-based, already part of the Cilium CNI — NFR-100) is architecturally attractive for Phase 4–5 consolidation: unified CNI + gateway data plane, eBPF-accelerated, Hubble observability, no extra component. Evaluate when: (a) Cilium Service Mesh L7 features mature past where they are in 2026; (b) HTTP/3 or gRPC-heavy workloads emerge where Envoy's protocol coverage earns the migration; (c) Kong Enterprise-feature gating creates meaningful friction. No decision required before Phase 4.
~~OQ-26 — Heimdall region strategy.~~ Resolved 2026-04-20. Launch: single-region shore Heimdall in the launch tenant's home region; onboard quantized SafeSpace module on every vessel (per OQ-21). Phase 5+ (multi-tenant, multi-region): evolve toward the hybrid — per-region shore SafeSpace as each new tenant region comes online (so safety-critical analysis stays in-region); single consolidation region for Enterprise / Studios / narrative scoring with metadata-only cross-border flow (content stays in tenant region; only hashes, embeddings, classification results, and aggregated metrics cross). SCCs + Transfer Impact Assessments cover the metadata flow. See NFR-158 (§6.14).

14. Integration Architecture (Open Primitives / Closed Services / Documented Interfaces)

Nautilus and its NT Connect sibling products follow a deliberate three-tier model. Understanding it is required to correctly scope Nautilus code, licensing, and third-party integration patterns (especially retrofitting onto vessels with legacy PBX / IT already aboard).

14.1 The three tiers

Tier A — Open primitives (published, permissively licensed)

NATS JetStream + Quanta agent contract — stream definitions (AGENT_MESSAGES workqueue + AGENT_RESPONSES ingest), agent JWT schema, capability validation, cross-account JetStream sourcing for tenant isolation. Apache 2.0.
Signal-Protocol crypto library — X3DH + Double Ratchet + session management + key-bundle format, compatible with what the closed Quanta keys-service + messaging-service run in production. Reference SDKs in TS / Kotlin-Java / Swift. AGPL-3.0 with linking exception (libsignal pattern; OQ-22 resolved).
PSI (Private Set Intersection) contact-discovery module — C++ native module + protocol spec. Apache 2.0 (OQ-22 resolved; matches Google's PSI reference).

Tier B — Closed services (commercial NT Connect products, integrated via Tier-C interfaces)

Quanta application services — auth, messaging-service, keys-service, websocket-gateway, push, media, group, admin, video, contact-discovery service wrapping the open PSI module.
ConnectOne — full Cloud PBX + voice/video transport, maritime specialization.
CallCraft — AI-voice surface (agents) inside ConnectOne.
Heimdall — DeBERTa-based content safety, sentiment, analytics (see Section 7 / FR-13 / FR-17–FR-20).

Tier C — Documented interfaces (published, CC BY 4.0 for specs + Apache 2.0 for reference stubs and conformance harnesses)

Every bus-fronted or API-fronted closed service exposes a published interface spec so third parties can (a) integrate legacy systems against Nautilus / Quanta without replacing them, (b) build compatible open-source alternatives where desired, or (c) buy the NT Connect managed implementation off-the-shelf.

Published Tier-C specs include — at minimum:

Bus subject contracts (event schemas, headers, ordering / delivery semantics per stream).
REST / gRPC API contracts where the closed service exposes one.
JWT claim schemas for bus auth (per integration type — agent, PBX bridge, admin, etc.).
Conformance test harness so an integrator can run their implementation against a fake closed service locally.
Reference stubs (minimal open implementations) for development and CI.

The first Tier-C spec, Ship-PBX Integration, is published at docs/integrations/ship-pbx.md. Additional specs land in docs/integrations/ as each integration surface is opened.

14.2 Why this split

Open the primitives where trust is cryptographic. Signal-Protocol + PSI are only credible when auditable. Keeping them closed caps Quanta's addressable market (regulated industries, privacy-sensitive verticals, government) and undercuts the security story.
Keep the service implementations where the commercial moat is operational. Running the auth + keys + messaging + media services at scale, with SLA, uptime, security-response, is where NT Connect earns. Opening the service code without opening the operational capability just lets competitors copy the easy parts.
Publish the interfaces where the integration pattern matters. Most cruise vessels arrive with a pre-existing PBX, a pre-existing iTV head-end, a pre-existing signage system. Nautilus deployments are retrofit-first in practice; greenfield is the exception. Tier-C specs make retrofit a day of work instead of a quarter.

14.3 Nautilus's relationship to the tiers

Nautilus source is AGPL-3.0 (see Section 15) — application code, not library code.
Nautilus depends on Tier-A libraries (Apache / MPL / AGPL-with-linking-exception): it imports them; AGPL-Nautilus using Apache-licensed libraries is a standard, non-controversial pattern.
Nautilus integrates Tier-B services via Tier-C interfaces. No proprietary Tier-B SDKs in the Nautilus tree; all integration is at the published-spec level so forks that swap in alternative Tier-B implementations remain possible.
Tenants choose their Tier-B operators. Default is NT Connect's managed services. Alternatives: bring-your-own-PBX (via docs/integrations/ship-pbx.md), bring-your-own-AI-voice (via the agent-contract spec), bring-your-own-Heimdall-equivalent (via the content-safety API spec).

14.4 Publishing sequence

Tier-C specs and Tier-A libraries publish in this order (lowest risk first):

Tier-C specs — interface definitions only. No crypto risk, no code-audit dependency. Can ship as soon as authored + reviewed.
Tier-A #1 — bus + agent contract — small, standards-play, Apache 2.0.
Tier-A #3 — PSI module — after specialist crypto audit (Trail of Bits / NCC Group / Least Authority class).
Tier-A #2 — Signal-Protocol library — largest; publish after audit + SDK maturation across at least three languages (TS, Kotlin-Java, Swift).

Tier-B services remain closed throughout.

14.5 Implications for OQ tracking

OQ-01 (bus) is resolved (Section 13): NATS JetStream, Tier A.
OQ-02 (Heimdall API contract) — the Tier-C spec for Heimdall lands in docs/integrations/heimdall.md when drafted.
New: OQ-22 — Tier-A licensing finalization. Signal-Protocol library: AGPL-with-linking-exception vs MPL-2.0 decision; PSI module: Apache vs MPL. Blocks first Tier-A release.
New: OQ-23 — Crypto-audit budget and vendor. Trail of Bits / NCC Group / Least Authority class. Blocks Tier-A #2 and #3.
New: OQ-24 — Interface-spec authoring queue. Ship-PBX is drafted (docs/integrations/ship-pbx.md); next candidates: Heimdall content-safety API, CallCraft agent contract, ConnectOne E911 / PA-GA signaling, Tier-B Quanta keys-service protocol.

15. Licensing

Nautilus source is released under a dual-license model:

15.1 Open-source license — AGPL-3.0

All Nautilus source code (every domain service, the React PWA, the React Native app, the iTV / kiosk / signage clients, infrastructure-as-code, Helm charts, documentation) is published under the GNU Affero General Public License, version 3 (AGPL-3.0).
AGPL applies to network use: any organization deploying a modified Nautilus instance and offering it as a network service to third parties (passengers, crew, other tenants) must publish the corresponding modified source under the same AGPL-3.0 terms.
Nautilus consumers (cruise operators, system integrators, partners) may run unmodified Nautilus internally without source-disclosure obligations beyond what AGPL otherwise requires.
Third-party dependencies must be license-compatible (no GPLv2-only or proprietary components in the AGPL distribution).

15.2 Commercial license (optional)

A commercial license is offered by NT Connect Holdings to tenants who:
- want to ship a closed-source derivative (white-label SaaS, embedded OEM, vessel-firmware bundles),
- cannot meet AGPL's network-use disclosure obligations (e.g., proprietary integrations whose source they cannot publish), or
- require commercial terms (indemnification, support SLA, escrow, contractual roadmap influence).
The commercial license is identical in code — same software, different rights — and includes commercial support, SLA, security patch guarantees, and indemnification.

15.3 Contributor License Agreement (CLA)

External contributors sign a CLA assigning copyright (or a sufficient license back) to NT Connect Holdings so that the dual-license model remains viable.
All inbound contributions land under AGPL-3.0; commercial relicensing is performed by the project maintainer.

15.4 NT Connect product dependencies

Nautilus integrates Quanta, ConnectOne, CallCraft, and Heimdall as sibling NT Connect products via documented APIs.
Whether those sibling products are themselves AGPL, commercially licensed, or hosted SaaS is out of scope for Nautilus's license; integration contracts (API + bus schema) are stable and documented.

15.5 Trademark

"Nautilus", the Nautilus marks, and the cruise-operator white-label brand assets are not licensed under AGPL — they remain owned by NT Connect Holdings (or the respective tenant for their own brand assets).

15.6 Why dual-license

AGPL maximizes ecosystem trust, third-party scrutiny, and adoption by integrators / academics / small operators.
The commercial license keeps the path open for large operators with proprietary go-to-market constraints, and funds ongoing development.

15.7 Pre-publish specialist audit commitment

The Signal-Protocol library and PSI contact-discovery module (Tier-A cryptographic code per §14) SHALL undergo independent specialist audit before first public release.
Expected audit partners: Least Authority + Trail of Bits as paired primary; NCC Group as fallback (OQ-23 vendor shortlist).
Audit scope covers: PSI timing / cache / side-channel analysis; Signal-Protocol wire-format compatibility + Double-Ratchet / X3DH / key-derivation correctness + session-store atomicity + test-vector compliance; cross-account JetStream multi-tenant isolation; agent JWT lifecycle (the current reported 10-year token lifetime is flagged for remediation before publish).
Budget commitment: $250–400k across three phases + remediation re-audits (OQ-23).
Audit findings + remediation history SHALL be published alongside the library releases — public audit reports are a marketing asset and a condition of credibility for Signal-Protocol-based crypto.
Bus + agent contract (Apache 2.0, OQ-22 artifact (a)) does not require specialist crypto audit prior to publish; general code review + security-disclosure policy suffice.

16. Glossary

Term	Meaning
SPMS	Shipboard Property Management System.
CRS	Central Reservation System (upstream of SPMS).
GDS	Global Distribution System (travel-industry distribution).
RevPax	Revenue per passenger.
OPI	Oracle Payment Interface (Oracle SPMS payments).
CMMS	Computerized Maintenance Management System.
FMS	Fleet Management System (Oracle HQ analytics).
KDS	Kitchen Display System.
PWA	Progressive Web App.
SOLAS	International Convention for the Safety of Life at Sea.
MARPOL	International Convention for the Prevention of Pollution from Ships.
STCW	Standards of Training, Certification and Watchkeeping for Seafarers.
ENOAD	Electronic Notice of Arrival / Departure.
ILO	International Labour Organization (working-hours regime for seafarers).
EU-LISA	EU agency for large-scale IT systems (immigration / border).
OIDC / OAuth2	Identity-federation protocols (Zitadel speaks these).
VSAT	Very Small Aperture Terminal (ship satellite link).
B2BUA	Back-to-Back User Agent (SIP topology). On ConnectOne's roadmap for the signaling layer (likely alongside OpenSIPS).
ConnectOne	NT Connect's comms platform (working name — may change): Cloud PBX (Domain 14.E) + maritime specialization (Domain 14.F) + voice/video transport. Umbrella under which CallCraft, the AI-voice surface, runs.
CallCraft	AI-voice surface inside ConnectOne. Hosts AI-voice agents that join calls/rooms for AI Notes, voice ordering, concierge intents, AI-guided emergency mustering, telehealth triage. Integrates with Quanta via `AGENT_MESSAGES` / `AGENT_RESPONSES` streams on NATS JetStream.
HCI	Hyperconverged Infrastructure (Harvester is NT Connect's HCI platform).
GitOps	Git repository as source of truth for deployed state (ArgoCD).
MoSCoW	Must / Should / Could / Won't prioritization scheme.
Quanta	NT Connect AI fabric and message bus: every domain event flows through Quanta and is observable to AI by construction.
Heimdall	NT Connect platform (`heimdall.nooz.ai`). 900M-param DeBERTa-v3-large multi-task model + 12 content-safety plugins + narrative-flow + influence scoring. Productized as TruthGuard, SafeSpace, Enterprise, Studios, Civic Shield, Defense, SIGINT-I, Market Intelligence, Campaign Intelligence. Nautilus consumes SafeSpace, Enterprise, and Studios surfaces.
SafeSpace	Heimdall productized content-safety stack — single API, 12 plugins, 4 audience tiers (COPPA / Teen / General / Relaxed).
At a Glance	Heimdall summarization feature (local Gemma 4): Summary, W5H (Who/What/When/Where/Why/How), Context, Claims, Sources Cited. Backs Nautilus "AI Notes" call summaries.
CSAM	Child Sexual Abuse Material. Heimdall detects via SHA-256 + PhotoDNA + Thorn Safer; US tenants must wire automated NCMEC reporting per 18 USC 2258A.
COPPA / KOSA	US Children's Online Privacy Protection Act / Kids Online Safety Act — drives Heimdall's COPPA tier and kids-profile gating in Nautilus.
5-Pathway Influence Score	Heimdall composite metric: Overt Propaganda, Stealth Manipulation, Emotional Manipulation, Balanced Manipulation, Information Quality (max across pathways, scaled 0-100).
PBX	Private Branch Exchange — a phone system that switches calls between internal extensions and to/from external lines. "Cloud PBX" runs the switching logic in software in a managed cluster.
IVR	Interactive Voice Response — touch-tone or voice menu (Nautilus's "Virtual Receptionist").
ATA	Analog Telephone Adapter — bridges a legacy analog handset to a SIP network.
DID	Direct Inward Dialing — an external phone number routed to a specific internal extension.
DECT	Digital Enhanced Cordless Telecommunications — legacy cordless handset standard, replaced on Cunard Queen Anne by NT Maritime CrewApp.
E911	Enhanced 911 — US emergency calling with automatic location identification; Nautilus implements Kari's Law (no prefix needed to dial 911) and dynamic E911 routing (location updates when extensions roam).
TDM	Time-Division Multiplexing — legacy telco signaling that PRI handoff translates to/from SIP.
PRI	Primary Rate Interface — legacy ISDN trunk interface used for Avaya / pre-IP PBX bridging.
BLF	Busy Lamp Field — visual presence indicator on a phone showing which extensions are in use.
MOH	Music On Hold.
SRTP	Secure Real-time Transport Protocol — encrypted media for SIP calls.
PA / GA	Public Address / General Alarm — ship-wide announcement and safety-alarm tiers; GA preempts PA and all other audio.
TALK app	NT Connect mobile softphone (iOS + Android) — calls over Wi-Fi / LTE / 5G; no roaming charges.
PBX App	NT Connect mobile business client (iOS + Android) — provisions a PBX extension on a phone.
RoboAgent	NT Connect spam-call filter; scores inbound calls 0–100% spam-likelihood and auto-routes likely spam to an attendant rather than voicemail.
AGPL	GNU Affero General Public License — copyleft license whose obligations extend to network use; Nautilus's open-source license (Section 15).
CLA	Contributor License Agreement — external contributors sign one so the dual-license model (Section 15) remains viable.
Omni / omnichannel	NT Maritime's federated messaging layer — single guest identity address resolvable across SIP, SMS, Viber, Telegram, iMessage, etc.
GuestApp	NT Maritime passenger app: voice / video / chat / voicemail over ship WiFi, white-label per tenant.
CrewApp	NT Maritime crew app: role-based voice / push-to-talk / chat (Cunard Queen Anne replaced DECT with this).
iTV	Interactive cabin TV; in Nautilus, the same React PWA in TV form factor and a first-class video-call endpoint.
Telehealth	Remote medical consultation (video / chat) between guest or crew and clinician (onboard or shore).
Contact tracing	BLE-wearable + BLE-gateway derived close-contact graph used to identify exposure following a confirmed case.
BLE	Bluetooth Low Energy.
SMCS	Safety Management & Compliance System (e.g., Martec SMCS — NT Maritime integrates with it).
STOMP	Streaming Text Oriented Messaging Protocol — message-broker wire protocol observed in NT Maritime's stack; relevant to OQ-01 if Quanta layers over it.
VADER	Valence Aware Dictionary and sEntiment Reasoner — lexicon/rule-based sentiment scorer used by Heimdall (returns `compound` score per message).
Starlink	SpaceX LEO satellite connectivity, named NT Maritime tier; primary high-throughput VSAT option where licensed.