# Reimport policy

ASSESSOR treats a reimport as a new, auditable interpretation of the unchanged original scanner source. The previous scan run remains stored and is linked to its replacement. Scanner-derived records may change; client-owned work must survive.

## When a reimport is required

A processing-profile version must be added and existing affected imports must be marked for reimport whenever a change can alter one or more of these persisted facts:

- scanner or report recognition;
- parser or extractor coverage, including newly readable sections, native scores, counters, details, evidence, attributes, or context;
- rule identity, finding boundaries, affected-asset identity, or duplicate handling;
- field-role mapping, status, outcome, severity, IOE, normalization, or canonical projection;
- report completeness diagnostics or security fixes that change which source records are accepted;
- scoring inputs that were not retained by the earlier import.

Presentation-only changes, labels, layout, filtering over already retained fields, and score-formula changes over already retained inputs do not require a source reimport. They must not be disguised as processing changes.

Clarification 2026-09-22 (Purple Knight for Entra ID): profile 1.4.0 and the summary extractor 1.2.0 recognize `Entra ID` summaries as Purple Knight context, retain the tenant and native Entra posture/counters, and label the scan separately from Purple Knight for Active Directory. Earlier imports stored that summary under the generic profile and therefore contain no canonical Entra observations. They remain unchanged and are marked `Reimport recommended`; the original files are required because scanner source bytes are not retained. Reimport uses the existing auditable replacement path and preserves eligible client-owned review state. No SQL migration is required.

Every scanner profile, including future profiles, declares its current processing contract. Historical contracts remain append-only. A material import change increments the relevant parser, extractor, profile, mapping, normalization, or presentation version and records `reimportRequired` plus the affected dimensions in `PROCESSING_VERSION_MANIFESTS`. Data Hub derives its warning from that persisted contract.

Clarification 2026-09-11: Data Hub assesses processing readiness per stored scan run. A generic-only run remains review-required. Generic companion files alongside exactly one recognized scanner profile in the same run do not independently require reimport when all file processing contracts are current or compatible. Every file retains its own profile, provenance and mapping; an inherited display label is not native recognition. A different run cannot supply the missing scanner context. Unknown/incompatible contracts, actual profile updates and unresolved client-review transfers remain actionable. A review-only state does not offer repeated reimport with unchanged processing as a remedy. This corrects status presentation over existing facts and requires no reimport or processing-version change.

## GPO re-evaluation and presentation

Clarification 2026-09-17 (missing retained GPO source): A persisted `backend-controlled` storage reference records custody and provenance; it does not prove that the file is currently accessible. The GPO status endpoint checks availability on each read, independently of repository revision, and distinguishes `Upload required` for missing bytes from `Storage unavailable` for an access/configuration failure. Automatic job repair, Retry and Reprocess check availability before enqueueing. A queued job that encounters a missing file stops after its first failed attempt instead of retrying three times. Data Hub and the GPO processing panel offer an artifact-bound original ZIP/folder upload; the project, optional timeslot, exact byte size and SHA-256 must match. Restoration atomically republishes only missing bytes under the original storage key, never overwrites an existing object and preserves original identities, timestamps and retained analysis history. Ordinary byte-identical resubmission repairs missing bytes as well. A missing-source job may resume after restoration; an already current analysis does not need another run just to restore its original file. Evaluation-only updates remain possible from retained inputs, while an analyzer update still requires the source before reprocessing. This is storage recovery, not a changed interpretation: no parser/analyzer/processing-manifest version bump, SQL migration or bulk reprocessing is required.

Clarification 2026-09-14 (baseline variants): Evaluator 1.5.0 compares each retained candidate independently and requires unanimous supported outcomes for Pass/Fail. It stores the versioned per-variant assessment and original values in the existing result JSON/JSONB. Historical 1.3.3/1.4.0 runs remain unchanged and require explicit re-evaluation through Data Hub; no scanner processing-manifest change or source reimport is required for this evaluation-only change. Inventory context does not establish a GPO target role. See [GPO_BASELINE_EVALUATION.md](GPO_BASELINE_EVALUATION.md) for the decision and evidence contract.

Clarification 2026-09-15 (mechanism-scoped baseline partiality): Evaluator 1.6.0 no longer lets a parser diagnostic from an unrelated delivery mechanism invalidate a separately resolved comparison. Diagnostics applicable to the candidate mechanism, unexplained partiality, ambiguous values and incomplete customer evidence remain review-only. Historical 1.5.0 results remain unchanged and require explicit re-evaluation in Data Hub; this evaluation-only change does not require a source reimport or processing-manifest update.

Clarification 2026-09-16 (policy-setting conflict roll-up): Evaluator 1.7.0 compares each retained configured member value of a customer conflict independently. One valid failing member makes the technical policy-setting verdict Fail once, while conflict/duplicate remain separate diagnostic flags; unresolved evidence remains review-only when no independently valid fail exists. Historical results through 1.6.0 remain unchanged and require explicit re-evaluation in Data Hub. The inputs were already retained, so this evaluation/presentation change requires neither a source reimport nor a processing-manifest update.

Clarification 2026-09-16 (analyzed-scope absence): Evaluator 1.8.0 reports an applicable recommendation with no observed configured value in the analyzed backup set as score-neutral `Not configured`, including for selected-subset imports. It retains a scope-limit diagnostic and does not claim domain-wide or effective-device absence. Historical results through 1.7.0 remain unchanged and require explicit re-evaluation in Data Hub; retained inputs are sufficient, so no source reimport or processing-manifest update is required.

Clarification 2026-09-16 (Registry.pol state requirements): Evaluator 1.9.0 compares retained `delete-value`, `delete-all-values`, `create-key` and typed empty-string recommendations as explicit backup-configuration states. Historical results through 1.8.0 remain unchanged and require explicit re-evaluation in Data Hub. The required original Registry.pol instructions, types and values are already retained, so this evaluator-only change requires no source reimport, processing-manifest update or SQL migration.

Clarification 2026-09-17 (baseline analyses of the written form): The Microsoft baseline analyzer consumes the same Security Template parser, so a baseline analysis produced before the parser change still carries the case-folded section. An evaluated setting takes its displayed identity from the baseline side, so the baseline packages must be re-analysed for the written form to reach Work. Append-only analyzer version `microsoft-baseline-gpo-settings` 1.3.0 -> 1.4.0; the accepted version list keeps every earlier value so historical analyses stay readable and are not rewritten. Two further selection rules were corrected in the same step. First, only analyses of the very same baseline package are one lineage: an interrupted supersession chain may leave several of its generations unsuperseded, and the newest analyzer version then wins, while independently analysed packages remain independent benchmarks. Second, the current run per aggregation is chosen by the distinct baselines actually compared rather than by the number of analysis references, so duplicated generations no longer outrank a narrower current run; where retained results name no baseline, the declared references stay the only measure. No source reimport, SQL migration or evaluator change; re-analysing a retained baseline package and re-evaluating is sufficient.

Clarification 2026-09-17 (written security-template section and key): The Security Template parser folded the section name to lower case and discarded the written form, so `[Privilege Rights]` was retained only as `privilege rights`. The parser now keeps the written section and key; the case-folded forms stay internal to grammar selection, grouping and the identity digest, which keeps existing observation and identity IDs stable. The native target resolver stores the written section and key in the retained target, matching what the registry resolver already did, so Work shows `Privilege Rights - SeCreateTokenPrivilege` and the value stays searchable against Microsoft documentation and external tables. This changes persisted parsing output, so it is an append-only processing-version change, not a presentation change: `gpo-security-template-inf` 1.1.0 -> 1.2.0, `gpo-backup-policy-analysis` 2.2.3 -> 2.2.4 and the GPO job processor 2.2.3 -> 2.2.4. Historical imports keep their retained values unchanged and are marked for reprocessing: Data Hub reports an affected GPO backup as `Reprocessing required` with the analyzer versions and offers the existing reprocess action on the stored source, so no upload is needed. Reprocessing precedes re-evaluation, and prior runs remain retained as history. No SQL migration and no evaluator change.

Clarification 2026-09-17 (Not comparable verdict): A retained customer setting whose delivery mechanism has no comparable technical policy identity - today always a Group Policy Preference - reaches Work under the score-neutral verdict `Not comparable` instead of being dropped. It is never resolved into a policy identity and never compared with a Microsoft baseline. The unified read projection additionally exposes the already retained preference CSE, action and item-level targeting status so that context stays readable in the agreed GPO columns; no new column, facet or persisted field is introduced. Snapshot-aggregation review hints that restate an unresolved identity already reported by their source analysis are no longer emitted a second time. All of this projects facts the importer already retained, so no processing-manifest version, source reimport, evaluator change or SQL migration is required.

Clarification 2026-09-17 (No baseline rule verdict): Work now projects every retained customer policy state under exactly one verdict. A resolved technical identity with no applicable Microsoft baseline recommendation in the compared baseline set receives the score-neutral verdict `No baseline rule`; a retained comparison that yields no safe verdict stays `Review required` instead of being dropped. `Conflicts`/`Duplicates` remain diagnostic flags on the setting's own row and no longer replace its verdict, so their counts and the Result-DB consistency projection follow the flag rather than the row status. Observations that already evidence an evaluated comparison, including child values of a registry-key requirement, are never reported a second time; unresolved identities keep their separate analysis-gap reporting. This is a read-time projection over already retained observations, aggregations and evaluations: no evaluator version change, source reimport, processing-manifest update or SQL migration is required, and no persisted record is rewritten.

Clarification 2026-09-17 (current baseline analysis generation): GPO evaluation readiness is no longer derived from the evaluator version alone. A retained evaluation stays pinned to the baseline analysis ids it was created with, so a newer Microsoft baseline analysis generation of the same baseline also marks it as requiring re-evaluation. The Re-evaluate action resolves every retained baseline reference to its current non-superseded analysis and never widens the evaluated baseline set: an unknown reference and a baseline without a newer generation keep their own analysis id. Prior runs remain retained and are not rewritten. Baseline packages, their analyses and the customer inputs are already persisted, so this readiness/selection change requires no source reimport, processing-manifest update or SQL migration.

Clarification 2026-09-11 (GPO evaluation readiness): A saved baseline comparison from a previous evaluation engine requires re-evaluation of retained inputs, not automatically another upload. Data Hub reports this separately from scanner-profile reimport, scoped through active profile, snapshot, identity-analysis and artifact references. Its explicit Re-evaluate action uses the existing evaluation API; prior runs remain retained. Work labels readable previous-engine comparisons as historical and keeps their original outcomes in a separate Historical result field instead of presenting them as current Pass/Fail. Missing baseline description metadata and failed description loading are separate presentation states. OS grouping and row-bound native counts use already retained environment observations; these display changes introduce no processing manifest or source reimport requirement.

## Preservation contract

Reimport replaces scanner-derived data only. The following client-owned values are preserved as one object and transferred to the replacement finding when the identity is unique:

- workflow status and custom label;
- priority and action-plan inclusion;
- owner and due date;
- comments, prerequisites, required access, next step, and acceptance evidence;
- markers, including accepted-risk state;
- future additional review fields carried in the same record.

The match uses scanner identity, native rule ID, and affected asset. It succeeds only for one old and one new occurrence. A stable definition-level review remains attached without copying. ASSESSOR never falls back to title-only or positional matching.

Structured Accepted Risk decisions retain every original revision and its target occurrence ID. A transferred acceptance displays `Review required` when the new occurrence differs from the approved target. Preservation does not silently renew approval, expiry or scope: recording acceptance for the replacement requires a new decision. See [RISK_ACCEPTANCE.md](RISK_ACCEPTANCE.md).

When a match is absent or ambiguous, the old review remains on the retained previous scan. The replacement records an unresolved count and Data Hub shows a persistent review-required state. The reimport is still auditable and does not silently discard or guess customer data.

Both direct reimport and adoption of an already imported byte-identical replacement execute review transfer and scan supersession in the same repository transaction. The exact source SHA-256 multiset, assessment, and scanner must match before replacement is accepted.