Technical
Technical Data Sheet
Specification-level reference for Kavanah — deployment model, client requirements, identity, API, integrations, data handling, and edition limits. Written for the IT and engineering reviewers on a procurement committee.
Last updated: July 28, 2026
This data sheet states what Kavanah is and what it requires. Narrative explanations live elsewhere: the Security Overview covers controls, Architecture covers the stack, and the Software Design Specification covers how the system is designed. Figures on this page are specifications, not measurements — where a number would be a performance claim, this document points to the SLA instead.
Deployment model
| Attribute | Specification |
|---|---|
| Delivery model | Multi-tenant SaaS. One production deployment serves all workspaces; tenants are separated by enforced row-level scoping rather than by separate installations. |
| Compute | Node.js serverless functions on Vercel Fluid Compute. Auto-scaling, with no customer-visible application host. |
| Compute isolation | Isolated per-request function instances. There is no long-lived shared application host that could retain one customer's data across another customer's request. |
| Database | Managed Neon Postgres, accessed exclusively via parameterized SQL. |
| Infrastructure providers | Vercel (application) and Neon (database). Both operate SOC 2-audited data centers. Full vendor inventory: Sub-processors. |
| Region | Production data is processed in the United States. |
| On-premise / self-hosted | Not offered. Kavanah is delivered exclusively as a hosted service. |
| Private / single-tenant instance | Not offered as a standard edition. Enterprise customers with specific residency or isolation requirements should raise them during evaluation. |
| Customer-managed infrastructure | None required. No servers, containers, databases, runtimes, or scheduled-job hosts for the customer to provision, patch, or scale. |
| Customer-managed keys (BYOK / HYOK) | Not offered. Encryption keys are managed by Kavanah; sensitive fields use per-workspace derived subkeys (see Data specifications). |
| Application shells | Web, desktop (macOS / Windows / Linux), and mobile (iOS / Android with native push) — all built from one codebase. |
| Update model | Shells load the deployed application rather than a bundled copy, so fixes and updates reach every platform at once. There is no stale client to patch and no customer-side upgrade window. |
Client system requirements
Supported clients
| Client | Requirement |
|---|---|
| Web browser | Current release channel of Chrome, Edge, Safari, or Firefox (evergreen — the latest stable version and the automatic updates that follow it). JavaScript and cookies must be enabled. |
| Desktop application | Native shell for macOS, Windows, and Linux. Optional — the web app is fully functional without it. |
| Mobile application | Native iOS and Android shells, with native push notifications. Optional. |
| Display / input | Responsive layout. The application imposes no minimum resolution and no pointer-device requirement. |
Network requirements
| Requirement | Specification |
|---|---|
| Outbound access | HTTPS (TCP 443) from the client to the application domain (kavanah.ai) and its content-delivery endpoints. |
| Ports | Standard web ports only. All client traffic uses TCP 443; no non-standard or ephemeral port range is required. |
| Inbound firewall changes | None. Kavanah never initiates a connection into the customer network, so no inbound rule, port forward, or DMZ host is required. |
| VPN / private link | Not required. Access is over the public internet, secured by TLS and authenticated on every request. |
| Endpoint agent | None. No desktop agent, kernel extension, or browser extension is required to use the web application. |
| Proxy / TLS inspection | Supported, provided the proxy passes standard HTTPS and does not strip authentication cookies or long-lived connections. |
| Static outbound IPs | Not published. Kavanah runs on auto-scaling serverless infrastructure whose egress addresses are not fixed; allow-listing should be done by domain. |
A network allow-list needs only outbound HTTPS to the application domain. Kavanah requires no change to inbound firewall policy, no VPN concentrator, and no software installed on managed endpoints.
Identity & access
| Control | Specification |
|---|---|
| Password authentication | Email and password. Passwords are hashed with bcrypt and are never stored or logged in plaintext. |
| Session model | Signed JWT sessions, validated server-side on every request, and revocable. |
| Multi-factor authentication | TOTP authenticator applications. |
| Single sign-on | SAML 2.0 and OIDC against enterprise identity providers. |
| OAuth sign-in | Google and GitHub. |
| Directory provisioning | SCIM directory sync for automated user provisioning and deprovisioning. |
| Role model | Owner, admin, member, and client-portal roles, with granular permission scopes layered on top for administrative and AI-agent capabilities. |
| API authentication | First-party session tokens, or workspace API keys prefixed kvn_live_presented as a bearer credential. A key inherits the RBAC of the user who minted it — it cannot exceed that user's permissions. |
| Cross-origin protection | Strict origin and CSRF checks on state-changing requests. |
| Agent identity | AI personas carry their own instructions, model, capability scopes, and member access list, so an automated identity is constrained independently of the human who invokes it. |
API surface
| Attribute | Specification |
|---|---|
| Specification format | OpenAPI 3.1 |
| Endpoint count | 500+ documented endpoints |
| Protocol | REST over HTTPS, with JSON request and response bodies |
| Machine-readable spec | /openapi.yaml |
| Human reference | The API Reference section of the product documentation at /docs, including a full endpoint listing generated from the specification. |
| Authentication modes | Session token (browser and native shells), or workspace API key (kvn_live_…) for server-to-server use. |
| Authorization | Identical to the UI. Every endpoint enforces the same authentication, workspace scoping, and role checks, because the UI is simply a client of this API. There is no privileged back channel and no endpoint that skips a check the UI performs. |
| Cross-origin controls | Strict origin and CSRF validation on state-changing requests. |
| Webhooks | Outbound webhooks deliver audit-log events to a customer-controlled endpoint. Inbound webhook receivers exist for supported integration providers. |
| Command-line access | A zero-dependency CLI drives the same REST API with a workspace API key, inheriting the minting user's RBAC on every request. |
Integration specifications
Every integration is authorized by the customer and can be revoked at any time from workspace settings. Credentials and OAuth tokens are encrypted at the application layer (see Data specifications), scoped to the least privilege each feature needs. Data is exchanged only between the customer's workspace and the service they connected.
| Provider | Mechanism | What syncs |
|---|---|---|
| Google Workspace — Gmail | OAuth 2.0 | Mail send and receive for the unified inbox |
| Google Workspace — Calendar | OAuth 2.0 | Calendar events and availability |
| Google Workspace — Drive | OAuth 2.0 | Files and documents linked to work items |
| Google Workspace — Sheets | OAuth 2.0 | Two-way spreadsheet sync for the deal room and accounts |
| Google Workspace — Admin directory | OAuth 2.0 | Directory lookup for member records |
| Microsoft 365 / Outlook | OAuth 2.0 (Microsoft Graph) | Mail and calendar |
| Microsoft Teams | OAuth 2.0 | Messaging surfaces |
| Slack | OAuth 2.0 | Messaging surfaces |
| GitHub | OAuth 2.0 / GitHub App | Repositories, pull requests, commits, and deploys |
| Notion | OAuth 2.0 | Pages and databases mapped to projects and tasks |
| Asana | OAuth 2.0 | Projects and tasks |
| Jira | Scoped API key | Issues and project mapping |
| ClickUp | Scoped API key | Tasks, lists, and project mapping |
| Monday | Scoped API key | Boards, items, and project mapping |
| ClearBooks | Scoped API key | Invoices, expenses, and finance records |
| ProtonMail | Scoped credential | Outbound and inbound mail |
| iCloud | Scoped credential (app-specific password) | Mail and calendar |
Further providers are listed in the in-product integrations catalogue. See Capabilities for the functional view and Architecture for the integration security model.
Data specifications
| Attribute | Specification |
|---|---|
| Storage engine | Managed Neon Postgres. All access is via parameterized SQL. |
| Tenancy model | Multi-tenant. Every workspace-scoped table carries a workspace_id, and every query against such a table must filter on it. |
| Isolation enforcement | Mechanical rather than procedural: a continuous-integration linter scans the codebase on every change and fails the build when a query against a workspace-scoped table is missing its tenant filter. Any exception requires an explicit allow-list entry with a written justification. |
| Encryption in transit | TLS 1.2+ for all client and API traffic, with HSTS enforced on the production domain. |
| Encryption at rest | AES-256 at the database and storage layer, provided by the managed infrastructure. |
| Field-level encryption | Integration credentials, OAuth tokens, MFA secrets, and classified PII fields are additionally encrypted at the application layer with AES-256-GCM (authenticated encryption). |
| Key separation | Field-level ciphertexts are bound to a subkey derived via HKDF-SHA256 from a root key and the owning workspace or subject. No two tenants share an encryption key, and a value cannot be decrypted outside its own context. |
| Secrets handling | API keys and signing secrets are held as platform environment secrets, never in source control. |
| Data residency | United States. |
| Backups | Continuous backups with point-in-time recovery at the managed database layer. Restore procedures are documented and exercised on a recurring drill. |
| Audit-log retention | Append-only audit log with immutability enforced by database triggers. Retention is configurable to 7+ years. |
| Legal hold | Deletion of specific users, projects, or workspaces can be frozen under litigation hold, with search and export across messages, tasks, and audit logs. |
| Deletion | Customer-initiated deletion of records, projects, and workspaces, with recoverable trash for supported entities before permanent removal. |
| Subject rights | GDPR and CCPA export and erasure, initiated by workspace owners from Settings → Data Governance. |
| Export formats | Structured JSON and CSV via the product and the REST API. Audit-log and compliance exports are produced from the audit surface. |
| Ownership | Workspace data is owned by the customer. Kavanah acts as a data processor and does not sell personal information. |
How customer data is — and is not — used by the underlying AI providers, including the no-training posture, is documented on the AI Transparency page.
Security controls summary
Compact control index. The narrative for each control is in the Security Overview.
| Control area | Implementation |
|---|---|
| Transport security | TLS 1.2+ with HSTS on the production domain |
| Encryption at rest | AES-256 at the storage layer; AES-256-GCM at the application layer for sensitive fields |
| Key management | Per-workspace subkeys derived via HKDF-SHA256; no shared tenant keys |
| Authentication | bcrypt passwords, signed-JWT sessions, TOTP MFA, SAML 2.0 / OIDC SSO |
| Authorization | Owner / admin / member / client-portal roles plus granular permission scopes, enforced identically for UI, API, and AI-agent access |
| Provisioning | SCIM directory sync |
| Tenant isolation | Mandatory workspace_id filtering, enforced by a CI linter that fails the build |
| Audit | Append-only audit log with database-enforced immutability, configurable 7+ year retention, and legal hold |
| Change management | Version-controlled changes with peer review; CI type checking, unit tests, lint, SQL and tenant-scoping linters, and twice-applied migrations |
| Vulnerability management | Annual third-party penetration test; summary and remediation status shared under NDA |
| Attestation | SOC 2 Type II is in its observation period. ISO/IEC 27001 is planned, targeting Q4 2027. |
| Healthcare | HIPAA BAA available on the Enterprise edition, executed before any PHI is processed |
| Disclosure | Coordinated vulnerability disclosure to security@kavanah.ai |
Kavanah does not currently hold a completed SOC 2 Type II attestation or an ISO/IEC 27001 certificate. SOC 2 Type II is in its observation period and ISO/IEC 27001 is planned for Q4 2027. Nothing on this page should be read as a claim to hold a certification we have not yet received; current status is always shown on the Trust & Compliance page.
Availability & recovery
Kavanah runs on auto-scaling serverless infrastructure with no single application host to fail, over a managed Postgres database with continuous backups and point-in-time recovery. Restore procedures are documented in an operational runbook and exercised on a recurring drill, because a backup that has never been restored is not a backup.
| Topic | Where it is specified |
|---|---|
| Uptime commitment and service credits | Service Level Agreement |
| Support severities and response targets | Service Level Agreement |
| Recovery objectives (RPO / RTO), backup schedule, drill cadence | Business Continuity & Disaster Recovery |
| Incident response and customer communication | Business Continuity & Disaster Recovery |
Availability and recovery figures are commitments rather than marketing numbers, so this data sheet does not restate them. The binding values are the ones in an executed order form or master agreement.
Observability & operations
| Facility | Specification |
|---|---|
| Health endpoint | A platform health endpoint (/api/system/health) reports application and dependency status and is continuously polled by monitoring. |
| Scheduled-job monitoring | A cron-health registry enumerates every scheduled background job with its expected interval, so a missed or failing run is detected rather than silently skipped. |
| Job execution model | Background jobs are idempotent by design: a re-run produces the same end state rather than duplicate work. |
| Audit logging | Security-relevant read, write, and administrative actions are written to an append-only log whose immutability is enforced by database triggers. Searchable and exportable, with configurable 7+ year retention. |
| Audit alerting | Audit-log alert rules and outbound webhooks let customer security tooling receive events without polling. |
| Administrative analytics | Workspace administrators have usage analytics for their own workspace. There is no cross-tenant reporting surface. |
| Production access | Least-privilege, scoped to the engineers who require it. |
Limits & quotas
| Edition | Price | Seats | Projects | Storage | AI credits |
|---|---|---|---|---|---|
| Starter | Free | 5 members | 3 | 2 GB | 100 / month |
| Basic | $3 per seat / month ($2 billed yearly) | Unlimited | 10 | 5 GB | 100 per seat / month |
| Pro | $6 per seat / month ($4 billed yearly) | Unlimited | 50 | 25 GB | 250 per seat / month |
| Enterprise | Custom | Unlimited | Custom | Custom | Custom |
Seats are uncapped on every paid edition — Basic, Pro, and Enterprise place no limit on how many members a workspace may have, and only Starter caps membership. AI credits are consumed by agent and AI-assisted features, and can be purchased on top of the included monthly allowance. Current pricing is on the Pricing page; the commercial terms that bind are those in an executed order form.
These are the commercial limits of each edition. Kavanah does not publish throughput, concurrency, or request-rate figures as product specifications. If your evaluation requires a specific load profile, raise it with us during the technical review.
Need this in your format?
Procurement teams often need these specifications transposed into a vendor questionnaire, an architecture-review template, or a completed SIG or CAIQ. Send us the form and we will complete it against this data sheet rather than paraphrasing it.
Artifacts shared under NDA — the SOC 2 report once the observation period closes, and the penetration-test summary — are requested from the Trust & Compliance page.
Questions from a security, privacy, or procurement team? Email security@kavanah.ai. For SOC 2, penetration-test, or questionnaire artifacts shared under NDA, use the request forms on the Trust & Compliance page.