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.