STARTMAKINGSENSE

Integration Types

The Identity-Aware AI Security Interoperability Graph uses a canonical set of integration types to describe how two products - each operating within a single pillar - interoperate across the inter-pillar interface.

Standard

This type is used for relationships mediated by a shared, named standard or formal mechanism that both products implement, consume, or rely on.

Typical attributes

  • The interoperability is anchored in a recognized standard with its own identity and stewardship.
  • Both products expose meaningful support for that standard or formal mechanism.
  • The standard best explains the relationship more clearly than a connector or a bespoke setup pattern.

Systems Integration Runbook

This type is used for relationships characterized by a documented implementation pattern, reference architecture, or deployment recipe rather than by a shared standard or packaged connector.

Typical attributes

  • Public documentation describes a repeatable way to connect the two products.
  • The relationship depends on following a setup pattern across the products' existing capabilities.
  • The interoperability is real and reproducible, but it is best understood as a runbook-style pattern.

Custom Vendor Integration

This type is used for relationships delivered through a named vendor-maintained connector, packaged integration, plugin, adapter, or marketplace offering.

Typical attributes

  • A specific integration, adapter, or connector is available as part of the relationship.
  • Vendor documentation presents the connection as an integration offering or packaged feature.
  • The interoperability is pair-specific rather than a broadly reusable shared standard.

Native

This type is used for relationships that are built directly into the participating product or products, without requiring a downloaded connector, a separate customer/vendor integration implementation path, or a runbook-style setup as the primary means of interoperability.

Typical attributes

  • The same product itself operates across the selected inter-pillar interface, or two different products each provide built-in native support for the relationship.
  • The capability is presented as built-in platform behavior rather than as an add-on connector or implementation recipe.
  • The interoperability works through onboard utilities, methods, or native platform support rather than through a separate connector or runbook.
Review Interoperability AssertionsSubmit an Interoperability Assertion