Pilot: 2-week implementation sprint (typical)
This document outlines the scope, deliverables, and expectations for a Swiftward pilot engagement.
Scope boundaries
- • Pilot covers 1–2 event sources and 5–10 rules — not a full T&S department buildout
- • We integrate with your existing systems — we don't build custom integrations from scratch
- • Focus is on proving fit and demonstrating value — not production deployment at scale
Objectives
- Validate fit — Confirm Swiftward addresses your policy enforcement needs
- Prove integration — Connect to 1–2 real event sources in your environment
- Demonstrate value — Show deterministic decisions, audit trails, and replay capabilities
- Build confidence — Hands-on experience for your engineering and T&S teams
Scope
Included
- Connect 1–2 event sources (e.g., UGC creation, AI output, PR webhooks)
- Deploy Swiftward in your environment (on-prem, private cloud, or isolated staging)
- Configure 5–10 rules covering your priority use cases
- Demonstrate decision traces and audit trail queries
- Walk through DLQ handling and event replay workflow
- Handoff session with your team (architecture review, policy authoring guidance)
Event Sources (Examples)
| Source Type | Integration Method |
|---|---|
| UGC posts/comments | HTTP webhook or queue consumer |
| AI model outputs | HTTP middleware / gateway |
| CI/CD (PR gate) | SCM webhook (GitHub, GitLab) |
| Fraud signals | HTTP API call |
Deliverables
| # | Deliverable | Description |
|---|---|---|
| 1 | Running instance | Swiftward deployed in your environment |
| 2 | Policy file | 5–10 rules in YAML covering pilot use cases |
| 3 | Integration code | Minimal glue code or config to connect event source(s) |
| 4 | Sample traces | Real decision traces from pilot events |
| 5 | Audit review | Walkthrough of trace interpretation and querying |
| 6 | DLQ demo | Failed event inspection, replay, and resolution |
| 7 | Handoff documentation | Architecture notes, policy authoring guide |
| 8 | Recorded session | Final handoff call recording |
Customer Requirements
For a successful pilot, we need:
| Requirement | Details |
|---|---|
| Sample events | 10–50 representative events (anonymized OK) |
| Event source access | Webhook endpoint or queue we can consume from |
| Environment | VM/container where we can deploy (Linux, Docker) |
| Postgres access | Managed or self-hosted Postgres instance (can be provisioned for pilot if needed) |
| Technical contact | Engineer available for integration questions |
| Use case definition | 3–5 policy scenarios you want to implement |
Environment Specs (Minimum)
- 2 vCPU, 4GB RAM for Swiftward
- Postgres 14+ (can be shared instance for pilot)
- Network access from Swiftward to event source and action targets
Timeline
Target time-to-first-value: 5–10 business days after prerequisites are ready.
Typical end-to-end pilot: 3–6 weeks including security/access, integration, and evaluation.
| Day | Activities |
|---|---|
| 1 | Kickoff call; review use cases; receive sample events |
| 2–3 | Deploy Swiftward; configure Postgres; basic health check |
| 4–5 | Connect first event source; initial policy draft |
| 6–7 | Iterate on rules; add signals; test with real events |
| 8 | Connect second event source (if applicable) |
| 9 | DLQ walkthrough; replay demo; trace review |
| 10 | Handoff session; documentation delivery; next steps |
Timeline assumes prerequisites are ready and reasonable availability from customer technical contact.
Pricing
Typical budget: $5,000–$10,000 depending on:
- Number of event sources
- Complexity of policy rules
- Integration effort (standard webhook vs. custom adapter)
- Environment constraints (security reviews, VPN, etc.)
Pricing confirmed after scoping call. Payment due before pilot start.
Success Criteria
The pilot is successful if:
- ✅ Swiftward processes events from at least one production-like source
- ✅ Policy rules produce expected verdicts for test cases
- ✅ Decision traces are queryable and interpretable
- ✅ Customer team can author basic rule modifications
- ✅ DLQ replay workflow demonstrated end-to-end
- ✅ No critical blockers for production deployment identified
Acceptance Criteria
At pilot end, customer confirms:
- ☐ Swiftward deployed and operational in target environment
- ☐ Event source(s) integrated and producing decisions
- ☐ Policy file reviewed and understood by customer team
- ☐ Audit trail meets compliance/debugging requirements
- ☐ Handoff session completed
Out of Scope
The following are not included in a standard pilot:
- Production support or SLA
- Custom UDF development (beyond standard library)
- Custom action integrations (beyond webhook/HTTP)
- Multi-region or HA deployment
- Performance tuning for >1000 events/sec
- Kafka/Redis/ClickHouse adapter setup (Postgres-only for pilot)
- Policy authoring beyond 10 rules
- Security review or penetration testing
These can be scoped separately if needed.
Next Steps
- Scoping call — Review your use cases and environment
- Proposal — Confirm scope, timeline, and pricing
- Kickoff — Start Day 1 activities
Contact: swiftward@disciplinedware.com
Further reading: