Start-ClearlyDefinedHarvest now uses Start-Job for the harvest POST. This returns immediately and leaves jobs unobserved/uncollected; in CI or short-lived scripts the PowerShell session may exit before the job runs, so harvesting may not be triggered at all, and repeated calls can accumulate many background jobs. Prefer a synchronous Invoke-WebRequest with retry parameters, or explicitly manage jobs (collect, Wait-Job, and Remove-Job) if async behavior is required.

$retryIntervalSec is a module-scoped variable and is mutated in catch blocks (e.g., incremented up to 300). Because this state is shared across all calls, a single transient failure can permanently change retry behavior for the rest of the session (and across unrelated callers), which is hard to reason about. Consider using a local retry/backoff variable per request/call instead of mutating module-level state.

$registrationsToSave is initialized to $newRegistrations but never changes. If the intent is to sometimes write a different registration set (e.g., when -ForceHarvestedOnly is used), update it accordingly; otherwise, consider removing the extra variable to reduce confusion.

Get-ClearlyDefinedData outputs the ClearlyDefined API response object (with coordinates + added harvested fields), not the input object. As a result, $item.Name/$item.PackageVersion are not populated here, so the $harvestStatus keys will be wrong and everything will be treated as unharvested. Build the lookup key from $item.coordinates (e.g., parse it via ConvertFrom-ClearlyDefinedCoordinates to get name + revision, or use the properties on coordinates if present).

These comparisons use $item.Name and $item.PackageVersion, but $item comes from Get-ClearlyDefinedData and won’t have those fields (it returns the API object + coordinates). This makes $matchingNewRegistration always empty and prevents the TPN update logic from running correctly. Parse $item.coordinates (or add name/version fields in Get-ClearlyDefinedData) and compare against those values instead.