Concepts

Draxis workflows

Declarative tenant workflows: a trigger, a sequence of steps, and the KRI events they emit. Authored through a guided interview; versioned; auditable.

Anatomy

A workflow has three parts:

  • Trigger — what starts a run. Either a KRI threshold breach, a scheduled time, or a manual button.
  • Steps — ordered actions: notify an owner, open a ticket in Jira/ServiceNow, run an expert-panel query, produce a document, post to Slack, wait for human approval.
  • KRI events — structured events emitted by steps that feed back into the risk model (e.g. “patch confirmed” closes the breach).

Authoring via interview

Workflows aren’t authored in JSON. The tenant admin starts a workflow interview (POST /api/workflow-interviews), and an LLM walks them through the workflow conversationally — trigger, steps, owners, approvals. When the admin is happy they confirm, which turns the interview transcript into a concrete workflow definition and archives the transcript for audit.

Lifecycle

  1. Draft — newly authored, not yet runnable.
  2. Active — runs on its trigger (POST /api/workflows/<id>/activate).
  3. Paused — trigger disabled; existing in-flight runs finish (POST /api/workflows/<id>/pause).
  4. Archived — read-only, preserved for audit (POST /api/workflows/<id>/archive).

Versioning

Every change to a live workflow creates a new workflow version. Existing in-flight runs keep executing against the version they started under; new runs pick up the latest active version. The change log (GET /api/workflows/<id>/change-log) shows every edit with the actor, a diff, and a reason.

KRI events

Workflow steps can emit structured events back into the risk model. Example: a “patch critical CVE” workflow emits a patch_applied event that decrements the critical_cves_unpatched KRI when the patch is confirmed. Event types and their effects on KRIs are declared via workflow_kri_definitions (see PUT /api/workflow-kri-definitions/<id>).

Relay config

Many workflow steps fan out to external systems (Slack, Jira, email). The relay config (GET /api/relay-config) holds the per-tenant connection settings for those destinations. Credentials live in the same encrypted form as kri_source credentials.

Public preview

Tenants can share a read-only view of a workflow with an unauthenticated stakeholder via a single-use token (GET /api/public/workflow/<token>). Useful for external auditors who need to verify a control without a full login.