Technical details.
The rest of the site is written for the person deciding whether to work with us. This page is written for the person who has to review the architecture before they say yes. Each section below is an executive summary followed by specifics: runtime, integration model, security posture, and delivery topology. Links go back to the corresponding customer-facing page.
Orva is a multi-tenant AI execution platform deployed on Railway with Postgres for persistence and Redis for job coordination. The reasoning engine is a customer-selected large language model — Anthropic Claude or OpenAI GPT-family — invoked through the customer's own API key. Tool access is provided through named, scoped OAuth grants per integration, and every model call, tool invocation, and result is written to an append-only audit log.
Runtime and deployment
Stateless Node.js/TypeScript services on Railway, horizontally scalable, fronted by Cloudflare. Postgres (managed) for tenant configuration, Skill definitions, run history, and audit records. Redis for job queueing and short-lived context. Secrets are stored in a vault, per-tenant, and referenced by ID at call time — never inlined into logs.
Integration model
Each integration is a first-class connector with an OAuth flow, scoped tokens, and a well-defined action surface (list, create, update, search) that the reasoning layer can invoke through structured tool calls. Tool schemas are versioned. New tools are added without redeploying tenants.
Skills
Skills are named, versioned, JSON-defined workflows composed of tool calls, prompts, and control flow. They can be invoked on demand from Slack, Microsoft Teams, or the Orva web portal, or scheduled with cron-style triggers. Each run captures inputs, model output, tool calls made, and final result.
Security and compliance
Encryption in transit (TLS 1.2+) and at rest (AES-256). Per-tenant data isolation at the row level with enforced tenant scoping in every query. OAuth grants are least-privilege by default. GDPR-aligned handling with configurable retention. SOC 2 program in progress. All access is logged; audit records are exportable.
Model choice
Customers bring their own model API key. The reasoning layer supports Anthropic and OpenAI today. Model selection is per-tenant and can be overridden per Skill. No customer data is used to train models.
AI Integration Services
See the AI Integration Services page →Custom engagements to design, build, and operate AI integrations across existing enterprise systems. Delivery uses the Orva platform as the execution substrate where appropriate, or a dedicated deployment for environments with specific compliance or data-residency requirements.
Delivery topology
Standard delivery runs on Orva's multi-tenant infrastructure. Dedicated deployments (single-tenant Postgres, isolated compute, customer VPC or on-prem gateway) are supported for regulated environments. In dedicated mode, deployment artifacts are transferred to the customer's cloud account and operated jointly under a defined RACI.
Integration surface
Connectors are built to the source system's supported API. Where APIs are absent, we implement authenticated event ingestion, SFTP, or scheduled polling with idempotent upserts. Integrations are transactional where the source supports it and idempotent where it does not.
Observability
Structured logs with per-run correlation IDs, integration-level success/failure metrics, and alerting on connector error-rate thresholds. Customers receive access to run history and metrics through the Orva portal.
Change management
All schema and Skill changes are version-controlled. Non-trivial changes ship through a staging tenant before production. Rollback is a version pin.
AI Consulting Services
See the AI Consulting Services page →Structured assessments that map organizational workflows to concrete AI opportunities and produce implementable architecture. Deliverables are written technical artifacts and working prototypes — not decks.
Assessment inputs
Workflow interviews, system inventory (identity provider, data warehouse, source-of-record systems, communication surfaces), and a data-access review. We produce a workflow map with candidate automation points annotated by feasibility, expected impact, and integration cost.
Architecture deliverables
For each recommended workflow: sequence diagram, integration surface (systems and required OAuth scopes), model call plan (prompts, expected tokens, guardrails), data-flow diagram with PII annotations, and a rollback plan. Deliverables are markdown and diagram files in a customer-owned repository.
Prototype scope
Where useful, we ship a working prototype in the customer's environment — connected to real systems, running against real (or masked) data — so the recommendation can be validated end-to-end before a production build is scoped.
Custom Software Development
See the Custom Software Development page →Web applications and services built to fit the customer's workflows and owned outright by the customer at the end of the engagement.
Default stack
TypeScript across the stack. React with a server-first framework (TanStack Start or Next.js) for web. Postgres for persistence, Prisma or Drizzle for typed access, Redis where async or caching is needed. Deployed to Railway, Vercel, or the customer's cloud account of choice.
Security defaults
OAuth or SAML SSO from day one, per-tenant row-level scoping, encrypted secrets, audit logging on privileged actions, dependency scanning in CI, and a documented data-retention policy shipped with the codebase.
Ownership
Customer owns the source repository, the CI/CD configuration, the cloud infrastructure account, and every credential. We can operate the system on retainer or hand off entirely.
Custom Software Integration
See the Custom Software Integration page →Purpose-built integrations between existing systems so data moves reliably and automatically instead of by hand. Integrations are idempotent, observable, and versioned.
Patterns supported
Event-driven (webhooks, message bus), scheduled polling with cursor state, and request-scoped RPC. Choice of pattern is driven by the source system's guarantees, not by preference.
Reliability model
Every write is idempotent and keyed. Every job has a bounded retry policy with exponential backoff and a dead-letter queue for permanent failures. Failures surface to a monitored channel with enough context to reproduce.
Data handling
PII fields are classified at design time and encrypted at rest. Retention windows are configurable per integration. Nothing is stored that isn't needed to make the integration work.
Ready to see what AI infrastructure actually looks like?
Discovery calls are the starting point. Tell us about your organization and we'll tell you whether we're the right fit.