Specification

Software Requirements Specification

The IEEE-830-shaped system specification for Kavanah — purpose and scope, overall description, functional and non-functional requirements, and external interfaces.

Last updated: July 28, 2026

This document is written to the section shape of IEEE 830 so that it can be read alongside your own specifications. It is the whole-system view: scope, user classes, operating environment, constraints, assumptions, and — most importantly for a regulated buyer — the non-functional requirements in section 3.2. Functional detail is referenced rather than duplicated: the numbered requirements live in the FRD and the behavioral detail in the FSD. Where we have no verified claim, this document says so rather than estimating.

1. Introduction

1.1 Purpose

This specification defines the requirements for Kavanah, an AI-native work-management platform delivered as a multi-tenant software service. Its audience is the technical, security, and procurement reviewers who must satisfy themselves that the product meets a defined requirement set before it is adopted, and the implementation teams who configure it afterwards. It is a description of the product as it exists, not a statement of roadmap intent.

1.2 Scope

Kavanah covers project and task management, team collaboration, client management and external portals, time tracking and project budgets, planning and portfolio management, reporting and analytics, engineering-delivery visibility, automation and external intake, and a governed AI agent that can act across all of the above. It is delivered as a web application, a native desktop application, and native mobile applications, together with a public REST API and an installable-apps platform.

Out of scope for this document: pricing and commercial terms (see pricing), contractual service commitments (see SLA), data-processing terms (see DPA), and implementation design (see TDS).

1.3 Definitions and abbreviations

Term	Definition
Workspace	The tenant boundary. Every record belongs to exactly one workspace; all access decisions are made within one.
Member	A user account holding a role within a workspace: owner, admin, or member.
Client-portal user	An external account confined to a single client record, holding no workspace role.
Persona / AI Employee	A configured agent identity with its own instructions, model, capability scopes, and member access list.
Capability scope	The set of agent tools a persona may use. A ceiling, never a grant of data access.
Safe mode	An agent mode in which write-capable tools are removed before the request is issued to the model.
Action policy	The engine that classifies a proposed agent action and parks risky actions for human approval.
Action ledger	The immutable record of agent tool executions.
Charter gate (KVN)	The delegation gate applied to every agent tool that creates a task.
Bet	A workspace-level statement of strategic intent that work associates upward to.
Sprint commitment	The scope a team records as committed at the start of a sprint.
FRD / FSD / TDS	Functional Requirements Document, Functional Specification Document, Technical Design Specification.

1.4 References

Document	Contains
FRD	Numbered functional requirements by area (WM, COL, CLI, TIM, PLN, RPT, AI, DEV, AUT, INT, IAM, SEC, ADM, API, PLT).
FSD	Workflows, state transitions, permission behavior, edge-case handling, business rules.
TDS	Technical design and implementation approach.
Capabilities Matrix	One-page functional summary.
Architecture Overview	System architecture and the integration security model.
Security Overview	Encryption, access control, tenant isolation, audit, secure development.
AI Transparency	How customer data is and is not used by AI providers.
Trust & Compliance	Certification status and NDA-gated artifact requests.

2. Overall description

2.1 Product perspective

Kavanah is a self-contained, multi-tenant SaaS product rather than a component of a larger system. It runs as a serverless application backed by a managed Postgres database; Kavanah operates no physical servers of its own. It interoperates with, but does not depend on, external systems: Google Workspace, Microsoft 365, ProtonMail, iCloud, Notion, ClickUp, Jira, Monday, ClearBooks, and GitHub are optional integrations authorized by the customer. A workspace with no integrations connected is fully functional.

One application codebase produces all three shells — web, desktop, and mobile — so functional behavior and security controls do not diverge by platform. The same authorization model serves the user interface, the REST API, and the AI agent's tool calls; there is no privileged back channel that bypasses it.

2.2 Product functions

Summarized here and specified in the FRD: work management (projects, tasks, sub-tasks, statuses, dependencies, custom fields, attachments, approvals, SLA policies, escalation, trash and restore); collaboration (chat, discussions, notifications, availability, calling); clients (records, portals, a Deal Room with Google Sheets synchronization); time and budgets; planning and portfolio (sprints, estimate calibration, quarter rollups, bets, capacity, skill-based routing with a decision ledger); reporting (dashboards, usage analytics, scheduled reports, State of the Business, executive meetings, digests); the AI agent and its governance; engineering delivery; automations and public intake; integrations and the community-apps marketplace; identity and access; security, audit and compliance tooling; administration; and the public API.

2.3 User classes and characteristics

User class	Characteristics	Requirement emphasis
Workspace owner	Commercially accountable. Typically a founder, partner, or department head. Low tolerance for administrative complexity.	Billing visibility, data governance, legal hold, audit access, plan and seat management.
Administrator	Configures the workspace: members, roles, integrations, automations, custom fields, SLA policies, personas. Technically confident.	Granular permission scopes, integration lifecycle, invite policy and approval queue, agent governance controls.
Member	Delivers the work. The highest-frequency user. May be on desktop, laptop, or phone throughout the day.	Fast task capture and status change, board/list/timeline views, time tracking, notification control including quiet hours.
Client-portal user	External to the customer's organization. Infrequent, low-training, high-sensitivity — the class where a disclosure mistake is most costly.	Strict confinement to one client record, non-enumeration of everything else, no path into internal surfaces.
Developer / integrator	Consumes the REST API or builds a marketplace app.	OpenAPI description, stable endpoints, scoped API keys, namespaced app tools, published SDK.
Auditor / reviewer	Security, privacy, or compliance function; may never log in at all.	Immutable audit log, retention configuration, eDiscovery export, evidence of tenant isolation, documented controls.

2.4 Operating environment

Layer	Environment
Server	Serverless functions on a managed platform; managed Postgres for persistence. No customer-operated infrastructure required.
Web client	Current versions of mainstream desktop and mobile browsers.
Desktop client	Native application shells for macOS, Windows, and Linux.
Mobile client	Native application shells for iOS and Android.
Network	HTTPS only; TLS 1.2 or higher, with HSTS asserted on the production domain.
Identity	Native accounts, SAML 2.0 or OIDC single sign-on, OAuth sign-in with Google or GitHub, optional TOTP MFA, optional SCIM provisioning.

2.5 Design and implementation constraints

Tenant filtering is mandatory. Every query against a workspace-scoped table must filter by workspace. This is enforced by an automated check in continuous integration that fails the build; exceptions require a written, allow-listed justification.
One authorization model. The user interface, the REST API, and agent tool execution resolve access through the same rules. A capability added to one path must be expressible in all three.
Agent writes are governed by construction. A write-capable agent tool must be registered with the safe-mode strip list and with an action-policy category; a tool that creates tasks must additionally be registered with the charter gate. These registrations are asserted by tests, so an unregistered write tool fails the build rather than shipping ungoverned.
Automatic action and credit spend are opt-in. Anything that acts without a user present or consumes AI credits defaults to disabled and fails closed. A workspace that has not enabled such a capability is served an identical product without it.
Schema changes are idempotent. Migrations must be safely re-applicable; continuous integration applies them twice to prove it.
Encryption keys are per-tenant. Application-layer ciphertexts are bound to a subkey derived per workspace or subject, so a value cannot be decrypted outside its own context.

2.6 Assumptions and dependencies

Customers authorize integrations themselves, via OAuth or a scoped API key they supply. Kavanah does not request credentials outside those flows, and any integration is revocable from workspace settings.
Functionality that depends on a third-party service — Gmail and Calendar sync, GitHub delivery data, Google Sheets synchronization, ClearBooks finance data — is available only while that authorization remains valid and that service is reachable.
AI features depend on an external model provider. Data handling by that provider, including the no-training posture, is documented on the AI Transparency page.
Clients require network connectivity for live data. The desktop and mobile shells present an informative offline state rather than failing blankly, but Kavanah is not an offline-first application.
Push notification delivery depends on the platform push services of Apple, Google, and the user's browser, and on the user granting permission.

3. Specific requirements

3.1 Functional requirements

Functional requirements are specified in full in the Functional Requirements Document and are not restated here. The table maps each SRS functional area to its FRD prefix and to the FSD section that describes the corresponding behavior, so a reviewer can trace a requirement from this document to a testable statement to an observable workflow.

Area	FRD prefix	Behavioral detail
Work management	`WM`	FSD §2 (workflow, transitions), §3 (views)
Collaboration	`COL`	FSD §9 (notification and delivery)
Clients and portals	`CLI`	FSD §4 (client-portal workflow)
Time and billing	`TIM`	FSD §6 (time tracking and triage)
Planning and portfolio	`PLN`	FSD §7 (planning workflow)
Reporting and analytics	`RPT`	FSD §9 (scheduled delivery)
AI agents	`AI`	FSD §8 (interaction model, safe mode, parking, personas)
Engineering delivery	`DEV`	FSD §1 (who sees delivery data)
Automations and intake	`AUT`	FSD §5 (intake workflow)
Integrations	`INT`	FSD §10.2 (duplicate and revocation handling)
Identity and access	`IAM`	FSD §1 (user classes), §10.1 (non-enumeration)
Security, audit, compliance	`SEC`	§3.2 below; /security
Administration	`ADM`	FSD §1 (role boundaries)
Programmatic access	`API`	§4.3 below
Platforms	`PLT`	§3.2.7 below

3.2 Non-functional requirements

The following are the system-quality requirements Kavanah is built against. Where a commitment is contractual rather than architectural, this section points at the contract instead of asserting a number.

3.2.1 Security

Requirement	Implementation
Confidentiality in transit	TLS 1.2 or higher for all client and API traffic; HSTS asserted on the production domain.
Confidentiality at rest	AES-256 at the database and storage layer. Integration credentials, OAuth tokens, MFA secrets and classified PII are additionally encrypted at the application layer with AES-256-GCM, so they are never readable plaintext even inside the database.
Key separation	Field-level ciphertexts are bound to a subkey derived with HKDF-SHA256 from a root key and the owning workspace or subject. No two tenants share an encryption key, and a ciphertext cannot be decrypted outside its own context.
Secret management	API keys and signing secrets are held as platform environment secrets, never in source control.
Tenant isolation	Every workspace-scoped query filters by workspace, enforced by an automated continuous-integration check that fails the build on violation. Exceptions require a written, allow-listed justification.
Authentication	bcrypt password hashing; signed JWT sessions validated server-side on every request; SAML 2.0 and OIDC SSO; TOTP MFA; OAuth sign-in with Google and GitHub; SCIM provisioning.
Authorization	Role-based access (owner, admin, member, client-portal) plus granular permission scopes, plus per-project and per-task access control. Applied identically to UI, API, and agent paths.
Least privilege for automation	Agent personas hold capability scopes that cannot exceed the invoking user's access; safe mode removes write tools entirely; the action policy parks risky actions for human approval.
Secure development	Peer-reviewed change management with automated type checking, unit tests, linting, SQL and tenant-scoping checks, and idempotent-migration verification on every change.
Vulnerability disclosure	A published good-faith reporting channel at security@kavanah.ai.

3.2.2 Privacy and compliance

Processor role. Workspace data belongs to the customer. Kavanah acts as a data processor and does not sell personal information. A Data Processing Addendum with Standard Contractual Clauses is available where required.
Data-subject rights. GDPR and CCPA export and erasure requests are supported and initiated by a workspace owner.
Data classification and loss prevention. Fields can be classified, and data-loss-prevention controls applied over classified data.
Data residency. Residency controls govern where workspace data is processed and stored. Discuss specific residency requirements before signature.
Sub-processors. The vendors that process customer data are published on the Sub-processors page.
Certification status — stated plainly. SOC 2 Type II is currently in its observation period; Kavanah is not SOC 2 certified today. ISO/IEC 27001 is planned, targeting Q4 2027. A HIPAA Business Associate Agreement is available on the Enterprise edition. Current status is maintained on the Trust & Compliance page; nothing on this page should be read as a certification.

3.2.3 Availability and recoverability

Kavanah runs on serverless compute with no long-lived shared application host, backed by a managed Postgres database with automated, continuous backups and point-in-time recovery. Restore procedures are documented in an operational runbook and exercised on a recurring restore drill, on the principle that a backup that has never been restored is not a backup. Platform health and every scheduled background job are monitored, with alerting on missed or failing jobs.

Availability targets, service credits, and support response commitments are contractual and are set out in the Service Level Agreement. Recovery objectives (RPO and RTO) and the wider continuity program are set out in Business Continuity. This specification deliberately states no figures of its own: the binding numbers are the ones in those documents, and a number repeated here would eventually contradict them.

3.2.4 Performance posture

Kavanah is architected for interactive, per-request scaling: compute is allocated per request rather than served from a fixed pool, so one tenant's load does not queue behind another's. Views apply their access filters and pagination at the data layer rather than fetching broadly and filtering in the client. Long-running work — scheduled reports, digests, integration synchronization, scheduled agent runs — executes on background schedules rather than inside an interactive request, and delivery is evaluated on due time so that a dropped scheduler tick delays nothing.

We publish no benchmark figures, no latency percentiles, and no throughput claims. Any number we quoted here would be a number measured on our data and our shapes, not yours. Where performance is a formal acceptance criterion, we will agree a measurement method against your workload rather than assert a figure.

3.2.5 Auditability

Requirement	Implementation
Tamper-evident audit trail	Security-relevant read, write, and administrative actions are written to an append-only audit log whose immutability is enforced by database triggers rather than by application convention.
Retention	Audit-log retention is configurable to seven years or longer for long-tail compliance obligations.
Agent attribution	Every agent tool execution is recorded to an immutable action ledger — what ran, under which persona, invoked by whom, with what outcome.
Decision attribution	Automated assignment decisions are recorded to an assignment-decision ledger with the factors that produced them, so an automated routing decision can be explained after the fact.
Reversibility	Agent actions with a defined inverse can be undone; both the action and its reversal appear in the ledger.
Legal hold and eDiscovery	Deletion of designated users, projects, or workspaces can be frozen under hold, with search and export across messages, tasks, and audit logs.
Administrator access	A workspace administrator can inspect their own workspace's audit log; no administrator can inspect another workspace's.

3.2.6 Maintainability

Continuous integration runs type checking, unit tests, linting, SQL and tenant-scoping analysis, and applies database migrations twice to prove idempotency, on every change.
Safety-critical registrations are asserted by tests rather than left to review: a write-capable agent tool that is missing from the safe-mode strip list or from an action-policy category fails the build, as does a task-creating tool missing from the charter gate.
The agent's capabilities are a flat registry of individually named tools with duplicate-name detection, so capability changes are reviewable one tool at a time rather than as opaque prompt edits.
The public API is described by a generated OpenAPI 3.1 document, and a coverage gate keeps the description aligned with the routes that exist.
Schema changes are additive and idempotent, allowing deployment without a maintenance window in the common case.

3.2.7 Portability across shells

Web, desktop (macOS, Windows, Linux) and mobile (iOS, Android) are built from one application codebase, with a native shell around it per platform. The consequence that matters for a security review is that feature behavior and security controls do not fork: there is no “mobile build” with a looser permission model, and a control added centrally applies on every device. Platform-specific surface is confined to what genuinely differs — native push delivery, application packaging and update, and the offline state a shell shows when it cannot reach the service.

3.2.8 Internationalization posture

The product interface is presented in English. Customer-entered content — task titles, messages, discussions, client records, documents — is stored and rendered as Unicode text, so non-English content is handled correctly throughout. Times are stored in coordinated universal time and rendered in the viewer's context, and scheduled delivery is evaluated against configured schedules rather than a single fixed office day. We do not currently publish localized interface translations, and we do not claim locale-specific formatting beyond date and time handling.

3.2.9 Accessibility posture

The interface is built on semantic HTML with keyboard-navigable controls, and colour treatments are theme-aware so that text contrast is maintained in both light and dark presentation. A formal VPAT or WCAG conformance report is not yet published, and we will not claim a conformance level we have not had assessed. If accessibility conformance is a procurement requirement, raise it during evaluation so we can tell you precisely where we stand rather than discovering it at contract stage.

4. External interface requirements

4.1 User interfaces

Interface	Description
Workspace application	The primary interface for owners, admins, and members: boards, list and timeline views, chat and discussions, planning, reporting, and administration. Behavior specified in the FSD.
Client portal	A separate interface for external stakeholders, confined to a single client record with no navigation path into internal surfaces.
Public intake forms	Unauthenticated, token-addressed forms that produce tasks. No account or session required to submit.
Conversational agent	A chat interface to the AI agent, subject to persona scopes, safe mode, and the action policy.
In-app knowledge surfaces	A knowledge base, in-app documentation, and a project-management course.
Desktop and mobile shells	The same application delivered as native applications, adding native push and an offline state.

4.2 Hardware interfaces

Kavanah requires no customer hardware beyond a network-connected personal computer or mobile device, and imposes no requirement for on-premises servers, appliances, or agents installed on customer infrastructure. The mobile and desktop applications interact with the host operating system only for what a native shell needs: notification delivery, local storage of the session, and application update.

4.3 Software interfaces

Interface	Contract
REST API	More than 500 endpoints across the product surface, described by an OpenAPI 3.1 document published at `/openapi.yaml` with human-readable reference at /docs.
API authentication	Workspace API keys of the form `kvn_live_…`, inheriting the permissions of the user who minted them and revocable at any time.
Agent tool execution	Named agent tools can be executed directly over HTTP, applying the same persona scope, policy evaluation, ledger write, and undo recording as the conversational path. Where policy requires approval the request parks rather than executing.
Identity providers	SAML 2.0 and OIDC for single sign-on; OAuth with Google and GitHub for sign-in; SCIM for directory provisioning and de-provisioning.
Productivity and mail	Google Workspace (Gmail, Calendar, Drive, Docs, Sheets, Slides, Forms, Tasks, Meet, Chat, Admin directory), Microsoft 365 and Outlook via Microsoft Graph, ProtonMail, and iCloud mail and calendar.
Work and finance systems	Notion, ClickUp, Jira, Monday, and ClearBooks.
Source control and delivery	GitHub via a GitHub App or OAuth authorization, supplying repositories, pull requests, commits, deploys, and build status.
Apps platform	A marketplace of installable community apps that register namespaced agent tools, together with a published app SDK. App tools are scoped and governed like first-party tools.
AI providers	An external model provider serves the agent. Data-handling terms are documented on the AI Transparency page.

Every integration above is established through customer-authorized OAuth or a scoped API key the customer supplies, is revocable from workspace settings, and has its stored credential encrypted at the application layer. Kavanah does not request credentials outside those flows.

4.4 Communications interfaces

Channel	Protocol and behavior
Client to service	HTTPS with TLS 1.2 or higher; HSTS asserted on the production domain. There is no unencrypted transport.
Outbound email	Notifications, scheduled reports, digests, invitations, and agent-composed mail, sent through the workspace's configured mail path.
Native push	Delivered to desktop and mobile applications through the relevant platform push service, subject to the user granting permission and to quiet-hours suppression.
Inbound webhooks	Events from authorized integrations, most significantly source-control activity from GitHub.
Scheduled background execution	Reports, digests, integration synchronization, and — where enabled — agent runs, executed on schedule and evaluated on due time rather than exact tick matching.

5. Editions and applicability

Functional and non-functional requirements in this document apply to the platform as a whole. Quantitative entitlements differ by edition and are the only dimension on which the product is deliberately limited; security controls, tenant isolation, encryption, and audit behavior do not vary by edition.

Edition	Members	Projects	Storage	AI credits
Starter (free)	5	3	2 GB	100 per month
Basic — $3 per seat / month	Unlimited	10	5 GB	100 per seat
Pro — $6 per seat / month	Unlimited	50	25 GB	250 per seat
Enterprise	Custom	Custom	Custom	Custom

A HIPAA Business Associate Agreement is available on the Enterprise edition. Current commercial terms are on the pricing page and take precedence over this summary.

Reviewing Kavanah against your own specification?

Send us your requirement schedule and security questionnaire. We will map them onto this document and onto the FRD requirement identifiers, answer the non-functional sections in your format, and state plainly where we do not yet meet a requirement. Audited artifacts and questionnaire responses are shared under NDA from the Trust & Compliance page.

Email security@kavanah.ai Trust & Compliance

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.