Autonomous Readiness

Use this page when you want to answer one question fast: "Is our workspace ready to run autonomous controls safely?" If a term is unfamiliar (for example autonomous readiness probe, idempotency key, or SLO), open the Glossary.

This guide is written for workspace admins and security leads with no prior Dralvia background.

Quick start (10 minutes)

1. Open #/autonomous-readiness and read the Overview status cards.
2. Open Modules and identify one blocked/degraded module.
3. Open Probes and run the relevant readiness probe.
4. Apply one corrective action in the relevant tab.
5. Re-run the probe and confirm status improvement.

Readiness tabs

#/autonomous-readiness opens on an overview-first layout so workspace admins can review one job at a time.

• Overview summarizes module enablement, workflow volume, pending approvals, audits, and support catalog coverage.
• Probes contains standard, deception, systemic, crisis, and federation readiness probe actions plus refresh.
• Federation contains trusted-federation readiness, partner/intent registry posture, workflow memory, quality monitor, scale, and security posture.
• Profiles contains continuity mode, deception readiness, Global Early Warning/systemic readiness, and crisis coordination readiness.
• Modules contains workspace module enablement toggles.
• Compliance contains CSV/JSON evidence export and compliance matrix preview.
• Support contains runbook/error-catalog/failure-mode links and known supportability entries.
• Activity contains recent autonomous actions and audit entries.

Deep dive setup flow (GUI + API parity)

Prerequisites

• Active workspace API key.
• Workspace modules provisioned for the capabilities you want to validate.
• Operator account with readiness module write permissions.

Exact fields to fill

• Module toggle: enabled (boolean) and module key path parameter.
• Probe request: optional profile (standard|deception|systemic|crisis|federation), optional idempotency_key.

Step-by-step flow

1. GUI: load readiness dashboard and note failing modules in Overview or Modules.
2. API parity: GET /api/autonomous/tenant-readiness.
3. GUI: open Modules and toggle module state if required.
4. API parity: POST /api/autonomous/tenant-readiness/modules/{module_key}.
5. GUI: open Probes, run the relevant probe, and watch result.
6. API parity: POST /api/autonomous/tenant-readiness/probe with explicit idempotency_key.

Expected result

• Module states are consistent between UI and API.
• Probe returns actionable status and details.
• Readiness summary trends toward ready after remediation.

Rollback path

1. Revert module toggle to previous known-good state.
2. Re-run readiness probe to confirm restored status.
3. Keep degraded mode if rollback is safer, then escalate for guided remediation.

Annotated screenshot

Figure: Detect blocked module, apply corrective action, and confirm probe recovery.

What this page does

The Autonomous Readiness workspace (#/autonomous-readiness) gives you:

• A readiness score for your workspace.
• Module-by-module status (for example: data quality, policy guardrails, evidence, rollback readiness).
• Guided actions to fix blockers.
• Probe checks you can run before enabling or changing automation.
• Dedicated route sections for probes, federation posture, readiness profiles, module toggles, compliance evidence, supportability, and activity/audit review.

What probes check (and what they do not)

Readiness probes are workspace-scoped control-plane checks. They evaluate Dralvia module health, workflow assets, and policy/safety prerequisites for your workspace.

They do not packet-capture your network or inspect all workspace traffic in real time.

What probes use:

• Workspace workflow/audit state (recent workflow runs, decision logs, approvals).
• Workspace module assets already in Dralvia (for example memory snapshots, simulation reports, performance profiles, evidence markers).
• Profile-specific synthetic probe seeding where needed (for example systemic readiness can seed safe synthetic signals).

Profile behavior at a glance:

• standard: runs a low-impact readiness workflow check path.
• deception: validates deception workflow readiness.
• systemic: validates systemic-anomaly readiness and can seed safe synthetic signals.
• crisis: validates crisis-coordination readiness and can create probe coalition/incident assets.
• federation: validates trusted-federation readiness and can create probe partner/intent assets.

Use probes to verify readiness before enabling autonomous actions, after major config/policy changes, and during recurring operational reviews.

Who should use it

• Workspace owner
• Workspace admin
• Security operations lead

If you are an analyst with read-only access, you can still review status but might not be able to save changes.

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

Confirm these prerequisites:

1. You are signed in with a workspace account.
2. Your account has admin-level permissions for readiness settings.
3. Your workspace has active data flow from the modules you care about (EDR, SWG, identity, scan pipelines).
4. Your browser clock is correct (time skew can affect freshness checks).

Step-by-step: first readiness review

1. Open #/autonomous-readiness.
2. In Overview, identify:
   • Module enablement count.
   • Recent workflow volume.
   • Pending approvals.
   • Recent audit volume.
3. Open Modules and read:
   • Current status (ready, degraded, blocked).
   • Why that status was assigned.
   • Recommended corrective action.
4. Open Probes and click Run probe (or equivalent check action) for modules that are degraded/blocked.
5. Wait for probe results and confirm:
   • Blockers are cleared, or
   • You have explicit remediation items.
6. Save any available configuration updates.
7. Re-run probe to confirm the status moved from blocked/degraded to ready.

How to interpret module states

• ready: safe to proceed for that module.
• degraded: module is running but with reduced confidence; review before enabling high-impact actions.
• blocked: hard stop; fix before using autonomous actions in that area.

What each common action means

• Run probe: executes a non-destructive health/readiness check.
• Save module: persists workspace-scoped module config.
• Refresh: reloads readiness data from backend.
• View details: opens raw signals and computed reasons behind the score.

Common problems and fixes

"Unable to load workspace readiness"

Possible causes:

• Temporary API/network issue.
• Expired session token.
• Missing workspace-scoped permission.

What to do:

1. Hard refresh the page.
2. Sign out/in once.
3. Retry after 30-60 seconds.
4. If still failing, capture timestamp + workspace ID and contact support.

Probe fails for one module

Possible causes:

• Upstream service unavailable.
• Missing API key/license for that module.
• Invalid module configuration.

What to do:

1. Read the exact probe error text in the module panel.
2. Fix configuration or credentials.
3. Re-run the same probe.
4. Confirm status flips to ready before moving on.

Daily operating pattern (recommended)

1. Check readiness at start of day.
2. Resolve all blocked modules first.
3. Record any degraded modules and owner.
4. Re-check after major policy/config changes.

API parity (optional)

If your team automates checks, use the workspace readiness endpoints exposed by Dralvia (same data source as UI). UI remains the recommended path for most teams.

Escalation checklist

When opening a support case, include:

• Workspace ID
• Module name
• Exact error text
• Timestamp (UTC)
• Screenshot of module state

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.

Step-by-step

Follow this sequence for predictable results:

1. Open the workspace from the workspace menu.
2. Review current status/health/last update indicators before making changes.
3. Apply one change at a time and save.
4. Run the available validate/probe/refresh action.
5. Confirm the expected output appears (status change, new event, successful result).
6. 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:

1. Daily: verify data freshness and error banners.
2. Weekly: review trends, limits, and failed actions.
3. Monthly: review permissions, keys/tokens, and stale entities.
4. 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:

1. Configuration: confirm required inputs are present and formatted correctly.
2. Permission: confirm your role can perform the action (401/403 usually indicates authz/authn mismatch).
3. License/feature: confirm the feature is enabled for your workspace plan and module toggles.
4. Quota/rate limit: check for 429 responses and cooldown windows.
5. 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:

1. Auth/session: refresh token by signing out/in.
2. Workspace context: confirm you are in the correct workspace.
3. Inputs/config: verify required fields and formats.
4. Quota/license: confirm limits and feature entitlement.
5. 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.

GUI -> API quick map

GUI action	API endpoint	Expected outcome
Load readiness dashboard	GET /api/autonomous/tenant-readiness	Returns module states, summary, actions, and audits.
Toggle module state	POST /api/autonomous/tenant-readiness/modules/{module_key}	Updates workspace module enablement.
Run readiness probe	POST /api/autonomous/tenant-readiness/probe	Starts/returns readiness probe workflow status.
Review supportability catalog	GET /api/autonomous/support/errors	Returns workspace-readable top autonomous errors/actions.

Copy-paste curl examples

BASE_URL="https://dralvia.tech"
API_KEY="YOUR_TENANT_API_KEY"
MODULE_KEY="deception"

curl -sS "$BASE_URL/api/autonomous/tenant-readiness" \
  -H "X-API-Key: $API_KEY"

curl -sS -X POST "$BASE_URL/api/autonomous/tenant-readiness/modules/$MODULE_KEY" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $API_KEY" \
  -d '{"enabled":true}'

Postman collection notes

• Store module_key and profile (standard|deception|systemic|crisis|federation) as variables.
• Add one request each for dashboard GET, module toggle POST, and probe POST.
• Keep probe response IDs so operators can correlate with workflow/audit views.

Idempotency and retry guidance

• GET /api/autonomous/tenant-readiness is safe to retry.
• Use an explicit idempotency_key in probe requests for safe replay semantics.
• For module toggles, verify current state with GET before repeating writes.

Next best actions

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

• EDR response and host actions
• Web Access Protection and dry-run events
• Identity risk and OAuth response
• EvidencePack verification and transparency log
• Risk economics and plan recommendation

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:

1. Validate the result in the related dashboard/workspace.
2. Export or capture evidence if this affects compliance/incident operations.
3. Share the same runbook internally so other operators follow identical steps.
4. 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:

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