[Neutrinos Platform] [Community-Support] End to End Flow of creating a Enterprise Level App in Neutrinos Platform

Neutrinos Platform
1

Hello All,

Can someone guide me on a detailed level, how the entire End-to-End Flow of creating an enterprise-level application in the Neutrinos Platform works in total? Where we start from the Reels Engine (where we add our business logic), SSD (For the UI & API’s), Alpha (For business process automation), and finally Trinity (For deployments)?

I am bit confused on how all of these modules (Reels, SSD, Alpha & Trinity) come together?

Any help would be highly appreciated.

2

@Sam or @Eldho - Any help would be highly appreciated.

3

@Sam @doomedCode please help

4

Hello @achintyakumar.shukla ,
This is just an example. There are many other scenarios with different use cases — this one is only to give you a basic understanding.
Example: Insurance Claim Processing

Scenario:
A customer submits a motor insurance claim after a car accident. The insurance company wants to process this claim quickly, accurately, and with minimal manual effort.

Step 1 – Neutrinos Reëls (Rules Engine)
The claim details (age of driver, claim amount, past history, etc.) are passed into Neutrinos Reëls.
The rules engine automatically checks conditions such as:

  • Is the driver’s age above 18?
  • Is the claim amount within policy limits?
  • Does the claim meet fraud detection rules?

Based on these rules, it decides whether the claim is STP (Straight Through Processing) or Non-STP (requires manual review).

Step 2 – Neutrinos Studio (SSD)
The front-end claim submission app is built on Neutrinos Studio.

  • Customers submit claims through a mobile-friendly app or web portal.
  • Studio integrates APIs from external services (e.g., police reports, hospital data) to enrich the claim details.

Step 3 – Alpha (Hyper-Automation Platform)
Once the rules engine makes a decision, Alpha takes over for automation:

  • If the claim is STP, Alpha automatically proceeds to the next step, such as continuing the BPM (Business Process Management) flow and moving the process further.
  • If the claim is Non-STP, Alpha routes the claim to a human adjuster along with all relevant documents for manual review.

Step 4 – Trinity (Application Lifecycle Platform)
The entire claim processing app (built in Studio, using Reëls and Alpha workflows) is deployed, managed, and monitored through Trinity.

  • Trinity ensures reliability, scalability, and performance monitoring of the claims system.

Hope this helps

1 Like
5

@Sam,

Thanks for your reply, but I still have a question in mind that how all these three modules (Reels, SSD & Alpha) integrate together ?

Please give us a detailed understanding on the same?

6

Hi @achintyakumar.shukla ,

Let me try to give you a sample view so it’s easier to understand.

  • Alpha – Think of it as the orchestration & automation layer (handling UI, workbench, BPM flows, and automation tasks).
  • SSD (Studio) – This is where our backend services and APIs are built and exposed, including integrations with external systems.
  • Reëls – Works as our rules engine and knowledge base. It stores master data, business rules, and executes validations/decisions.

These three work hand-in-hand:

  • Alpha → SSD: Alpha calls backend APIs exposed by SSD.
  • Alpha → Reëls: Alpha queries the rules engine to validate conditions and execute business logic.
  • SSD → Reëls: SSD may also interact with Reëls for validations before sending data back to Alpha.

Here’s an insurance claim example to make it clearer:

  1. Claim submission (SSD/Studio) – The customer submits a claim through a portal built in Studio. APIs integrate external data (e.g., police/hospital records).
  2. Validation (Reëls) – Claim details are checked against configured rules (driver’s age, claim amount, fraud checks, etc.). Reëls decides if it’s STP (auto-processed) or Non-STP (manual review).
  3. Process automation (Alpha) – Based on the Reëls decision:
  • If STP → Alpha continues the BPM flow automatically.
  • If Non-STP → Alpha routes it to a human adjuster with all supporting docs.

So in short: Alpha drives orchestration, SSD provides backend APIs/integrations, and Reëls ensures decisioning & rules execution. Together, they enable a seamless end-to-end process.

Hope this gives you a clearer picture :rocket: