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 moderation platforms like Hive or Checkstep?

Hive, Checkstep, and similar vendors provide classification signals — toxicity scores, CSAM detection, category labels. Swiftward provides the full enforcement layer: signals, policy rules, stateful decisions, actions, HITL queues, and audit trails. You can use Swiftward with your existing classifiers as signal inputs, or use Swiftward's built-in signals, or both. All on your infrastructure.

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 policy enforcement — AI safety, Trust & Safety, and financial risk:

Use OPA/Cedar for authorization. Use Swiftward for policy enforcement — AI safety, content moderation, fraud detection, and compliance.

Does Swiftward replace workflow orchestrators like Temporal or Airflow?

No. Swiftward is purpose-built for policy enforcement, not general workflow orchestration.

What Swiftward does: Policy-specific HITL (pause event processing for human review, escalation chains, SLA timeouts, resume on decision).

What it does not: Multi-day sagas, complex state machines, distributed transaction coordination, general task orchestration.

Use Temporal/Airflow for orchestration. 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):

• LLM Gateway — OpenAI-compatible proxy with policy evaluation on every request/response
• MCP Gateway — tool call authorization for AI agents
• GitHub/GitLab webhooks (PR gate)
• Custom protocol adapters

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 pilot partner feedback
4. Professional services: Custom development for specific needs

Pilot includes discussion of your roadmap requirements.

Is there a UI?

Yes. Swiftward ships with a full Control UI (React) and a Control API for programmatic access. The UI covers:

• Policy management — upload, validate, activate, rollback, compare versions
• Investigation console — decision trace search with filtering and time-series
• Entity state browser — inspect and mass-edit labels, counters, buckets, metadata
• HITL review queues — case assignment, SLA tracking, escalation
• Replay console — re-evaluate historical events against any policy version
• A/B testing management — traffic splitting, shadow mode, comparison dashboards

For long-term analytics, connect your existing observability stack (Grafana, etc.) 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).

What is Swiftward NOT?

• Not a SaaS moderation API — self-hosted only
• Not a black-box classifier — you define the rules
• Not a BPM/workflow engine — purpose-built for policy enforcement
• Not a chatbot wrapper — infrastructure for decisions

More Questions?

Contact: [email protected]