Putting Autonomy on a Leash

Strix's operating choices determine whether its evidence chain is useful for a particular decision. This chapter compares scan depth, completion semantics, locality, integrations, and extension authority so readers can choose a posture for a pull request, a routine review, a release assessment, or an integrated environment. The practical test is not which mode sounds most powerful. It is whether the selected mode has enough time, access, and visibility to support the conclusion the organization wants to draw.

The trade-off is unavoidable. A fast scan can provide valuable feedback while a change is still easy to alter, but it cannot explore every edge case. A deep scan can spend more time on chained paths and source-aware validation, but it consumes more model calls and depends on a stable runtime. A local run can keep artifacts under the operator's control, while a managed path can reduce infrastructure work and add team workflows. In each case, the evidence standard stays the same even though the operating conditions change.

flowchart TD A["Decision: what must this scan inform?"] --> B{"Required feedback latency"} B --> C["Pull request or smoke test"] B --> D["Routine security review"] B --> E["Release or critical assessment"] C --> F["Quick, headless, diff-aware"] D --> G["Standard, broader review"] E --> H["Deep, with sufficient budget"] F --> I["Verify status, coverage, and cost"] G --> I H --> I I --> J{"Locality and authority posture"} J --> K["Local CLI and explicit source policy"] J --> L["Managed path and team workflow"] K --> M["Review MCP, telemetry, and viewer exposure"] L --> M

The decision begins with the consequence of being wrong. If the goal is quick feedback on a small change, latency is a meaningful criterion. If the goal is confidence before exposing a critical application, unexamined scope is the larger risk. The rest of the chapter explains why the branches in the diagram are conditional rather than a ranking from “weak” to “strong.”

Choose depth by decision latency

Strix offers three documented modes. Quick is designed for fast checks and is positioned for pull requests, CI pipelines, and smoke tests. Standard is a balanced review for routine assessments and development milestones; in white-box work it uses source-aware mapping and static triage to prioritize dynamic validation. Deep is the thorough default, intended for comprehensive audits and critical or pre-production assessments, with broader source-aware triage and more systematic validation of promising paths.

The modes differ in the amount of investigation they attempt, not in the basic meaning of a proof. A quick scan that validates a real unauthorized effect has a stronger finding than a deep scan that merely notices a suspicious pattern. Conversely, a quick scan that reports no issue has a narrower claim because its time and scope are intentionally constrained. Depth is therefore a resource allocation, while evidence quality is a separate axis.

For a pull request, quick mode can be the right gate because the feedback arrives before the change merges.