Open-Standard Connector Architecture

Overview#

Intelligence platforms ingest data from dozens of heterogeneous sources simultaneously. When the extraction logic inside each connector is tightly coupled to the platform's internal type model, two problems emerge: adding a new data source requires understanding platform internals before writing a single line of connector code, and it becomes difficult to verify that a connector's output is correct independent of the platform. The Argus open-standard connector architecture solves both problems by requiring every connector to produce a well-known open international standard as its primary output, and separating that extraction step entirely from the Argus type mapping step.

The architecture separates connector operation into two distinct phases. In Phase 1 the connector extracts data and serialises it as a STIX 2.1, NIEM, or CAP v1.2 object graph: formats defined by OASIS and US federal interoperability bodies, with published JSON schemas and independent validation tooling. In Phase 2 a structural mapping layer converts those validated open-standard objects to Argus entity format using compile-time GraphQL type definitions. No runtime ontology is consulted during either phase. The connector author works entirely within the open standard; Argus enforces the internal type contract at compile time, not at extraction time.

Last Reviewed: 2026-04-14 Last Updated: 2026-04-14

Key Features#

• Open-Standard Primary Output: Every connector declares the open international standard it implements via the openStandard field in its manifest. Permitted values are STIX 2.1, NIEM, CAP 1.2, STANAG 4607, AIS (ITU-R M.1371), and custom-open (with a citationUrl pointing to the published specification). Extraction logic inside the connector is guided solely by the declared open standard, not by the Argus type system.

• Phase 1 Open-Standard Validation: After extraction, the connector's output is validated against the published open-standard JSON schema before any Argus-specific processing occurs. The STIX, NIEM, and CAP base connector classes provide validation methods that run JSON Schema validation against structural subsets of the respective specifications. A validation result object records pass/fail status, per-object error messages, and entity count.

• Phase 2 Structural Type Mapping: Only after Phase 1 validation passes does the mapping layer convert open-standard objects to Argus entity format. This mapping is driven by compile-time GraphQL type definitions declared in Argus schema files. The mapping is a static field-name translation; it does not receive ontology parameters at runtime, does not consult a property graph during field resolution, and does not validate transformation scripts using runtime ontology parameters.

• Connector Manifest Standard Declaration: The connector registry model, the registration GraphQL mutation, and the Python and TypeScript SDK manifest types all include a required openStandard field. This field is recorded at registration time and surfaced through the connector definition GraphQL type, making the standard declaration auditable across the connector fleet.

• Abstract Base Classes: The connector base package provides STIX, NIEM, and CAP abstract base classes. Each exposes an abstract extraction method (Phase 1), a validation method (Phase 1 gate), and a mapping method (Phase 2). Connector authors subclass the appropriate base and implement only the extraction method, receiving validation and mapping for free.

• Graceful Degradation: When the jsonschema library is unavailable (for example in lightweight edge environments), the validation methods log a warning and return a passed result with an explanatory error message rather than raising an exception, ensuring the pipeline remains operational.

Open Standards#

• STIX 2.1 (OASIS CTI TC): The OASIS Structured Threat Information eXpression standard for representing and sharing cyber threat intelligence, covering indicators, malware, attack patterns, threat actors, and vulnerabilities.
• NIEM 5.0 (National Information Exchange Model): A US federal interoperability framework for justice, emergency management, immigration, and defence information exchange, with a normative JSON-LD binding for structured data.
• CAP v1.2 (OASIS Emergency Management TC): The OASIS Common Alerting Protocol standard for emergency public alerting, used by meteorological agencies, civil protection authorities, and emergency management organisations worldwide.
• STANAG 4607 (NATO): The NATO standard for ground moving target indicator radar data, supported as a connector output contract for defence and surveillance data sources.
• JSON Schema (IETF Internet-Draft): The IETF vocabulary for annotating and validating JSON documents, used as the Phase 1 validation mechanism against the published schemas of each declared open standard.
• GraphQL (GraphQL Foundation): The open query language and schema definition standard used to declare compile-time type contracts for the Phase 2 structural mapping layer.

Use Cases#

The connector architecture is used across cybersecurity operations, emergency management, and defence interoperability programmes.

• Threat Intelligence Ingestion: STIX 2.1 connectors for MISP, OpenCTI, TAXII feeds, CISA KEV, and NVD produce validated indicator and vulnerability objects before Argus type mapping, enabling independent validation of connector output against the OASIS STIX 2.1 specification.
• Sanctions and Regulatory Data: NIEM-based connectors for sanctions lists, corporate registries, and court filing systems produce JSON-LD objects conforming to NIEM namespaces, making connector output independently verifiable by any NIEM-aware tool.
• Emergency and Civil Protection Alerts: CAP v1.2 connectors for national meteorological services, CECIS, and ERCC produce alerts conforming to the OASIS CAP standard, allowing the same connector to feed both Argus and any other CAP-capable alerting platform.
• Multi-Standard Fleet Management: The openStandard field in the connector registry allows operators to query, filter, and audit the connector fleet by standard, identifying which connectors are producing independently verifiable open-standard output versus custom-open connectors with a cited specification.
• EDF/PESCO Interoperability: Open-standard connector output can be shared with allied national platforms that consume STIX 2.1 or NIEM data natively, supporting EDF cloud-of-clouds federated data sharing without requiring partner platforms to understand Argus internal types.

Integration#

• Connector Registry: Each connector registration carries the openStandard and optional citationUrl fields, queryable through the connectors GraphQL query and visible in the connector definition GraphQL type.
• Ingestion Pipeline: The ingestion pipeline service documents the two-phase boundary in its module docstring, making the architectural separation explicit for developers instrumenting or extending the pipeline.
• Intelligence Correlation: After Phase 2 mapping, Argus entities flow into the correlation engine for cross-source entity resolution using the same RBAC and tenant-scoping controls as all other Argus data.
• SDK: Both the Python (argus-connector-sdk) and TypeScript (@argus/connector-sdk) SDKs expose OpenStandard as a typed enum and include it in ConnectorManifest, so connector authors declare their standard at manifest authoring time.
• External Contract: The openStandard, citationUrl, and the open standard enumeration and validation result types are included in the versioned external partner contract bundle.