---
id: CAP-PFM-DJE-017
title: Reset a loading workspace and review its release
feature: FEAT-PFM-DJE-05
product_area: platform
module: data-job-engine
revision: 1
status: draft
product_intent: confirmed
implementation_evidence: partially-observed
supersedes: []
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69
intent_sources:
  - 'services-platform:docs/milestones/PLAT-M19-data-job-engine-foundations.md#D5'
  - 'services-platform:docs/milestones/plans/PLAT-M19-plan.md#S23'
  - 'services-platform:docs/milestones/plans/PLAT-M22-plan.md#A1'
  - 'services-platform:docs/milestones/plans/PLAT-M22-plan.md#A3'
  - 'services-platform:docs/milestones/plans/PLAT-M22-plan.md#9. Acceptance scenarios'
purpose: >-
  Implementation staff recover from a faulty initial load while a separate activation decision controls
  when ordinary workspace work can resume.
outcomes:
  - Reset clears loaded domain data while retaining implementation support records.
  - The cited reload fixtures preserve records and numbering.
  - Activation has separate authority and a planned readiness gate.
concepts:
  - CON-PFM-DJE-005
  - CON-PFM-DJE-004
actors:
  - ACT-PFM-037
  - ACT-PFM-038
surfaces:
  - api
preconditions: []
postconditions: []
permissions:
  - key: hq.data-runs.manage
    where_checked: api
    scope: global
  - key: hq.tenants.activate
    where_checked: api
    scope: global
rules:
  - id: BR-CAP-PFM-DJE-017-01
    proved_by: [ATS-PFM-DJE-017-01]
    statement: >-
      The reset contract requires implementation status, loading lifecycle and the workspace identifier
      as confirmation, with eligibility checked before recording and processing the reset.
    kind: validation
    enforced_at:
      - service
    must_prove: true
    provenance: documented
    source: 'services-platform:docs/data-jobs/tenant-reset.md#1. When a tenant may be reset'
    origin: 'services-platform:docs/milestones/PLAT-M19-data-job-engine-foundations.md#D5'
  - id: BR-CAP-PFM-DJE-017-02
    proved_by: [ATS-PFM-DJE-011-12, ATS-PFM-DJE-015-08, ATS-PFM-DJE-016-17, ATS-PFM-DJE-017-02, ATS-PFM-DJE-017-08, ATS-PFM-DJE-017-09, ATS-PFM-DJE-017-10, TST-PFM-DJE-122]
    statement: >-
      The reset contract clears participating domain data, jobs and producer mappings while preserving
      security, uploads, run records and retained implementation configuration; CRM fixtures demonstrate
      removal of loaded CRM records.
    kind: policy
    enforced_at:
      - service
    must_prove: true
    provenance: test
    source: >-
      services-crm:modules/data-jobs/tests/integration/services/jobs/initial-import-guarantees.integration.spec.js#removes
      everything the load wrote: no contact, organization, imported type or crosswalk row is left
    origin: 'services-platform:docs/milestones/plans/PLAT-M19-plan.md#S23'
  - id: BR-CAP-PFM-DJE-017-03
    proved_by: [ATS-PFM-DJE-017-03]
    statement: The reset contract refuses unsupported service participants before any removal.
    kind: validation
    enforced_at:
      - service
    must_prove: true
    provenance: documented
    source: 'services-platform:docs/data-jobs/tenant-reset.md#3.1 Declaring support'
    origin: none
  - id: BR-CAP-PFM-DJE-017-04
    proved_by: [ATS-PFM-DJE-011-12, ATS-PFM-DJE-015-08, ATS-PFM-DJE-016-17, ATS-PFM-DJE-017-04, ATS-PFM-DJE-017-08, ATS-PFM-DJE-017-09, ATS-PFM-DJE-017-10, TST-PFM-DJE-122]
    statement: >-
      In the cited reset fixtures, repeating reset removes nothing, another workspace remains intact and
      reloading the package reproduces records and numbers.
    kind: invariant
    enforced_at:
      - service
      - database
    must_prove: true
    provenance: test
    source: >-
      services-crm:modules/data-jobs/tests/integration/services/jobs/initial-import-guarantees.integration.spec.js#reloads
      the same records as the load before the reset, numbers included
    origin: 'services-platform:docs/milestones/plans/PLAT-M22-plan.md#9. Acceptance scenarios'
  - id: BR-CAP-PFM-DJE-017-05
    proved_by: [ATS-PFM-DJE-016-17, ATS-PFM-DJE-017-09]
    statement: >-
      A failed reset can leave domain data partly removed while the workspace remains loading; another
      attempt starts the participant sequence again.
    kind: lifecycle
    enforced_at:
      - service
    must_prove: false
    provenance: documented
    source: 'services-platform:docs/data-jobs/tenant-reset.md#1. When a tenant may be reset'
    origin: none
  - id: BR-CAP-PFM-DJE-017-06
    proved_by: [ATS-PFM-DJE-017-05]
    statement: >-
      Activation uses permission separate from loading and reset, restoring active lifecycle without
      changing workspace status.
    kind: permission
    enforced_at:
      - api
    must_prove: true
    provenance: documented
    source: 'services-platform:docs/data-jobs/data-runs.md#7. The summary and the readiness verdict'
    origin: 'services-platform:docs/milestones/plans/PLAT-M22-plan.md#A3'
  - id: BR-CAP-PFM-DJE-017-07
    proved_by: [ATS-PFM-DJE-017-06]
    statement: >-
      The product should refuse activation while load-readiness blockers remain; the cited activation
      implementation does not yet apply that gate.
    kind: policy
    enforced_at: []
    must_prove: true
    provenance: documented
    source: 'services-platform:docs/milestones/plans/PLAT-M22-plan.md#A3'
    origin: 'services-platform:docs/milestones/plans/PLAT-M22-plan.md#A3'
  - id: BR-CAP-PFM-DJE-017-08
    proved_by: [ATS-PFM-DJE-017-07]
    statement: >-
      A loading workspace permits its users to reach allowed job and reconciliation routes while ordinary
      routes report unavailable.
    kind: policy
    enforced_at:
      - api
    must_prove: true
    provenance: documented
    source: 'services-platform:docs/data-jobs/platform-data-operations.md#Reading a load back by source key'
    origin: 'services-platform:docs/milestones/plans/PLAT-M19-plan.md#A7'
scenarios:
  - id: SC-CAP-PFM-DJE-017-01
    given: A loading workspace received input with incorrect mappings.
    when: Staff reset its data and register corrected input.
    then: >-
      The earlier loaded records are removed and the new load uses retained implementation support,
      including uploads and users.
    provenance: test
    source: >-
      services-crm:modules/data-jobs/tests/integration/services/jobs/initial-import-guarantees.integration.spec.js#applies
      every item of every file of the reload, nothing being recognised from before the reset
edge_cases: []
constraints: []
depends_on: []
related:
  - CAP-PFM-DJE-016
  - CAP-PFM-DJE-015
journeys:
  - JNY-PFM-DJE-004
open_questions: []
evidence:
  - >-
    Reviewed evidence: services-platform (ad3f6a65): docs/data-jobs/tenant-reset.md, data-runs.md §7;
    modules/data-jobs/services/maintenance/tenant-participant.ts, data-operations-participant.ts;
    services/persistence/tenant-purges.ts; the reset, loading and activation routes in modules/tenants
    (named as a dependency only); docs/milestones/PLAT-M22 record and plan.
  - >-
    Reviewed evidence: services-crm (a8d1364f): docs/data-jobs.md (Reset); tests
    initial-import-guarantees.integration.spec.js.
controls: [TC-AVL-001, TC-AVL-004, TC-AZ-001, TC-AZ-002, TC-AZ-003, TC-AZ-004, TC-AZ-005, TC-CHG-001, TC-CHG-002, TC-CHG-003, TC-CHG-004, TC-CHG-005, TC-CHG-006, TC-CHG-007, TC-DAT-001, TC-DAT-002, TC-DAT-003, TC-DAT-006, TC-IAM-003, TC-LOG-001, TC-LOG-004, TC-LOG-005, TC-MON-001, TC-PI-001, TC-PI-002, TC-PI-004, TC-PI-005, TC-TEN-001, TC-TEN-002, TC-TEN-003, TC-VEN-001, TC-VEN-002, TC-VEN-003]
exercised_by: [FAS-PFM-DJE-05-01, FAS-PFM-DJE-05-02, FAS-PFM-DJE-05-03, FAS-PFM-DJE-05-05]
suites: [TST-PFM-DJE-122]
---

# Reset a loading workspace and review its release

## Purpose

Implementation staff recover from a faulty initial load while a separate activation decision controls when ordinary workspace work can resume.

## How It Works

Implementation staff request reset when correcting individual records cannot repair an initial load. They confirm the intended workspace and its loading context. The reset contract checks participant support before removal. Participant work clears loaded records and mappings while retaining the resources needed to load again. A failed sequence can leave partial removal and must be addressed before repeating it. Existing CRM fixtures demonstrate repeatable removal and reload within their tested participant set. Reconciliation then supports review of the new load. A separately authorized operator releases the workspace through activation. The planned blocker check is absent, so an active lifecycle is currently not proof that the load passed readiness.

## Relationships

- Migration runs supply the initial load that reset clears.
- Producer-key reconciliation supports review before release.
