Deploy Scout in a Private Environment

In a private deployment, Scout uses the customer's FactVerse environment, DFS sources, MDM identities, semantic models and platform AI service. Confirm that the delivered product release includes the required components and tenant capabilities before configuration begins.

Define the Deployment Boundary

Area	Confirm with the customer
Access	Tenant sign-in, users, roles, approver and release operator
Sources	Authorized files, databases or MQTT broker; read scope and credentials
Data services	Access to the required database, cache and tenant time-series services
AI service	Model API address, supported adapter, model name, credentials, capacity and timeout limits
Network	DNS, TLS trust, firewall policy and reachability from application services
Data handling	Metadata, samples and documents permitted for processing, and their processing location
Operations	Backup, monitoring, upgrade, recovery and outage owners

Model server capacity, model weights and provider subscriptions are deployment inputs managed through the customer's approved infrastructure process.

Understand the Request Path

Verify every connection from the running application environment. Connectivity from an engineer's workstation does not establish application connectivity.

Select the Model Route

Choose one of the routes approved for the customer's data policy:

• Private model service: a compatible endpoint hosted within the approved network boundary
• Approved external model API: an explicitly permitted route with defined data scope and credentials

The selected adapter and model must support Scout's structured investigation responses. Test a real Scout analysis request using permitted data. Review imported environment configuration so DNS names, credentials and model routes point to the intended services.

Configure and Verify

1. Install or upgrade the delivered release using its approved deployment procedure.
2. Enable DFS Pro and Scout for the tenant.
3. Assign viewer, operator, reviewer, approver and release-operator access.
4. Configure authorized sources and verify a real read from the application environment.
5. Configure the approved model route and run a small Scout investigation.
6. Confirm equipment identity and field meaning with the responsible domain owner.
7. Exercise the selected validation, approval and release workflow on a controlled scope.
8. Check the effective dataset or model version, source observations and downstream use.

Use a clearly labelled test scope for infrastructure verification. Customer acceptance should use the agreed customer-source scope and acceptance criteria.

Model-Service Failure Handling

Existing task evidence remains available during a model-service interruption. Deterministic comparison and human review can continue when their data prerequisites are available. Scout resumes AI analysis after the configured service recovers.

Record the interruption in the task and ask the model-service owner to check routing, credentials, capacity, timeouts and response compatibility. Resume the existing task after recovery so its evidence and decisions remain together.

Complete the Handover

Provide:

• installed product and configuration versions
• enabled tenant capabilities and assigned roles
• verified source, model and AI-service connections
• the result and time of the controlled Scout investigation
• data-processing scope and known limitations
• backup, monitoring, recovery and support owners

Source configuration and publication are separate steps. For MQTT, CSV and business datasets, see Connect Data Sources. For semantic-model publication, see Work with Brick Models.