Skip to content

Workspace configuration

Workspace Configuration is the read-only overview of the settings that apply across Assessments in one Workspace. Read it with GET /v1/workspace-configuration, then use each linked resource to make a change.

Workspace Configuration contains three typed resources:

Resource What it controls What changes when you update it
Assessment Policy Compliance packages, Workspace rules, and granular package-rule adjustments Affected Assessments are reevaluated under the new policy revision.
Monitoring Policy Whether eligible Assessments run again, the interval, and the maximum monitoring duration Eligible Assessment schedules are recalculated. Current Decisions remain valid.
Job Profile Namespaced customer job references and job-specific rules Assessments that resolve through affected references are reevaluated.

Notification Destinations and Notification Routes are separate resources. They control event delivery, not assessment behavior.

Assessment Policy defines how Dockt evaluates Assessments in a Workspace. One active policy revision combines these rule sources:

  • Dockt-maintained compliance packages selected by the Workspace.
  • Workspace rules, such as requiring every worker to be at least 18 years old.
  • Adjustments to individual package rules.
  • Rules from the Job Profile selected by an Assessment, when applicable.

Compliance packages are baselines rather than fixed document checklists. Each package contains atomic rules with stable references. You can strengthen, weaken, or waive one supported package rule without replacing the package or changing unrelated rules.

Rules from multiple packages remain independent. Dockt doesn’t automatically merge similar rules or infer that one rule replaces another. The Assessment’s requirements, advisories, and Decision show the effective result for that case.

To require uploaded proof for Job Profile qualifications, enable require_job_profile_qualification_uploads. Each qualification then requires proof of the credential being accepted, including qualifications within nested alternatives. Rule applicability and enforcement stay the same: advisory and waived rules do not block the Decision.

The setting defaults to false. An individual qualification rule can require uploaded_proof_required: true even when the policy-wide setting is disabled. Dockt records both settings in the Assessment’s immutable Effective Policy Snapshot.

See Qualification uploaded proof for the distinction between registry assurance and a matching uploaded certificate.

Every effective rule has one enforcement level:

  • required: An unmet rule can make the Decision non-compliant. An unresolved rule can make the Decision incomplete, and an ambiguous result can require review.
  • advisory: Dockt evaluates the rule and reports a non-satisfied result without blocking the Decision.
  • waived: The rule remains visible for audit but doesn’t block the Decision.

A waiver differs from a rule that doesn’t apply. A waived rule applies, but the Workspace chooses not to enforce it. A non-applicable rule doesn’t match the Assessment context.

Dockt records each package-rule adjustment with its direction, source, hashes, and reason. You must provide a reason when an adjustment weakens or waives a rule. A compliant Decision reflects the active Workspace policy; it doesn’t claim that every unmodified package baseline also passed.

Assessment Policy and Job Profiles use an immutable publication workflow:

  1. Create or retrieve a draft based on the active revision.
  2. Apply catalog-backed authoring commands with the draft’s current lock_version.
  3. Preview the complete effective rules and resolve every validation issue.
  4. Activate the draft with its current lock_version.

Each successful command increments lock_version. A stale value returns a conflict instead of overwriting another change. Active and superseded revisions can’t be edited.

Activation pins the package versions, Qualification Definition revisions, and compiled rules used by the policy. Each Assessment input version then pins an immutable Effective Policy Snapshot. Later configuration changes can produce a new Decision, but they never rewrite an earlier Decision.

Read GET /v1/policy-authoring-catalog before you build a policy-authoring interface. The response contains the facts, operators, evidence types, Qualification Definitions, comparison presets, assurance levels, rule templates, and package-rule operations accepted by the API.

Use catalog values unchanged. Don’t let authors type internal fact codes, Qualification Definition IDs, resolver names, or expression trees. The API validates every command against the same catalog and compiler used at runtime.

Monitoring Policy controls periodic reevaluation without changing evaluation rules. Periodic mode requires both interval_hours and max_duration_days. Disabled mode contains neither value.

Assessment context can further limit monitoring:

  • assignment.start_date can schedule a run on the first assignment date.
  • The inclusive assignment.end_date prevents later scheduled runs.
  • Without an assignment end date, the Workspace maximum duration starts at Assessment creation.
  • assessment.evaluation_date makes the Assessment point-in-time and prevents periodic monitoring.
  • monitoring_enabled can stop or resume monitoring for one Assessment.

Changing Monitoring Policy reschedules eligible Assessments. It doesn’t invalidate their current Decisions. When monitoring produces a material change, Notification Delivery can route assessment.reassessed through the Workspace’s existing Notification Routes.

Follow Configure Assessment and Monitoring Policy to select packages, add rules, preview the result, activate the revision, and set monitoring behavior.

Follow Configure Job Profiles when your customer system sends job identifiers that require job-specific documents, facts, or qualifications.