LINC / Trusted exchange / Intended architecture
Information connected. Authority preserved.
LINC, Linked Intelligence Network Communications, is the communications and trusted-exchange layer in development for Constellation. Its job is to govern the exchange while each participating product remains responsible for its own information and decisions.
Availability, supported scope and assurance are agreed for the named evaluation. This page does not claim a production-ready or accredited deployment.
- 01Source product
Retains information authority
- 02Policy evaluated
Identity, recipient, purpose and handling
- 03LINC durable exchange
Named route and current permission
- 04Destination acknowledgement
Delivery recorded after durable receipt
An approved decision permits this illustrative flow.
Connect information without surrendering authority.
The communications and trusted-exchange layer in development for Constellation. Durable messaging and explicit policy decisions keep the exchange traceable while each connected product remains responsible for its own information.
Owns exchange protocol, routing and transfer state. A connection is not permission.
01 / LINC
Define the exchange, not a universal permission
LINC’s intended role covers the exchange protocol, routing and transfer state for NERVE, CORTEX, GTK, PAL, PULSE and approved external services. A product’s presence in the portfolio does not mean that every pair of systems has an available or authorised connection.
Agree a versioned contract for each named flow: producer, consumer, purpose, handling marking, identity, payload, ordering expectations and the evidence required to establish acceptance and delivery.
02 / LINC
Accept durably before reporting success
The messaging design covers publish/subscribe, work queues, directed commands and request–reply. Each message is a versioned, immutable envelope that carries handling information, provenance and an integrity hash.
Acceptance follows durable storage. Delivery uses at-least-once semantics with idempotent processing, bounded retries and a protected dead-letter queue. Repeated transport must not be presented as permission to repeat a business action. Decisions and state changes remain auditable.
03 / LINC
Recover the link without reviving permission
Disconnected nodes are designed to retain authorised messages durably and forward them in order when an approved route returns. Reconnection requires fresh checks of peer identity and current policy.
An expired or revoked permission does not become valid because a tunnel is available again. The evaluation should include interrupted delivery, changed recipient rights, a policy service that cannot be reached and recovery without duplicate business effects.
04 / LINC
Apply policy at the point of exchange
A connection is not permission. Encryption protects the route; the applicable policy decides the flow. MARKER supplies classification-aware marking and information-flow policy. Unknown or unavailable policy means the message is held, not sent.
The message contract and policy decision need enough context to evaluate the sender, recipient, purpose, handling marking, compartments and caveats. A transport acknowledgement is not a substitute for an authorisation decision.
05 / LINC
Treat export and import as independent decisions
Across security domains, a transfer passes through an approved boundary gateway. Export approval and import validation are separate decisions. The source cannot infer destination acceptance from the fact that it sent the message.
The intended transfer path distinguishes Requested, Marked, Evaluated, AwaitingRelease, ExportApproved, Exported, ImportValidated and Delivered. Exported is not Delivered. Delivery is recorded only after a durable destination acknowledgement.
Cross-domain use depends on independently approved gateways, policies and accreditation for each named flow.
06 / LINC
Keep the originator in control of derivatives
Lower-marked headings or a summary do not create a right to release a higher-classified document to a lower domain. The original retains its classification and remains in the origin domain.
Only an originator-authorised derivative, with its exact bytes approved by an independent reviewer, is eligible for the approved transfer. Each side retains its own hash. Protected source lineage stays in the origin domain; the destination receives only the approved opaque reference. Replays after revocation are rejected.
Cross-domain use depends on independently approved gateways, policies and accreditation for each named flow.
07 / LINC
Separate the shared foundations from product authority
LINC is built on the intended Constellation foundations: AIC FOUNDRY and FOUNDATION for shared messaging primitives, identity and hosting conventions; MARKER for marking and flow policy; SHACE for authenticated, protected transport.
These roles do not displace CORTEX review authority, NERVE source ownership, PULSE edition responsibility or the receiving application’s business rules. AIC FOUNDRY is distinct from Palantir Foundry, which PAL.NET accesses through supported platform interfaces.
08 / LINC
Scope the deployment and acceptance evidence
The architecture identifies LINC Broker, LINC Gateway, LINC Node, LINC Link and LINC Console, with single-node, multi-node and disconnected deployment profiles. Confirm which elements and behaviours are available in the release proposed for evaluation.
Bring the systems, domains, message contracts and operating constraints. Prove durable acceptance, denial and hold behaviour, bounded retry, recovery, revocation handling and durable destination acknowledgement with approved representative data. Capability descriptions are intended state, not evidence of an accredited deployment.
Bring a requirement we can evaluate.
Name the source, the destination, the flow and the authority responsible for approving it.