How to Operate and Audit a Praxist Run

Praxist is easiest to use responsibly when operation follows the same evidence boundaries as the research loop. This chapter turns those boundaries into a practical sequence—setup, takeover, validation, detached execution, canonical-state inspection, and independent checking—then uses Rocket Booster Recovery to show why platform and task evidence must remain separate.

Installation is not research authorization

The first-use experience prepares Praxist; it does not choose a scientific project for the operator. Setup installs the package and maintained runtime integrations, presents the Fair Source License, User Agreement, and privacy notice, lets the operator select a coherent runtime/provider/model profile, registers the appropriate skills, materializes writable examples, and runs host diagnostics. It does not select a task or start a research run.

That separation protects two different decisions. Installation answers, “Is the software and its execution profile ready?” Takeover answers, “Is this particular research project ready to be run?” A saved model login, an existing provider key, or a passing host diagnostic cannot substitute for the second decision. The task still needs a runnable baseline, an evaluator, a measurable objective, and explicit scientific constraints.

Product-usage consent is a third decision. It is separate from accepting legal terms and separate from authorizing research. Collection is off unless the operator explicitly opts in after reviewing the current notice. The documented product-usage protocol is closed-schema and aggregate: it may record lifecycle events such as run start, generation completion, run finish, and reconciliation, but it is designed not to include task content, prompts, research results, paths, commands, credentials, provider details, model names, or hardware information.

The privacy distinction is worth keeping precise. The system describes the data as pseudonymized, not fully anonymous. A randomly generated environment identifier can link events from the same local environment across runs. Withdrawal stops future capture and removes unsent local events, while already delivered events follow the documented retention and deletion process. An operator should therefore treat consent as a real data decision, not as a harmless setup checkbox.

After setup, takeover is explicit. The operator selects the task project path and asks Praxist to resolve it. The validation path checks task-local references, evaluator readiness, runtime/provider compatibility, and the declared evidence contract before an expensive cohort begins. This is where the framework can stop and name a missing prerequisite instead of allowing an incomplete project to produce an apparently authoritative run.

flowchart TD Install["Install and configure Praxist"] --> Profile["Review terms and choose runtime profile"] Profile --> Consent["Optional separate product-usage consent"] Consent --> Select["Select an explicit task project"] Select --> Gates["Resolve and doctor readiness"] Gates --> Ready{"Mandatory gates pass?"} Ready -->|"No"| Repair["Repair task or runtime contract"] Ready -->|"Yes"| Start["Start a detached run"] Start --> Observe["Status and read-only monitor"] Observe --> Inspect["Inspect canonical artifacts and replay"] Inspect --> Continue{"Continue or stop?"} Continue -->|"Continue"| Observe Continue -->|"Stop"| Stop["Freeze admission and stop"] Stop --> Resume["Resume only from a recognized boundary"] Inspect --> Validate["Independently validate the science"]

The sequence shows that consent, readiness, execution, and scientific validation are related but not interchangeable. Passing an earlier gate does not authorize a later claim.