01 Architecture, security and deployment
For the people who have to approve it
One direction of travel: out of your systems, never back in
RE-ViVE source connections are read-only: the platform reads the operational records it needs and does not write transactions back to those source systems. The platform can be deployed in RE-ViVE cloud, your cloud tenancy or your data center.
source accessnothing written back
shapesSaaS, private cloud, on-prem
stacksame build in all three
and RBACSSO where you need it
02 Deployment shapes
Three deployment options. Choose where the boundary sits.
The core RE-ViVE runtime and Execution Data Model stay together. The main deployment choice is where that runtime and data reside: RE-ViVE cloud, your cloud tenancy or your data center.
| SaaS | Private cloud | On-premises | |
|---|---|---|---|
| Runtime location | RE-ViVE-managed cloud | Your cloud tenancy | Your data center |
| Execution Data Model location | RE-ViVE-managed cloud | Your cloud tenancy | Your data center |
| Data crosses your boundary | Yes | No | No |
| Infrastructure operated by | RE-ViVE | Your team | Your team |
| Source system access | Read-only | Read-only | Read-only |
| Authentication | Inbuilt or SSO | Inbuilt or SSO | Inbuilt or SSO |
| Internet egress required | Yes | Not for the platform to function | Not for the platform to function |
For regulated environments, this comparison makes the data boundary and operating responsibility explicit.
03 Footprint and sizing
A practical starting footprint for many first engagements
The figures below are a reference starting point for a typical scenario of around 100 GB of raw source data. Actual sizing is confirmed against data volume, history depth, process complexity and expected concurrency.
- host os
- Ubuntu 24.04 LTS
- runtime
- Docker Engine & Compose v2
- cpu
- 8 cores
- memory
- 32 GB
- storage
- 500 GB SSD
- reference raw data
- 100 GB
Volume, depth and concurrency
Raw source volume sets storage. History depth and the number of activities per case drive memory during model building. Concurrent analyst sessions drive CPU. These are assessed together rather than from a single number.
Beyond the reference box
Larger estates are sized during the engagement. Because the platform is a container stack, adding resource is an infrastructure change on your side rather than a different edition of the product.
04 Access and identity
RE-ViVE can use built-in authentication or your identity provider
RE-ViVE includes built-in authentication for environments that need it. Where organizations prefer to use their own identity provider, single sign-on can be configured.
Runs without an external identity provider
RE-ViVE includes user management and authentication, allowing an on-premises deployment to operate without depending on an external identity service when required.
Microsoft 365, Google and standard providers
Single sign-on is supported for Microsoft 365, Google and standard identity providers. Each integration is configured for your environment during the engagement rather than enabled from a settings page.
Role-based access control, built in
Permissions are granted by role, so what a user can open, drill into and configure follows their role rather than being uniform across the platform. Roles are defined during setup and adjusted as teams change.
05 Data handling
What RE-ViVE stores — and what it does not write back
RE-ViVE stores the extracted operational records needed for analysis, the Execution Data Model and platform configuration. Source-system connections are read-only, and connection credentials are stored encrypted.
Read-only source connections
Extraction accounts require read access only. RE-ViVE does not use those connections to alter source records, trigger source-system transactions or close source-system cases.
Sensitive configuration is encrypted
Passwords, connection strings and other connection details are held encrypted rather than in clear configuration. This covers what the platform needs to reach your systems.
Disk and transport follow your environment
In private cloud and on-premises deployments, disk encryption and transport security are provided by the host platform you already run, under your existing standards. These are confirmed as part of deployment design rather than replaced by the application.
Operational records and the Execution Data Model
The deployment stores extracted operational data, the Execution Data Model and the configuration needed for process analysis, controls, dashboards and roles. Documents provided to ViVE Genie are stored according to the selected deployment design.
06 Backup, recovery and releases
Protect the configuration and the running environment
RE-ViVE configuration can be protected separately from the host environment. Configuration export protects platform setup; infrastructure backup protects the running deployment and its data.
Configuration as an XML export
The platform metadata — process definitions, compliance rules and controls, dashboards, roles — exports as XML and imports into another instance. This is the route for protecting the work your analysts have done, and for moving a configuration between environments.
Server or container-host backup
Backing up the host that runs the container stack captures the application and the execution data together, using whatever backup and snapshot tooling you already operate. This is the route for full recovery rather than reconfiguration.
Issued as critical issues are identified
Where a critical issue is found, a hot fix is provided rather than held for the next planned release.
Planned every six months
Functional releases arrive on a six-month service pack cycle, which gives your change process a predictable window to plan around.
07 Settled with your team
The decisions we make with your team
Several deployment choices depend on your environment and standards. These are confirmed during deployment design rather than assumed in advance.
- Network topology and firewall rulesWhich segments the runtime sits in, and what it is permitted to reach.
- Extraction schedule and incrementsHistorical backfill depth, and whether increments are batch or near real-time.
- Retention and deletionHow long extracted records and derived history are kept, under your data policy.
- Actual sizingConfirmed against your volumes, history and concurrency during presale and engagement.
- SSO configurationYour provider, claim mapping and the customization each integration needs.
- Role modelWhich roles exist and what each is permitted to see and configure.
- Backup schedule and recovery targetsHow often each route runs, and what recovery point you need.
- Change and release windowsHow hot fixes and six-monthly service packs land in your process.
These decisions can be worked through alongside an initial engagement rather than requiring every enterprise deployment detail to be settled before analysis begins.
08 The platform itself
One deployment. Four ways to use the process data.
The same RE-ViVE deployment supports ViVE Optim, ViVE Comply, ViVE Insights and ViVE Genie over the same Execution Data Model.
ViVE Optim
Variants, times, rework, bottlenecks and root cause, with drilldown to the individual case and what-if simulation.
ViVE Comply
SLAs, mandatory and sequenced activities, segregation of duties, and X-R and X-S controls monitored against real execution.
ViVE Insights
Drag-and-drop reports and dashboards over the Execution Data Model, built the way your team wants to monitor the process.
ViVE Genie
Ask questions in natural language using the same RE-ViVE process data, with your SOPs and designs available as additional context.