Skip to main content

Trusted Federation (Preview)

If a term is unfamiliar, open the Glossary.

Trusted Federation is an autonomous capability for workspace-scoped partner registries and signed policy-intent exchange.

Workspace participation control​

  • Workspace self-service participation lives in #/settings.
  • The route now opens on Overview first and keeps the actual opt-in toggle under Participation.
  • The toggle controls whether your workspace contributes vote-only community trust signals to the federated pool.
  • Comments remain workspace-private even when participation is enabled.

What workspaces can do​

  • create/read federation partner entries
  • create/read signed intent exchange entries
  • keep every write decision in immutable decision logs

API endpoints​

  • GET /api/autonomous/contracts/federation
  • GET /api/autonomous/federation/partners
  • POST /api/autonomous/federation/partners
  • GET /api/autonomous/federation/partners/<partner_id>
  • GET /api/autonomous/federation/intents
  • POST /api/autonomous/federation/intents
  • GET /api/autonomous/federation/intents/<intent_id>
  • GET /api/autonomous/federation/memory
  • GET /api/autonomous/federation/memory/summary
  • GET /api/autonomous/federation/quality-monitor
  • GET /api/autonomous/federation/scale
  • GET /api/autonomous/federation/readiness-delta
  • GET /api/autonomous/federation/quarterly-review-bundle
  • POST /api/autonomous/federation/simulation-harness/run
  • POST /api/autonomous/federation/self-heal/reconcile
  • POST /api/autonomous/federation/performance-profile
  • POST /api/autonomous/federation/security-posture
  • POST /api/autonomous/federation/workflows/start
  • GET /api/autonomous/federation/workflows/<workflow_id>
  • POST /api/autonomous/federation/workflows/<workflow_id>/approve
  • POST /api/autonomous/federation/workflows/<workflow_id>/retry
  • POST /api/autonomous/federation/workflows/<workflow_id>/rollback
  • GET /api/autonomous/federation/workflows/<workflow_id>/evidencepack
  • GET /api/autonomous/federation/workflows/<workflow_id>/evidencepack/verify

Federation workflow orchestration​

Use this sequence for governed and auditable federation execution:

  1. Create or reuse a partner.
  2. Create an intent (status=accepted for lower-friction execution or status=proposed for approval flow).
  3. Start workflow with intent_id and idempotency_key.
  4. If response is approval_required, run /approve using a second approver account.
  5. If execution fails transiently, run /retry.
  6. Pull and verify EvidencePack (Dralvia's exportable evidence report) for compliance evidence.
  7. If needed, run /rollback.

Action execution and rollback behavior​

  • Federation workflow actions are tracked in workspace action-state as:
    • resource_type=federation_intent
    • resource_id=<intent_id>
  • Query state with:
    • GET /api/autonomous/action-state?tenant_id=<tenant>&resource_type=federation_intent&resource_id=<intent_id>
  • After successful execution the state shows an exchanged intent.
  • After rollback the state is restored to the previous value.

EvidencePack automation parity​

  • Successful federation workflows automatically generate an EvidencePack.
  • Retrieve pack:
    • GET /api/autonomous/federation/workflows/<workflow_id>/evidencepack
  • Verify pack integrity and transparency inclusion:
    • GET /api/autonomous/federation/workflows/<workflow_id>/evidencepack/verify
  • If the workflow has not executed yet (for example pending_approval), these endpoints return evidencepack_not_available.

Federation memory store​

  • Federation workflow pointers are retained in workspace-scoped long-term memory namespace:
    • federation_workflow_memory
  • Read retained entries:
    • GET /api/autonomous/federation/memory
    • optional query params:
      • limit (default 100, max 500)
      • include_expired=true
      • memory_key_prefix=intent:<INTENT_ID>
  • Read summary totals/retention view:
    • GET /api/autonomous/federation/memory/summary

Federation model drift + quality monitoring​

  • Drift/quality monitor API:
    • GET /api/autonomous/federation/quality-monitor
  • Query params:
    • window_days (default 30, max 365)
    • limit (default 1000, max 5000)
  • Response includes:
    • per-action EMA quality score and drift score
    • drift alert flags by threshold
    • federation workflow success/failure/pending summary
  • Alert thresholds:
    • drift alert when score exceeds 0.15 for 15m
    • quality alert when score falls below 0.70 for 15m

Scale and Multi-workspace Load​

  • Endpoint:
    • GET /api/autonomous/federation/scale
  • Purpose:
    • shows workflow and memory quota headroom for trusted federation
    • helps prove noisy-neighbor isolation per workspace
  • Policy gate:
    • requires federation.scale.read
  • Response 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 federation scale snapshot​

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

Federation readiness delta report​

  • Endpoint:
    • GET /api/autonomous/federation/readiness-delta
  • Purpose:
    • compare current-window federation readiness against the previous window for the same workspace
    • track trend deltas for readiness score, drift alerts, and failed workflows
  • Useful query params:
    • window_days (default 90, min 30, max 365)
    • persist_report (default true)
  • Response includes:
    • current_window and previous_window snapshots
    • delta values (readiness_score, drift_alert_actions, failed_workflows, alert_breaches)
    • alert_breach_trend (improved, flat, regressed)

Auditor quarterly review bundle​

  • Endpoint:
    • GET /api/autonomous/federation/quarterly-review-bundle
  • Purpose:
    • export an auditor-ready JSON bundle with federation readiness, quality, security, scale, and compliance evidence
    • include section hashes and top-level bundle hash for integrity checks
  • Useful query params:
    • window_days (default 90, min 30, max 365)
    • limit evidence row cap (default 500, max 1000)
    • persist_bundle (default true)
  • Response includes:
    • sections.readiness
    • sections.readiness_delta
    • sections.quality_monitor
    • sections.security_posture
    • sections.scale_snapshot
    • sections.compliance_summary
    • sections.federation_evidence
    • sections.memory_summary
    • sections.supportability
    • sections.evidence_rows
    • section_hashes and bundle_hash

Federation simulation harness expansion​

  • Deterministic simulation harness API:
    • POST /api/autonomous/federation/simulation-harness/run
  • Useful inputs:
    • seed (default 1337)
    • min_scenarios (default 20)
    • chaos_profile (default baseline)
      • supported values:
        • baseline
        • partner_trust_degradation
        • upstream_policy_instability
        • combined
    • verify_deterministic (default true)
    • persist_report (default true)
  • Returns:
    • deterministic replay status
    • summary report (scenario_count, pass_rate)
    • selected chaos_profile in response/report for replay traceability
    • federation quality snapshot in the report
    • memory pointer when persisted:
      • namespace: federation_simulation_harness
      • key: latest

Federation self-healing routines​

  • Scoped self-heal reconcile API:
    • POST /api/autonomous/federation/self-heal/reconcile
  • Purpose:
    • retries transiently failed federation workflows with remaining retry budget
    • stays workspace-scoped and policy-gated
  • Useful input:
    • limit (default 25, max 100)
  • Response:
    • workflow_scope=federation_policy_exchange_workflow
    • recovered_count
    • recovered workflow list with attempt and MTTR metadata

Federation performance profiling​

  • Endpoint:
    • POST /api/autonomous/federation/performance-profile
  • Purpose:
    • measures p50/p95 latency and outcome rates for federation workflows
    • supports per-workspace profiling windows and retention of latest report
  • Useful inputs:
    • window_days (default 7)
    • limit (default 500, max 2000)
    • target_seconds (default 30.0)
    • persist_report (default true)
    • include_workflows (default true)
  • Response:
    • workflow_scope=federation_policy_exchange_workflow
    • summary totals and success/failure rates
    • execution/end-to-end/startup latency percentiles
    • latest report memory pointer when persisted:
      • namespace: federation_performance_profile
      • key: latest

Security Hardening Posture​

  • Endpoint:
    • POST /api/autonomous/federation/security-posture
  • Purpose:
    • validates federation policy action coverage required for secure operations
    • reports latest autonomous security-hardening gate status for SBOM/vulnerability policy checks
  • Response includes:
    • policy_coverage (required_actions, present_actions, missing_actions, valid)
    • security_gate (gate pass/fail summary and artifact metadata)
    • tracked_vulnerability_exceptions metadata
  • posture_ok boolean and recommendations when remediation is needed

Guardrails​

  • default-deny policy enforcement
  • same-workspace isolation for workspace-scoped keys
  • cross-workspace requests blocked
  • confidence/evidence/rollback attached to write decisions
  • high-risk federation workflows require approval (pending_approval) before execution
  • requester cannot self-approve; a second approver identity is required

Notes​

  • Contracts and safe skeleton APIs are available.
  • Federation workflow execution and rollback orchestration are available.

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:

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

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.

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:

  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.

ErrorMeaningWhat to do now
401 UnauthorizedSession 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 ForbiddenYou 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 FoundThe 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 RequestsRate limit/quota window was exceeded.Wait for cooldown/reset window, retry once, then reduce burst traffic/backoff if automated.
500 Internal Server ErrorBackend 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.