Deployment starts with the operating boundary.
Technical authorities and information owners should select a product profile against infrastructure, identity, information handling and assurance requirements. Confirm every option for the release being evaluated.
Profiles by product
CORTEX: Local, Team, Edge, Secure, Enterprise and Hybrid profiles described by AIC. NERVE: Local, Disconnected, Private Cloud and Approved Cloud. GTK 2.0: secure workstation, team server, disconnected or edge, customer private network and private cloud. PAL.NET: SDK inside the customer’s application estate, supplied through licensed feeds or offline bundles. These descriptions require release-specific confirmation.
Connectivity and residency
Offline availability, a supported disconnected profile and an air-gapped approval are different requirements. Identify resident data, models, licences and identity dependencies. Data location and permitted transfers are agreed deployment decisions; the portfolio name is not a residency guarantee.
Identity, retention and audit
Confirm user and workload identities, denied-access behaviour, dataset and purpose restrictions, retention, deletion, logging and export authority. For report workflows, identify the accountable reviewer and release decision. Test behaviour when access changes after a record has been cited.
Encryption and assurance evidence
Algorithms and configuration follow the approved product profile. GTK’s published cryptographic integration requires product-owner verification before precise implementation claims are used. Product capability does not establish accreditation, handling-level authorisation or blanket compliance.
Review checklist
Identify the organisation and technical authority, network boundary, protective marking, approved integrations, audit requirements, retention owner and incident-support expectations. Request relevant evidence through approved channels. Do not send classified architecture, credentials or operational datasets through the marketing enquiry route.
Assessment delivery and exchange are different assurance scopes
PULSE’s current specification describes an area-assessment service with an intended OFFICIAL-SENSITIVE handling ceiling. That is a design limit, not accreditation. Agree the customer marking scheme, hosting, recipient access, review and release arrangements, retention and delivery record. Do not infer SECRET or higher handling from the Constellation portfolio.
LINC’s intended exchange architecture requires current peer identity and applicable policy before a message is forwarded. Across domains, export and import are separate decisions through an approved gateway. Source authority, originator approval and the destination’s acceptance remain distinct responsibilities.
Cross-domain use depends on independently approved gateways, policies and accreditation for each named flow.