> For the complete documentation index, see [llms.txt](https://docs.oomus.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.oomus.org/features/simulation-engine.md).

# Simulation engine

Oomus CampaignID's v2 simulation engine takes a **capability-first** : it recommends the plan suited to your program, generates contractual proforma documents, and follows an admin approval workflow — without ever exposing technical unit costs on the client side.

***

## Why simulate?

Before launching a national card distribution program, decision-makers need answers to operational and institutional questions:

* What infrastructure capacity is needed to cover 500,000 beneficiaries?
* Which plan guarantees a 99.9% SLA across 10 regions?
* What capabilities are included in my plan?
* How do I produce the documents for institutional budget approval?

***

## 5 simulation modes

Each mode is designed for a specific scope of action:

| Mode              | Beneficiary scale      | Recommended plan        | Use case                                  |
| ----------------- | ---------------------- | ----------------------- | ----------------------------------------- |
| **Quick**         | < 20 000               | Essential               | Pilot project, district, local NGO        |
| **Regional**      | 20,000 – 200,000       | Regional Command        | Multi-district regional program           |
| **National**      | 200,000 – 2,000,000    | National Infrastructure | National government campaign              |
| **Multi-country** | 2,000,000 – 20,000,000 | Sovereign Cloud         | Sovereign federation, continental program |
| **Sovereign**     | > 5 000 000            | Sovereign Cloud         | Dedicated cloud by country                |

***

## Plan recommendation engine

The engine `recommend_plan()` calculates the optimal plan based on:

* Beneficiary volume
* Number of regions covered
* Selected simulation mode
* Data sovereignty requirement

**Example result:**

```json
{
  "plan": "national_campaign",
  "label": "National Infrastructure",
  "confidence": 94,
  "reasons": [
    "Volume of 450,000 beneficiaries across 12 regions",
    "Dedicated national infrastructure required",
    "Large-scale communication capabilities"
  ],
  "capacities": {
    "identities": "1,000,000",
    "omnichannel_comms": "5,000,000 / month",
    "verifications": "500,000 / month",
    "storage": "500 GB"
  },
  "sla": "99.9%"
}
```

> Unit prices are never included in the engine response — capability-first approach.

***

## Simulation wizard — 6 steps

### Step 1 — Simulation mode

Selection of the mode among the 5 types. Each mode card displays:

* Target scale (number of beneficiaries)
* Recommended plan
* Use case description

### Step 2 — Parameters

* Number of target beneficiaries
* Number of regions
* Number of field agents
* Campaign duration
* Deployment country
* Desired SMS / WhatsApp / QR volumes
* Required SLA level

### Step 3 — Infrastructure

| Option                       | Description                                                   |
| ---------------------------- | ------------------------------------------------------------- |
| **Shared infrastructure**    | Shared resources across programs (lower cost)                 |
| **Dedicated infrastructure** | Exclusive resources for your program (guaranteed performance) |

Dedicated infrastructure is required for Premium and Critical SLAs.

### Step 4 — RBAC governance

Governance model configuration:

* Number of organizations and users
* Required approval levels (up to 10 configurable levels)
* Audit log retention
* Geographic scope (national, regional, district)

### Step 5 — Plan recommendation

The recommendation card displays:

* Recommended plan with confidence score
* Reasons for the recommendation
* Included capabilities (identities, communications, verifications, storage)
* Guaranteed SLA
* Suggested add-on modules

### Step 6 — Results & Quote

Two available paths:

1. **Automatic debit** — if the balance is sufficient, immediate activation of the plan
2. **Institutional quote** — sent to the Oomus sales team, response within 24h

Exportable documents:

| Document               | Format        | Content                                          |
| ---------------------- | ------------- | ------------------------------------------------ |
| **Proforma PDF**       | PDF           | Institutional quote, capabilities, SLA, workflow |
| **Excel simulation**   | XLSX (4 tabs) | Capacity details, planning, governance, costs    |
| **JSON configuration** | JSON          | Complete technical parameters                    |
| **YAML configuration** | YAML          | Readable version of the configuration            |

***

## DPI Options — Multipliers

| DPI     | Factor           | Usage                                |
| ------- | ---------------- | ------------------------------------ |
| 300 dpi | ×1.0 (reference) | Digital display, mobile distribution |
| 450 dpi | ×1.4             | Laser printing, badges               |
| 600 dpi | ×2.0             | High-quality PVC printing            |

***

## SLA levels

| Level        | Availability | P1 response      | Multiplier |
| ------------ | ------------ | ---------------- | ---------- |
| **Standard** | 99,0%        | 8 business hours | ×1.0       |
| **Enhanced** | 99,5%        | 4 hours          | ×1.3       |
| **Premium**  | 99,9%        | 1 hour           | ×1.8       |
| **Critical** | 99,99%       | 15 minutes       | ×2.5       |

***

## Admin approval workflow

```
Simulation submission
        │
        ▼
   [submitted]
        │
        ▼ (Oomus admin reviews)
   ┌────┴──────────────────────┐
   │                           │
   ▼                           ▼
[approved]           [modification_requested]
   │                           │
   │              (Program corrects and resubmits)
   │
   ▼
[provisioning] → [provisioned]
```

| Status                   | Description                               |
| ------------------------ | ----------------------------------------- |
| `submitted`              | Simulation submitted for approval         |
| `approved`               | Simulation approved, provisioning started |
| `rejected`               | Simulation rejected (reason communicated) |
| `modification_requested` | Changes requested by the admin            |
| `provisioning`           | Infrastructure being deployed             |
| `provisioned`            | Operational program                       |

***

## Engine admin configuration

Administrators can configure the simulation engine's internal settings via `PUT /api/v1/admin/billing/engine-config`. These values are stored in `PlatformSetting` (persisted in DB, effective immediately):

| Parameter                    | Description                      |
| ---------------------------- | -------------------------------- |
| `infra_base_fcfa_per_worker` | Base infrastructure worker cost  |
| `bsp_sms_fcfa_per_msg`       | BSP cost per SMS                 |
| `bsp_whatsapp_fcfa_per_msg`  | BSP cost per WhatsApp message    |
| `autoscaling_factor`         | Autoscaling multiplier           |
| `sovereign_factor`           | Sovereign cloud multiplier       |
| `verify_platform_monthly`    | Monthly verification portal cost |

***

## Next steps

* [Plans & Features](/getting-started/plans-and-pricing.md) — Choose the right plan
* [Billing](/api-reference/billing.md) — billing and ledger API
* [Dashboard & Analytics](/features/dashboard-analytics.md) — Track actual usage


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.oomus.org/features/simulation-engine.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
