Normalize once. Return results through the partner workflow.
Use versioned Workbench contracts for findings, evidence, runtime traces, attack observations, path state, remediation, retest, workforce objects, and learner outcomes. Map the portable object to the partner's native schema and lifecycle, then limit every public compatibility claim to the highest maturity actually demonstrated.
Related OEM motions
Use this framework to de-risk OEM, scanner-provider, and offensive-platform integrations, or to validate a joint technology alliance, before claiming native support.
OEM
Add selected Workbench capabilities to another scanner, platform, managed service, or security product through the OEM Engine.
Scanner Providers
Add AI application, RAG, agentic workflow, JSON, SARIF, and evidence-bundle coverage to existing scanner products.
Offensive & Adversarial Platforms
Add gray-box context, evidence-qualified attack paths, validation, and remediation intelligence to offensive-security platforms.
Connect the systems that produce, govern, and consume security evidence.
Code and artifact sources, runtime and observability, scanner and AppSec platforms, offensive and adversarial platforms, identity and policy systems, developer and governance workflows, and LMS or workforce systems can all exchange supported data through one interoperability core.
- Findings, evidence, traces, and lifecycle contracts
- Identity, provenance, and versioning
- Read, enrich, and return workflows
- Scoped API access and approval boundaries
The shared core preserves findings, evidence, traces, identity, provenance, versioning, lifecycle state, and approval boundaries while each product keeps its native workflow.
Normalize first. Bind second. Validate before GTM.
The interoperability route explains what can be mapped, what has only been projected, and what requires partner confirmation before public launch. Use it when independent products need to exchange supported data and lifecycle state - not when Workbench capability is embedded behind your own product (see OEM Engine) or adds specialist findings to an existing scanner (see Scanner Providers or Offensive Platforms).
Findings and Scanner Interoperability
Normalize scanner findings, severity, affected assets, remediation metadata, SARIF-compatible outputs where supported, and evidence references into stable Workbench contracts.
Runtime Trace and Evidence Interoperability
Normalize runtime traces, attack observations, validation artifacts, gray-box context, Attack Path Analysis results, and remediation chokepoints without claiming live partner acceptance before validation.
Workforce and Learning Interoperability
Normalize role architecture, learning objects, practical labs, readiness scoring, learner outcomes, and cohort intelligence for LMS and workforce platforms.
Separate portable interoperability from vendor-specific integration.
A canonical adapter handles parsing, validation, normalization, identifiers, provenance, and supported lifecycle states. A vendor binding adds the endpoint, authentication, field mapping, update behavior, and environment-specific assumptions.
The canonical adapter creates portability. A named integration claim requires the partner-specific binding and its return, update, remediation, and retest behavior to reach the stated maturity level.
Stable objects before vendor-specific glue.
These public contract families define the objects AI Security LLC can normalize or project across partner workflows. The displayed versions are public contract identifiers, not claims of production support for every vendor system.
Finding
Stable issue identity, affected entity, location, severity or priority, description, remediation, evidence, and lifecycle.
Evidence
Provenance, artifact reference, visibility, support, validation, review, and claim state.
Runtime Trace
Ordered observed events, trace identity, correlation references, identity, control state, and safe contextual metadata.
Attack Observation
Partner-produced attack result, reproduced behavior, campaign event, or adversarial finding.
Attack Path
Candidate, supported, validated, reproduced, rejected, or residual path state with evidence grounding and explicit inference.
Remediation State
Proposed, accepted, in progress, implemented, rejected, superseded, or reopened remediation state with evidence references.
Retest State
Not required, required, scheduled, running, closed, residual, failed, blocked, rejected, or inconclusive state where supported.
Workforce Object
Role architecture, capability expectation, content mapping, assessment boundary, organizational context, and readiness-claim rules.
Learner Outcome
Assessment evidence, practical evidence, completion, scoring context, development recommendation, and human-review state.
Use one vocabulary for every public integration claim.
Every named integration, compatibility statement, badge, logo, marketplace entry, or public partner claim must identify the highest maturity level actually demonstrated.
Documented contract
The portable object or mapping behavior is documented. No representative fixture has passed. Allowed claim: contract documented.
Fixture-tested adapter
A canonical adapter passes representative local fixtures. Allowed claim: fixture-tested adapter.
Projection available
The Workbench can emit a documented target shape. Partner-side acceptance and lifecycle behavior remain unvalidated. Allowed claim: projection available.
Return path validated
Representative ingest, normalization, enrichment, projection, return, update, remediation, and retest behavior pass the agreed round trip. Allowed claim: return path validated.
Native partner integration
The partner-specific binding, supported environments, lifecycle behavior, release process, support boundary, and production use are agreed and demonstrated. Allowed claim: native partner integration.
Adapter maturity is a public claim boundary
Fixture validation does not equal live partner acceptance. Public compatibility does not equal native integration. Technical compatibility is also not automatically a named alliance - no logo, badge, named-integration claim, marketplace listing, or alliance announcement may be published until the demonstrated maturity level and exact wording have been approved in writing.
Integration maturity is a claim boundary.
File exchange, structured contracts, native round trips, and embedded workflow state represent different levels of semantic fidelity, operational dependency, and support responsibility.
Higher maturity is not implied by public documentation or fixture testing. Status remains partner-specific and must reflect the strongest level actually demonstrated.
What an approved technology alliance must define
Build selects the canonical contract and identity mapping. Validate tests native behavior, evidence boundaries, secrets, and round trips. Launch assigns support, compatibility, and version ownership.
Joint outcome
The customer or product outcome the combined capabilities create.
Technical scope
Named objects, directions, versions, deployment modes, and exclusions.
Commercial ownership
Who owns the account, sale, billing, support, and renewal.
Claim language
The exact approved compatibility and relationship description.
Release responsibility
Who validates updates, regressions, migrations, and deprecations.
Escalation
How integration defects and customer-impacting issues are diagnosed and communicated.
Compatibility describes formats, not partnerships.
Real supported formats and their current maturity, verified against the adapters already fixture-tested elsewhere in this codebase.
Interoperability is proven by the return path.
A representative object must survive acceptance, validation, normalization, analysis, projection, return, update, remediation, and retest without losing identity, provenance, claim state, or lifecycle history.
- 1Ingest
- 2Validate
- 3Normalize
- 4Enrich
- 5Project
- 6Return
- 7Update
- 8Retest
A useful one-way export remains an export, not a complete product integration.
Bring the native object and lifecycle before a named integration claim.
Share representative findings, traces, path objects, schemas, lifecycle events, or content contracts so the partner profile can move from projection to return-path validation.