ODW.ai Suite FAQ

ODW.ai is an open-source, data-sovereign AI suite for business. It's a platform of agentic modules that companies run on their own infrastructure, with their own data, using any model they choose.

The suite has 10 modules covering the core business functions where AI creates value:

• Vault — knowledge base & RAG (the foundation)
• Loop — workflow orchestration
• Desk — AI customer support (WhatsApp-first)
• Recap — meeting transcription & action items
• Voice — AI phone receptionist
• Pulse — multilingual content generation
• Hunt — outbound sales co-pilot
• People — hiring & HR assistant
• Books — AI bookkeeping
• Shield — governance & compliance layer

Each module works standalone. Together, they form a complete sovereign AI stack.

Primary: Small-to-midsize businesses (10–500 employees) in regulated or data-residency-sensitive contexts:

• Healthcare (HIPAA, patient data)
• Financial services (SOC 2, transaction data)
• Legal (attorney-client privilege)
• Government contractors (FedRAMP, ITAR)
• EU/privacy-bound companies (GDPR)
• Education, manufacturing, professional services

These businesses need full AI capability but cannot or will not surrender sensitive data to cloud AI vendors.

Secondary: Developers and self-hosters who adopt the open-source tools and become internal champions at their companies.

Three fundamental differences:

1. Ownership. ChatGPT and Copilot are cloud SaaS — your data goes to their servers. ODW runs on your infrastructure. Your data never leaves unless you choose.
2. Business-specific. General AI tools are generic assistants. ODW modules are purpose-built for specific business functions — customer support, hiring, bookkeeping, sales — with domain-specific workflows, compliance controls, and integrations.
3. Suite integration. ODW modules work together. Vault grounds every other module in your actual knowledge base. Loop orchestrates multi-module workflows. Shield provides unified governance. This isn't available when you stitch together separate SaaS tools.

You can use any combination. Each module is fully functional on its own. There's no "all or nothing" commitment.

Common starting points:

• Knowledge-first: Vault + Desk — ground your AI in your docs, deploy customer support
• Sales-first: Hunt + Pulse — personalized outreach + localized marketing
• Operations-first: Recap + Loop — automate meeting notes and workflows
• Compliance-first: Shield + Vault — establish governance before scaling AI
• Communication-first: Desk + Voice — cover chat and phone support

Add modules over time as your needs evolve.

Yes. The core of each module is open-source — you can download, deploy, and use it without paying license fees. The code is transparent and auditable.

The business model is open-core:

• Free: core functionality, single-instance deployment, community support
• Paid tier: cross-module orchestration at scale, enterprise governance (Shield), HA deployment, SLA-backed support, premium connectors

Revenue comes from support subscriptions, consulting, and a certified partner network — not from license sales or data.

That's the goal. Each ODW module targets a specific SaaS category:

ODW competes on ownership, privacy, model-choice, and suite integration — not on feature breadth. It never competes head-on with incumbents on their strongest axis.

Built (production-ready or beta):

• Vault — sovereign RAG knowledge platform
• Loop — agent orchestration & workflows
• Desk — WhatsApp-first AI customer support
• Recap — on-device meeting transcription

Planned (in development):

• Voice — AI receptionist
• Pulse — multilingual content
• Hunt — outbound sales
• People — hiring & HR
• Books — AI bookkeeping
• Shield — governance & compliance

Yes. ODW modules integrate with common business tools:

• CRM: Salesforce, HubSpot (via API or Loop workflows)
• Calendar: Google Calendar, Outlook (for Voice appointment booking)
• Communication: Slack, Microsoft Teams, WhatsApp, Telegram
• Accounting: QuickBooks, Xero (for Books)
• HRIS: Workday, BambooHR (for People)
• Content platforms: WordPress, HubSpot (for Pulse)

For tools not on this list, build custom integrations via Loop or the REST API.

ODW's vision: become the sovereign alternative to cloud AI SaaS for business.

The strategy is modular and compounding:

1. Vault is the foundation. Every other module draws from the same knowledge base. This creates a flywheel — the more you use ODW, the more valuable your knowledge base becomes.
2. Shield is the commercial backbone. Free open-source tools build adoption; governance and compliance convert adoption into revenue.
3. Modules compound. Each new module increases the value of existing ones. Adding Voice makes Desk more valuable (same knowledge base, new channel). Adding People makes Shield more valuable (more audit trails).
4. Never compete on feature breadth. ODW competes on ownership, privacy, model-choice, and integration. Incumbents win on features; ODW wins on control.

Sovereign AI means you own and control the entire AI stack — the models, the data, the infrastructure. Nothing leaves your environment unless you explicitly allow it.

Contrast with cloud AI (OpenAI, Anthropic, Google): you send data to their servers, they process it, you get a response. You don't control where your data goes, how long it's stored, or who has access.

With ODW's sovereign AI suite:

• All data stays on your infrastructure (your servers, your cloud, your laptop)
• All processing happens locally — no third-party API calls unless you configure them
• You control the models, the data, and the access policies
• You can run completely air-gapped (zero internet) if needed

Three reasons:

1. Data protection: Your sensitive data (customer PII, financial records, HR documents, legal contracts) never touches a third-party server. Critical for healthcare (HIPAA), finance (SOC 2), legal (attorney-client privilege).
2. Regulatory compliance: GDPR, China's PIPL, and other data protection laws require data residency and control. Sovereign AI makes compliance dramatically simpler because you have full control over where data lives.
3. Competitive advantage: Control your AI stack → customize for your needs → integrate deeply → avoid vendor lock-in. You're not dependent on a SaaS vendor's pricing, uptime, or feature roadmap.

Open-source means the code is publicly available — anyone can inspect, modify, and deploy it. Sovereign means you control the infrastructure where the software runs.

ODW is both:

• Open-source: code is transparent, auditable, community-driven
• Sovereign: you deploy on your own infrastructure, controlling data and environment

Not all open-source software is sovereign. If you deploy open-source software on a managed platform (Heroku, Vercel, AWS Lambda), the cloud provider still has access to your data. Sovereign means you control the entire stack — from code to hardware.

Yes. ODW is model-agnostic. You can mix local models and cloud APIs:

• Use local models for sensitive data (customer PII, financial records)
• Use cloud APIs for less sensitive tasks (drafting marketing copy, general Q&A)
• Configure per-module: Vault uses local models, Pulse uses cloud APIs for content generation

When you use cloud APIs, only the minimal context needed is sent — not your entire knowledge base. You control exactly what data goes out.

No. ODW does not collect any telemetry, analytics, or usage data from your deployment. There is no "phone home" behavior.

When you deploy ODW, it runs entirely on your infrastructure with no outbound connections to ODW servers — unless you explicitly configure integrations with external services.

This is a core principle of sovereign AI: you control everything, including what data leaves your environment.

With cloud AI, you're exposed to:

• Sudden price increases (OpenAI has changed pricing multiple times)
• Terms of service changes that affect your use case
• Service discontinuation (Google killed many AI products)
• Geopolitical risk (sanctions, export controls, data localization laws)

With ODW, your AI stack runs on your infrastructure. No vendor can pull the plug. If you use local models, you're completely independent. If you use cloud APIs, you can switch providers without re-architecting — the model-agnostic design means you're not locked in.

No. ODW is specifically designed for SMBs (10–500 employees). The whole point is to make sovereign AI accessible to companies that can't afford enterprise AI teams.

How ODW makes this practical for SMBs:

• Docker deployment: single command to get started
• Free core tier: no license fees, pay only for infrastructure
• Managed options: if you don't want to self-host, certified partners can run it for you
• Minimal hardware: a single modern laptop can run individual modules with cloud APIs

The infrastructure cost for a small deployment (one module, cloud APIs) is comparable to a SaaS subscription — but you own the data.

Yes. ODW can run in a fully air-gapped environment with zero internet connectivity.

This is critical for:

• Government and defense contractors (ITAR, FedRAMP)
• Healthcare (HIPAA with strict data isolation)
• Financial institutions with regulatory requirements
• Any organization that cannot risk data exfiltration

In air-gapped mode, you use local models only (no cloud APIs). All processing, storage, and inference happen on your local infrastructure.

Frame it in terms they care about:

• Risk reduction: "Our AI data never leaves our infrastructure. No third-party exposure. No supply chain risk from AI vendors."
• Compliance simplification: "We control where data lives and how it's processed. GDPR data residency, HIPAA isolation, SOC 2 audit trails — all architecturally guaranteed, not policy-dependent."
• Vendor independence: "We're not locked into any AI vendor's pricing, terms, or availability. We can switch models or providers without re-architecting."
• Audit readiness: "Every AI action is logged with full traceability. When the auditor asks 'who did what and when,' we have the answer in minutes, not weeks."

Three integration layers:

1. Vault is the knowledge foundation. Desk, Hunt, Pulse, Voice, and People all pull from Vault to ground their responses in your actual documentation — not generic AI training data.
2. Loop is the orchestration layer. It connects modules into automated workflows. When Recap finishes a transcript, Loop can extract action items and route them. When Desk gets a question, Loop can trigger a Vault search and format the response.
3. Shield is the governance layer. It provides unified access control, audit logging, and compliance reporting across all modules.

Example flow: Customer messages Desk → Desk searches Vault → if confident, responds with citation → if not, escalates to human → Loop logs the conversation in Vault → Shield audits the entire flow.

Depends on your business, but here's a common pattern:

1. Phase 1 — Foundation (Weeks 1–2): Deploy Vault (knowledge base) and Shield (governance). Secure, auditable foundation.
2. Phase 2 — Customer-facing (Weeks 3–4): Deploy Desk (support) and Voice (phone). Direct customer impact.
3. Phase 3 — Internal ops (Weeks 5–6): Deploy Recap (meetings) and Loop (workflows). Automate internal processes.
4. Phase 4 — Growth (Weeks 7–8): Deploy Hunt (sales) and Pulse (content). Scale outbound and marketing.
5. Phase 5 — Specialized (Weeks 9+): Deploy People (hiring) and Books (accounting) as needed.

This is a suggestion, not a requirement. Start with what solves your most urgent problem.

Each module is fully functional standalone. You don't need Vault to use Desk, or Shield to use Recap.

What you do get from integration:

• Vault integration: modules answer from your actual docs instead of generic AI knowledge
• Loop workflows: automate multi-step processes across modules
• Shield governance: unified audit trails and access control across all modules

Start standalone. Add integration when you see the value.

Vault is the knowledge foundation. It's the central knowledge base that other modules query to ground their AI responses in your actual documentation.

Without Vault: AI modules use generic training data. They might hallucinate or give outdated answers.

With Vault: AI modules answer from your uploaded documents, policies, product specs, and internal wiki. Responses include citations. Hallucination is dramatically reduced.

Vault supports:

• Document ingestion (PDF, DOCX, XLSX, HTML, Markdown)
• Bilingual search (e.g., search in English, find Chinese documents)
• Access control (different teams see different knowledge)
• Version tracking (know which version of a doc was used for an answer)

Loop is the orchestration layer. It wires modules into automated, multi-step workflows.

Examples:

• Recap finishes a meeting transcript → Loop extracts action items → adds them to your task manager
• Desk gets a support question → Loop searches Vault → formats response → logs in CRM
• Hunt identifies a lead → Loop checks Vault for relevant case studies → drafts personalized email → sends via your email provider
• People receives an application → Loop screens against criteria → schedules interview → notifies hiring manager

Loop has a visual builder for non-engineers and a code escape hatch (Python/TypeScript) for advanced logic.

Shield is the governance and compliance layer. It's the commercial backbone of the suite — the module where paid revenue concentrates, because governance is what enterprises pay for.

Shield provides:

• Access control: SSO, role-based and attribute-based policies across all modules
• Audit logging: immutable, tamper-evident logs for every AI action across the suite
• Compliance reporting: pre-built mappings to SOC 2, ISO 27001, HIPAA, GDPR
• Data residency controls: policies ensuring data doesn't leave defined boundaries
• Configuration hardening: guided enforcement of security baselines

Every other module generates compliance signals (SSO requirements, audit trail demands, data-residency constraints). Shield unifies them into a single governance plane.

Yes. Data sharing between modules happens through controlled, auditable channels:

• Vault queries: modules request knowledge from Vault through authenticated API calls. Access is controlled by Shield policies.
• Loop workflows: data flows between modules through Loop's orchestration engine. Every data transfer is logged.
• Shared auth: all modules use the same authentication layer (managed by Shield). A user logged into Desk is authenticated for Vault queries.

Data never leaves your infrastructure during these transfers. All inter-module communication is encrypted and auditable.

Scenario: Regulated healthcare clinic

1. Voice answers an inbound patient call, books an appointment
2. Desk handles follow-up questions via WhatsApp ("What do I bring to my appointment?")
3. Both Voice and Desk query Vault for the clinic's policies, insurance info, and preparation instructions
4. Recap transcribes the doctor-patient consultation (on-device, no cloud)
5. Loop extracts follow-up actions from the transcript → schedules next appointment → sends patient instructions via Desk
6. Shield ensures all patient data (PHI) stays on-prem, logs every access for HIPAA audit
7. People handles hiring for a new nurse — screening, scheduling interviews, compliance logging
8. Books processes the month-end reconciliation, categorizes transactions

Every module runs on the clinic's infrastructure. No patient data touches a third-party server.

For basic integration: no. Loop's visual builder lets non-engineers compose workflows. Module connections (Vault → Desk, Recap → Loop) are pre-configured.

For advanced integration: some technical capability helps. Custom connectors, complex conditional logic, and API integrations benefit from someone comfortable with Python/TypeScript.

Options if you don't have in-house technical staff:

• Certified partners: ODW's partner network handles deployment and configuration
• Professional services: ODW offers consulting for setup and customization
• Managed deployment: a partner runs ODW on your behalf (still on your infrastructure, still sovereign)

All data is stored on your own infrastructure — the servers, cloud accounts, or devices you control. ODW does not have any central servers that store your data.

You can deploy on:

• Your own data center (on-premises)
• Your cloud accounts (AWS, Azure, GCP, Alibaba Cloud)
• Employee laptops (for modules like Recap and Vault)
• Hybrid setups (some modules on-prem, some in cloud)

You choose where data lives. It never touches ODW's servers — because there are none.

Yes:

• At rest: AES-256 encryption for stored data (databases, files, backups)
• In transit: TLS 1.3 for all network communication

You control the encryption keys. On cloud infrastructure, use customer-managed keys (CMK) for maximum control.

ODW is designed so PII never leaves your infrastructure unless you explicitly allow it:

• Local models: all processing of PII happens on your hardware. Zero exposure.
• Cloud APIs (optional): if you route to OpenAI/Anthropic, you control what context is sent. Shield can enforce PII detection and block sensitive data from being sent to external APIs.
• Data minimization: modules are designed to process only the data needed for each task.
• Retention controls: configure how long data is kept, with automatic deletion policies.

Yes — full air-gapped deployment is supported. No internet required.

Requirements for air-gapped mode:

• Local models deployed on your infrastructure (Llama, Mistral, Whisper, etc.)
• Model weights downloaded beforehand and transferred via secure media
• All dependencies bundled in Docker images or offline packages

Trade-off: you're limited to local model capabilities. No access to frontier model quality (GPT-4, Claude). But for many business use cases, local models are sufficient — and the sovereignty gain is worth it.

Because ODW runs on your infrastructure, you're responsible for incident response. But ODW provides the tools:

• Shield: audit logs, access control, anomaly detection
• Immutable logs: all security events are logged and cannot be tampered with
• Access control: role-based and attribute-based policies limit who can access what

Recommended incident response process:

1. Define your incident response plan before you need it
2. Use Shield to monitor for anomalies (unusual access patterns, failed logins)
3. If a breach occurs, use Shield's audit logs to determine scope and impact
4. Follow regulatory obligations for breach notification (GDPR: 72 hours)

Only the people you authorize.

ODW has no access to your data — there are no ODW servers storing it. Access is controlled by:

• Infrastructure-level: whoever has server/cloud access controls the data at the system level
• Application-level: Shield manages user authentication, roles, and permissions within ODW
• Module-level: each module can have its own access policies (e.g., only HR can see People data)

Shield provides the unified access control plane. You define who can see what, and every access event is logged.

Yes. Because you control where ODW is deployed, you control where data lives:

• Deploy in EU data centers for EU customer data (GDPR)
• Deploy in mainland China for Chinese data (PIPL)
• Deploy on-premises for maximum control
• Deploy in specific regions for industry requirements (HIPAA, FedRAMP)

Shield can enforce data residency policies — blocking any attempt to route data outside the configured boundary. This is a policy-level guarantee, not just a configuration suggestion.

ODW addresses supply chain risk at multiple levels:

• Open-source code: auditable by anyone. No hidden backdoors in the application layer.
• Container images: built from known base images, signed and verified.
• Dependency management: documented dependencies with version pinning. Security advisories tracked.
• Model supply chain: you choose which models to use. Local models = no external model dependency. Cloud APIs = you know exactly which provider processes your data.

For high-security environments, we recommend:

1. Audit the ODW source code before deployment
2. Build container images from source (don't use pre-built images)
3. Pin all dependencies to specific versions
4. Run vulnerability scanning on your deployment

Requirements depend on modules and model choice:

Minimal (single module, cloud APIs):

• Any modern laptop or server (8GB+ RAM)
• Internet connection (for cloud APIs)

Recommended (full suite, local models):

• Server with 32GB+ RAM (for multiple local models)
• GPU (NVIDIA with CUDA) for faster inference — optional but recommended
• 100GB+ storage for knowledge base, logs, and model files

Enterprise (high availability, multi-region):

• Kubernetes cluster or managed container platform
• Load balancer and auto-scaling
• Database cluster (PostgreSQL) for multi-module data

Yes. ODW provides deployment guides and templates for:

• AWS: EC2, ECS, EKS
• Azure: VMs, Container Instances, AKS
• GCP: Compute Engine, GKE, Cloud Run
• Alibaba Cloud: ECS, ACK

You deploy ODW in your cloud accounts — you control the infrastructure, the data, and the access policies. ODW doesn't operate any cloud infrastructure on your behalf.

Yes. ODW modules run on macOS with Apple Silicon (M1/M2/M3/M4). Local models run efficiently via MLX or llama.cpp, which are optimized for Apple's Neural Engine.

This is particularly relevant for:

• Recap: on-device meeting transcription on your laptop
• Vault: personal/team knowledge base running locally
• Development: testing and prototyping before deploying to production servers

For production deployments serving multiple users, a server or cloud instance is recommended. But for individual use or small teams, a Mac is a viable deployment target.

ODW modules are deployed as containers (Docker). Updates are straightforward:

1. Pull the latest version from the ODW repository
2. Deploy the update to your infrastructure
3. Restart the module

For zero-downtime updates: use rolling deployments (Kubernetes, Docker Swarm). For single-instance deployments: expect brief downtime (seconds to minutes) during restart.

Always test updates in a staging environment before deploying to production.

Single instance: the module is unavailable until you restore it.

For high availability:

• Deploy multiple instances behind a load balancer
• If one instance fails, traffic routes to the others

For data durability:

• Use database replication (PostgreSQL streaming replication)
• Back up your knowledge base (Vault) and logs regularly
• Store backups in a separate location (different region or cloud)

Docker is enough for most deployments. Kubernetes is only needed for:

• High availability across multiple nodes
• Auto-scaling based on load
• Multi-region deployment
• Large teams with complex module configurations

For a single team running a few modules, Docker Compose on a single server is perfectly adequate. Start simple, scale when you need to.

Yes. Modules are independent services. You can distribute them across your infrastructure however makes sense:

• Vault on a high-storage server (it holds your knowledge base)
• Recap on individual laptops (on-device transcription)
• Desk and Voice on a public-facing server (customer-facing)
• Shield on a secure internal server (governance data)

Modules communicate via REST APIs. As long as they can reach each other on your network, they work together regardless of physical location.

Depends on your usage:

• ODW modules (without local models): ~5GB for application code, databases, and logs
• Local models: 5–40GB per model depending on size (7B = ~5GB, 70B = ~40GB)
• Vault knowledge base: depends on your documents. 1,000 documents ≈ 1–5GB including embeddings
• Recap transcripts: ~10MB per hour of audio
• Logs and audit trails: ~1GB/month for active deployments

A reasonable starting point: 100GB for a single-module deployment with one local model. Scale storage as your knowledge base and usage grow.

Yes:

• Docker images: published for each module on Docker Hub / GitHub Container Registry
• Docker Compose: ready-to-use compose files for single-server deployments
• Kubernetes manifests: Helm charts for production-grade deployments
• Cloud templates: Terraform/CloudFormation for AWS, Azure, GCP

Documentation includes step-by-step deployment guides for each platform.

ODW is designed to help you comply — but compliance is ultimately your responsibility, because you control the infrastructure.

ODW provides:

• GDPR: data minimization, purpose limitation, retention controls, data subject rights workflows (access, deletion, portability)
• HIPAA: all processing on your infrastructure, so PHI never touches third-party servers. Shield provides audit trails.
• SOC 2: Shield provides access control, audit logging, and compliance reporting aligned with SOC 2 Trust Services Criteria
• EU AI Act: People and Shield designed for EU AI Act requirements — human oversight, transparency, audit trails

For formal certification (SOC 2 audit, HIPAA assessment), engage a third-party auditor. ODW provides the technical controls; the auditor verifies your implementation.

ODW modules are designed to meet EU AI Act requirements for their risk classification:

• High-risk (People — hiring): human oversight, transparency, audit trails, conformity assessments
• Limited risk (Desk, Voice — customer-facing): transparency (disclose AI usage), human escalation options
• Minimal risk (Vault, Recap, Pulse — internal): standard data protection and security

Shield provides the governance layer to help you demonstrate compliance — audit logs, access control, compliance reporting.

Many regulations require data to stay within specific geographic boundaries:

• GDPR: EU data must stay in the EU (or adequate jurisdictions)
• China's PIPL: Chinese personal data must stay in mainland China
• Russia: personal data of Russian citizens must be stored in Russia
• India (DPDP Act): data localization requirements for certain categories
• Brazil (LGPD): data transfer restrictions

Because you control where ODW is deployed, you ensure data residency by deploying in the right jurisdiction. Shield enforces data residency policies — blocking any attempt to route data outside configured boundaries.

Increasingly, yes. Multiple jurisdictions require AI chatbot disclosures:

• EU AI Act: requires transparency when AI interacts with humans
• California (CCPA/CPRA): requires disclosure of automated decision-making
• Other jurisdictions: emerging laws requiring AI disclosure

For Desk and Voice, we recommend:

• Disclosing that AI is used in customer communications
• Providing an option to speak to a human
• Explaining what data is collected and how it's used

Shield can help generate compliant privacy notices based on your configuration.

Shield turns weeks of audit preparation into minutes:

• Immutable audit logs: every AI action is logged with timestamp, actor, action, and data accessed
• Compliance mappings: pre-built mappings to SOC 2, ISO 27001, HIPAA, GDPR control frameworks
• Evidence packages: generate auditor-ready evidence packages on demand
• Access reports: who accessed what, when, and why — exportable in standard formats

Target: produce auditor-ready evidence in under 1 hour (vs. industry baseline of days/weeks).

The regulatory landscape is evolving rapidly. ODW is designed to be adaptable:

• US Executive Order on AI (2023): focuses on safety, security, and trustworthiness. ODW's model-agnostic design and audit trails support compliance.
• China's Generative AI regulations: require content labeling and data localization. ODW's sovereignty architecture supports both.
• NYC Local Law 144: requires bias testing for automated employment decision tools. People is designed for this.
• Canada's AIDA: proposed AI and Data Act. ODW's human-in-the-loop design aligns with proposed requirements.

Shield's compliance framework is updated as new regulations emerge. The goal: ODW should make compliance easier, not harder, as the regulatory landscape expands.

Yes. When your procurement team needs to assess ODW as a vendor:

• Security documentation: architecture diagrams, data flow descriptions, encryption standards
• Open-source code: auditable — your security team can review the code directly
• Self-hosted: no third-party data exposure by default. This simplifies vendor risk assessments dramatically.
• Compliance mappings: Shield generates evidence for your vendor risk questionnaire

The fact that ODW is self-hosted means many vendor risk questions become moot — there's no third-party data processing to assess.

ODW provides tools to fulfill data subject rights:

• Right of access (Art. 15): export all data related to a specific individual
• Right to rectification (Art. 16): correct inaccurate data
• Right to erasure (Art. 17): delete all data related to an individual across all modules
• Right to data portability (Art. 20): export data in machine-readable format
• Right to object (Art. 21): stop processing an individual's data

Shield provides the workflow tools to process these requests systematically and log compliance.

As an open-source, self-hosted product, ODW itself doesn't hold certifications in the traditional SaaS sense (SOC 2 Type II, ISO 27001 certification). Those certifications apply to managed services.

What ODW provides instead:

• Technical controls: the building blocks for your certification (access control, encryption, audit logging)
• Compliance mappings: Shield maps your configuration to specific control frameworks
• Evidence generation: produce the documentation your auditor needs

If you need a certified managed service, ODW's certified partner network offers managed deployments where the partner holds the certifications.

ODW is model-agnostic. It supports both local and cloud models:

Local models (run on your infrastructure):

• Llama 3, Mistral, Qwen (via Ollama, vLLM, or llama.cpp)
• Whisper (for transcription in Recap and Voice)
• Embedding models (for RAG in Vault)

Cloud APIs (optional):

• OpenAI (GPT-4, GPT-4o)
• Anthropic (Claude)
• Google (Gemini)
• Alibaba (Qwen via DashScope)
• AWS Bedrock

Mix and match — local models for sensitive data, cloud APIs for general tasks.

Yes. ODW supports any model that follows standard APIs (OpenAI-compatible, Hugging Face transformers, etc.).

If you have a fine-tuned model for your specific domain (legal, medical, financial), deploy it and point ODW modules to it.

This is a key advantage of sovereign AI — you're not locked into a vendor's model. Use whatever model works best for your use case.

Yes. ODW's model-agnostic architecture means workflows reference capabilities (summarize, classify, extract), not specific models.

You can:

• Swap LLM providers without rewriting automations
• Configure different models per module
• Route to different models per task (sensitive → local, complex → frontier)
• A/B test models to find the best fit

Switching models is a configuration change, not a code change.

The gap has narrowed significantly. For many business tasks, local models are sufficient:

ODW's model-agnostic design means you can configure fallback models:

• Primary: cloud API (e.g., OpenAI GPT-4)
• Fallback: local model (e.g., Llama 3 70B)
• Secondary fallback: different cloud API (e.g., Anthropic Claude)

If your primary model provider goes down, ODW automatically routes to the fallback. No service interruption for your users.

This is another advantage of having local models in the mix — they're your always-available fallback.

Yes. Each module can be configured independently:

• Vault: local embedding model + local LLM for RAG (maximum sovereignty for knowledge queries)
• Desk: local model for routine FAQ, cloud API for complex queries
• Recap: local Whisper for transcription (on-device, no cloud)
• Pulse: cloud API for content generation (best quality for marketing copy)
• People: local model for screening (PII-heavy, stay local)

This gives you fine-grained control over the sovereignty/quality trade-off per use case.

ODW uses multiple strategies to reduce hallucination:

1. Vault grounding: modules answer from your actual documents, not generic training data. Responses include citations to source documents.
2. Confidence thresholds: if the model's confidence is below a threshold, it escalates to a human instead of guessing.
3. Retrieval-augmented generation: the RAG pipeline in Vault ensures answers are grounded in retrieved context.
4. Human-in-the-loop: for high-stakes tasks (People hiring decisions, Books financial entries), AI assists but humans decide.

No system eliminates hallucination entirely. ODW's approach: make hallucination detectable (citations), preventable (confidence thresholds), and recoverable (human escalation).

Local models:

• Upfront: hardware cost (GPU server: $5K–$20K, or use existing Mac/laptop)
• Ongoing: electricity, maintenance. No per-token cost.
• At scale: dramatically cheaper. 1M tokens on local hardware ≈ $0.50–$2 in electricity vs. $5–$60 on cloud APIs.

Cloud APIs:

• Upfront: $0
• Ongoing: per-token pricing. GPT-4: ~$10–$30 per 1M tokens. Claude: ~$3–$15 per 1M tokens.
• At scale: costs grow linearly with usage.

ODW modules support 100+ languages, with particularly strong support for:

• English
• Chinese (Simplified and Traditional) — critical for GBA and Greater China operations
• Japanese, Korean
• Spanish, French, German, Portuguese
• Arabic, Hindi, and other major languages

Pulse provides true localization across 50+ languages — not just translation, but cultural adaptation for each market.

Vault supports bilingual search (e.g., search in English, find Chinese documents).

Translation converts words from one language to another. Localization adapts content for a specific market — adjusting tone, idiom, register, cultural references, and contextual framing.

Example: A US marketing campaign saying "Hit a home run with our product" would be:

• Translated to Japanese: literal baseball reference — confusing in a market where baseball metaphors don't resonate the same way
• Localized for Japan: adapted to use a culturally relevant metaphor that conveys the same message of success

Pulse does localization, not just translation. The output reads as natively authored in each target language, not like a translation.

Yes. Vault supports bilingual and multilingual search:

• Search in English → find Chinese documents
• Search in Chinese → find English documents
• Search in any supported language → find relevant documents regardless of their original language

This works through multilingual embedding models that map concepts across languages into the same vector space. The semantic meaning is matched, not just keyword translation.

This is critical for businesses operating across markets — a question in English can surface relevant knowledge from documents written in Chinese, Japanese, or any other language in your knowledge base.

Yes. Both Desk and Voice support multilingual conversations:

• Auto-detection: the AI detects the customer's language and responds in the same language
• Knowledge base: Vault returns relevant answers regardless of the language they were written in
• Consistent brand voice: your brand persona is maintained across languages

A customer can message in Cantonese, get a response in Cantonese, drawn from English documentation — all automatically.

Yes. This is a key differentiator. Pulse is configured with your brand voice guidelines:

• Tone (formal, casual, authoritative, playful)
• Vocabulary (industry terms, brand-specific language)
• Style guidelines (sentence length, formality conventions per market)

When generating content in different languages, Pulse adapts the brand voice to each market's conventions while maintaining consistency. A playful brand in English becomes appropriately playful in Japanese — not a literal translation of the English tone, but a culturally appropriate equivalent.

ODW supports RTL languages in both display and content generation:

• UI: interfaces render correctly for RTL languages
• Content generation: Pulse generates culturally appropriate content in Arabic, Hebrew, and other RTL languages
• Vault: indexes and retrieves RTL documents correctly
• Desk/Voice: handles RTL conversations

For markets in the Middle East and North Africa, ODW provides the same sovereign, culturally-aware capabilities as for any other region.

Yes. Pulse supports batch content generation across markets:

• Write a product announcement in English
• Pulse generates localized versions for Japan, Germany, Brazil, and the Middle East — simultaneously
• Each version is culturally adapted, not just translated
• Brand voice is consistent across all versions

This eliminates the traditional localization bottleneck where content goes through sequential translation → review → adaptation for each market. With Pulse, all markets are served in parallel.

ODW operates on an open-core model:

• Free core: individual modules with full basic features, no usage limits, no time limits
• Paid tier: cross-module integration at scale, enterprise governance (Shield), HA deployment, SLA-backed support, premium connectors

Specific pricing depends on deployment size, number of users, and modules. Contact ODW for a quote.

The free core is available indefinitely — no time limit, no credit card required. Deploy and use individual modules for free, forever.

For the paid tier (cross-module integration, enterprise features), a 30-day trial is available. Contact ODW to get started.

Yes, the core is open-source. The specific license varies by module but follows open-source standards (typically MIT or Apache 2.0 for the core).

What "open-core" means in practice:

• Core (free, open-source): the module's essential functionality — deploy, use, modify, redistribute
• Enterprise features (paid): advanced capabilities that enterprises need but SMBs don't — HA, multi-tenant orchestration, premium connectors, white-glove support

The open-source core is genuinely useful on its own. The paid tier adds operational capabilities for larger deployments.

Typical SaaS costs for a 50-person company:

• Intercom/Zendesk: $5,000–$20,000/year
• Apollo/Outreach: $10,000–$30,000/year
• Otter.ai/Fireflies: $3,000–$10,000/year
• Greenhouse/Lever: $10,000–$25,000/year
• QuickBooks + bookkeeper: $5,000–$15,000/year

Total: $33,000–$100,000/year in SaaS subscriptions — plus you don't own the data.

ODW replaces these with a single suite. Pricing is based on deployment scale, not per-seat. For most SMBs, ODW is significantly cheaper — and you own your data.

Pricing is based on deployment scale, not per-seat or per-module.

This is intentional — per-seat pricing penalizes companies for growing their team. Per-module pricing penalizes companies for using more of the suite.

ODW's model: you pay based on the scale of your deployment (number of instances, HA requirements, support level). Use all 10 modules or just 1 — the pricing model doesn't penalize adoption.

For the paid tier:

• Bank transfer / wire (for enterprise contracts)
• Credit card (for smaller deployments)
• Crypto (USDC, USDT) — aligned with the open-source/sovereign ethos

Annual and multi-year contracts available with discounts. Contact ODW for details.

Yes. ODW is building a certified partner network:

• Deployment partners: handle setup, configuration, and ongoing management for clients
• Consulting partners: provide industry-specific customization and integration
• Reseller partners: bundle ODW with their own services

Partners receive certification, technical support, and revenue sharing. If you're interested in becoming a partner, contact ODW.

Depends on deployment complexity:

• Single module, laptop deployment: under 1 hour
• Single module, cloud deployment: 1–2 days
• Full suite, enterprise deployment: 2–4 weeks (including configuration, integrations, team training)

ODW provides deployment guides, Docker images, and professional onboarding services to accelerate setup.

For basic deployment: minimal technical skill needed. If you can run Docker commands, you can deploy ODW.

For advanced deployment (HA, multi-module, custom integrations): some DevOps capability helps.

Options if you don't have in-house technical staff:

• Certified partners: handle deployment for you
• Professional services: ODW consulting for setup
• Managed deployment: a partner runs ODW on your behalf

For free tier: self-service. Documentation, guides, and community support.

For paid tier:

1. Discovery call: understand your use case, compliance requirements, and existing stack
2. Deployment planning: architecture design, infrastructure requirements, integration mapping
3. Setup & configuration: deploy modules, configure integrations, set up Shield policies
4. Data migration: import existing data from your current tools
5. Team training: train your team on the modules they'll use
6. Go-live support: hands-on support during the transition period

Yes. ODW provides data import tools for common migration scenarios:

• Intercom/Zendesk → Desk: conversation history, customer profiles, knowledge base articles
• Notion/Confluence → Vault: documents, wikis, structured content
• Otter/Fireflies → Recap: existing transcripts and meeting notes
• Greenhouse/Lever → People: candidate data, job postings, pipeline history
• QuickBooks → Books: chart of accounts, transaction history

For custom migrations, use the REST API or Loop workflows to import data from any source.

Yes, at multiple levels:

• Documentation: comprehensive guides for each module, including video tutorials
• Community: GitHub discussions, community forum, Discord/Telegram channels
• Team training: included with paid tier — we train your team on the modules they'll use
• Admin training: for IT staff managing the deployment (Shield configuration, infrastructure monitoring)
• Advanced workshops: custom training for complex integrations, fine-tuning, and optimization

Enterprise support includes proactive monitoring, quarterly business reviews, and priority feature requests.

Absolutely. This is the recommended approach:

1. Start with the module that solves your most urgent problem
2. Get comfortable with the deployment model and sovereignty architecture
3. Add modules as you identify new use cases
4. Connect modules via Loop when you're ready for multi-module workflows

There's no pressure to adopt the full suite. Many customers start with one module and expand organically over 6–12 months.

Book a discovery call with ODW. We'll assess:

• Your industry and compliance requirements
• Current tool stack and pain points
• Team size and technical capability
• Priority use cases (what's costing you the most time/money right now?)

Based on this, we'll recommend a starting configuration and a phased adoption plan. No obligation — the goal is to help you find the highest-value starting point.

Key areas of development:

• Module releases: completing the remaining 6 modules (Voice, Pulse, Hunt, People, Books, Shield)
• Deeper integration: tighter cross-module workflows, shared context, unified search
• Model support: new local models as they're released, better quantization for edge deployment
• Industry templates: pre-configured setups for healthcare, legal, finance, manufacturing
• Partner ecosystem: certified deployment partners, marketplace for community connectors

Roadmap is influenced by community feedback and customer needs. File feature requests on GitHub.

ODW welcomes contributions:

• Code: bug fixes, features, improvements via GitHub pull requests
• Documentation: guides, tutorials, translations
• Community: answer questions, share use cases, help other users
• Connectors: build integrations with tools not yet supported
• Models: contribute fine-tuned models for specific domains or languages

Target: 50+ external PRs/month by month 12. The community is a core part of ODW's development.

Yes:

• GitHub Discussions: feature requests, bug reports, technical questions
• Community forum: longer-form discussions, use case sharing
• Discord/Telegram: real-time chat with the community and ODW team

These are the best places to get help, share feedback, and connect with other ODW users.

File a feature request on the relevant module's GitHub repository. Include:

• What problem you're trying to solve
• Your proposed solution (if you have one)
• Your use case and industry context

Feature requests are reviewed regularly. High-impact requests that serve multiple users are prioritized. Paid tier customers can also submit requests through their account manager.

Yes. ODW is designed to be configurable:

• Healthcare: HIPAA-compliant handling, medical terminology in Vault
• Legal: attorney-client privilege, document review workflows, trust accounting
• Finance: SOC 2 compliance, audit trails, multi-currency
• Manufacturing: supply chain documentation, quality control records
• Professional services: project management, client communication

For deep customization, the open-source code is available. Modify it to fit your exact needs. Or work with ODW's consulting team or a certified partner.

Bug reports: file on GitHub with reproduction steps. Critical bugs are prioritized and patched quickly.

Feedback: share via GitHub Discussions, community forum, or your account manager (paid tier).

Transparency: ODW publishes development updates, roadmap changes, and known issues. The community can see what's being worked on and why.

Paid tier customers get direct access to the product team for feedback and feature discussions.

ODW's long-term vision: become the default sovereign AI platform for business.

The thesis: as AI becomes more powerful and more regulated, businesses will need AI they can trust — AI they own, control, and audit. Cloud AI works today, but the regulatory, geopolitical, and competitive risks are growing.

ODW is building for that future:

• A complete suite covering all major business functions
• A governance layer (Shield) that makes compliance tractable
• A model-agnostic architecture that adapts as AI evolves
• An open-source community that ensures transparency and longevity

The goal isn't to beat cloud AI on convenience. It's to be the trustworthy alternative when sovereignty matters.