Choose the right domain context, profile source, and analysis run

Treat a domain context as an exact evidence address

A Domain Overview context is not just a typed domain name. It is the authorized workspace, normalized domain, country location code, and language code together. Snapshots, the derived Domain profile, history, storage quotas, and module sources are resolved inside that address. Evidence from another workspace, host scope, country, or language is a different context even when the brand name looks the same.

The optional keyword-gap comparison adds a directed domain pair to one run. It does not become a general profile module because a gap belongs to source domain plus missing-from domain. Always retain both sides and their direction when handing the result elsewhere.

Choose between the Domain profile and an immutable run

The selector groups retained runs by domain and lists them newest first. The Domain profile option keeps the currently selected domain and market context; it does not silently jump to the newest run from another domain. Loading older analyses extends the paginated picker without changing the current dossier.

Choose the profile when you need the latest successful evidence available for each eligible module. Choose a dated run when you need one acquisition event with its original plan, module states, cost outcome, gap direction, and coverage. Switching views never refreshes provider data or overwrites a run.

• A running run stays selectable so its progress remains visible.
• A failed or deleting entry does not hide an older usable run on initial load.
• A plain domain deep link opens existing usable data when it can be found in the loaded history.
• A directed gap deep link opens the paid request form because it asks for a new pair-specific result.

Read identity and provenance before the first metric

Keep the different evidence clocks visible

The run creation time records when Crawl Foundry accepted the analysis. Completion records when its terminal result was stored. A module can also carry fetched-at and provider-updated times. Monthly history rows describe their own months. The profile updated time records when the derived projection changed, not when every provider value was collected.

These clocks can diverge. A current profile header can contain last-known backlink rows from an older run, while ranking evidence is newer. A recent Crawl Foundry run can still contain provider history whose latest available month precedes the request. Use the module source date and provider date that belong to the claim instead of assigning one page-wide freshness date.

Start a new run only for a changed or stale decision context

Do not buy another run merely because a profile projection is still building or a list has not loaded its next page. Profile construction and pagination read saved data. They do not call the provider.

• The exact domain, country, language, keyword depth, or comparison direction has changed.
• The relevant module source is too old for the decision after considering provider update cadence.
• A required module is unavailable and a selective repair is not the better option.
• You need a comparable post-change measurement after enough time for search and provider data to update.
• An existing usable run cannot answer the new question without pretending that its scope changed.

Understand the quote, reservation, settlement, and storage gate

The preflight quote resolves the permitted plan, provider-price catalog, markup, and exchange rate, then checks the organization's spendable balance. Starting the run reserves the quoted customer amount in the same transaction that creates the running snapshot. The final settlement uses the recorded real provider cost from executed steps with the frozen pricing context.

A zero-spend terminal failure releases the reservation. A failure after positive provider spend settles that spend as an error transaction rather than presenting it as refunded. Partial runs settle fetched work. Billing evidence remains even when the user later deletes the dossier.

• The form shows the current effective workspace and domain-context storage limits, not an unbounded archive promise.
• The code defaults are 500 retained headers per workspace and 100 per domain, country, and language context; resolved policy can lower or otherwise govern the displayed effective limit.
• At capacity, delete eligible older analyses or wait for retention processing before requesting another run.
• Replaying the same safe client request ID with identical inputs returns the existing accepted request instead of minting another charge.

Interpret run and module states without turning missing data into zero

A completed run can contain available, empty, or truncated modules. A partial run contains at least one failed requested source alongside usable fetched evidence. A failed run has no usable terminal dossier, but it can still carry settled provider cost if upstream work completed before the failure. The customer-facing failure state distinguishes recorded spend from a dispatch that never started.

For a module, empty is successful evidence of no returned result in that scope. Failed and pending are not evidence of zero. Not requested means the plan or request did not include the module. Truncated identifies a current bounded sample whose missing rows cannot be classified as lost. Legacy means an older run lacks the newer manifest and must be interpreted conservatively.

Verify source selection in the Domain profile

Only completed or partial runs with successful module evidence can supply the profile. A newer successful module replaces the older source. A newer failed module leaves the older successful evidence visible as last known. A newer successful empty module replaces the older non-empty source, because retaining old rows would falsely present them as current.

Current, last known, and unavailable are source states, not judgments about the domain. Entity rows from a truncated top set can be outside the latest sample rather than historical. The profile never merges provider values into invented rows; it points to retained snapshot evidence and can open that source run.

Buy only missing profile modules when that is enough

When a ready profile has modules that are not current, Fetch missing data offers only the eligible refresh modules. The user selects the sections, waits for a fresh one-time maximum quote, confirms sufficient balance, and starts a linked repair run. No background process can confirm that paid request on the user's behalf.

Selective refresh covers visibility overview, history, ranking keywords, competitors, top pages, backlink summary, anchors, referring domains, and indexed pages. The directed keyword gap is excluded because it belongs to one explicit domain pair. A repair result remains a real snapshot with its own state, cost, provenance, and retention lifecycle.

Make a comparison reproducible before reading the delta

Know the current retention tiers

Within one workspace, domain, country, and language context, every usable analysis no older than 180 days keeps full detail rows. The ten newest usable analyses also keep rows while no older than 365 days. Runs still referenced by a profile module, living comparison, or dependent analysis are protected. The newest usable run for the context is protected even when the context becomes dormant.

Eligible older runs are compacted: detailed keyword, competitor, page, anchor, referring-domain, and related rows are removed, while the retained header metrics and history remain available. Unprotected headers older than three years are deleted. Failed runs are deleted after 30 days. Saved comparisons expire after one year and release their references. These rules use run creation age, and protected or newest-usable evidence can outlive the ordinary tier.

Delete safely and leave an audit trail

A user with the required workspace editing capability can request deletion of a terminal run. Running analyses are blocked. A run referenced by a saved comparison or a dependent deep analysis must first be released by removing the dependent record. When a profile points to the run, Crawl Foundry rebuilds the projection around remaining evidence before deleting referenced rows in bounded batches.

Deletion removes the saved analysis, not the financial ledger and not provider work already performed. Before deleting, record any source run required for an open decision. After deletion, verify which profile modules became current, last known, or unavailable and whether a later report still cites evidence that no longer exists in the workspace UI.