# Rails ERP Technical Appraisal Document

**Product:** Rails ERP
**Appraisal snapshot:** 24 August 2026
**Repositories reviewed:** `C:\Apache24\htdocs\railserp` (frontend), `C:\Apache24\htdocs\cutehorse` (backend)
**Assessment status:** Technical appraisal baseline; not a production certification

## Executive assessment

Rails ERP is a multi-tenant ERP solution with a React/Vite frontend, a modular PHP API, and PostgreSQL migrations organized by business domain. The strongest evidenced capability is the beta foundation around authentication, tenant onboarding, IAM, settings, contacts, customers, CRM leads/opportunities, relationships, and Customer 360.

The repository also contains a broad frontend catalogue for sales, purchasing, inventory, warehouse, POS, HR/payroll, assets, accounting, reporting, support, automation, marketing, manufacturing, and productivity. Several of these areas are prototype or demo surfaces rather than evidenced production workflows. No institution should rely on an unqualified production-readiness claim from this snapshot: formal VAPT, performance/load results, backup-restore tests, CI/CD evidence, signed UAT, complete API specification, generated ERD/data dictionary, licence report, and ROI evidence are outstanding.

## 1. Module catalogue and functional specifications

The functional catalogue below combines the frontend route/page inventory, backend module manifest, migrations, and the existing product evidence pack.

| Module | Functional scope | Implemented/evidenced behaviour | Appraisal status |
| --- | --- | --- | --- |
| IAM | Login, signup, tenant onboarding, sessions, users, roles, permissions, activity, status, password and profile workflows | API-backed user and role administration, tenant context, auth guards, permission-filtered navigation, session handling | Beta |
| Settings | Branding, localization, numbering, approval rules, inventory defaults, financial periods, payment terms, notifications, integrations, API keys, subscription, preferences | Tenant-scoped settings persistence and file upload support are present; full cross-module configuration UAT is pending | Beta |
| Contacts | Contact register, categories, activity history, import/export | Contact categories/activity and add/edit flows are wired; import/export evidence is incomplete | Beta |
| Customers | Customer register, create/edit/view/status/remove, credit, payment terms, industry, Customer 360 | Customer workflow and tenant currency display are implemented; relationship integration is present | Beta |
| CRM leads | Sources, statuses, assignment, scoring, conversion, pipeline and analytics | Lead setup, optional assignment, workbench, conversion and analytics are represented in the frontend/backend foundation | Beta |
| Opportunities | Stages, sources, lifecycle and analytics | Stage/source setup and opportunity analytics exist; end-to-end sales lifecycle UAT is pending | Beta |
| Relationships and custom records | Relationship types, entity relationships, custom record types, fields and records | CRM relationship model and Customer 360/customer-drawer visibility are implemented | Beta |
| Customer 360 | Timeline, engagement, purchases, support, financials and insights | Timeline, engagement and relationship visibility exist; AI insight service remains planned | Beta |
| Sales | Quotations, orders, approvals, tracking, returns, forecasts and credit | Broad frontend pages and schema alignment exist; page-by-page API hardening is incomplete | Prototype |
| Purchases | Purchase orders, approvals, receiving, shortlanded, overages, returns and supplier performance | Frontend pages and schema alignment exist; full workflow evidence is incomplete | Prototype |
| Suppliers | Onboarding, profiles, status, returns, price history and analytics | Frontend catalogue and schema alignment exist; full backend workflow evidence is incomplete | Prototype |
| Inventory | Items, categories, brands, stock, counts, transfers, scrap, reorder and variance | Frontend catalogue and migration alignment exist; operational hardening is incomplete | Prototype |
| Warehouse | Warehouses, locations/bins, inbound, outbound, transfers, reconciliation and analytics | Frontend catalogue exists; full production API evidence is incomplete | Prototype |
| POS | Shops, stock assignment, terminal, transactions, returns, cashier sessions and reports | Frontend pages exist; backend production wiring is not verified | Prototype |
| HR and payroll | Employees, profiles, organization, recruitment, onboarding, attendance, leave, payroll, statutory, performance and self-service | Very broad frontend inventory; backend workflow hardening and UAT are pending | Prototype |
| Assets | Asset register, categories, locations, allocations, transfers, depreciation, maintenance, audit and compliance | Frontend/schema foundation exists; full workflow evidence is pending | Prototype |
| Accounting and finance | Chart of accounts, journals, invoices, expenses, receivables/payables, trial balance, P&L, balance sheet, cash flow and tax | Frontend pages and schema alignment exist; accounting control evidence is pending | Prototype |
| Approvals | Queues, module approvals, audit trail and escalation | Frontend exists; backend route loader is a placeholder | Demo-only |
| Automation | Rules, builder, triggers, scheduled jobs, actions and execution logs | Frontend builder/pages exist; production execution semantics are not verified | Demo-only |
| Marketing | Campaigns, audiences, nurturing, A/B tests, landing pages and analytics | Frontend pages exist; backend production wiring is not verified | Demo-only |
| Reports and data | Standard reports, report builder, warehouse, datasets, pipelines and exports | Frontend pages exist; backend report/analytics route loaders are placeholders | Demo-only |
| AI insights | Business, sales, customer, supplier and financial insights | Cutecat Python/FastAPI service is planned but is not included in either reviewed checkout | Roadmap |
| Integrations | Merchant hub, API keys, webhooks, notification channels and imports | Settings/integration scaffolding exists; connector, retry and webhook evidence is pending | Prototype |
| Help and support | Help centre, knowledge base, tickets, notes, assignment, SLA and analytics | Support schema/API wiring and frontend surfaces exist; complete workflow evidence is pending | Prototype |
| Manufacturing | BOM, MRP, requisitions, production orders, WIP, consumption, quality and efficiency | Frontend pages exist; backend route loader is a placeholder | Demo-only |
| Productivity | Tasks, projects, calendar, reminders, notes and team queues | Frontend pages exist; backend route loader is a placeholder | Demo-only |

## 2. Module maturity matrix

**Definitions:** Production-ready requires complete API-backed workflows, tenant scoping, authorization, validation, automated tests, security evidence, operational controls, and UAT. Beta means the main path is implemented but formal evidence or edge-case coverage remains. Prototype means UI/schema or partial APIs exist. Demo-only means visual demonstration is possible but operational semantics are not evidenced. Roadmap means planned or external capability.

| Maturity | Modules |
| --- | --- |
| Production-ready | None evidenced in this appraisal snapshot. |
| Beta | IAM; Settings; Contacts; Customers; CRM Leads; Opportunities; Relationships and Custom Records; Customer 360 |
| Prototype | Sales; Purchases; Suppliers; Inventory; Warehouse; POS; HR and Payroll; Assets; Accounting and Finance; Integrations; Help and Support |
| Demo-only | Approvals; Automation; Marketing; Reports and Data; Manufacturing; Productivity |
| Roadmap | AI Insights |

This classification is intentionally conservative. It reflects the absence of formal VAPT, performance, availability, DR, CI/CD, code-coverage, and signed UAT evidence, even for modules with working paths.

## 3. Product version history and v3.2.1 release notes

### Verified repository version state

| Component | Observed version state |
| --- | --- |
| Frontend | `package.json` reports `0.0.0` |
| Backend | `config/app.php` reports `0.1.0` |
| Git state | Both repositories are on `main`; no verified `v3.2.1` tag was found in the reviewed evidence |
| Milestone label | `v3.2.1` is used as the product hardening milestone name, not as a verified release artifact |

### Version history visible in backend history

The backend history includes initial setup, tenant onboarding, IAM/roles and permissions, HR/settings/assets, CRM/suppliers/contacts, inventory/HR/sales/purchases, and a subsequent page-by-page QA/hardening milestone. Commit history is not a substitute for a signed release record.

### v3.2.1 milestone release notes

Release date stated by the evidence pack: 23 August 2026. Release type: CRM, IAM, settings and relationship foundation hardening.

- Rebuilt public authentication and tenant signup flows.
- Added tenant onboarding and trial-flow assumptions.
- Hardened authenticated route guards, session expiry, RBAC navigation filtering and tenant context.
- Replaced mock IAM surfaces with API-backed user, role, permission, security, status, activity and password workflows.
- Added user profile and account password change capabilities.
- Added tenant settings coverage for branding, localization, numbering, approvals, inventory defaults, periods, payment terms, notifications, integrations, API keys, subscription and preferences.
- Hardened contacts, contact categories, activity history, customers, tenant currency display and Customer 360 entry points.
- Added CRM lead statuses, opportunity stages, sources, assignment, scoring, conversion, pipeline and analytics improvements.
- Added relationship types, record relationships, custom business record types, fields and records.
- Added support/helpdesk schema and owner-permission backfills.
- Aligned sales receipts/collections, credit notes, invoices, expenses and purchase vendor bills with accounting/payables.

Known limitations: large frontend bundle, incomplete non-CRM hardening, placeholder route loaders, and missing formal security, load, DR, CI/CD and UAT evidence.

## 4. Architecture diagrams

### System context

```mermaid
flowchart LR
  U[Business User] --> FE[Rails ERP Web App]
  A[Tenant Administrator] --> FE
  FE --> API[Rails ERP Backend API]
  API --> DB[(PostgreSQL)]
  API --> FS[(Tenant uploads)]
  API --> EXT[Email, SMS, payment and merchant systems]
  API -. planned .-> Q[RabbitMQ]
  API -. planned .-> C[Redis]
  FE -. planned .-> AI[Cutecat AI service]
```

### Component architecture

```mermaid
flowchart TB
  subgraph Browser
    React[React + TypeScript SPA]
    Guards[Auth and RBAC guards]
    Pages[Module pages and workflows]
    Client[Authenticated API client]
    React --> Guards --> Pages --> Client
  end
  subgraph PHP API
    Router[HTTP router]
    Middleware[Auth, tenant, permission, rate-limit and logging middleware]
    Modules[Domain modules]
    Repositories[Repositories and services]
    Router --> Middleware --> Modules --> Repositories
  end
  Client --> Router
  subgraph Storage
    Platform[(platform)]
    IAM[(iam)]
    CRM[(crm)]
    Domains[(sales, purchases, inventory, warehouse, accounting, HR, etc.)]
  end
  Repositories --> Platform
  Repositories --> IAM
  Repositories --> CRM
  Repositories --> Domains
```

### Deployment architecture

```mermaid
flowchart LR
  Browser[Browser] --> Apache[Apache HTTP Server]
  Apache --> Static[Vite build assets]
  Apache --> PHP[PHP 8.2 application]
  PHP --> PostgreSQL[(PostgreSQL)]
  PHP -. planned .-> Redis[(Redis)]
  PHP -. planned .-> RabbitMQ[(RabbitMQ)]
  PHP -. planned .-> ObjectStore[(File/object storage)]
```

### Integration architecture

```mermaid
flowchart LR
  ERP[Rails ERP API] --> Webhooks[Outbound webhooks]
  ERP --> Messaging[Email and SMS]
  ERP --> Merchants[Merchant/payment connectors]
  ERP --> Imports[CSV/file imports]
  External[External system] --> PublicAPI[API keys/public API]
  PublicAPI --> ERP
  ERP -. planned .-> Cutecat[Cutecat AI/FastAPI]
```

### Data architecture

```mermaid
flowchart TB
  T[platform.tenants] --> I[iam.users]
  T --> S[settings.*]
  T --> C[contacts.contacts]
  T --> CU[crm.customers]
  CU --> L[crm.leads]
  L --> O[crm.opportunities]
  CU --> E[crm.customer_timeline_events]
  CU --> R[crm.record_relationships]
  R --> RT[crm.relationship_types]
  R --> BR[crm.business_records]
  BR --> BRT[crm.business_record_types]
  BRT --> BRF[crm.business_record_fields]
```

## 5. Technology stack and infrastructure specifications

| Layer | Observed technology/specification |
| --- | --- |
| Frontend | React 18.3, TypeScript 5.8, Vite 5.4, React Router 6, TanStack Query, Tailwind CSS, shadcn/Radix UI, Recharts, Lucide icons |
| Backend | PHP 8.2, PSR-4 Composer autoloading, modular application structure |
| Web server | Apache HTTP Server with rewrite rules; `Authorization` forwarding is required |
| Database | PostgreSQL, schema-per-domain approach; migrations and seeds are in the backend checkout |
| Authentication | Bearer JWT/session model, one-hour access-token and fourteen-day refresh-token defaults in configuration |
| Caching | Redis is planned/configured as an architectural dependency; production instance and sizing are not evidenced |
| Queuing | RabbitMQ is planned for asynchronous notifications, audit events, integrations and long-running work; production deployment is not evidenced |
| Files | Backend storage directories include logs, cache and uploads; object-storage policy is not evidenced |
| Runtime topology | No production host sizing, container image, OS baseline, browser support matrix, scaling policy, monitoring or SLO configuration is attached |

Minimum deployment prerequisites should include PHP 8.2, Composer, Apache rewrite support, PostgreSQL, secure environment variables, a generated application key/JWT secret, and an HTTPS termination point. Exact CPU, memory, storage, database sizing and supported browser commitments require a capacity assessment.

## 6. Database ERD and data dictionary

### ERD

```mermaid
erDiagram
  PLATFORM_TENANTS ||--o{ IAM_USERS : owns
  PLATFORM_TENANTS ||--o{ SETTINGS : configures
  PLATFORM_TENANTS ||--o{ CONTACTS : owns
  PLATFORM_TENANTS ||--o{ CRM_CUSTOMERS : owns
  CRM_CUSTOMERS ||--o{ CRM_LEADS : has
  CRM_LEADS ||--o{ CRM_OPPORTUNITIES : progresses_to
  CRM_CUSTOMERS ||--o{ CRM_CUSTOMER_TIMELINE_EVENTS : has
  CRM_RELATIONSHIP_TYPES ||--o{ CRM_RECORD_RELATIONSHIPS : defines
  CRM_BUSINESS_RECORD_TYPES ||--o{ CRM_BUSINESS_RECORD_FIELDS : defines
  CRM_BUSINESS_RECORD_TYPES ||--o{ CRM_BUSINESS_RECORDS : owns
```

### Schema dictionary

| Schema/domain | Representative data | Purpose and tenant boundary |
| --- | --- | --- |
| platform | tenants, onboarding/subscription context | Business identity and tenant lifecycle; parent boundary for tenant-owned records |
| iam | users, roles, permissions, mappings, sessions, activity/security records | Authentication, authorization and auditability |
| settings | branding, localization, numbering, approval rules, operational defaults, integrations, API keys | Tenant configuration |
| contacts | contacts, categories, activities, import/export resources | Shared people and organization records |
| crm | customers, leads, opportunities, sources, statuses, stages, activities, assignments, relationships and custom records | CRM and Customer 360 |
| sales/purchases | orders, quotations, invoices, receipts, returns, purchase orders, receiving and variances | Commercial transactions and procurement |
| inventory/warehouse | items, stock, movements, counts, reorder rules, warehouses, locations and transfers | Stock control and fulfilment |
| accounting | accounts, journals, invoices, receivables, payables and financial reports | Financial records |
| hr_payroll/org | employees, organization, payroll, attendance, leave and recruitment | Workforce administration |
| assets | assets, maintenance, depreciation, movement and compliance | Fixed-asset lifecycle |
| workflow/reports/support | approvals, audit trail, reporting data, tickets and notes | Cross-cutting workflow, reporting and support |

A complete column-level data dictionary, indexes, foreign keys, constraints, retention classifications, row counts and generated live-database ERD are not present in the reviewed checkout and must be produced from the target PostgreSQL instance before procurement sign-off.

## 7. API and integration documentation

The API uses a versioned `/api/v1` prefix. Tenant-scoped requests use `X-Tenant-Id`; protected requests use `Authorization: Bearer <access_token>`. The common response envelope is `success`, `message`, and `data`, with `errors` for validation failures and `meta` for list metadata.

### Verified IAM examples

| Method | Path | Access |
| --- | --- | --- |
| POST | `/api/v1/auth/login` | Tenant middleware; public authentication |
| POST | `/api/v1/public/users/register` | Public tenant signup |
| POST | `/api/v1/auth/refresh` | Refresh-token flow |
| POST | `/api/v1/auth/logout` | Auth and tenant middleware |
| GET | `/api/v1/users/me` | Auth and tenant middleware |
| GET | `/api/v1/users` | Auth, tenant and `users.view` permission |
| GET | `/api/v1/users/{id}` | Auth, tenant and `users.view` permission |

### CRM/relationship resources described by the evidence pack

`/api/v1/crm/customers`, `/api/v1/crm/leads`, `/api/v1/crm/opportunities`, `/api/v1/crm/lead-sources`, `/api/v1/crm/lead-statuses`, `/api/v1/crm/opportunity-stages`, `/api/v1/crm/relationships`, `/api/v1/crm/relationship-types`, `/api/v1/crm/business-record-types`, `/api/v1/crm/business-record-fields`, and `/api/v1/crm/business-records`.

The IAM module README and `postman/Users-IAM-2026-05-06.postman_collection.json` provide the strongest endpoint-level evidence. OpenAPI/Swagger, complete endpoint schemas, error catalogue, webhook payloads, connector contracts, retry/idempotency rules, API-key lifecycle and non-IAM Postman coverage remain outstanding.

## 8. Security architecture, RBAC, VAPT and vulnerability status

```mermaid
flowchart LR
  Login[Login/signup] --> Token[JWT/session]
  Token --> FEGuard[Frontend auth guard]
  Token --> APIAuth[Backend auth middleware]
  APIAuth --> Tenant[Tenant context]
  Tenant --> RBAC[Roles and permissions]
  RBAC --> Route[Route access]
  RBAC --> Action[Action authorization]
  APIAuth --> Audit[Activity/security logs]
```

Observed controls include auth guards, tenant context, backend auth/tenant/permission middleware, route/navigation filtering, rate-limit and logging middleware structure, password/session workflows, soft-delete fields, and tenant-aware API headers.

### RBAC summary

| Area | Permission examples |
| --- | --- |
| IAM | `users.view`, `users.create`, `users.update`, `users.delete`, `roles.view`, `security.view`, `profile.view` |
| CRM | `crm.view`, `customers.create`, `crm.relationships.view`, `crm.business_records.view`, `customer360.view` |
| Sales/purchasing | `sales.view`, `sales.orders.create`, `purchases.view`, `purchases.orders.create` |
| Operations | `inventory.view`, `warehouse.view`, `manufacturing.view`, `pos.view` |
| Finance/reporting | `accounting.view`, `reports.view` |
| Administration | `settings.view`, `approvals.view`, `automation.view`, `integrations.view` |

The frontend includes CRM RBAC tests for Sales Manager, Sales Rep and Support Agent access. A full backend permission export and a matrix of every role/action/resource is pending.

### Vulnerability status

No formal VAPT, SAST, DAST, dependency scan, vulnerability register, tenant-isolation test, authorization-bypass test, certificate review, or security certification is attached. Two configuration risks require remediation before deployment: `APP_DEBUG` defaults to true/local mode in `config/app.php`, and `JWT_SECRET` has the fallback value `change-me-in-production` in `config/auth.php`. These are configuration defaults, not evidence of a production compromise, but production must fail closed when secrets are absent.

## 9. Performance, load testing and availability

The frontend production build is available as a build script and a known oversized main JavaScript bundle remains an optimization issue. A settings-save latency issue was identified and optimized during QA. No measured latency, throughput, concurrency, browser performance, database query, stress, soak, capacity, uptime, incident or availability report is present.

Therefore no SLA, uptime percentage, response-time percentile, user capacity or transaction-rate metric should be represented as validated. Required evidence includes a workload model, endpoint p50/p95/p99 latency, error rate, concurrent-user and transaction throughput results, stress/soak results, database plans, frontend performance results, monitoring dashboards and an agreed SLO report.

## 10. Backup, restoration and disaster recovery

The repository contains storage directories and architectural recommendations, but no verified backup schedule, backup location, encryption evidence, restore log, DR runbook, RTO/RPO approval or successful recovery-test report.

A proposed baseline for institutional review is daily full PostgreSQL backup, continuous WAL archiving for point-in-time recovery, encrypted backup storage in a separate account/location, protected environment secrets, backup of tenant uploads, quarterly restore testing, and a runbook covering database, files, configuration, DNS and application deployment. RTO and RPO must be agreed with the institution and validated by timed recovery tests; they must not be presented as current product metrics.

## 11. Source repository, CI/CD and automated test evidence

| Item | Evidence |
| --- | --- |
| Frontend source | `C:\Apache24\htdocs\railserp`; React/Vite package manifest and Vitest configuration |
| Backend source | `C:\Apache24\htdocs\cutehorse`; Composer PSR-4 PHP application |
| Branch state | Both reviewed repositories report branch `main` and a clean working tree for the frontend; backend contains local documentation changes |
| CI/CD | No CI workflow or deployment pipeline configuration was found in the reviewed checkout |
| Frontend tests | Vitest setup, an example test, and CRM RBAC tests are present |
| Backend tests | Unit/Feature/Integration directories exist, but no executable backend test files were evidenced |
| Coverage/release artefacts | No coverage report, signed build, artifact hash, deployment log or release manifest was evidenced |

Remote repository URLs, branch protection, pull-request policy, pipeline history, deployment approvals, rollback procedures and reproducible artifact evidence must be supplied separately.

## 12. User manuals, configuration guides and UAT

The IAM module README is an implementation/API guide. The backend also contains architecture and schema-gap documentation. A complete user-documentation set is not present.

Required deliverables are tenant onboarding, IAM, settings, contacts/CRM, Customer 360, relationships/custom records, and module guides for Sales, Purchases, Inventory, Warehouse, POS, HR, Assets, Accounting, Reports, AI, Integrations and Support. UAT should include signed scripts and results for IAM, settings, CRM and cross-module journeys: lead-to-customer-to-opportunity, quote-to-order-to-invoice, purchase-to-receiving-to-inventory, transfer-to-reconciliation, and employee-onboarding-to-payroll. Defect logs, retest results and closure approvals are also required.

## 13. IP ownership and third-party/open-source licences

Product ownership of custom source code, database schema, UI, documentation, configuration and data models must be confirmed by contract and supplied with the appraisal pack. The reviewed manifests identify React ecosystem, Radix/shadcn, Tailwind, Vite, TypeScript, ESLint, Vitest, PHP/Composer and PostgreSQL dependencies.

A complete bill of materials and licence report is pending for `package-lock.json`, `composer.lock`, fonts, icons, images, generated assets and any Cutecat/AI dependencies. The institution should require licence compatibility review, notices/attributions, transitive dependency coverage, version/CVE mapping and confirmation that all commissioned work is owned or appropriately licensed.

## 14. Efficiency and ROI evidence

No efficiency or ROI figure should be treated as validated from this repository. The required evidence is a before/after time study, transaction volumes by module, users and roles, error/rework rates, labour rates, implementation/training costs, infrastructure/support/licence costs, and a sensitivity analysis.

```text
Annual efficiency value =
  (baseline minutes per transaction - target minutes per transaction)
  * annual transaction count / 60
  * weighted average hourly labour cost

Annual error reduction value =
  (baseline error rate - target error rate)
  * annual transaction count
  * average cost per error

Net annual benefit =
  annual efficiency value
  + annual error reduction value
  + avoided software/process cost
  - annual operating cost

ROI = net annual benefit / implementation cost
Payback period = implementation cost / monthly net benefit
```

Each input should have a source, measurement period, owner, calculation workbook and sensitivity range. Benefits should be separated from revenue forecasts and should not be inferred from illustrative dashboard values.

## Evidence register and procurement gates

| Evidence track | Current state | Gate to close |
| --- | --- | --- |
| Catalogue/specification | Drafted from source and product docs | Product-owner approval and workflow acceptance criteria |
| Maturity | Conservative repository assessment | Module-by-module signed UAT and production controls |
| Release 3.2.1 | Milestone notes only; versions remain 0.0.0/0.1.0 | Signed tag, artifact hash, changelog and deployment record |
| Architecture | High-level Mermaid diagrams | Approved target topology and infrastructure bill of materials |
| ERD/data dictionary | High-level only | Generated live schema export with constraints and classification |
| API/integrations | IAM and selected CRM evidence | OpenAPI, complete Postman suite, webhook and retry contracts |
| Security | Partial controls and frontend RBAC tests | VAPT, SAST/DAST, dependency scan, remediation register and isolation tests |
| Performance/availability | No validated metrics | Load, stress, soak, browser, database and SLO reports |
| Backup/DR | Recommendations only | Implemented schedules, encrypted storage, restore test, RTO/RPO and runbook |
| CI/CD/tests | Frontend Vitest only; no backend suite/pipeline evidence | Pipeline run, coverage, E2E/UAT and release automation |
| Manuals/UAT | IAM guide and technical docs | Complete manuals, signed UAT, defect closure and training pack |
| IP/licensing | Manifests only | SBOM/licence report and ownership confirmations |
| ROI | Calculation model only | Baseline measurements, workbook, assumptions and sensitivity analysis |

### Recommendation

Proceed with a controlled beta/pilot appraisal focused on IAM, settings, contacts, customers and CRM, subject to security and data-protection review. Do not approve an unrestricted production rollout or accept 3.2.1 as a verified production release until the outstanding procurement gates above are closed and independently reviewed.

## Source evidence index

- Frontend application and route catalogue: `C:\Apache24\htdocs\railserp\src\App.tsx`
- Frontend dependencies and scripts: `C:\Apache24\htdocs\railserp\package.json`
- Frontend access-control matrix: `C:\Apache24\htdocs\railserp\src\lib\accessControl.ts`
- Frontend CRM RBAC tests: `C:\Apache24\htdocs\railserp\src\test\crm-rbac.test.ts`
- Backend module manifest: `C:\Apache24\htdocs\cutehorse\docs\modules.md`
- Backend API registry: `C:\Apache24\htdocs\cutehorse\routes\api.php`
- IAM endpoint guide: `C:\Apache24\htdocs\cutehorse\app\Modules\Users\README.md`
- IAM Postman collection: `C:\Apache24\htdocs\cutehorse\postman\Users-IAM-2026-05-06.postman_collection.json`
- Backend configuration: `C:\Apache24\htdocs\cutehorse\config\app.php` and `config/auth.php`
- Database migrations: `C:\Apache24\htdocs\cutehorse\database\migrations\`
- Existing product evidence pack: `C:\Apache24\htdocs\cutehorse\docs\rails-erp-v3.2.1-overview-and-evidence-pack.md`