Skip to main content

Long-form · Partner, integrator · 6 min

The integration model.

How a cleared partner takes the engine from contract to first deployment. What runs on partner infrastructure. What TASCET supports behind the partner. The commercial guarantees, written down.

The contract shape.

The contract is between the partner and the customer. TASCET is not party to the customer-side contract. The partner sells, integrates, runs, and supports. The customer relationship belongs to the partner.

The partner buys the engine from TASCET under a margin-floor agreement with vertical exclusivity in the territories the partner serves. The margin floor is fixed. The partner sets the customer-side price above it. The partner keeps the spread. TASCET does not undercut.

What runs on partner infrastructure.

Every deployment runs on partner infrastructure. The partner controls the cloud, the on-premises hardware, or the hybrid mix. TASCET does not run the engine for the customer. TASCET supports the partner who runs the engine.

The standard deployment is OpenShift, on a partner-managed Kubernetes cluster. We provide the helm chart, the SYM appliance firmware, the ICONN service binary, the registry schema, and the post-quantum-key bootstrap. The partner provides the cluster, the network, the storage, the operator runbook, and the customer-facing SLA.

What TASCET supports.

Behind the partner, TASCET provides three things. One: the engine itself, including the modified-ArcFace foundation, the 49-region pipeline, the post-quantum encryption layer, and the registry schema. Two: the certification path, including the documentation a partner needs to take the engine through their existing customer certification regimes. Three: an engineering on-call channel, available to the partner during incidents, with a 30-minute response target during business hours and a 4-hour response target outside.

TASCET does not provide customer-facing support, customer-facing documentation, or customer-facing SLAs. The partner owns those. If a customer escalates to TASCET, we route them back to the partner.

The certification path.

The engine has been built to clear the certification regimes the partner operates under. We do not pre-clear it for every regime. We clear it on demand, in the order partners request. The first partner certification is in progress. The second is queued.

The certification documentation includes the architectural decomposition, the threat model, the cryptographic audit, the data-flow diagrams, and the deployment evidence. It does not include synthetic compliance language. The certification regime auditor reads the same documents we read.

What the customer experiences.

From the customer side, the engine is the partner's product. The branding, the support channel, the contract, and the SLA all carry the partner's name. The customer integrates against the partner's API surface. The customer does not call TASCET. The customer's runbook does not mention TASCET. The engine is opaque to the customer-side operator and visible to the partner-side operator who tuned it.

This is by design. The engine stack is infrastructure. Infrastructure is not a brand the customer interacts with. The partner is the brand. The customer is the user.

The economics in one paragraph.

Margin floor protects the partner from a vendor that undercuts on price. Vertical exclusivity protects the partner from a vendor that resells the same engine to a competitor in the same territory. Deal control protects the partner from a vendor that goes around them. TASCET signs all three commitments in writing before the first deployment. That is how the partner channel runs.

Talk to us

Become a partner.

Read the partner economics. Read the certification path. Then talk to a person.

The first reply comes from a person who can answer the integration question.

Partners ship under their own brand. TASCET supports behind them.