A fielded publisher. A new recipient.
A sensor service exposes observations over an existing HTTP interface. Another operator’s mission application needs those observations in its own format. A maintenance application has a valid identity, but has no reason to participate in this exchange.
Sensor operator
Fielded observation publisher↓ Existing HTTP feed
↓ Local HTTP
Authenticated, encrypted connection
Mission operator
↓ Local HTTP
Receiving mission applicationThe application contract
An authorized adapter reads the publisher’s output, maps the agreed fields and sends the result to the receiving interface. The teams define units, schema versions, error handling and what to do with incomplete observations. The adapter processes plaintext and implements application-specific handling rules.
Its QHx identity identifies the registered adapter workload. If the original feed lacks authenticated origin, the adapter does not turn it into a cryptographically signed statement by the sensor.
The operator’s controls
Each operator configures identity issuance and accepted trust material. The proxies mutually authenticate their connection using TLS. The receiving proxy accepts the adapter’s identity and refuses the maintenance identity. Local listeners and direct routes to the applications need their own protection.
Evaluation observes the permitted exchange and the refused connection, including an attempt to bypass the proxy. These are the results to establish for this illustrative integration.
Then the receiving application changes.
The publisher stays in service. A replacement recipient introduces a new interface, identity or deployment environment. The integration team reviews each part of the exchange to determine what needs to change and what can be reused.
| Part of the exchange | Review and update | Potentially reusable |
|---|---|---|
| Application contract | Adapter mapping, output schema and error behavior. | The fielded publisher and its existing interface. |
| Identity and service path | Destination, registrations, accepted peer identities and network rules. | Issuance services, proxy mechanisms and policy structure. |
| Operation | Deployment artifacts, validation and recovery procedures. | The test approach and the team’s recorded operating knowledge. |
A matching API or service identity can reduce the work. After the change, re-test permitted and refused access, credential renewal and the path around the proxy. Examine established sessions separately from new connection attempts.
Inspect the identities and receiving configuration →A selected service for a partner.
A publishing organization wants a partner’s mission application to receive an approved observation product. The sharing arrangement defines that exchange and leaves the publisher’s other services and information outside it.
- Recognize the partner. Permit the application.
- SPIFFE federation lets QHx authenticate identities from the partner’s authority. The service operator separately configures which identities its proxy accepts. Recognizing the authority does not open every service. The teams implement the approved release decision in the publishing application and configure service access.
- Choose what an intermediary can read.
- If a shared broker or archive should carry information without reading it, a separate CABE client integration encrypts each object and obtains keys under the Key Service’s Policy. CABE key access and QHx connection permission are separate decisions.
- Evaluate the intended boundary.
- Test that the approved partner completes the exchange and an authenticated but unapproved application is refused. For object protection, also check that the broker holds ciphertext without a key and that a new, unauthorized recipient cannot obtain the key. The approved sharing arrangement determines where information may be carried, including any required cross-domain mechanism.
Illustrative application pattern
Examine the separate object-protection path →Local operation after reach-back is lost.
The observation service and receiving application still have a local network. Their link to a remote operating site has gone. What remains usable depends on where the required services run, what they depend on and which trust material the peers still accept.
Place the dependencies.
The operator places required application and QHx services locally, provides storage and time, and prepares trust bundles and policy before disconnection. Identify the remote authority or service that becomes unavailable and measure how long each dependency remains usable.
Separate continuity from restart.
Local proxies use the configured paths, policy and accepted trust material. A local issuing service can renew credentials while its own dependencies and attestation path remain available; otherwise operation is bounded by the credentials and sessions the peers still accept. Test a running exchange separately from a node restart, new identity issuance, credential renewal and a fresh key request.
Establish recovery.
Disconnect the remote link while retaining the local network. On reconnection, refresh trust and policy and verify recovery. If the application depends on a queue, also test restart recovery, acknowledgments, duplicates and expiry. An in-memory buffer is not durable delivery.
Illustrative application pattern
Plan local dependencies and recovery →Service evidence
For supported AI interactions, QHx Notary can retain signed request records linked to workload statements. An independent reviewer examines captured content and the signer after the service has stopped. Model correctness and missing captures require separate evaluation.
Request evidence and verification →Configuration authority
QHx signed resources bind a configuration bundle to an accepted signer and version. The destination checks the signature and retained version state before applying it. Test changed content, unaccepted signers, older versions and recovery of that state.
Signed configuration changes →