Single Assignment
A defined task with an explicit owner, objective, jurisdiction, evidence path, and handoff.
MODLAN CARRIER OPERATING MODEL CENTER
Coordinate more capability without losing control of who owns the decision.
MODLAN can support a carrier or TPA through individual assignments, service-family capacity, or coordinated multi-service programs. The operating model is designed so claims authority, investigative independence, evidence custody, integration ownership, and CST intelligence remain distinguishable and reviewable.
Service-Family Capacity
Recurring or overflow work in one operating family under established client guidelines and program controls.
Multi-Service Program
Claims, adjusting, SIU, evidence, integration, and intelligence connect under one governed operating model.
PROGRAM GOVERNANCE QUESTIONS
The bigger the program, the more explicit the ownership model should become.
Authority
Who can authorize work, make claim decisions, approve referrals, or change program scope?
Ownership
Who owns the claim record, evidence record, integration configuration, exception, and final decision?
Separation
Which roles must remain operationally distinct for licensing, independence, privilege, or defensibility?
Evidence
What must be preserved, who may access it, how does it move, and when may it be retained or disposed?
Technology
Which systems remain authoritative and what approved context may cross the CST boundary?
Assurance
What evidence proves access, reconciliation, exception handling, review, and change control operated as intended?
ILLUSTRATIVE GOVERNANCE MATRIX
Accountability should remain visible as the program becomes more integrated.
This public matrix illustrates a common control pattern. Final responsibility, approval, consultation, and notification are defined by contract, jurisdiction, professional role, and the client operating model.
A AccountableR ResponsibleC ConsultedI Informed
| CONTROL AREA | CLIENT / CARRIER | MODLAN PROGRAM OPS | SERVICE SPECIALIST | PLATFORM / INTEGRATION |
|---|---|---|---|---|
| Business authorityThe client defines the mandate, authority limits, program objectives, and system-of-record ownership. | A/R | C | I | I |
| Program configurationMODLAN configures the approved operating model; client approval remains visible. | A | R | C | C |
| Claim decisionCoverage, settlement, and claim authority remain with the authorized client function unless expressly delegated by contract and law. | A/R | C | C | I |
| Investigative findingQualified investigators develop and report facts; findings do not automatically become coverage or legal conclusions. | I | A | R | I |
| Evidence custodyCustody responsibilities are matter- and program-specific and must be documented before evidence moves. | A | R | C | C |
| Integration mappingMappings, tenant boundaries, checkpoints, and reconciliation operate only inside the approved integration scope. | A | C | I | R |
| CST intelligence outputCST returns approved decision-support context; protected mechanics remain inside MODLAN. | A | C | C | R |
| Assurance & exceptionsControl evidence, exceptions, access, and reconciliation remain reviewable by the accountable program owner. | A | R | C | C |
ENTERPRISE DEPENDENCY MAP
Each layer can add capability without silently inheriting authority from the layer before it.
CLIENT AUTHORITY
Mandate, decision rights, jurisdictions, client guidelines, source-of-record ownership.
Open layer →↓PROGRAM OPERATIONS
TPA, adjusting, SIU, private investigation, evidence, and technical lanes execute inside approved scope.
Open layer →↓EVIDENCE CONTROL
Provenance, custody, secure exchange, retention, and disposition remain explicit across service handoffs.
Open layer →↓INTEGRATION FABRIC
Adapters, canonical mappings, tenant boundaries, checkpoints, and reconciliation connect approved systems.
Open layer →↓CST PROTOCOL™
MODLAN-owned, patent-pending fraud intelligence consumes only approved context through a protected boundary.
Open layer →↓ASSURANCE
Access, exceptions, controls, reconciliation, vendor dependencies, and program decisions remain reviewable.
Open layer →PROGRAM LAUNCH GATES
Production should begin only after the operating model can explain who may do what, with which data, under which controls.
These are design gates, not public service-level promises or a substitute for customer-specific security, legal, licensing, or compliance review.
- 01DEFINE BEFORE LAUNCH
AUTHORITY
Program sponsor, permitted services, jurisdictions, decision rights, escalation, and system-of-record ownership are defined.
- 02DEFINE BEFORE LAUNCH
ROLE SEPARATION
Claims, investigative, technical, counsel-directed, and intelligence roles are separated where law, contract, or defensibility requires it.
- 03DEFINE BEFORE LAUNCH
DATA MINIMIZATION
Only the information necessary for the authorized purpose is identified, classified, and approved for use.
- 04DEFINE BEFORE LAUNCH
EVIDENCE LIFECYCLE
Ingress, integrity, custody, participant access, retention, legal hold, and disposition responsibilities are documented.
- 05DEFINE BEFORE LAUNCH
INTEGRATION CONTROL
Tenant boundaries, credentials, mappings, checkpoints, idempotency, retry/replay, and reconciliation are validated before production sync.
- 06DEFINE BEFORE LAUNCH
CST BOUNDARY
Approved context and approved outputs are defined without exposing protected algorithms, scoring logic, schemas, or internal orchestration.
- 07DEFINE BEFORE LAUNCH
ASSURANCE
Access review, control evidence, exceptions, vendor dependencies, incident paths, and audit requirements have accountable owners.
- 08DEFINE BEFORE LAUNCH
LAUNCH AUTHORITY
The accountable client and MODLAN owners approve launch criteria, unresolved exceptions, rollback/stop conditions, and production scope.
FROM DESIGN TO CONTROLLED LAUNCH
Use MODLAN as one coordinated partner without turning the operating model into one undifferentiated role.
Program design should preserve client authority, licensed/professional boundaries, evidence discipline, tenant isolation, system-of-record ownership, protected CST mechanics, and evidence-backed assurance.