This requirement outlines the core functionality required for effort estimation and quotation purposes. Detailed specifications will be provided to the selected bidder.
We are building a web platform to manage contents such as policies, SOPs, standards, manuals, and contracts. This requirement covers only the core functions needed to estimate the development effort.
Published 1 Nov 2026
At the centre of the system is a document editor where content is organised into sections and clauses with automatic numbering and cross-references. The editor supports both English and Dhivehi (including right-to-left text). Documents follow a controlled workflow through Draft, Review, Approval, and Active stages. Users can add comments and track changes, providing a clear history of who made changes and why. Only one version of a document can be active at a time, and when a new version is approved, it automatically replaces the previous version. All actions are recorded in an audit log for accountability and traceability.
Sign-in through an OIDC/OAuth 2.0 SSO adapter, with role-based access for Author, Reviewer, Approver, Reader and Admin. Readers can't see drafts, and superseded versions are visible only to Authors and Admins.
A document editor built on TipTap (ProseMirror):
The structure is Document, then Sections, then Clauses, then nested Clauses, and numbering updates automatically (1, 1.1, 1.1.1).
Cross-references to clause numbers update when clauses move, and are flagged when their target is deleted.
LTR and RTL can be set per paragraph or for the whole document, with Thaana font support.
Comments in threads on highlighted text, with reply, resolve and reopen. Track changes records who made each insertion and deletion and when.
Four view modes: proposed changes only, full markup, clean revised view, and side-by-side comparison.
A document lifecycle with these states: Draft, Under Review, Pending Approval, Approved, Active, Periodic Review Required, Archived and Rejected. Transitions are enforced by role and workflow rules.
Approval workflow:
Approval submission is blocked until critical comments are resolved.
Approvers can approve, reject with a reason, or request a revision.
All decisions go through one unified service, so other channels such as email, teams and others can be added later.
Versioning:
The Author picks a minor or major target version, which stays locked through approval.
Only one version can be Active at a time.
Activating a new version supersedes the old one in a single database transaction.
A reading view with a table of contents, a metadata banner and a version badge. Print and PDF output come from print CSS that keeps the RTL fonts.
Document metadata (code, type, department, owner, effective date, review cycle, confidentiality), validated before submission.
Full Unicode search, including Thaana, that returns only documents the user is allowed to see.
An append-only audit log of every action and state change.
The frontend uses Next.js (App Router) with TypeScript, TipTap rendered on the client only, and Tailwind logical properties for RTL.
The backend uses a relational database with full Unicode text storage and transactional state changes. Editor content is stored as JSON.
Notifications go through an interface, with a basic SMTP adapter.
The editor must load a 100-page document in under 1.5 seconds, with no character corruption in Dhivehi text.
It must work in Edge, Chrome, Safari and Firefox.
The code must leave extension points for later components:
events and hooks on lifecycle changes
the decision service API
the notification interface
an auth provider adapter
a file storage interface
an editor extension registry
a scheduler hook
Source code for the core module, with a README and setup instructions.
Database schema and migrations.
OpenAPI documentation for the backend endpoints.
Automated tests covering clause renumbering and lifecycle state transitions.