Specification
Functional Requirements Document
Numbered, individually testable statements of what the Kavanah platform must do — the artifact an enterprise implementation traces acceptance criteria against.
Last updated: July 28, 2026
This document enumerates the functional requirements of Kavanah as a product. Each requirement is written as a single verifiable statement, carries a stable identifier, and can be mapped one-to-one to an acceptance test. It deliberately does not describe screens, sequencing, or interaction detail — that is the job of the Functional Specification Document.
Identifier scheme. Requirement IDs take the form PREFIX-NNN, where the prefix names the functional area (for example WM for work management, IAM for identity and access). Identifiers are stable: a requirement that is superseded is marked as such rather than renumbered, and new requirements take the next free number in their area. Reference requirements by ID in RFP responses, traceability matrices, and test plans.
Availability.Unless a row's notes say otherwise, the requirement describes generally available functionality across all Kavanah editions. Where a requirement is edition-gated, administrator-only, or dependent on a customer-supplied integration credential, the notes column says so explicitly. Plan limits (member counts, project counts, storage, AI credits) are set out on the pricing page and are not restated per requirement.
How to read this document set
| Document | Answers | Read it when |
|---|---|---|
| FRD (this page) | What must the system do? | You are building a traceability matrix or scoring an RFP requirement by requirement. |
| FSD | How does the product behave? | You need workflows, screen behavior, state transitions, business rules, and edge-case handling. |
| SRS | What are the whole-system requirements, functional and non-functional? | You need the IEEE-830-shaped document: scope, user classes, constraints, non-functional requirements, and external interfaces. |
| TDS | How is it built? | You are reviewing the technical design, data model, and implementation approach. |
| Capabilities Matrix | What is in the box, at a glance? | You want a one-page functional summary rather than requirement statements. |
| Security Overview | How is the data protected? | You are running a security or vendor review; pairs with the SEC requirements below. |
WM — Work management
Requirements governing the core objects of the platform: projects, tasks, and the lifecycle they move through.
| ID | Requirement | Notes |
|---|---|---|
| WM-001 | The system shall allow an authorized user to create, rename, edit, archive, and delete projects within a workspace. | Project count per workspace is edition-limited. |
| WM-002 | The system shall allow an authorized user to create tasks and to associate each task with at most one project. | A task may also exist without a project. |
| WM-003 | The system shall support sub-tasks, such that a task may have child tasks that are tracked and completed independently of the parent. | Sub-tasks carry the same field set as top-level tasks. |
| WM-004 | The system shall maintain a task status of open, in progress, review, or completed, and shall allow an authorized user to move a task between statuses. | Status is the axis boards and reporting are organized around. |
| WM-005 | The system shall allow a task to be assigned to a workspace member, reassigned, or left unassigned. | See PLN-007 for automated routing. |
| WM-006 | The system shall allow a due date to be set, changed, and cleared on any task. | Overdue state is derived, not stored. |
| WM-007 | The system shall allow dependencies to be declared between tasks so that one task is recorded as blocking or blocked by another. | Surfaced in timeline and planning views. |
| WM-008 | The system shall allow a workspace administrator to define custom fields and shall allow values for those fields to be recorded against tasks. | Custom-field definitions are workspace-scoped. |
| WM-009 | The system shall allow files to be attached to a task and retrieved by any user permitted to view that task. | Attachment storage is edition-limited. |
| WM-010 | The system shall present tasks in board, list, and timeline views, and shall allow a user to switch between them without losing the active filter context. | Board is grouped by status. |
| WM-011 | The system shall support an approval step on a task, such that a designated approver records an approval decision before the task is treated as complete. | Task approvals are configured per workspace. |
| WM-012 | The system shall allow escalation rules to be defined that act on tasks meeting configured conditions. | Administrator-configured. |
| WM-013 | The system shall allow SLA policies to be defined and evaluated against tasks so that response and resolution expectations are tracked. | Administrator-configured. |
| WM-014 | The system shall retain deleted tasks and projects in a recoverable trash state and shall allow an authorized user to restore them. | See FSD for retention and restore behavior. |
COL — Collaboration
| ID | Requirement | Notes |
|---|---|---|
| COL-001 | The system shall provide direct messages between workspace members, group message threads, and named channels. | Collectively, team chat. |
| COL-002 | The system shall support replying to a specific message and forwarding a message to another conversation. | |
| COL-003 | The system shall support @-mentions of members within chat and discussions, and shall notify the mentioned member. | Mention read state is tracked per user. |
| COL-004 | The system shall record and display delivery receipts for chat messages. | |
| COL-005 | The system shall provide threaded, project-scoped discussions distinct from chat. | Discussions are durable project records; chat is conversational. |
| COL-006 | The system shall provide an in-app notification centre listing notifications addressed to the signed-in user. | |
| COL-007 | The system shall deliver notifications by email and by native push on desktop and mobile, per the recipient's preferences. | Push requires the desktop or mobile app. |
| COL-008 | The system shall allow a user to configure quiet hours, during which email and push notifications are suppressed. | In-app notifications continue to accrue. |
| COL-009 | The system shall allow members to self-report their availability, and shall allow a leader to raise an availability request that members respond to. | |
| COL-010 | The system shall support video and voice calling between workspace members. |
CLI — Clients & portals
| ID | Requirement | Notes |
|---|---|---|
| CLI-001 | The system shall allow client records to be created and maintained, and shall allow projects and tasks to be associated with a client. | |
| CLI-002 | The system shall provide a client portal through which external stakeholders access the work associated with their client record. | |
| CLI-003 | The system shall issue client-portal members their own accounts, distinct from workspace member accounts. | See IAM-008 for the role boundary. |
| CLI-004 | The system shall restrict client-portal members to the client record they belong to, such that work belonging to other clients is not listed to them. | Non-enumeration, not shown-and-denied. See FSD. |
| CLI-005 | The system shall provide a Deal Room in which sales opportunities are tracked through a pipeline. | |
| CLI-006 | The system shall support two-way synchronization between the Deal Room and a customer-authorized Google Sheet. | Requires a connected Google account. |
| CLI-007 | The system shall support linking a client or account record to a Google Sheet for synchronization. | Requires a connected Google account. |
TIM — Time & billing
| ID | Requirement | Notes |
|---|---|---|
| TIM-001 | The system shall allow a member to record a time entry against a task or a project. | |
| TIM-002 | The system shall support an active timer that a member starts and stops, producing a time entry on stop. | One active timer per member. |
| TIM-003 | The system shall allow a member to edit or delete their own time entries. | |
| TIM-004 | The system shall report logged time aggregated by member, task, project, and period. | |
| TIM-005 | The system shall allow a budget to be set on a project. | |
| TIM-006 | The system shall allow budget entries to be recorded against a project budget and shall report consumption against it. |
PLN — Planning & portfolio
| ID | Requirement | Notes |
|---|---|---|
| PLN-001 | The system shall support sprint planning, allowing work to be selected into a sprint and a sprint commitment to be recorded. | |
| PLN-002 | The system shall allow effort estimates to be recorded against tasks. | |
| PLN-003 | The system shall calibrate estimates against historical actuals and present a p50–p90 forecast range at the planning layer. | The forecast is presentational; it is never written back onto the stored estimate. |
| PLN-004 | The system shall roll planned and delivered work up to a quarter view. | |
| PLN-005 | The system shall allow workspace-level bets to be defined and work to be associated with them. | Bets express strategic intent above the project layer. |
| PLN-006 | The system shall model member capacity and allocation across projects for portfolio resourcing. | |
| PLN-007 | The system shall recommend and, where enabled, automatically assign a task to the best-matched member. | Automatic routing is opt-in per workspace. |
| PLN-008 | The system shall record every automated assignment decision, including the factors considered, in an assignment-decision ledger. | Readable by administrators. |
| PLN-009 | The system shall maintain skill profiles for members and shall update member experience profiles from completed work. | |
| PLN-010 | The system shall provide a triage queue of unrouted or unassigned incoming work. |
RPT — Reporting & analytics
| ID | Requirement | Notes |
|---|---|---|
| RPT-001 | The system shall present a productivity dashboard summarizing completion and throughput for the workspace. | |
| RPT-002 | The system shall present workspace usage analytics to workspace administrators. | Administrator-only. |
| RPT-003 | The system shall allow a recurring report to be scheduled on a cron expression. | |
| RPT-004 | The system shall deliver a scheduled report to named recipients or to a dynamic group evaluated at send time. | |
| RPT-005 | The system shall produce a State of the Business report summarizing the workspace across delivery, clients, and financial signals. | Opt-in per workspace. |
| RPT-006 | The system shall support executive meetings (boardrooms) in which agent participants deliberate over workspace data and produce a written output. | Opt-in per workspace; consumes AI credits. |
| RPT-007 | The system shall produce digests summarizing recent workspace activity for delivery to members. |
AI — AI agents
Kavanah's agent is a first-class actor in the workspace, not a chat sidebar. The requirements below cover both what it can do and the governance that constrains it. Data handling by the underlying model providers is documented on the AI Transparency page.
| ID | Requirement | Notes |
|---|---|---|
| AI-001 | The system shall provide a conversational agent that can search the workspace, answer questions about it, and create or update work in response to a natural-language request. | |
| AI-002 | The system shall expose the agent's capabilities as a registry of discrete, individually named tools. | Approximately 896 tools registered. |
| AI-003 | The system shall allow an administrator to define AI Employees (personas) with their own instructions, model selection, and capability scopes. | |
| AI-004 | The system shall restrict which workspace members may invoke a given persona. | Per-persona member access control. |
| AI-005 | The system shall restrict a persona to the subset of tools permitted by its capability scopes. | Scope filtering applies to every invocation path. |
| AI-006 | The system shall maintain agent memory, follow-ups, goals, and runbooks so that context and commitments persist across conversations. | |
| AI-007 | The system shall support scheduled agent runs that execute on a recurring schedule without a user present. | Opt-in per workspace; consumes AI credits. |
| AI-008 | The system shall provide a product-knowledge tool through which the agent can direct a user to any feature of the application. | |
| AI-009 | The system shall provide a safe mode in which all write-capable tools are removed from the agent before the request is issued. | Not a post-hoc refusal — the capability is absent. |
| AI-010 | The system shall evaluate each proposed agent action against a configurable action policy and shall park actions classified as risky for human approval rather than executing them. | |
| AI-011 | The system shall record every agent tool execution to an immutable action ledger. | See SEC-005. |
| AI-012 | The system shall maintain an undo stack of inverse operations so that an eligible agent action can be reversed by a user. | |
| AI-013 | The system shall apply a charter gate (KVN) to every agent tool that creates a task, such that agent-created work must satisfy the workspace's delegation charter. | An agent boundary; human and API task creation is intentionally ungated. |
| AI-014 | The system shall support drafting and summarization of messages, reports, and documents on request. | |
| AI-015 | The system shall meter AI usage against the workspace's credit allowance. | Allowance is edition-dependent. |
DEV — Engineering delivery
| ID | Requirement | Notes |
|---|---|---|
| DEV-001 | The system shall present repositories, pull requests, and commits for connected source-control accounts. | Requires a connected GitHub account. |
| DEV-002 | The system shall present deploys and build status alongside the work they relate to. | |
| DEV-003 | The system shall record incidents and present them in the delivery view. | |
| DEV-004 | The system shall present observability alerts in the delivery view. | |
| DEV-005 | The system shall synchronize repository and pull-request state from GitHub via a GitHub App or OAuth authorization. | Customer-authorized; revocable. |
| DEV-006 | The system shall generate a structured task breakdown from a written specification. | Consumes AI credits. |
| DEV-007 | The system shall present code-review diffs for a pull request within the application. |
AUT — Automations & intake
| ID | Requirement | Notes |
|---|---|---|
| AUT-001 | The system shall allow automation rules to be defined that trigger on a workspace event. | |
| AUT-002 | The system shall allow automation rules to be defined that trigger on a time condition, such as a task becoming overdue. | |
| AUT-003 | The system shall allow the action taken by an automation rule to be configured. | |
| AUT-004 | The system shall allow an automation rule to be enabled and disabled without deleting it. | |
| AUT-005 | The system shall provide public request-intake forms addressable by an unguessable token. | No account required to submit. |
| AUT-006 | The system shall convert a submitted intake form into a task in the workspace that owns the form. | See FSD for the intake workflow. |
INT — Integrations
| ID | Requirement | Notes |
|---|---|---|
| INT-001 | The system shall integrate with Google Workspace, covering Gmail, Calendar, Drive, Docs, Sheets, Slides, Forms, Tasks, Meet, Chat, and the Admin directory. | Per-service scopes; customer-authorized. |
| INT-002 | The system shall integrate with Microsoft 365 and Outlook via Microsoft Graph. | |
| INT-003 | The system shall support ProtonMail, and iCloud mail and calendar, as mail and calendar sources. | |
| INT-004 | The system shall integrate with Notion, ClickUp, Jira, and Monday for work synchronization. | |
| INT-005 | The system shall integrate with ClearBooks for finance data. | |
| INT-006 | The system shall establish every integration through customer-authorized OAuth or a scoped API key supplied by the customer. | Kavanah never requests credentials outside these flows. |
| INT-007 | The system shall allow a workspace administrator to revoke any integration from workspace settings, after which the stored credential is no longer usable. | |
| INT-008 | The system shall encrypt stored integration credentials and OAuth tokens at the application layer. | See SEC-002. |
| INT-009 | The system shall deduplicate calendar events and resolve mail to a single backend where two connected providers surface the same underlying account. | |
| INT-010 | The system shall provide a marketplace of installable community apps, each able to register namespaced agent tools, together with a published app SDK. | App tools are namespaced and scoped like first-party tools. |
IAM — Identity & access
| ID | Requirement | Notes |
|---|---|---|
| IAM-001 | The system shall authenticate users and issue sessions as signed JSON Web Tokens validated server-side on every request. | |
| IAM-002 | The system shall store user passwords only as bcrypt hashes and shall never log or transmit them in plaintext. | |
| IAM-003 | The system shall support single sign-on via SAML 2.0 and OIDC. | Enterprise identity providers. |
| IAM-004 | The system shall support OAuth sign-in with Google and GitHub. | |
| IAM-005 | The system shall support TOTP and WebAuthn (passkey / security key) multi-factor authentication on every sign-in path. | MFA secrets are encrypted at the application layer. |
| IAM-006 | The system shall support SCIM directory synchronization for user provisioning and de-provisioning. | |
| IAM-007 | The system shall allow a workspace to invite users by email, governed by a configurable invite policy and, where the policy requires it, an invite-approval queue. | |
| IAM-008 | The system shall assign every account exactly one of the roles owner, admin, member, or client-portal within a workspace. | Client-portal accounts cannot hold a workspace role. |
| IAM-009 | The system shall constrain administrative and agent capabilities by granular permission scopes in addition to role. | |
| IAM-010 | The system shall support per-project access control, restricting a project and its contents to designated members. | |
| IAM-011 | The system shall support per-task access control, restricting an individual task to designated members. | |
| IAM-012 | The system shall apply the same access decisions to human requests, API requests, and agent tool calls. | One authorization model, three entry points. |
SEC — Security, audit & compliance
These requirements are the functional expression of the controls described in the Security Overview. Certification status is stated on the Trust & Compliance page and is not asserted here.
| ID | Requirement | Notes |
|---|---|---|
| SEC-001 | The system shall serve all client and API traffic over TLS 1.2 or higher and shall assert HTTP Strict Transport Security on the production domain. | |
| SEC-002 | The system shall encrypt integration credentials, OAuth tokens, MFA secrets, and classified PII at the application layer using AES-256-GCM. | In addition to AES-256 at-rest encryption at the storage layer. |
| SEC-003 | The system shall derive a distinct encryption subkey per workspace or subject using HKDF-SHA256, such that a ciphertext cannot be decrypted outside its own tenant context. | |
| SEC-004 | The system shall scope every query against a workspace-scoped table by workspace identifier, enforced by an automated check that fails the build on violation. | Exceptions require a written, allow-listed justification. |
| SEC-005 | The system shall record security-relevant actions to an append-only audit log whose immutability is enforced by database triggers. | |
| SEC-006 | The system shall allow audit-log retention to be configured to seven years or longer. | |
| SEC-007 | The system shall support legal hold, freezing deletion of designated users, projects, or workspaces. | |
| SEC-008 | The system shall support eDiscovery search and export across messages, tasks, and audit logs. | |
| SEC-009 | The system shall support GDPR and CCPA data-subject requests, producing an export of an individual's data or erasing it. | Initiated by a workspace owner. |
| SEC-010 | The system shall support data-classification of fields and data-loss-prevention controls over classified data. | |
| SEC-011 | The system shall support data-residency controls governing where workspace data is processed and stored. | |
| SEC-012 | The system shall monitor platform health and every scheduled background job, and shall alert on missed or failing jobs. |
ADM — Administration
| ID | Requirement | Notes |
|---|---|---|
| ADM-001 | The system shall allow a workspace to be created, named, branded, and configured by its owner. | |
| ADM-002 | The system shall allow an administrator to list workspace members, change a member's role, and remove a member. | Subject to the role hierarchy — see FSD. |
| ADM-003 | The system shall allow an administrator to de-provision a departing member and transfer their assigned work to another member. | |
| ADM-004 | The system shall allow an administrator to enable or disable optional workspace features individually. | Optional features default to disabled. |
| ADM-005 | The system shall allow an administrator to review and act on the invite-approval queue. | Where the invite policy requires approval. |
| ADM-006 | The system shall present the workspace's plan, seat count, and AI-credit consumption to the owner. | |
| ADM-007 | The system shall provide a knowledge base, in-app documentation, and a project-management course to workspace users. | |
| ADM-008 | The system shall allow an administrator to inspect the audit log for their own workspace. |
API — Programmatic access
| ID | Requirement | Notes |
|---|---|---|
| API-001 | The system shall expose a REST API covering more than 500 endpoints across the product surface. | |
| API-002 | The system shall publish a machine-readable OpenAPI 3.1 description of that API. | Served at /openapi.yaml. |
| API-003 | The system shall publish human-readable API reference documentation. | At /docs. |
| API-004 | The system shall allow a workspace to mint API keys of the form kvn_live_… for programmatic access. | |
| API-005 | The system shall constrain an API key to the permissions of the user who minted it. | A key cannot exceed its minter's access. |
| API-006 | The system shall allow an API key to be revoked, after which requests presenting it are rejected. | |
| API-007 | The system shall allow a named agent tool to be executed directly over HTTP, applying the same scope, policy, ledger, and undo behavior as the conversational path. | Parks rather than executes where policy requires approval. |
PLT — Platforms
| ID | Requirement | Notes |
|---|---|---|
| PLT-001 | The system shall be available as a web application in current versions of mainstream browsers. | |
| PLT-002 | The system shall be available as a native desktop application for macOS, Windows, and Linux. | |
| PLT-003 | The system shall be available as a native mobile application for iOS and Android. | |
| PLT-004 | The system shall build all three shells from a single application codebase, so that features and security controls remain consistent across platforms. | |
| PLT-005 | The system shall deliver native push notifications on desktop and mobile. | |
| PLT-006 | The system shall present an informative offline state in the desktop and mobile shells when the application cannot reach the service. |
Requirement status and change control
Traceability
Every requirement in this document is intended to be traceable in both directions: forward to the behavior described in the FSD and the design described in the TDS, and backward to the scope and constraints set out in the SRS. Non-functional requirements — security posture, availability, performance, maintainability, portability, compliance, and auditability — are not duplicated here; they live in section 3 of the SRS.
Change control
This document is versioned by its last-updated date. Requirements are added, amended, or marked superseded — never silently renumbered, because customer traceability matrices reference the identifiers. Where a customer has a signed order form that references specific requirement IDs, the version in force is the one attached to that order form.
Need this mapped to your requirements?
If you are running a formal evaluation, we will map these requirement IDs onto your own requirement schedule, complete your functional questionnaire, and identify anything in your list that Kavanah does not do. We would rather tell you that during evaluation than after signature.
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.