tracemint.
Deployment

Place the product.
Define the model boundary.

SaaS or on-premises. Local inference, a TraceMint-operated model, or your own provider API key. Choose where the application lives—and separately, where its analysis goes.

Plan an enterprise evaluation
Four deployment routes

The same product.
Different operating boundaries.

Application location and model location are separate decisions.

SaaS · TraceMint-operated

Use the product. We operate it.

Access TraceMint as a hosted service, with the application and its operating environment managed by our team.

TraceMint environment
ApplicationTraceMintProduct + database
Operated by TraceMint
Hosted analysisModel response
Configured hosted environment
InferenceModel endpointSupported model + runtime
TraceMint-managed model connection
Operating responsibility
TraceMint operates the application and database. The model endpoint, processing location and applicable provider are defined for your service.
Data crossing the boundary
Repositories or reports are processed in the hosted environment. Model context reaches the configured endpoint; review its operator, retention and data terms.
Customer hardware
No customer GPU requiredUse the hosted application; inference infrastructure is not yours to provision.

SaaS does not automatically mean a dedicated stack or private database. Agree any additional isolation requirements explicitly.

Fully local · Product + model on-prem

Keep the product and inference inside.

Run the application, database and a supported local model within your own environment. Your team operates both the product and inference infrastructure.

One customer operating boundary
Your environment
ApplicationTraceMintProduct + database
Operated by your team
Internal analysisModel response
Same customer boundary
InferenceModel endpointSupported model + runtime
Local model · operated by your team
Operating responsibility
Your team operates the application, database and local model serving. Choose the supported model, runtime and capacity together.
Data crossing the boundary
Model context stays within the configured local model boundary. SCM, ticketing, updates and other connections have their own data flows.
Customer hardware
Local inference hardware is requiredSize local inference separately from the application host.

On-premises is not automatically air-gapped. Offline operation also requires local dependencies, offline update and licence procedures, and an integration review.

TraceMint LLM · On-prem product · hosted inference

Your product installation. Our model operations.

Keep TraceMint and its database on-premises while using a TraceMint-operated model endpoint. Your team does not need to host the model.

Your environment
ApplicationTraceMintProduct + database
Operated by your team
Analysis context crosses this boundaryModel response
TraceMint environment
InferenceModel endpointSupported model + runtime
Model operated by TraceMint
Operating responsibility
Your team operates the application and database. TraceMint operates the agreed model endpoint and its inference infrastructure.
Data crossing the boundary
Selected source, report or finding context is sent to TraceMint for inference; model responses return to your installation. This is not an air-gapped deployment.
Customer hardware
No customer GPU requiredProvision the application host. The remote endpoint provides inference compute.

Keeping the database on-premises does not keep every analysis input local. Agree the endpoint, transmitted context, region and retention before connecting.

Your API key · On-prem product · BYOK inference

Use your model account and API key.

Connect your on-premises installation to a supported model provider or gateway using a customer-supplied API key. You choose the account and manage its credentials.

Your environment
ApplicationTraceMintProduct + database
Operated by your team
Context sent under your provider accountModel response
Your selected model provider
InferenceModel endpointSupported model + runtime
Provider operates hosted inference
Operating responsibility
Your team operates the application and database, and owns the provider account, usage charges, key rotation and access scope. The selected provider operates the hosted model.
Data crossing the boundary
Analysis context reaches the configured provider under its processing, region and retention terms. An API key changes account ownership, not the data boundary.
Customer hardware
No customer GPU for hosted inferenceProvision the application host. The remote endpoint provides inference compute.

BYOK here means a model/provider API key, not a customer-managed database encryption key. Supported endpoints and model capabilities are checked during setup.

Deployment topology

This diagram describes operating boundaries, not a live connection or an infrastructure health check.

Before deployment

Make the choices explicit.
Keep the responsibilities clear.

Hardware & inference

Do we need a GPU?

Not for SaaS or on-premises with hosted inference—whether the model is operated by TraceMint or accessed with your own provider API key. On-premises still needs application compute and storage. For a local model, size inference hardware against the selected model (for example, 27B–1T), quantization, context length and concurrency. Parameter count alone is not a hardware specification, and CPU-only performance is not assumed.

When is on-premises actually offline?

When the product, model and required dependencies are available inside the approved boundary, and update, licensing and integration workflows also support that boundary. A remote model endpoint requires connectivity even when the application and database are local.

What does BYOK change?

You supply a supported model/provider API credential and control that account. Confirm endpoint compatibility, billing, least-privilege access, rotation and the provider’s data terms. Do not send API keys through a demo form or support ticket; agree the protected setup path with your administrator.

Who owns the day-to-day operations?

Map application and model operators separately. Agree identity and support access, upgrades, retention, backup and recovery, monitoring, and incident handling for each environment. Service levels and any dedicated isolation requirements belong in that agreement.

Review data flow & retention
Enterprise evaluation

Start with a question.
Finish with a decision.

Use these four checkpoints to scope a useful evaluation together. Timing, participants and deliverables are agreed for your project; this is a planning framework, not a fixed service package.

  1. Agree the question

    Security lead + engineering owner

    Choose the workflows to evaluate and the decisions the results should support. Identify an authorized sample repository or existing report, the people reviewing it and the criteria for success.

    Output to agree

    Evaluation brief: scope, inputs, reviewers and acceptance criteria.

  2. Confirm the boundaries

    Platform owner + security reviewer

    Select the application and inference route. Record operators, locations, integration permissions, support access, retention and deletion expectations before introducing customer data.

    Output to agree

    Deployment and data decision sheet, including open questions and their owners.

  3. Run a scoped evaluation

    AppSec + developers

    After scope and access are approved, exercise the agreed workflows. Inspect source identity, findings, supporting evidence and any limitations. Compare results with the acceptance criteria and review a remediation workflow where relevant.

    Output to agree

    Observed results, evidence samples and an explicit list of gaps or untested areas.

  4. Review the decision

    Evaluation owner + procurement + operations

    Decide whether to proceed, revise the scope or stop. For a rollout, agree operating responsibilities and applicable commercial and data terms. For a closeout, confirm the handling of evaluation data and access.

    Output to agree

    Decision record with next steps, owners and agreed data closeout actions.

In your request, share the workflow you want to evaluate and any deployment constraints. A request starts a conversation; it does not book a meeting, create a tenant or authorize a scan. Keep source code, credentials and sensitive findings out of the demo form.

Security review checklist Technical evaluation pack
Discuss deployment