Architecture

Last updated: July 2026

Revenue Quality Engine is a scoring and recommendation layer that can sit on top of an existing CRM or operate standalone as the system of record for revenue operations. This page describes the pieces and how they connect. Integrations have their own page at /reference/integrations/.

System overview

┌─────────────────────────────────────────┐
│  CRM (HubSpot / Salesforce / Pipedrive) │  ← optional
│              or CSV / API / native UI   │
└──────────────────┬──────────────────────┘
                   │
                   ▼
        Revenue Quality Engine
                   │
 ├── Ingestion       (CRM sync, CSV import, API, native UI)
 ├── Data model      (Client, Deal, Product, Commission, User)
 ├── Scoring engine  (Revenue Score per deal)
 ├── AI engine       (Next Best Action recommendations)
 ├── Commission      (per-seller, per-period payouts)
 ├── Reporting       (dashboards, exports)
 ├── Public API      (REST, versioned)
 └── Events          (webhooks + event log)

Pipeline

The data pipeline accepts records from CRM connectors, CSV import, the public API, or the RQE native UI. When a CRM is connected, reads are one-way (CRM → RQE) and actions can be pushed back as tasks or notes. When RQE is the source of truth, records are created and updated directly in RQE. Every ingested record is tagged with tenant and source, and every derived record retains provenance.

Ingest. CRM connectors, CSV import, the public API, or the RQE UI create and update deals, clients, products, and users.
Normalize. Records are mapped to RQE's canonical data model. Missing required fields produce a warning, not a silent drop.
Score. The scoring engine computes Revenue Score per deal on every material change and at least once per day.
Recommend. The AI engine produces Next Best Action per deal, with the score's contributing factors as inputs.
Distribute. Results are available in the UI, via the API, via webhooks, and via exports.

Scoring engine

The scoring engine outputs a Revenue Score on a 0-100 scale per deal, plus the top three contributing factors. Inputs include deal amount, stage, age, historical seller performance, product mix, and margin. The engine is explainable by construction: every score exposes its top drivers.

AI recommendations

Next Best Action recommendations are generated by combining the deal's current state, the score's contributing factors, and the historical action-to-outcome patterns for similar deals. Recommendations are concrete (verb + object + reason) and time-scoped where possible.

RQE does not train models on tenant data by default. Recommendations for tenant A never depend on tenant B's data.

Data model

The core entities are:

Entity	Purpose	Notes
Client	Account / company the deal is with	Per-org; ownership tracked
Deal	Commercial opportunity in the pipeline	Carries score, stage, amount
Product	What is being sold	Per-org; templated at seed
Commission	Payout computed per seller per period	Rules configurable per plan
User	Seller, manager, admin, or finance role	Roles are separated from profile

Every entity is tenant-scoped (multi-org). Row-Level Security enforces isolation at the database layer; no cross-tenant read is possible even for admin roles.

Events

RQE emits an event log for every material state change. Events are namespaced by domain. Representative events:

deal.created, deal.updated, deal.scored, deal.won, deal.lost
client.created, client.transferred, client.archived
commission.computed, commission.paid
recommendation.produced, recommendation.dismissed

Events can be consumed via webhooks or via the public API. Delivery is at-least-once with idempotency keys.

Public API and SDK

The public API is an OpenAPI 3.1 contract. See /reference/api/ for the overview. A TypeScript SDK is generated from the OpenAPI contract and versioned with the same release status labels (experimental, beta, ga, deprecated).

Governance

Contract governance is enforced by architecture decision records (ADRs) and CI guards. Key rules: operationId is immutable once published; snapshots per info.version are frozen; x-release-status at operation level must differ from the root default to appear. See openapi/GOVERNANCE.md in the source repository.