Scan plans and previews

A scan plan describes proposed repository scope, analysis actions, policy decisions, risk, and approval boundaries before Sentinel performs supported read-only work. Plans can load from a plan store, while the wider private-alpha product also contains demo, fixture, empty, and unsupported states. Review the plan as a control artifact: it shows what is intended and blocked, but it is not evidence that every listed rule or action will execute.

Plan generation

Plan generation starts from the selected authorized repository, scope, and scan profile. The resulting plan can identify proposed analysis work, action classes, policy decisions, risk, and approval requirements. Those concepts are present, but a complete plan schema is not available for every surface.

A generated plan is not an authorization source. Repository permission must already exist, and the plan must remain inside that boundary. If it includes an unexpected path or action, return to intake rather than accepting the plan as correct.

Plan-store loading is verified, but complete persistence, versioning, editing, and history behavior require further review. Treat the plan shown by the inspected interface as the operative preview for that scan attempt.

A scan plan translates repository scope into proposed analysis actions and governance decisions. Sentinel types define scope kind, verification state, policy decisions, approval requirements, risk levels, audit events, and tool-invocation concepts. Policy outcomes are allow, deny, and requires_approval. Approval classes are none, human_required, and blocked.

Sentinel types define scope kind, verification state, policy decisions, approval requirements, risk levels, audit events, and tool-invocation concepts; check that the repository and scope match the authorized assessment. Action classes include read-only analysis, patch generation, mutation-oriented actions, disclosure, live-target scanning, credential testing, destructive testing, and unknown actions; confirm that planned scanners and rules are appropriate for the selected code scope. A preview is useful for governance and expectation setting, but it does not guarantee scan completion or finding coverage.

Scope preview

A scope preview should identify the repository boundary and the files or directories included by the plan. Exclusions matter because a later result outside the authorized boundary can indicate a planning or intake defect. Do not normalize that result as an ordinary finding.

Policy information can express allow, deny, or requires_approval, while approval requirements can be none, human_required, or blocked. These values describe the planned action boundary. They do not prove that every declared action class is implemented, and a blocked action must remain blocked even when its name appears in the plan.

The scope preview should make repository boundaries understandable before scanning begins. Review included paths, excluded areas, profile intent, and any scope-verification state shown by the product.

Compare the preview with the permission granted. A broad filesystem path can expose more than the repository under review. Narrow the source when unrelated code, personal files, secrets, or production data appear within the proposed scope.

Scope also affects findings and evidence. A later finding outside the approved boundary should not be triaged as a normal result. It should trigger a review of intake and plan generation.

A universal visual plan editor and exclusion language are not verified. Use only the controls shown by the current private-alpha surface.

The preview should make the authorized repository boundary visible before scanner work starts. Action classes include read-only analysis, patch generation, mutation-oriented actions, disclosure, live-target scanning, credential testing, destructive testing, and unknown actions. A declared action class is a vocabulary item, not proof of a runnable feature. Scan plans can be loaded from the plan store, but complete rule coverage and approval enforcement require verification.

Approval classes are none, human_required, and blocked; read each policy outcome and identify actions that are denied, blocked, or require a human decision. Scan plans can be loaded from the plan store, but complete rule coverage and approval enforcement require verification; do not approve mutation, live-target, credential, destructive, or disclosure actions based only on a plan entry. The supplied evidence does not establish a universal rules catalog or a persistable approval workflow for every action class.

Rules

Rule and action names express intended analysis, not guaranteed coverage. The type system includes read-only operations such as repository snapshots, codegraph construction, static scanners, SARIF ingestion, candidate-finding creation, and validation concepts. It also includes mutation, disclosure, live-target, credential, and destructive action classes for policy classification.

Do not infer that every declared class is runnable. A plan can mention an action that policy denies or blocks. Likewise, a visible scan profile does not prove that every scanner is installed, configured, or applicable to the selected repository.

The exact rule catalog, severity mapping, scanner versions, and coverage claims remain under review. Public documentation should not promise that a plan detects all issues of a given class.

Rule names and action classes indicate intent but do not prove complete scanner coverage. Preflight should expose unsupported or blocked work before a scan begins. Confirm that planned scanners and rules are appropriate for the selected code scope. Do not approve mutation, live-target, credential, destructive, or disclosure actions based only on a plan entry.

A declared action class is a vocabulary item, not proof of a runnable feature, within the current product boundary; confirm that planned scanners and rules are appropriate for the selected code scope. Sentinel types define scope kind, verification state, policy decisions, approval requirements, risk levels, audit events, and tool-invocation concepts; return to intake when the source, scope, or authorization does not match the plan.

Review

Review the plan for three kinds of mismatch: a path outside the authorized repository boundary, an action whose policy decision is denied or blocked, and a capability that is only declared in types rather than supported by the product. Resolve those mismatches before a scan attempt. A reviewer can accept the scope conceptually without implying that the product has a persistable approval workflow for every action.

Plan review is the point to identify mismatches before analysis begins. Check the repository, scope, proposed actions, policy decisions, risk, approval class, and unsupported work.

A plan can be technically valid and still inappropriate for the current authorization. Human review should catch that difference. Do not rely on an automatic policy outcome as a substitute for ownership and permission.

If the product labels the plan as demo or fixture, use it for interface review only. Do not attach it to a customer repository report.

Plan review identifies denied, blocked, unsupported, and approval-bound work. Return to intake when the source, scope, or authorization does not match the plan. Check that the repository and scope match the authorized assessment.

Preflight should expose unsupported or blocked work before a scan begins; do not approve mutation, live-target, credential, destructive, or disclosure actions based only on a plan entry. Approval classes are none, human_required, and blocked; check that the repository and scope match the authorized assessment.

Approval boundaries

Approval classes describe how an action should be governed:

These values do not establish a universal persistent approval workflow. Reviewer roles, signatures, decision storage, expiry, and enforcement across every action are not defined for approval previews. Document the class shown by the plan and preserve the private-alpha limitation.

Approval cannot authorize work outside the repository permission boundary. Live-target scanning, credential testing, destructive actions, automatic patch application, pull requests, and disclosure remain excluded even if their action names exist in the type system.

Approval classes express policy posture without establishing a universal persistable decision system. Read each policy outcome and identify actions that are denied, blocked, or require a human decision.

Policy outcomes are allow, deny, and requires_approval; return to intake when the source, scope, or authorization does not match the plan. A declared action class is a vocabulary item, not proof of a runnable feature; read each policy outcome and identify actions that are denied, blocked, or require a human decision.

Limitations

A plan preview cannot establish scanner completeness, production scheduling, universal rule coverage, or support for every action class. Keep unverified rules and approval enforcement behind their review flags, and label the result as a preview whenever no supported scan record exists.

A scan plan previews proposed work. It cannot guarantee scanner execution, complete rule coverage, findings, durable history, or a successful remediation path. Data can still resolve to store, demo, fixture, empty, or unsupported states later in the workflow.

Do not publish a complete rules directory, fixed severity rubric, universal approval contract, or persistence promise from the supplied files. Keep plans tied to the current repository, scope, source state, and build.

When a plan cannot be reviewed safely, return to intake. Do not start analysis on an unauthorized source, bypass a denied action, or broaden scope to compensate for an unsupported scanner.

Plans describe proposed work and cannot guarantee execution, coverage, or findings.