Standard Operating Procedure // Protocol

SCA Protocol // Matrix

Comprehensive guide to the Shared Crew Access architecture. Learn how to seamlessly share a Mission (Campaign) between a Game Master (Referee) and multiple players in a fully collaborative environment.

Protocol Version 4.3 // SCA Hardened

Architectural Overview

The Shared Crew Access (SCA) Protocol is a high-level operational matrix designed to eliminate hardbound constraints on personnel assignment. Its primary function is to share a Mission (Campaign) between a Game Master (Referee) and multiple players in a fully collaborative environment. By tearing down structural silos, SCA enables rapid, frictionless redeployment of certified crew members across distinct Assets and operations within the same collaborative matrix.

Operative Roles

GM — Campaign Master

The Campaign.user — the account that initialized the mission. Has unconditional control over all mission parameters, asset deployment, player access, and crew shared flags. No permission checks apply.

Player

A registered Nav-Fi³ user who joined the campaign via invite code (NV-XXXXX). Stored as a CampaignPlayer record with isActive = true. Can view campaign assets and operate on them only if also assigned as a Crew Member with the appropriate SCA grants. The GM can suspend or reinstate at any time.

Crew Member

A character assigned to a specific Asset, linked to a Nav-Fi³ user account. The operative layer. Three granular SCA permissions:

  • »SCA Pilot — plot routes and execute jumps
  • »SCA Cargo — manage hold, loot, and trade
  • »SCA Finance — register costs and incomes on the ledger

Captains inherit all three automatically.

01

Cross-Deployment

Phase: MECHANICS

Traditionally, personnel assigned to an Asset were rigidly tethered. The SCA Protocol introduces an abstraction layer allowing personnel, designated as is_shared, to break free from localized limitations:

  • » Pool Elevation: Once authenticated by the Master, a crew member is elevated to a globally accessible pool within campaign parameters.
  • » Instant Transfer: A Master can select any crew member with SCA clearance and immediately re-assign them to a secondary Asset within the fleet.
  • » Zero-latency: Data streams—covering salaries, skill matrices, and deployment history—are synced instantaneously across the holo-console.
02

Security & Visibility

Phase: AUTHORIZATION

Shared access does not bypass master-level security frameworks. It enforces a strict containment field based on explicit campaign signatures.

  • » Campaign Integrity: Personnel are only exposed to assets explicitly sharing the corresponding campaign signatures.
  • » Shielded Modes: Crew members lacking the is_shared flag remain strictly locked and shielded behind their primary Asset's sub-matrix.
SECURITY ADVISORY: Tampering with the `is_shared` flag outside of Master-Only controls will result in terminal de-sync.
03

Personnel Invite

Phase: ESTABLISH

The SCA matrix requires a valid Invite Code for players to join a mission. Masters can manage these codes via the Mission Details interface:

  • » Code Generation: Missions created after v3.8 auto-generate codes. For legacy dockets, use the Generate Code function.
  • » Secure Sharing: Codes are strictly classified. Share them only with authorized crew members to allow them to bind their matrix to the campaign.
04

Operative Roles

Phase: DELEGATION

Nav-Fi³ distinguishes between Structural Ownership and Operative Authority. Crew members can be granted granular access to ship subsystems:

SCA Pilot
Authorized to manage waypoints and execute J-Sync jumps.
SCA Cargo
Full access to cargo hold, loot management, and market trade.
SCA Finance
Permission to register costs and incomes on asset ledgers.

Note: Captains automatically inherit all SCA permissions for their assigned asset.

05

Personnel Control

Phase: ENFORCEMENT

The Campaign Master retains full override authority over any registered personnel. The Suspension Protocol allows revoking a player's active clearance without purging their mission record:

  • » Non-Destructive Lockout: Suspended personnel retain their roster entry and historical data. Their clearance is frozen — not erased.
  • » Full Access Revocation: A suspended player loses all SCA permissions (PILOT, CARGO, FINANCE) and campaign visibility immediately.
  • » Instant Reinstatement: The Master can reactivate suspended personnel at any time, restoring their prior clearance level without re-issuing an invite code.
COMMAND ADVISORY: Suspension takes effect immediately upon toggle. The affected operative will be denied access on their next request without prior warning.

Typical Session Flow

End-to-end sequence from campaign initialization to active crew deployment.

01
GM creates the campaign. An invite code (NV-XXXXX) is auto-generated. The GM shares it via out-of-band channel (chat, table, etc.) with authorized players.
02
Players JOIN via invite code. Each player submits the code through the Join Operations dialog. A CampaignPlayer record is created with isActive = true. They are now visible to the GM as registered personnel.
03
GM adds their Assets to the campaign and assigns Players as Crew Members. Assets (ships, vehicles, etc.) are created and owned exclusively by the GM. From the Mission Details page, the GM selects which of their assets to deploy under this campaign. They then navigate to each Asset's Crew section and assign registered Players as crew members. At this stage assigned players have no operative permissions yet.
04
GM grants SCA permissions to each Crew Member. For each crew assignment the GM selects one or more operative roles: SCA PILOT SCA CARGO SCA FINANCE Captains inherit all three automatically.
05
Player operates within their clearance level. From this point the player can access the Asset's subsystems according to their SCA grants: plot routes, manage cargo, register costs. No other Asset or data outside their clearance is accessible.
!
GM can suspend a Player at any time. Suspension is non-destructive: the CampaignPlayer record is preserved but isActive is set to false. All SCA access is revoked immediately. Reinstatement restores full prior clearance without requiring a new invite code.

Access Flow Matrix

Permission resolution from campaign setup to operative clearance.

GM Player System Decision Blocked Continues
GM

Creates the Campaign, all Assets (ships, vehicles) and sets the session date.

Mission Master
auto-generates
SYS

Invite code NV-XXXXX generated. GM shares it out-of-band.

GM

Adds Assets to the Campaign from Mission Details. This must happen before assigning any crew member.

PLR

Submits the invite code via the Join Operations dialog.

◆ already in campaign?
YES → still active?
Already active
no change
🚫 Suspended
access denied
NO ↓ continues
Player record created
access granted
GM

Creates a Crew character → NPC

PLR

Creates a Crew character → PC

◆ crew available?
🚫 NOT AVAILABLE
Already assigned to another ship
Status: MIA or Deceased
FREE ↓ continues
Not assigned to any ship
status not blocking
GM

Assigns the free Crew character to the Asset. Since the Asset is already in the Campaign with a session date, the character is immediately activated.

GM

Sets operative permissions on each active Crew Member:

CAPTAIN — inherits all SCA PILOT SCA CARGO SCA FINANCE
system resolves clearance
PLR SCA Pilot Plot routes & jumps
PLR SCA Cargo Manage hold & loot
PLR SCA Finance Register costs & incomes
Nav-Fi³ Interface Imperial standard drift lane // Protocol 7.4

© 2026 Nav-Fi³ Open Systems | Certified TAS Peripheral

The Traveller game in all forms is owned by Mongoose Publishing. Copyright 1977 - 2025 Mongoose Publishing. Fair Use Policy Privacy Protocol

Restricted Access Level 4 Clearence Required