LINC product branding

Articles

LINC: governed message exchange for intelligence systems

Marketing and Outreach Team

5 Min Read

Explore LINC messaging for intelligence systems, with named contracts, policy checks, durable acceptance, recovery and evidence of destination delivery.

Intelligence systems need to exchange information while retaining clear responsibility for its handling and use. A message crossing a network can affect a report, an assessment or a receiving applicationโ€™s business process. The exchange needs to explain who authorised it, what was accepted and whether the destination received it durably.


LINC, Linked Intelligence Network Communications, is AICโ€™s governed message-exchange layer, available now for customer demonstrations. The LINC product overview explains its responsibilities for protocol, routing and transfer state. Each connected product retains authority over its own information and decisions.


Start with a named exchange contract


A useful integration discussion identifies the producer, consumer, purpose and information being exchanged. The contract needs a version, stable identifiers, handling requirements, authentication, expected ordering and a definition of acceptance. It also needs an owner who can resolve a change in either system.


That precision matters across organisations as well as across products. An intelligence programme may involve different identity providers, retention rules and release authorities. Agreement on a network route alone leaves those questions unanswered.


The Constellation integration overview separates source references, geospatial outputs, assessment editions and developer access. Use that separation to describe the exact flow required from LINC and the receiving capability that will consume it.


Distinguish durable acceptance from delivery


LINC carries messages in versioned, immutable envelopes with handling information, provenance and a content hash. It supports publish-and-subscribe exchanges, work queues, directed commands and request-reply patterns. Select the contract and pattern that fit the customerโ€™s exchange, then inspect them in the demonstration.


Acceptance follows durable storage. Delivery requires evidence from the destination. Between those events, the system needs to retain enough state to explain an interruption, retry or rejected message. A visible transfer record gives operators a basis for deciding what needs attention.


LINC uses at-least-once delivery with idempotent processing. Transport may repeat a message; the receiving process recognises it and avoids repeating the same business action. Include a repeated message in the demonstration and inspect the destinationโ€™s record of that action.


Apply the current policy to the flow


The applicable policy governs whether information may move to the named recipient for the stated purpose. Encryption protects the route. The policy decision still needs the relevant identity, handling, compartment and caveat information before forwarding can proceed.


LINC holds a message when required policy is unknown or unavailable. Remove a required policy response in the test environment, inspect the retained message and check what the operator can see about the reason for the hold.


A second useful case changes the recipientโ€™s rights after a message has entered the exchange. The result should establish how current authority is checked and recorded. Information owners need that evidence to assess the proposed flow, particularly where delivery can be delayed.


Test interrupted links and recovery


Disconnected nodes retain authorised work while a route is unavailable. When the link returns, LINC checks peer identity and current policy before forwarding resumes. Test that recovery with a permission change made during the interruption.


Use interruptions at different points: before acceptance, after durable acceptance and after receipt but before the acknowledgement returns. Inspect retries, ordering expectations and destination behaviour. Agree how operators handle a message that cannot complete within the allowed retry policy.


The disconnected operations guidance distinguishes exchange recovery from local product availability. A working LINC route cannot supply data, models or services that another applicationโ€™s disconnected workflow requires. Each productโ€™s dependencies need their own evaluation.


Keep export and import decisions explicit


Cross-domain exchanges require separate export and import decisions through an approved boundary gateway. LINCโ€™s transfer model distinguishes requested, marked, evaluated, awaiting release, export approved, exported, import validated and delivered states. Durable destination acknowledgement establishes delivery.


Those states help an operator identify where authority or processing is still required. The source needs evidence that an export was approved. The destination needs its own validation before acceptance. The transfer record must preserve the distinction between those responsibilities.


Every cross-domain flow requires independently approved gateways, policies and accreditation. A derivative also needs the relevant originator authority and independent approval of the exact content being transferred. Keep those decisions with the named flow and the evidence supporting its acceptance.


Preserve each productโ€™s responsibility


NERVE retains responsibility for source holdings and provenance. CORTEX retains intelligence workflow and release authority. PULSE retains its assessment watches and editions. LINCโ€™s exchange record supports those responsibilities without becoming the authority for their underlying judgements or business rules.


The ecosystem architecture places MARKER at the marking and flow-policy boundary and SHACE at the protected transport boundary. AIC FOUNDRY supplies reusable engineering capability; FOUNDATION supplies project templates and delivery scaffolding. PAL.NET serves the separate task of typed developer access to supported Palantir services.


For each connection, record the source and receiving release, schema version, supported operations and permissions. Exercise the contract with representative data, including its failure cases, so the application owners can assess the same exchange.


Demonstrate the failure cases before pricing the work


The LINC exchange evaluation provides an illustrative test design. It covers durable acceptance, unavailable policy, changed permissions, interrupted transport, repeated messages and destination acknowledgement. These cases make the operating requirements concrete for both the technical authority and the buyer.


Ask AIC to price the named flows, deployment components, implementation and support responsibilities against that scope. The cost-of-ownership guide explains how to include integration and ongoing change in the comparison.


To arrange a LINC demonstration, email commercial@aicuk.ltd or contact AIC. Provide a non-sensitive outline of the source, destination, message type, connectivity and approval authority. Agree the exchange that the demonstration needs to prove.

Join our newsletter list

Sign up to get the most recent blog articles in your email every week.

Author

Marketing and Outreach Team

AICโ€™s Marketing and Outreach Team builds visibility and trust across Defence and security. We deliver strategic campaigns, thought leadership, and stakeholder engagement while balancing transparency with discretion. Our mission is to position AIC as a trusted, innovative partner to the UK MoD and beyond.