Connector Model

The connector model defines the structure and expectations of a connector product operating within the lnkpt container substrate. It describes the required metadata, declared API surfaces, configuration boundaries, and lifecycle behaviour that allow connectors to run consistently across environments.

lnkpt supports both multi‑connector deployments and standalone deployments where a single connector is hosted in isolation. This enables organisations to introduce a dedicated endpoint without modifying existing infrastructure, keeping integration clean and low‑impact.

Connector Definition

A connector is a certified product that exposes one or more API surfaces. Connectors may provide access to retention servers, audit log feeds, regulated services such as .gov endpoints, or any other external system. lnkpt does not define connector logic; it provides the environment in which connectors operate.

Because connectors are independent, lnkpt does not require connectors to interact with one another. A single connector can be deployed on its own, making lnkpt suitable for incremental adoption or isolated endpoint hosting.

Required Metadata

Every connector must define a minimal set of metadata to ensure predictable operation within lnkpt. This includes:

• Connector identity — name, version, and unique identifier.
• Declared API surfaces — the endpoints the connector exposes.
• Configuration schema — the parameters required for operation.
• Operational boundaries — resource expectations and external dependencies.

lnkpt relies on metadata to ensure connectors operate within their declared boundaries, regardless of whether the deployment is standalone or part of a larger connector set.

API Surface Declaration

Connectors must explicitly declare the API surfaces they expose. An API surface may be:

• Internal — accessible only within the deployment environment.
• External — reachable outside the environment, such as a public or regulated endpoint.

In standalone deployments, a connector may expose a single API surface, allowing lnkpt to function as a clean endpoint host without introducing cross‑cutting dependencies.

Configuration Boundaries

Connectors define their own configuration schema. lnkpt provides the mechanism for supplying configuration values but does not impose domain‑specific rules. Configuration may include:

• Credentials for external systems
• Retention or audit parameters
• Service URLs, including .gov endpoints
• Operational thresholds or limits

The connector is responsible for validating and applying its configuration.

Lifecycle Behaviour

Connectors operate within a defined lifecycle managed by lnkpt. The lifecycle includes:

• Initialisation — loading configuration and preparing API surfaces.
• Active operation — exposing declared surfaces and performing connector logic.
• Update — applying new versions without disrupting declared behaviour.
• Shutdown — graceful termination and optional evidence finalisation.

This lifecycle applies equally to standalone and multi‑connector deployments.

Optional Evidence Output

Some connectors may produce evidence outputs such as retention logs, audit trails, or ISO 42001‑aligned evidence packets. These outputs are optional and depend entirely on the connector’s product design. lnkpt provides the environment in which such evidence can be generated and exposed through the connector’s API surfaces.