Missions
Mission decisions depend on information reaching an application authorized to use it. Different audiences can require different access without a separate copy of every surrounding service.
Mission partner
exchange
In a Mission Partner Environment (MPE), different audiences need different information. A separate stack for each can mean duplicate brokers, service deployments and accounts to maintain. Where the handling environment permits it, approved components can be shared while access remains distinct.
Consider two synthetic reports at the same classification level, inside an environment approved to handle both. The information authority establishes different handling attributes for Report A and Report B. An authorized publisher applies those attributes and protects each report through a separate CABE client integration.
The common approved broker carries both encrypted reports without payload-decryption keys. QHx establishes participating workload identities and governs their configured service connections. CABE’s Key Service separately authenticates its clients and decides which keys they may obtain under its policy.
Application A is authorized for Report A; Application B for Report B. Membership in the same network gives neither application permission to read the other report. Handling attributes inform the Key Service’s decision; labels alone do not enforce access.
One repository. Two release audiences.
Report A and Report B share a classification level and have different approved audiences.
- Encrypted objects
- Key requests / responses
- Identity / connection control
Authorized publisher
Applies authority-established handling attributes, then encrypts through CABE.
Common approved broker / repository
Carries encrypted Report A and Report B.
No payload-decryption keys in this CABE path.
Recipient A
Approved for audience Alpha. Receives both encrypted objects.
Receiving an object does not give this application its key.
Key Service
Authenticates its client and applies key-access policy.
- Recipient A requests Report A’s key
- Permit — key released
- Recipient A requests Report B’s key
- Refuse — no key released
Recipient A’s decrypting endpoint
Report A plaintextAvailable here with the released key.
Report B remains encrypted; no key was released for that request.
QHx identity authority
Configured workload credentials
QHx proxy connection controls
Configured service peers and paths
An accepted identity or service connection does not grant a report’s key. CABE key access is a separate decision.
A different recipient
Replacing Application B can require a new adapter mapping, workload identity or registration, service and key-access policies, and approval from the relevant information authority. Reusing an enforcement mechanism does not transfer the former application’s permissions.
The approved broker, issuance services, Key Service and proxy mechanisms can remain in place when their interfaces and handling arrangements still fit. The teams review the changed application contract and release rules instead of assuming every surrounding service must be implemented again.
Publisher release decisions, permitted storage and transport, and required boundary controls remain. Connection permission, release of key material and permission to perform an application action are separate decisions. A key-access decision is not a record of every subsequent local decryption.
Sensor-to-command
integration
An onboard mission application—or an authorized AI workload supporting it—needs observations exposed by an existing sensor-service interface. An adapter can bridge that interface to the application’s agreed format.
QHx supplies workload credentials and proxy connection controls around the exchange. The receiving service permits the adapter’s identity and refuses an unapproved participant. The adapter’s credential identifies that workload; it does not authenticate an original sensor that supplies no origin evidence.
Schema versions, units, missing values and stale observations remain part of the application contract. Replacing the receiver can change how observations are interpreted, not just where they are sent. The integration team reviews that contract and the identities and rules around it.
Receiving observations does not grant permission to issue a tasking request. The application enforces which resources and actions each participant may use.
Replace the receiver. Review the contract.
The publisher stays; the receiving interface, mapping and permitted identities are reviewed.
Sensor operator
Existing observation publisher
Existing HTTP observations
Existing integration adapter
Schema, units, missing and stale values
QHx client proxy
Adapter workload identity
encrypted connection
Configured proxy-to-proxy path
Mission operator
QHx server proxy
The connection gate permits the configured adapter identity.
Replacement mission application
Interprets observations; enforces resource and action permissions.
and application permissions
What can stay: the publisher, its existing interface, issuance services and proxy mechanisms, where the revised arrangement still fits.
What needs review: adapter mapping, receiving interface, identities, accepted peers and application permissions. The adapter’s identity does not authenticate an original sensor with no origin evidence.
Onboard and
forward computing
A shipboard or forward installation needs compute close to its applications and observation sources. Power, thermal management, environmental protection, mounting and connectivity shape what can be installed.
Blackhole provides a turnkey QHx appliance or rugged compute for another workload. Place the application and required QHx services at the installation; configure the issuing authority, trust material and service paths for that environment.
Local placement and operation without reach-back are different properties. Continued processing depends on the particular workload, accepted credentials and available services. Starting again, renewing an identity or obtaining a new object key can require dependencies a running exchange has not yet needed.
For supported interactions, optional QHx Notary records retain selected requests and responses for later examination. The record’s capture scope and trust material determine what a reviewer can verify; it does not establish an AI answer’s correctness.
For controlled changes at the installation, signed resources provide a separate signature and version-checking path.
Compute close to the application.
Blackhole · Orin Nano configuration render
Local observation exchange
Local network remains available
- Application services
- Publisher, adapter and receiving application
- QHx connection services
- Client and server proxies
- Prepared locally
- Accepted credentials, trust bundles and connection policy; required storage and time
Remote issuing authority
Remains remote in this configuration. Credential renewal over this link is unavailable.
The running exchange depends on credentials and sessions the peers still accept. Restart, renewal and recovery require their own dependency review.