Required pilot inputs
- One representative, sanitized object or target
- Source identifiers
- Expected product workflow
- Allowed data handling
- Desired returned result
- An acceptance owner and support contact on the partner side
Pilot sequence
- Confirm the integration boundary
- Validate the representative input
- Run the bounded SecEng capability
- Review the structured output together
- Confirm identity and provenance survived the round trip
- Evaluate product and workflow fit
- Define the production decision
Success criteria
- Input is accepted without a bespoke adapter
- Source identifiers survive end to end
- SecEng adds context or analysis the partner did not already have
- Grounded vs. inferred content stays explicit in the returned object
- Failures are actionable, not opaque
- Both teams can describe who owns what in production
After the pilot, the production decision is one of: stop, refine the representative proof, adopt a versioned file or CLI integration, build a native adapter, embed the capability, or expand to additional modules. A native adapter is never assumed as the default outcome.
Active pilots today
SecEng currently has adapter bindings — not yet confirmed native integrations — for offensive-security platforms and scanner providers, including active pilot conversations with Verno and AppCheck. Each has exactly one active pilot workspace, reached through a qualified private proposal rather than a public route on this site. See:
- Offensive security platforms — public commercial framing for the Verno-adjacent pilot.
- Scanner providers — public commercial framing for the AppCheck-adjacent pilot.
- Integration patterns — the technical adapter framework both pilots build on.
Neither pilot claims a final native schema, webhook contract, confirmed SARIF import, or confirmed rescan semantics for the partner platform — see integration patterns for the four-stage claim boundary this project holds itself to.