Workflow · Doctor

Doctor: Evidence-Based Interpretation Before Action

Doctor interprets structured findings using baseline context and time-aware evidence. It prioritizes risk, explains why drift matters, and recommends next steps before Repair acts.

Purpose

What Doctor is for

Doctor is the interpretation layer in AuditWalk. It does not collect evidence and it does not execute changes. It explains what the evidence means, what is likely benign, what is risky, and what should happen next.

Reference Context

Why baseline makes Doctor stronger

Without a trusted baseline, Doctor can only classify current findings. With baseline context, Doctor can reason about drift from an accepted reference state and produce recommendations with stronger confidence.

scan run               -> capture evidence
baseline set --scan-id <scan_id> -> establish trusted reference
compare run            -> compute drift
doctor run             -> interpret drift and recommend actions

Inputs

Evidence Doctor should use

  • Current compare result and drift classes
  • Baseline lineage and timestamps
  • PreFlight output when available
  • Browser review findings when included
  • Historical recurrence and prior repair context
  • Collection warnings and blind spots

Method

How Doctor constructs responses

  1. Normalize and group findings by signal and scope.
  2. Score risk and confidence using baseline and time context.
  3. Separate likely-routine drift from anomalies.
  4. Recommend one of: monitor, review, or repair planning.
  5. Explain rationale and cite evidence IDs for every recommendation.

Integration

How Doctor depends on the workflow

Upstream dependencies

  • Scan and Baseline Scan
  • PreFlight and Compare
  • Optional browser review

Downstream impact

  • Feeds Repair planning scope
  • Defines urgency and risk posture
  • Improves operator decision quality

Quality

What good Doctor output should look like

  • Clear recommendation category (monitor, review, repair candidate)
  • Confidence and risk level per finding group
  • Evidence references (compare_id, baseline_id, scan_id)
  • Explicit uncertainty notes where data is incomplete
  • Concrete next-step command suggestions

Semantics

Time is essential in Doctor reasoning

Doctor should treat time as core evidence context, not metadata decoration.

  • Baseline timestamp vs current observation timestamp
  • Time since drift first appeared
  • Change clustering windows
  • Recency of prior repairs touching the same scope

CLI

CLI examples

auditwalk doctor run
auditwalk doctor run --compare-id <compare_id>
auditwalk doctor run --path /etc
auditwalk doctor run --include browser
auditwalk doctor run --format json
auditwalk compare run
auditwalk repair plan --compare-id <compare_id>

Workflow

Evidence-to-advice workflow

auditwalk scan run --profile full
auditwalk baseline set --scan-id <scan_id>
auditwalk preflight run --include browser
auditwalk compare run --format json
auditwalk doctor run --compare-id <compare_id>
# if action is justified
auditwalk repair plan --compare-id <compare_id>

This keeps Doctor as an interpretation layer between evidence and action, preserving disciplined execution boundaries.

Positioning

Public-facing copy

Doctor helps AuditWalk translate drift into decisions. It evaluates evidence from baseline, compare, and preflight context, prioritizes what matters, and recommends next steps before any repair is applied.