Crisis Coordination (Coalitions + Incidents)

If a term is unfamiliar, open the Glossary.

Dralvia can help you coordinate multi-step security response work using a small, workspace-scoped "crisis coordination" layer:

Coalitions: a lightweight registry of the groups you coordinate with (business units, response teams, external partners, etc.).
Incidents: a simple incident object with an event timeline.

This is designed for UI-first operations, but it also works via API for automation and integrations.

What You Get

A workspace-scoped coalition registry (coalitions)
A workspace-scoped incident list with timeline events (incidents)
Every write emits a decision envelope with:
- confidence (0..1)
- evidence (structured)
- rollback (structured)

Quick Start (API)

Prerequisites:

A workspace API key (X-API-KEY) created in Dralvia.

1) Create a coalition

curl -sS -X POST "https://dralvia.tech/api/autonomous/coalitions" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY" \\
  -H "Content-Type: application/json" \\
  -d '{ "name": "Coalition Alpha" }'

2) List coalitions

curl -sS "https://dralvia.tech/api/autonomous/coalitions" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY"

3) Create an incident

curl -sS -X POST "https://dralvia.tech/api/autonomous/incidents" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY" \\
  -H "Content-Type: application/json" \\
  -d '{ "title": "Credential leak triage" }'

4) List incidents

curl -sS "https://dralvia.tech/api/autonomous/incidents" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY"

Crisis Workflows (Approvals + EvidencePack)

Once you have an incident_id, you can trigger a crisis workflow tied to that incident.

Example: isolate a host (this is considered high-risk, so it requires a second approver).

5) Start a crisis workflow

curl -sS -X POST "https://dralvia.tech/api/autonomous/crisis/workflows/start" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY" \\
  -H "Content-Type: application/json" \\
  -d '{
    "incident_id": "<INCIDENT_ID>",
    "idempotency_key": "crisis-workflow-001",
    "action": "host.isolate",
    "target": { "host_id": "host-01" }
  }'

If approval is required, the API returns 202 and includes workflow_id.

6) Approve the workflow (second approver)

curl -sS -X POST "https://dralvia.tech/api/autonomous/crisis/workflows/<WORKFLOW_ID>/approve" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY" \\
  -H "X-Actor: <SECOND_APPROVER>"

7) Verify the EvidencePack

curl -sS "https://dralvia.tech/api/autonomous/crisis/workflows/<WORKFLOW_ID>/evidencepack/verify" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY"

8) Roll back (if needed)

curl -sS -X POST "https://dralvia.tech/api/autonomous/crisis/workflows/<WORKFLOW_ID>/rollback" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY"

The incident timeline will show transcript events like incident.workflow.requested and incident.workflow.succeeded.

Long-Term Memory (Workflow Pointers)

For reliability and auditability, Dralvia stores a small per-incident pointer to the most recent crisis workflow status in the workspace-scoped autonomous memory store.

This powers readiness and support workflows without requiring you to keep your own state.

List crisis workflow memory entries

curl -sS "https://dralvia.tech/api/autonomous/crisis/memory" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY"

Summarize crisis workflow memory usage

curl -sS "https://dralvia.tech/api/autonomous/crisis/memory/summary" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY"

Drift + Quality Monitoring

Dralvia also exposes a workspace-scoped quality monitor for crisis workflows.

It tracks confidence drift against your configured baseline.
It summarizes healthy vs alerting crisis actions.
It reports crisis workflow success/failure shape for the selected window.
Monitor endpoint: GET /api/autonomous/crisis/quality-monitor

Read crisis quality monitor snapshot

curl -sS "https://dralvia.tech/api/autonomous/crisis/quality-monitor?window_days=30&limit=1000" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY"

Scale & Multi-workspace Load

Dralvia exposes a crisis scale snapshot so workspaces can self-check quota headroom and verify noisy-neighbor isolation.

Endpoint: GET /api/autonomous/crisis/scale
Policy gate: requires crisis.scale.read
Output includes:
- workflow_quota (active_limit, active_workflows, available_slots, utilization_percent, per_workflow_type)
- memory_quota (total_entries, active_entries, expired_entries, per_namespace)

Read crisis scale snapshot

curl -sS "https://dralvia.tech/api/autonomous/crisis/scale" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY"

Simulation Harness Expansion

Dralvia provides a deterministic simulation harness for crisis workflows so your workspace can replay crisis scenarios safely.

Endpoint: POST /api/autonomous/crisis/simulation-harness/run
Supports deterministic replay verification (verify_deterministic=true)
Persists the latest report in crisis simulation memory by default

Run crisis simulation harness

curl -sS -X POST "https://dralvia.tech/api/autonomous/crisis/simulation-harness/run" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY" \\
  -H "Content-Type: application/json" \\
  -d '{
    "seed": 1337,
    "min_scenarios": 20,
    "verify_deterministic": true,
    "persist_report": true,
    "include_results": false
  }'

Self-healing Routines

Dralvia can automatically retry transiently failed crisis workflows for your workspace.

Endpoint: POST /api/autonomous/crisis/self-heal/reconcile
Scope: only crisis_coordination_workflow failures with retry budget and policy approval
Safety: cross-workspace requests are denied

Run crisis self-heal reconcile

curl -sS -X POST "https://dralvia.tech/api/autonomous/crisis/self-heal/reconcile" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY" \\
  -H "Content-Type: application/json" \\
  -d '{
    "limit": 25
  }'

Performance Profiling

Dralvia can build a workspace-scoped performance profile for crisis workflows so you can track p95 latency and success/failure ratios against your SLO target.

Endpoint: POST /api/autonomous/crisis/performance-profile
Scope: only crisis_coordination_workflow
Persisted report memory namespace: crisis_performance_profile

Run crisis performance profile

curl -sS -X POST "https://dralvia.tech/api/autonomous/crisis/performance-profile" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY" \\
  -H "Content-Type: application/json" \\
  -d '{
    "window_days": 30,
    "limit": 500,
    "target_seconds": 30,
    "persist_report": true,
    "include_workflows": false
  }'

Security Hardening Posture

Dralvia can validate your crisis coordination hardening posture by checking policy-action coverage and latest SBOM/vulnerability gate status.

Endpoint: POST /api/autonomous/crisis/security-posture
Policy gate: requires crisis.security.read
Output includes:
- policy_coverage (required_actions, present_actions, missing_actions)
- security_gate (latest gate pass/fail summary)
- tracked_vulnerability_exceptions (tracked exception count and policy path)

Read crisis security hardening posture

curl -sS -X POST "https://dralvia.tech/api/autonomous/crisis/security-posture" \
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

If you need to coordinate with another organization (another Dralvia workspace), you can share a sanitized incident transcript:

9) Export a transcript package

curl -sS "https://dralvia.tech/api/autonomous/incidents/<INCIDENT_ID>/transcript/export?tenant_id=<YOUR_TENANT_ID>" \\
  -H "X-API-KEY: CHANGE_THIS_TO_YOUR_API_KEY"

10) Import the transcript package (in the other workspace)

curl -sS -X POST "https://dralvia.tech/api/autonomous/incidents/transcript/import" \\
  -H "X-API-KEY: <OTHER_TENANT_API_KEY>" \\
  -H "Content-Type: application/json" \\
  -d '<PASTE_EXPORTED_JSON_HERE>'

Workspace Isolation

All crisis coordination data is workspace-scoped:

You cannot read or write another workspace's coalition/incident data.
Workspace context is derived from your signed-in session or workspace API key; unsupported workspace overrides are rejected.

See Workspace Playbooks -> Autonomous Security for how crisis coordination connects to EvidencePacks (Dralvia's exportable evidence reports), approvals, and response workflows.

Who this is for

This guide is for workspace owners, workspace admins, and security operators who need clear, repeatable steps without support intervention for day-to-day execution.

Role-based start here

Workspace Owner: Start with Before you start, then complete Step-by-step and Known limits and rate limits.
Workspace Admin: Focus on Step-by-step, What each button does, and API and automation.
Security Analyst: Start at Day-2 operations and Troubleshooting, then use API error quick reference.
Integrator/Engineer: Start at API and automation, then validate with Step-by-step and FAQ.

Before you start

Use this short checklist before making changes:

Confirm you are signed into the correct workspace account.
Confirm your role includes the permissions needed for this page.
Confirm your browser session is fresh (if pages behave unexpectedly, sign out/in once).
Confirm required prerequisites (API keys, agent enrollment, license, upstream integrations) are already in place.

Step-by-step

Follow this sequence for predictable results:

Open the workspace from the workspace menu.
Review current status/health/last update indicators before making changes.
Apply one change at a time and save.
Run the available validate/probe/refresh action.
Confirm the expected output appears (status change, new event, successful result).
If behavior is not as expected, use Troubleshooting below before repeating actions.

Day-2 operations

After initial setup, keep this surface healthy with a simple routine:

Daily: verify data freshness and error banners.
Weekly: review trends, limits, and failed actions.
Monthly: review permissions, keys/tokens, and stale entities.
After any incident: capture evidence and update your internal operating notes.

What each button does

Button labels can vary by module, but behavior is consistent:

Refresh: reloads the latest data from backend APIs without changing configuration.
Save: persists workspace-scoped configuration changes.
Run/Probe/Validate: executes a non-destructive health or verification action.
Download: fetches workspace-scoped artifact(s) (for example bundle, checksum, signature, or report).
Verify: checks integrity/consistency and returns pass/fail details.
Enable/Disable: toggles module behavior for your workspace; audit evidence should be recorded.

If a button appears disabled, check role permissions, required fields, and workspace license/feature entitlement first.

Self-check playbook

Use this 5-step isolation flow before escalating:

Configuration: confirm required inputs are present and formatted correctly.
Permission: confirm your role can perform the action (401/403 usually indicates authz/authn mismatch).
License/feature: confirm the feature is enabled for your workspace plan and module toggles.
Quota/rate limit: check for 429 responses and cooldown windows.
Service health: if you see 5xx, retry once after 30-60 seconds and capture exact error text.

If still failing, escalate with workspace ID, UTC timestamp, route, action, payload shape (no secrets), and screenshot/error response.

Troubleshooting

Use this quick triage order to reduce time-to-fix:

Auth/session: refresh token by signing out/in.
Workspace context: confirm you are in the correct workspace.
Inputs/config: verify required fields and formats.
Quota/license: confirm limits and feature entitlement.
Service health: retry after short delay if backend is transiently degraded.

For escalation, include workspace ID, timestamp (UTC), route name, action attempted, and full error message.

API and automation

Everything in this page should remain workspace-scoped. If your team prefers automation, use the corresponding API endpoints with the same guardrails as the UI:

Use authenticated requests bound to your workspace context.
Use idempotency/retry controls where available.
Validate outcomes in the UI after automated runs.

If your endpoint mapping is not obvious, start from Help Center and follow the linked API docs.

Next best actions

After finishing this page, continue with related workflows so your workspace setup stays end-to-end complete:

FAQ

Q: I clicked save but nothing changed. A: Refresh once, confirm permissions, and verify required fields.

Q: Why do I see missing API key/unauthorized errors? A: Confirm your workspace API key/session is valid and mapped to the correct workspace scope.

Q: Can non-admin users use this page? A: Usually read-only access is possible; write actions require workspace-admin or equivalent roles.

Next steps

After finishing this guide:

Validate the result in the related dashboard/workspace.
Export or capture evidence if this affects compliance/incident operations.
Share the same runbook internally so other operators follow identical steps.
Return to Help Center for adjacent workflows.

API error quick reference

Use this matrix when a UI action fails with an HTTP/API error.

Error	Meaning	What to do now
`401 Unauthorized`	Session token is missing/expired or request is not authenticated.	Sign out/in, refresh once, then retry. Confirm your session is active in the correct workspace.
`403 Forbidden`	You are authenticated but your role is not allowed to perform this action.	Confirm your role includes the required permission for this button/action. Ask workspace admin to grant access.
`404 Not Found`	The route/resource does not exist in current workspace context (or feature not enabled).	Confirm URL/route, workspace context, and feature availability. Refresh and retry; if persistent, capture timestamp and route and contact support.
`429 Too Many Requests`	Rate limit/quota window was exceeded.	Wait for cooldown/reset window, retry once, then reduce burst traffic/backoff if automated.
`500 Internal Server Error`	Backend failed unexpectedly while processing the request.	Retry after 30-60 seconds. If still failing, escalate with workspace ID, UTC time, route, action, and full error text.

Known limits and rate limits

These limits can vary by plan and feature, but behavior is consistent:

Burst traffic can trigger 429 Too Many Requests.
Workspace quotas apply per feature/module and reset on configured windows.
Repeated retries without backoff can extend recovery time during saturation.

Recommended operator behavior:

Retry once after cooldown for 429 responses.
Use exponential backoff in automation.
Monitor usage/quota dashboards for sustained high utilization.
Request quota review when normal workload regularly approaches limits.

What You Get​

Quick Start (API)​

1) Create a coalition​

2) List coalitions​

3) Create an incident​

4) List incidents​

Crisis Workflows (Approvals + EvidencePack)​

5) Start a crisis workflow​

6) Approve the workflow (second approver)​

7) Verify the EvidencePack​

8) Roll back (if needed)​

Long-Term Memory (Workflow Pointers)​

List crisis workflow memory entries​

Summarize crisis workflow memory usage​

Drift + Quality Monitoring​

Read crisis quality monitor snapshot​

Scale & Multi-workspace Load​

Read crisis scale snapshot​

Simulation Harness Expansion​

Run crisis simulation harness​

Self-healing Routines​

Run crisis self-heal reconcile​

Performance Profiling​

Run crisis performance profile​

Security Hardening Posture​

Read crisis security hardening posture​

Share Incident Transcript (Multi-Org)​

9) Export a transcript package​

10) Import the transcript package (in the other workspace)​

Workspace Isolation​

Next​

Who this is for​

Role-based start here​

Before you start​

Step-by-step​

Day-2 operations​

What each button does​

Self-check playbook​

Troubleshooting​

API and automation​

Next best actions​

FAQ​

Next steps​

API error quick reference​

Known limits and rate limits​