Reproducible, auditable Trust & Safety decisions — on-prem.

Swiftward is a modular on-prem policy engine for UGC, AI outputs, and internal workflows — with a full audit trail.

Request a design-partner pilot Limited design-partner slots. Pilot license fee may be waived.

Who it's for · Example · Pilot

Who it's for

•Teams shipping AI features (agents, copilots, auto-summaries) and need guardrails + audit.
•UGC platforms where moderation mistakes have real cost.
•Regulated orgs (fintech/health/enterprise) needing deterministic compliance evidence.

If you're already hiring Trust & Safety / Policy / Compliance roles — you likely feel this pain.

What Swiftward is

Swiftward is a modular, on-premise Trust & Safety engine for enforcing deterministic, auditable policies across UGC, AI outputs, and internal workflows — from a single-node setup to distributed deployments.

It fits environments where incorrect decisions have real cost (operational, financial, reputational) and where reproducible outcomes with a clear audit trail are required.

Why not just X?

Why not OPA?

OPA: Policy decision engine — great for authorization/DevOps.

Swiftward: Policy runtime + event processing + state management + audit trails + DLQ/replay. Built for Trust & Safety workflows.

Why not prompt/LLM guardrails?

Those protect prompts/responses; Swiftward is a general policy runtime over events + workflows.

Why not build in-house?

You'll re-create policy versioning, deterministic execution ordering, audit trails, DLQ/replay, and integrations.

Key capabilities

Deterministic decisions

DAG signals, ordering guarantees, two-phase execution (evaluation ≠ side effects). Same event + same policy = same verdict, always.

Full audit trail

Every signal, rule match, state mutation, and action logged per event. Traces, investigations, replay/DLQ for compliance.

On-prem control

No SaaS lock-in, data stays inside. Deploy anywhere: Docker, Kubernetes, or bare metal.

Scale without rewrites

Postgres-first design scales to Kafka/Redis/ClickHouse via adapters. Switch backends without changing policy logic.

Examples

1 / 3

AI guardrails: Block user prompts containing threats or harassment.

Every decision traced — for appeals, investigations, and compliance.

Policy (YAML)

signals:
  safety:
    udf: llm/moderation
    params:
      text: "{{ event.data.prompt }}"
      categories: [toxicity, violence]

rules:
  block_threats:
    enabled: true
    all:
      - path: "signals.safety.violence"
        op: gte
        value: 2  # severe
      - path: "signals.safety.confidence"
        op: gte
        value: 0.7
    effects:
      verdict: rejected
      state_changes:
        set_labels: ["threat_detected"]
        change_counters:
          blocked_prompts: 1
      actions:
        - action: security_alert
          params:
            channel: "#ai-safety"
      response:
        blocked: true
        reason: "Prompt contains threatening content"

Decision trace

trace_id:       tr_ai_20250115_003
policy_version: ai_guardrails_v1
duration:       89ms

SIGNALS COMPUTED
+ safety = THREAT DETECTED (67ms, llm/moderation)
  -> violence: 2 (severe)
  -> toxicity: 1 (mild)
  -> confidence: 0.94
  -> rationale: "Direct physical threat"

RULES EVALUATED
[P100] block_threats           MATCHED

VERDICT: REJECTED
Source:  block_threats
Reason:  Prompt contains threatening content

STATE MUTATIONS
+ SET LABELS:      ["threat_detected"]
+ CHANGE COUNTERS: blocked_prompts += 1

ACTIONS EXECUTED
+ security_alert -> #ai-safety (32ms, OK)

UGC moderation: Block posts containing personal information (PII).

Works with any content platform — forums, marketplaces, social apps.

Policy (YAML)

signals:
  pii_detected:
    udf: pii/scanner
    params:
      text: "{{ event.data.text }}"
      types: ["email", "phone", "ssn"]

rules:
  block_pii_exposure:
    enabled: true
    all:
      - path: "signals.pii_detected.found"
        op: eq
        value: true
    effects:
      verdict: rejected
      state_changes:
        set_labels: ["pii_violation"]
        change_counters:
          pii_violations: 1
      response:
        blocked: true
        reason: "Content contains personal information"

Decision trace

trace_id:       tr_ugc_20250115_001
policy_version: ugc_moderation_v1
duration:       106ms

SIGNALS COMPUTED
+ pii_detected = FOUND (12ms, pii/scanner)
  -> Email detected: [email protected]

RULES EVALUATED
[P100] block_pii_exposure     MATCHED

VERDICT: REJECTED
Source:  block_pii_exposure
Reason:  Content contains personal information

STATE MUTATIONS
+ SET LABELS:      ["pii_violation"]
+ CHANGE COUNTERS: pii_violations += 1

Coordinated abuse: Detect multiple new accounts posting the same link.

Stateful detection across entities — not possible with stateless APIs.

Policy (YAML)

signals:
  account_age:
    udf: time/minutes_since
    params:
      timestamp: "{{ event.data.account.created_at }}"

  same_link_posters:
    udf: analytics/count_users_by_link
    params:
      link: "{{ event.data.link }}"
      within: "10m"

rules:
  coordinated_link_spam:
    enabled: true
    all:
      - path: "signals.account_age"
        op: lt
        value: 30
      - path: "signals.same_link_posters"
        op: gte
        value: 5
    effects:
      verdict: rejected
      state_changes:
        set_labels: ["coordinated_abuse"]
      response:
        blocked: true
        reason: "Coordinated spam detected"

Decision trace

trace_id:       tr_spam_20250115_007
policy_version: anti_abuse_v1
duration:       41ms

SIGNALS COMPUTED
+ account_age = 8 (1ms, time/minutes_since)
+ same_link_posters = 7 (32ms)
  -> domain: example.xyz
  -> window: 10m

RULES EVALUATED
[P100] coordinated_link_spam   MATCHED

VERDICT: REJECTED
Source:  coordinated_link_spam
Reason:  Coordinated spam detected

STATE MUTATIONS
+ SET LABELS:      ["coordinated_abuse"]

Architecture & scaling

Swiftward runs as a single binary that can operate as one process or be deployed as role-based components (ingestion, workers, control API) for horizontal scaling.

•Single executable → role-based services: Run as one process for small teams, or deploy role-based components for scale.
•Reference deployments: Docker Compose profiles for minimal (Postgres only), full (+ Kafka, Redis), and analytics (+ ClickHouse, VictoriaMetrics).
•Postgres-first design: Queues, DLQ, state, rule versions, and execution history in one database for moderate workloads.
•Horizontal scaling: Stream partitioning by entity_id preserves per-entity ordering.
•Optional adapters: Kafka (ingestion/buffering), Redis (caching/rate limiting), ClickHouse/Druid (analytics) via config.
•Switch backends without changing policy logic: No code changes required, only deployment configuration.
•Two-phase execution: Deterministic rule evaluation separate from state mutations and external actions.

What it is NOT

Swiftward is purpose-built for Trust & Safety and policy enforcement, not general business orchestration.

•Not a SaaS moderation API
•Not a black-box classifier
•Not a BPM/workflow engine
•Not a chatbot wrapper

Pilot offer

I'll personally help you install and run a pilot. Swiftward pilots are offered in two formats, depending on fit and goals.

Design partner pilot

Limited slots. License fee may be waived in exchange for active participation, structured feedback, and a reference if the pilot is successful.

Standard paid pilot

Fixed-fee on-prem engagement, credited toward a commercial license.

Outcome: a go/no-go decision for adopting Swiftward with a working policy pack and reproducible traces on your data.

Target time-to-first-value

5–10 business days after prerequisites are ready — see pilot guide for detailed timeline

Typical end-to-end pilot: 3–6 weeks including security/access, integration, and evaluation.

Deliverables

• Policy pack for 1-2 real use cases
• Audit/investigation workflow demo
• Performance baseline + go/no-go criteria

Success criteria

• We can express your policies and reproduce verdicts deterministically
• We can produce a complete audit trace for any decision
• Latency/throughput targets met for your workload (or acceptable async)

Week 1 outcome

First event source integrated + first policy running + trace visible

What we need from you

• Access to environment (k8s/docker/vm) + Postgres
• Sample events/test dataset (10–50 events, anonymized OK)
• Integration endpoint owner (webhook/API contact)
• Success criteria & owner (one technical contact)

Standard paid pilot pricing

Paid on-prem pilot (fixed-fee): typically $5k–$10k depending on scope. Final scope and fee confirmed after a 30-minute scoping call. See pilot guide for details.

Request a pilot

Built by Konstantin Trunin — hands-on CTO (Go, distributed systems). LinkedIn ↗

FAQ

Is the design partner pilot free?

For a limited number of design partners, the pilot license fee may be waived. This requires active participation, real use cases, and agreement to provide feedback and a reference if successful.

Do we need to learn a new DSL?

Yes, but it's YAML-first; we provide examples and do onboarding. Policies are defined declaratively using constants, UDF and action profiles, signals, and rules.

Do you have prebuilt detectors/UDFs?

Some; expanding library. AI calls are generic UDF; you can bring your own. UDFs implement domain-specific logic such as heuristics, scoring, parsing, enrichment, or LLM checks.

Human-in-the-loop?

Not in v1; available as an extension. Tell us your workflow and we can discuss integration options.

Documentation

Architecture docs

Component overview, scaling, and deployment patterns.

Core concepts

Rules, signals, state, actions, and execution model.

Extended FAQ

Additional and in-depth questions.

Pilot guide

Pilot engagement scope and process.