Your first analysis

A useful Scopwis run needs three things: a reachable Server, a compatible reasoning model, and at least one data source the current actor is allowed to inspect.

1. Configure the reasoning model

Open Settings → Models, choose a provider, enter the credential, load or enter a model, run Test, then Save. Model credentials stay on the Server and are never returned to the client.

The model must support native tool/function calling. Plain-text-only models cannot drive the production Agent.

2. Add or choose data

Open Settings → Data sources for managed data, or use the data-object browser from Analyze. Scopwis distinguishes catalog visibility from real analytical access: a source is not considered usable until the Server can perform the required bounded read.

3. Ask a scoped question

Good requests name the object, metric, comparison, or decision you care about without prescribing SQL.

For example:

Analyze stocks.csv. Profile price quality by symbol, compare coverage and distributions, then investigate time behavior where the date field is valid. Report missingness and limitations.

The Agent can discover the source, inspect metadata, record a plan, execute typed queries or registered methods, and synthesize findings. You do not need to select a table implementation or write a query plan yourself.

4. Read the evidence, not just the answer

During a run the workspace exposes real execution state:

Data → Plan → Trace → Evidence

Query, mining, analysis, and report artifacts remain inspectable through the Observatory / Artifact surface. Important findings must point to current-run evidence.

5. Ask for a report only when you want one

Normal analysis ends with a verified answer. If you want a durable visual deliverable, say so explicitly:

Turn this analysis into a report with a summary, symbol comparison table, price-distribution chart, and limitations.

That request enables the ReportSpec path. Scopwis does not create a report merely because a question was analytical.

When Scopwis asks for input

A run should request input only when a decision, permission, missing object, or ambiguous business definition genuinely requires you. Internal model/tool/protocol failures should be reported as execution limitations rather than being reframed as a request to re-authorize an already accepted task.