The platform

AI-first by construction.

Trisilva runs on two layered platforms. TrisilvaOS is the AI engine that builds and operates every product. InsureFlow is the insurance-domain platform every product binds to. Together they are one backbone, built to run across multiple regions and multiple insurers.

Products
MicroFlow, ClaimFlow, and the InsureFlow familyThe outcomes buyers run in production
DistributionUnderwritingClaimsServicing
InsureFlow
The insurance-domain platform every product binds toShared model, adapters, tenant separation, audit trail, data residency
OPIN modelAdaptersMulti-tenantMulti-region
Insurance standards
Open Insurance Standards, Trisilva-authored market profilesOpen, interoperable, portable
OPINCountry adaptation
TrisilvaOS
The AI engine that builds and operates every productAI-first delivery and operations, by construction
Agent orchestrationMethodology engineAI model gatewaySecurity & observability

One insurance backbone. The insurance domain on InsureFlow, the AI engine on TrisilvaOS.

AI-first, at three layers

AI is load-bearing at three layers.

AI is an architectural decision here, not a feature. It builds the platform, it does the work inside every product, and it operates the running system in production. Each layer below shows where, and what it produces.

The delivery layer

Layer 01

AI agents build and test the platform itself, under our AI Development Life Cycle. Every change runs plan-driven and test-first, through a conformance gate against the standards stack before it ships.

Code that meets the standards on arrival, not corrected into them later

The product layer

Layer 02

AI runs inside every product on the live path of work: severity triage on a claim, an adjuster co-pilot that drafts the assessment and flags fraud, multi-insurer routing on a policy.

Work completed inside the product rather than merely reported by it

The operations layer

Layer 03

The running platform is operated by coordinated AI agents against real-time service-level targets, with human handoff wherever confidence is too low to proceed alone.

Operations that stay reliable at scale, on a complete and tamper-evident audit trail
TrisilvaOS · the AI engine

The six parts of the AI engine, named and described.

TrisilvaOS is the shared AI engine every product is built and run on. Its architecture is not a trade secret. We describe it plainly, because the advantage is in owning it and improving it with every engagement, not in hiding it.

Integration fabric

01

Pre-built connectors to insurance systems: carrier APIs, claims cores, channel surfaces, document services, and payment rails, ready to configure.

Integration time falls from weeks to days, and the library grows each time

Client intelligence

02

Engagement memory across every case: real-time SLA dashboards, anomaly detection, and operational insight that feeds both today's monitoring and tomorrow's estimates.

The signal that drives the live SLA cockpit on every ClaimFlow claim today

Automated quality gates

03

Automated checkpoints at every stage for code quality, security, performance, and regulatory compliance, each calibrated to insurance standards.

No stage advances without clearing a conformance gate against the tier stack

Methodology engine

04

Our delivery framework, Discover, Build, Operate and Optimise, encoded as executable workflows rather than as a document someone has to remember.

Quality is enforced by the workflow itself, not left to individual discipline

Agent orchestration

05

AI agents working in coordination: parallel execution where it accelerates, conditional routing where the workflow demands it, human handoff where confidence is too low.

The same agents that operate ClaimFlow in production today

AI model gateway

06

A multi-model gateway with insurance-domain knowledge bases, so each task runs on the right model against vocabulary the platform already understands.

From claim severity to carrier terms of art, the right model per task
InsureFlow · the insurance-domain platform

The insurance domain, modelled once and reused everywhere.

InsureFlow is the insurance-specific platform every product runs on. It holds the shared insurance model, the pattern for connecting older insurer systems, and the tenant separation, audit trail, and data-residency controls a regulated operation needs. It is Tier 3 of the open standards stack, and it extends OPIN, the open insurance standard, and the market profile.

See how the standards stack fits together
OPIN domain model
The common insurance vocabulary every record is mapped to, so local-language codes and carrier-specific identifiers never leak into the coreModelled once, reused everywhere
OPIN entitiesTwelve modulesOpen under MPL 2.0
Anti-corruption adapter pattern
Every outside system connects through an adapter that translates its data format, sign-in, and lifecycle into the shared modelPlatform-level pattern, product-specific implementations
Carrier APIsLegacy-core adaptationOne canonical surface
Multi-tenant identity and scope catalogue
A model that keeps each organisation on the platform, whether broker, insurer, or channel, separate, each with its own identity and its own defined access from end to endPer-tenant scope, verifiable end to end
Per-tenant scopeRole-scoped accessOutcome-verifiable
Audit log
An append-only, system-wide log where every agent action is recorded with full traceability, for compliance, dispute resolution, and outcome-based billing verificationRegulator-ready by construction
Append-onlyFull traceabilityRegulator-ready
Document Service
A shared service for binary attachments where each product registers its own document classes, scoped to its semantic domainShared once, class-scoped per product
Class-scopedOwner-typedShared once
Multi-region operating topology
A Singapore control layer for identity, tenants, and configuration that holds no personal data, sitting over regional data layers that keep personal data in its own countryResidency by design, not manual carve-out
SG control planeIn-region data planesResidency by design
Connecting what already runs

Every party keeps the system it already runs.

An operation crosses parties who each run something of their own: a carrier core, a broker's platform, workshop tooling, a dealer management system, an operator's own portal. Each of them keeps it. The integration fabric gives them one common interface instead, so a new connection takes days rather than months.

Adapters, written once

01

A carrier API, a workshop system or a partner portal is normalised once against the canonical model and reused across every product and engagement.

The second product on a carrier inherits the first product's integration

Legacy-core adaptation

02

A legacy claims or policy core is bridged through the same adapter pattern that fronts a modern carrier API.

A carrier does not have to modernise its core before it can run on the platform

The anti-corruption boundary

03

Carrier-specific formats, authentication, and lifecycle quirks are confined to the adapter and never reach product logic.

One carrier's exceptions never become every other product's problem to handle
Designed for how Asian insurance actually runs

Multi-region, multi-carrier, multi-channel, multi-market, by design.

4 markets
Vietnam, Indonesia, the Philippines, and Singapore, with each market's residency and jurisdiction handled at the platform.
10 carriers
One normalised carrier-API adapter library runs the Vietnam insurer panel, and it compounds with every engagement.
Multi-channel
Mobility super-apps, agent terminals, web portals, and embedded surfaces unify through one integration fabric.
Security and compliance

Residency, tenancy, and the audit trail are designed in, not added later.

Where data lives, how tenants are separated, and what gets written down are decided in the design of the platform, not added by policy after products ship.

The full posture, the regimes, and the certification roadmap

Residency by architecture

Personal data stays on an in-country data plane. The Singapore control plane holds identity, tenancy, and configuration, and no personal data.

Tenant-isolated, append-only

Every carrier, broker, and channel runs under a defined tenant identity and scope, and every action lands on a log that only adds entries.

Built to the regimes it runs in

Designed to Singapore's PDPA and to the direction set by the OJK in Indonesia and the MAS in Singapore.

Audit log · append-onlylive
09:41:07claim.triaged · CLM-4821 · tenant/vinfast-xdv#a7f3
09:41:08copilot.assessment.drafted · agent/adjuster#a7f4
09:41:11supplier.dispatched · workshop/HN-14#a7f5
09:41:14sla.clock.checkpoint · on-track#a7f6
09:41:19settlement.approved · scope/insurer-tenant#a7f7
09:41:19ledger.reconciled · outcome-fee/verified#a7f8
writing next entry…

Every agent action lands on the append-only trail, in real time.

See the platform against the systems already in place.

Tell us the systems you already operate. We will show you where they sit on InsureFlow.

Singapore · Vietnam · Indonesia · Philippines