Frequently Asked Questions

Is Swiftward SaaS or self-hosted?

Self-hosted only. Swiftward runs on your infrastructure — on-prem, private cloud, or your own VPC. Your data never leaves your environment. We do not offer a managed SaaS version.

How is Swiftward different from OPA or Cedar?

OPA and Cedar are general-purpose policy engines focused on authorization (can user X do action Y on resource Z?). Swiftward is purpose-built for Trust & Safety:

Use OPA/Cedar for authorization. Use Swiftward for content moderation, fraud detection, and safety workflows.

Does Swiftward replace workflow orchestrators like Temporal or Airflow?

No. Swiftward is not a general BPM or workflow engine. It makes fast, synchronous policy decisions. It does not support:

• Long-running workflows
• Human-in-the-loop task assignment
• Complex branching and state machines
• Cross-service saga coordination

If you need orchestration, use Temporal/Airflow. Use Swiftward for the policy decision step within those workflows.

Can Swiftward call LLMs for content classification?

Yes, optionally. Signals (UDFs) can call external LLM APIs (OpenAI, Anthropic, local models). Example:

signals:
  toxicity_score:
    udf: llm/moderation
    params:
      text: "{{ event.data.text }}"
      provider: openai
      model: moderation

LLM calls add latency. For sync processing, consider caching or async fallback. Swiftward caches signal results within an event evaluation.

How does Swiftward handle data retention and privacy?

You control retention. Swiftward stores:

• Event queue: Until processed (configurable retention)
• Decision traces: As long as you keep them (no auto-delete)
• Entity state: Until you delete it

For GDPR/privacy, you can:

• Delete entity state on user deletion request
• Anonymize traces after retention period
• Run in isolated environment with no external access

Swiftward does not send data externally (except actions you configure, like webhooks).

What throughput can Swiftward handle?

Architecture supports horizontal scaling, but we don't publish hard numbers without benchmarking your workload. Factors:

• Postgres-only: Thousands of events/sec with tuned Postgres
• With Kafka: Higher ingestion rates, buffering for spikes
• With Redis: Faster signal caching, rate limiting at scale

For pilots, we test with your representative load. Production sizing depends on event complexity, signal latency (especially if calling LLMs), and state access patterns.

How do policy rollbacks work?

Policies are versioned. To rollback:

1. Use Control API to activate a previous version
2. New events immediately use the activated version
3. In-flight events complete with their original version
4. No restart required

You can also preview a policy version against historical events before activating.

What integrations are supported?

Event sources:

• HTTP webhooks (any system that can POST JSON)
• gRPC
• Kafka consumer (optional adapter)

Actions:

• HTTP/webhook (any endpoint)
• SCM integrations (GitHub/GitLab PR checks)
• Logging (structured output)
• Custom actions via plugin interface

Gateways (optional):

• GitHub webhooks (PR gate)
• GitLab webhooks
• Custom protocol adapters

Integrations beyond HTTP require gateway development or custom adapter.

What's the security posture?

• On-prem: Your infrastructure, your network, your controls
• No phone-home: Engine does not contact external services for operation
• Secrets: Loaded from environment variables, not stored in policies
• TLS: All HTTP/gRPC endpoints support TLS
• Audit: Every decision traced; who changed what policy, when

Why YAML for policies instead of code?

YAML provides:

• Readability: Non-engineers (T&S analysts, compliance) can review policies
• Diffability: Policy changes are easy to review in PRs
• Validation: Schema validation catches errors before deployment
• Versioning: Entire policy is a single file; easy to version and rollback
• Separation: Policy logic separate from engine code; update policies without redeploying

For complex logic, use signals (UDFs) written in code. Keep rules declarative.

Can I test policies before deploying?

Yes. Several options:

1. Dry-run mode: Evaluate events without committing state or executing actions
2. Policy preview: Run historical events against a candidate policy version
3. Unit tests: YAML-based test cases with expected verdicts
4. Shadow mode: Run new policy in parallel, compare decisions

Testing workflow is part of pilot handoff.

How does Swiftward handle failures?

• Event processing failure: Event goes to DLQ; can inspect and replay
• State commit failure: Retry with backoff; event remains in queue
• Action failure: Logged in trace; can retry actions independently
• Postgres unavailable: Queue backs up; resumes on recovery

DLQ includes failure reason, original event, and last error. Replay is one-click.

What if I need a feature that doesn't exist?

Options:

1. Custom UDF: Write a signal function for your logic
2. Custom Action: Write an action plugin for your side effect
3. Feature request: We prioritize based on design partner feedback
4. Professional services: Custom development for specific needs

Pilot includes discussion of your roadmap requirements.

Is there a UI?

Control API provides programmatic access. A minimal Admin UI is available for:

• Policy version management
• DLQ inspection
• Trace search

Full dashboards typically use your existing observability stack (Grafana, etc.) connected to Swiftward's analytics output.

What's the deployment footprint?

Minimal deployment:

• Single binary (Linux, ~50MB)
• Postgres database

That's it. Add Kafka/Redis/ClickHouse only if you need their specific capabilities.

What are the three verdict types?

Swiftward uses three verdict types:

The response field in rule effects can include additional context for the caller (e.g., blocked: true, needs_redaction: true, pending_review: true).

More Questions?

Contact: swiftward@disciplinedware.com