Prove one representative workflow before production licensing.
A Vendor Pilot tests one bounded input, one selected SecEng capability, one output contract, and one partner-native return path. The objective is a documented production decision - not an open-ended integration project or implied partnership.
Eight facts before you scope a call
A compact specification grid so procurement, legal, and technical reviewers see the same bounded shape.
Default orientation: 30 days after fixture and contract readiness. Final duration is defined in the SOW.
Uses the existing route-specific commercial range where applicable. For a scanner OEM pilot, reference the published $50k-$100k orientation. No single fee applies to every vendor pilot.
One agreed finding, repository selection, attack trace, workflow fixture, workforce object, or other bounded contract input.
One primary capability, with additional modules only where required to prove material value.
One agreed structured return shape, version, identity mapping, evidence behavior, and lifecycle expectation.
Kickoff, contract review, midpoint review, and acceptance review by default.
Production adapter hardening, unrestricted source access, unrelated customer data, public integration claims, redistribution rights, and ongoing support unless explicitly included.
Proceed, revise and retest, extend scope, or stop.
Pilot acceptance target
The same nine-criteria model used across every SecEng pilot route, generalized for any bounded pilot input.
Representative input accepted
The agreed fixture, finding, trace, or object enters the selected module successfully.
- Pass condition
- Selected module processes the agreed representative input without a blocking error.
- Evidence produced
- Execution log and accepted-input confirmation.
Stable identity preserved
The partner's own identifier or correlation ID survives enrichment and return.
- Pass condition
- Returned object carries the original partner identifier unchanged.
- Evidence produced
- Input/output identifier comparison.
Supported output returned
The result is produced in the agreed output contract and format.
- Pass condition
- Output validates against the agreed contract version.
- Evidence produced
- Schema validation result.
Mapping and severity accepted
Both parties approve the field mapping and any severity or claim translation.
- Pass condition
- Written sign-off on mapping and claim language from both technical owners.
- Evidence produced
- Mapping review notes.
Evidence supports review
The result retains enough provenance and context for technical and analyst review.
- Pass condition
- Evidence references resolve to reviewable, sanitized artifacts.
- Evidence produced
- Evidence reference list.
Deduplication or repeat behavior demonstrated
Repeated analysis does not create uncontrolled duplicate results.
- Pass condition
- A second run against the same input does not create a duplicate record.
- Evidence produced
- Repeat-run comparison.
Update, remediation, or retest state preserved where in scope
Lifecycle state can return to the partner system of record when that behavior is in scope.
- Pass condition
- Lifecycle field updates round-trip without loss where agreed in scope.
- Evidence produced
- Lifecycle round-trip log.
Data boundary respected
No prohibited source, customer data, credential, payload, or hidden reasoning leaves the agreed boundary.
- Pass condition
- Boundary review confirms no excluded data category was transferred.
- Evidence produced
- Data-boundary review checklist.
Production decision recorded
Proceed, revise, extend, or stop is documented with reasons and remaining obligations.
- Pass condition
- Written acceptance-review record signed by both technical owners.
- Evidence produced
- Acceptance review summary.
Who owns what during the pilot
Illustrative contract shape. Final responsibility allocation is defined in the executed SOW.
Bounded Vendor Pilot Data Flow
A representative fixture moves from the partner environment, across one agreed transfer or local-invocation boundary, into the selected SecEng capability only, and back as a partner-native structured return.
Bounded Vendor Pilot Data Flow
A representative fixture crosses one agreed transfer boundary, reaches only the selected SecEng capability, and returns as a partner-native, structured result.
Four stacked stages: partner environment holding the representative fixture and stable identifier, an agreed transfer or local-invocation boundary with validation and redaction, the SecEng capability boundary limited to the selected module, and the partner-native return containing the structured result and evidence references.
The final SOW defines the actual execution location, transfer method, retention period, deletion event, and approved evidence set.
What is retained, and what is never required
Pilot acceptance target for data handling: minimum necessary processing, explicit retention, and explicit exclusions.
- Configuration and audit metadata
- Approved evidence objects
- Acceptance artifacts
- Full unrelated source tree
- Credentials or secrets
- Private attack corpus
- Unrestricted payloads
- Hidden model reasoning
- Unrelated customer information
Each party keeps what it brought.
Ownership boundaries that apply to every pilot, regardless of module or vertical.
- The partner retains its data, product, UI, customer relationship, branding, and pre-existing intellectual property.
- SecEng retains its engines, methods, canonical contracts, internal prompts, scoring logic, detector implementation, source, and pre-existing intellectual property.
- The partner receives ownership or licensed use of the agreed pilot outputs only as defined in the SOW and applicable license.
- The pilot does not transfer SecEng source code, hidden reasoning, internal scoring logic, unrestricted redistribution rights, or unrelated tooling.
- Ownership of derivative integration work, adapters, mappings, documentation, and productization artifacts is defined explicitly in the SOW.
A successful pilot ends with a production decision.
Seven steps from acceptance review to a closed or converted engagement.
Acceptance review
Record passed, failed, unresolved, and excluded criteria.
Production license discussion
Select the capability, deployment, entitlement, redistribution, and customer-organization model.
Integration hardening
Define production adapter work, monitoring, release process, and operational controls.
Support tier
Agree severity definitions, response targets, escalation contacts, supported versions, and update cadence.
Versioning plan
Record engine, contract, adapter, and deployment versions plus migration and offline-update behavior.
Launch and claim review
Approve any public compatibility statement, logo use, marketplace entry, customer reference, or benchmark claim.
Close or convert
If no production agreement follows, complete the agreed return, deletion, expiry, or fixture-destruction process.
Validation before publicity.
Neither party may publish a partnership claim, compatibility claim, customer name, logo, benchmark result, marketplace listing, case study, or production-support statement until the relevant maturity level has been demonstrated and both parties have approved the exact language in writing.
- Partnership announcements
- Compatibility badges
- Customer or partner logos
- Named integration claims
- Benchmark or uplift claims
- Production-support claims
- Exact approved relationship description
- Verified maturity level
- Approved technical scope
- Approved logo treatment
- Approved benchmark methodology and result
- Approved support status
Preview the packet before sharing sensitive material.
Every card below links to a real, visible artifact on this page - a sanitized reference example, not a claim of a completed engagement.
{
"contract_version": "seceng.oem.request.v1",
"request_id": "req_demo_001",
"organization_id": "partner_customer_042",
"module": "code_scanner",
"input": {
"kind": "repository_selection",
"repository_ref": "repo_demo",
"revision": "commit_or_archive_ref",
"paths": ["services/agent/**"]
},
"data_policy": {
"retain_source": false,
"return_evidence_refs": true
}
}Sample pilot plan
One bounded workflow, schedule, meetings, exclusions, and decision gate.
Sample input
Sanitized representative request or fixture.
Sample finding or output
Structured result with identity, evidence, validation, remediation, and lifecycle state.
Acceptance matrix
Nine pass/fail criteria with required evidence.
Responsibility matrix
Partner, SecEng, shared, and approval responsibilities.
Data-flow diagram
Bounded input, processing, return, retention, and exclusions.
Production-conversion summary
License, hardening, support, versioning, claims, and closeout path.
Sanitized reference example. A signer-ready pilot SOW is prepared during scoping using the same acceptance criteria, responsibility matrix, and data boundary shown above.
Next step
Scope one representative workflow before a production conversation.
Start with the bounded pilot shape above. We will confirm the representative input, selected module, output contract, and acceptance criteria before any native schema or fixture is exchanged.