Single source of truth for the architecture, every SOP, every integration, and ISO 9001 / 14001 / 45001 / 27001 coverage. Acts as both system documentation and user guide.
| Document ID | BLUEDXP-IMS-MAN-001 |
|---|---|
| Document title | Wajeeh BI — Platform, Processes & IMS Manual |
| Version | 2.37.1 |
| Status | Approved (working draft) |
| Classification | Internal — Confidential |
| Owner | PLATFORM_ADMIN + COMPLIANCE_OFFICER |
|---|---|
| Approved by | ORG_ADMIN (top management) |
| Effective date | |
| Next review | |
| Standards | ISO 9001:2015, ISO 14001:2015, ISO 45001:2018, ISO 27001:2022 |
| Git revision | loading… |
| Branch / remote | loading… |
git revert <sha> — see the full Git Trail in the
Git Trail tab.
Static HTML shells served by Vercel, with serverless functions under api/* and shared logic under
api/_lib/*. Optional Postgres (Vercel / Neon) for durable features. AI is server-side only via
Anthropic, using BlueDXP keys.
This document acts as both system documentation for engineers and a user guide / IMS manual for operators and auditors. Every SOP is mapped to the ISO clauses it satisfies (or would satisfy once the module is live), and every process has a visual flow diagram and a RACI matrix.
Domain terms used throughout this manual.
DAG of every major subsystem. Layers run top-to-bottom; arrows show calls and data flows. Pan / scroll horizontally if the diagram extends beyond your viewport.
Top-to-bottom flow: users / external systems → static HTML shells → serverless API → service lib → data & storage. Curved lines are calls or data flows. Some services call back out to external systems (e.g. agents → Anthropic, gateway → WhatsApp).
Modules are the logical building blocks. Each maps to one or more files in the repo. Dependencies show which other modules it relies on; status reflects implementation maturity.
Modules positioned by depth (left = no dependencies; right = sits on the most layers). Coloured stripe shows status. Hover any node for the full purpose statement.
Each SOP states trigger, owner, modules used, the step-by-step procedure, the records it produces, and the ISO clauses it satisfies. SOPs marked TO-BUILD are part of the IMS roadmap (module M20). All SOPs are expanded by default — use Collapse all if you prefer the compact view, or click any header to toggle a single SOP.
Tip — open vercel.json alongside this page to see how routes map to the static HTML files referenced in each SOP.
End-to-end view of how a customer experiences Wajeeh BI — from first awareness to advocacy. Each stage shows what the customer is trying to do, the touchpoints we offer, the modules & SOPs working in the background, the KPIs we measure, and the known pain points to address. Click any stage on the rail to focus its card.
Helps an auditor or new joiner trace any customer-visible moment back to the procedure that powers it.
A bird's-eye view of every documented process: how they cluster, how complex each is, which ISO standards they touch, where automation already exists, and where bottlenecks remain. Use this when prioritizing automation, audits, or training.
Each cell = number of ISO clauses that SOP satisfies in that standard. Darker = more coverage.
Steps per SOP, automation level (% of steps performed by services vs humans), modules touched, ISO clauses covered.
SOPs flagged as TO-BUILD, requiring external systems, or with high human-handoff counts — natural candidates for automation, simulation, or redesign.
Every record produced by any SOP — useful for ISO 9001 §7.5 (documented information) and ISO 27001 retention controls.
Live picture of the platform's residual risk and how mature each ISO management system is. The risk grid plots each risk by likelihood × impact (1–5 each); the maturity radar shows our self-assessed level (1 = ad-hoc, 5 = optimised) against the four standards.
Hover any chip to see the risk title, owner, ISO clause, treatment and status.
Self-assessed maturity (1 → 5) against the four standards in the IMS. Aim is to reach ≥ 3 across all axes before external certification audit.
Every external system the platform reads from or writes to. integration-status.js is the live health endpoint that reports which of these are configured in the current environment.
Defined in api/_lib/roles.js. Tier reflects scope & trust level — Tier 1 is cross-tenant, Tier 5 is read-only. SOPs reference these IDs in their Owner field.
Clause-by-clause assessment against the four standards in an Integrated Management System: ISO 9001 (quality), ISO 14001 (environment), ISO 45001 (occupational H&S), ISO 27001 (information security). Status: covered (process exists in code), partial (exists but not formalized for audit), gap (must be built before certification).
Fastest path is to treat M20 as one epic delivering document control, NCR/CAPA, risk register, and management-review evidence. Most technical controls are already in place.
The IMS standards (9001, 14001, 45001, 27001) require these documents by name.
This is the live to-do list to reach Stage-1 certification readiness — it is also rendered in the
IMS Compliance tab as gap rows. As each item is authored or
automated, flip its status here and in the ISO_READINESS array (see .cursor/rules/keep-ims-manual-in-sync.mdc).
Update this list whenever a controlled document is authored, reviewed, or retired. Evidence link should point to the version-controlled file path or a Data Room URL.
Auto-generated from git log by scripts/update-manual-revisions.js and
stored in manual-revisions.json beside this file. Every entry is a real git commit you can
retrieve, audit, or revert with git revert <sha>. Satisfies
ISO 9001 §7.5.3 (Control of documented information) and ISO 27001 A.5.33 (Protection of records).
If this list is empty when you open the file locally (file://…), it's because
the browser refuses to fetch manual-revisions.json over the file protocol.
On Vercel (/manual) it works. To populate it locally, run
node scripts/update-manual-revisions.js and serve the folder over HTTP
(e.g. npx serve .).
Cross-reference matrices and version history of this manual. Use this as the central index when an auditor asks "where is X documented?" or when a new joiner needs to find every place a module is touched.
A Cursor rule (.cursor/rules/keep-ims-manual-in-sync.mdc) requires that whenever code, routes, integrations, roles, or modules change on the platform, the relevant data array inside this HTML file is updated, a CHANGELOG entry is added, and the version is bumped — in the same change. This way the manual cannot silently drift from reality.
Which modules each SOP touches. Helps engineers find every process affected by a module change.
Inverse view — for each module, which SOPs depend on it. Useful for impact analysis before refactoring.
For each role, which processes they own or participate in (from SOP owner + step actors).