Features and compliance packages

Before Dockt can evaluate an Assessment, it needs to know which compliance rules your Workspace intends to apply. Workspace Features and social compliance packages provide that configuration.

Features is the active configuration for one Workspace. Social compliance packages are versioned sets of requirements and guidance that Features can enable. You configure them once for the Workspace; you don’t choose packages separately on every Assessment request.

Social compliance packages

A social compliance package describes the possible evidence, requirements, and obligations for a compliance workflow. The package catalog is the list of packages your Workspace can select. Read it with GET /v1/social-compliance-packages and use its package codes when updating Features.

Package catalog entries describe what a package may evaluate. They are not a fixed document checklist. The evidence that is actually required can differ between workers because Dockt considers the worker identity and Assessment context together with the enabled packages.

Your integration should therefore use the catalog for Workspace configuration, then use each Assessment’s requirements as the checklist for that specific case.

Workspace Features

Read the active Workspace configuration with GET /v1/features. Enable package codes with PATCH /v1/features:

{
  "social_compliance_packages": [
    "PACKAGE_CODE"
  ]
}

Use package codes returned by the catalog. The API rejects package codes that can’t be enabled.

Configure Features before creating your first Assessment. A standalone Document can still be processed independently, but an Assessment needs Workspace Features to determine what to evaluate.

Effect on Assessments

When you create an Assessment, Dockt applies the Workspace’s current Features automatically. You don’t send a Features ID or package list in the Assessment request. The response records what was applied so the result remains understandable later:

• features_id, which identifies the configuration used.
• applied_packages, which records the applied package code and version.
• input_requests, which asks for context still needed.
• requirements, which reports required evidence and its status.
• advisories, which reports external or planning obligations.

features_id identifies the exact Workspace configuration used for that Assessment input version. applied_packages records the package code and version used by the evaluation. Store these fields with high-impact results when you need to show which configuration produced them.

Changing Features can cause existing Assessments to be evaluated again. A new result creates a new immutable Decision for a newer Assessment input version; it doesn’t rewrite an earlier Decision.

Requirements and advisories

A requirement represents evidence that the current Assessment may need. Its status is:

• missing: required evidence has not been satisfied.
• not_required: the requirement doesn’t apply to this Assessment.
• satisfied: accepted evidence supports the requirement.

Use the requirement’s document ID lists to understand which uploads support it, are still processing, require review, or are invalid. This lets your product distinguish “upload still processing” from “evidence is missing” or “uploaded evidence needs review.”

An advisory describes an obligation or consideration that may sit outside the uploaded evidence. Its severity and optional phase indicate how and when to surface it. An advisory doesn’t satisfy evidence and doesn’t make an evidence requirement incomplete by itself; treat it as separate workflow guidance.