> ## Documentation Index
> Fetch the complete documentation index at: https://docs.levery.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Institutional Deployments

> Deployment models, governance boundaries, and assurance posture.

Levery is built for regulated institutional environments with clear trust boundaries, strong governance, and evidence ready operations. All models are single tenant and preserve the same transaction critical enforcement and governance logic; only the runtime location changes.

## Supported deployment models

<CardGroup cols={3}>
  <Card title="SaaS" icon="cloud">
    Vendor hosted, dedicated env. Optimized for speed to production with full governance and evidence delivery.
  </Card>

  <Card title="BYOC" icon="shield-check">
    Dedicated runtime inside the institution cloud account, with managed operations and perimeter sovereignty.
  </Card>

  <Card title="On-Prem" icon="building">
    Dedicated runtime in the institution datacenter for maximum sovereignty and local integration needs.
  </Card>
</CardGroup>

## Architecture and trust boundaries

<Steps>
  <Step title="Transactional core (on-chain enforcement)">
    Transaction critical flows are enforced by smart contracts. Settlement, permissioning, and core invariants execute deterministically on-chain, reducing reliance on mutable off-chain services in the critical path.

    Institutional outcomes:

    * Reduced mutable attack surface for highest risk functions
    * Independent verification via on-chain state and events
    * Clear trust boundaries between governance systems and transactional execution
  </Step>

  <Step title="Governance and oversight layer (institution console)">
    The institution console is the system of record for governance and evidence:

    * identity and role based access control (RBAC)
    * separation of duties and approval workflows for sensitive actions
    * policy configuration (permissions, limits, risk constraints)
    * release metadata (versioning and immutable artifact identifiers)
    * audit logs (who, what, when, where)
    * operational workflows (deployment requests, rollback requests, secret rotation requests)
    * evidence generation for audits, incident timelines, and resilience testing

    Operational principles:

    * Least privilege by default, scoped to tenant and environment boundaries
    * Separation of duties for sensitive operations
    * Evidence first operations with correlation IDs
  </Step>

  <Step title="Execution layer (institution dedicated runtime)">
    A dedicated single tenant stack per institution, hardened to institutional baselines:

    * network segmentation and least privilege
    * minimal exposed ports with explicit allow rules
    * encryption in transit (TLS) and encryption at rest where applicable
    * host and container hardening with patching and vulnerability management
    * backups and restore drills aligned to defined RTO and RPO targets
    * logging and monitoring aligned to institution oversight processes
  </Step>
</Steps>

<Callout type="note" title="Service availability vs operational availability">
  Levery separates service availability (runtime serving end users) from operational availability (ability to deploy,
  roll back, and configure under governance). This preserves resilience without weakening change control.
</Callout>

## Security and assurance posture

<Steps>
  <Step title="Release integrity and controlled change">
    * Deployments reference immutable artifacts (for example pinned image digests)
    * Production changes run only through approved workflows
    * Release metadata and outcomes are recorded in the governance layer
    * Rollbacks are standardized and tested
  </Step>

  <Step title="Auditability and end to end traceability">
    The operating model preserves evidence of: - who requested the change - who approved the change - what changed
    (release identifier) - where it was applied (tenant and environment) - the resulting outcome (health checks and
    timestamps)
  </Step>

  <Step title="Resilience and recoverability">
    * Backups aligned to defined retention policies - Periodic restore drills with recorded outcomes - RTO and RPO targets
      agreed per deployment - Standardized incident management workflow with evidence capture
  </Step>

  <Step title="Security operations readiness">
    * Structured operational and security events with correlation identifiers
    * Export of relevant logs and evidence for SOC review
    * Alerting for privileged actions, configuration changes, and deployment events
  </Step>
</Steps>

## SaaS (single tenant, vendor hosted)

**Summary**
A vendor operated dedicated environment that prioritizes speed to production while providing governance and evidence for institutional oversight.

**Where each layer runs**

| Layer              | Location                           |
| ------------------ | ---------------------------------- |
| Transactional core | on-chain                           |
| Governance layer   | vendor managed institution console |
| Execution layer    | vendor hosted dedicated runtime    |

**Typical institutional fit**

* Vendor hosted outsourcing is permitted by internal policy
* The institution prefers managed operations
* Governance and evidence delivery are required for third party oversight

**Security and governance characteristics**

* Strict change governance with approvals, immutable release identifiers, and standardized rollback
* Complete audit trail for privileged actions and operational events
* Resilience evidence (backup policy, restore drills, RTO and RPO commitments)
* Clear data retention and portability approach

**Due diligence focus**

* Vendor hosting risk controls and evidence cadence
* Incident response posture and notification SLAs
* Disaster recovery posture and test evidence
* Assurance that deployed artifacts match approved releases

## BYOC (single tenant, institution hosted in the institution cloud account)

**Summary**
The institution provides the infrastructure boundary in its own cloud account, while Levery deploys and operates the dedicated stack inside approved controls. This combines managed operations with perimeter sovereignty.

**Where each layer runs**

| Layer              | Location                                                                 |
| ------------------ | ------------------------------------------------------------------------ |
| Transactional core | on-chain                                                                 |
| Governance layer   | vendor managed institution console (or a dedicated instance if required) |
| Execution layer    | institution cloud account runtime                                        |

**Typical institutional fit**

* Policy requires workloads and data to remain inside the institution cloud account
* Alignment with internal network controls and infrastructure evidence is required
* Data residency and encryption key ownership requirements must be satisfied with institution owned primitives

**Security and governance characteristics**

* The institution controls the perimeter, routing, firewall policy, and infrastructure audit logs
* Managed operations remain governed through approved workflows and immutable releases
* Evidence is straightforward to package and correlate across infrastructure, governance, and application layers

**Recommended security patterns**

* Outbound only operational connectivity where required by policy
* Institution controlled encryption keys (KMS or HSM) when mandated
* Strict segmentation between tiers with least privilege connectivity
* Standardized incident and resilience procedures with recorded evidence

## On-Prem (single tenant, institution hosted on premises)

**Summary**
The institution provides dedicated compute and network controls in its datacenter. Levery deploys and operates the dedicated stack under strict segmentation and privileged access governance.

**Where each layer runs**

| Layer              | Location                                                                 |
| ------------------ | ------------------------------------------------------------------------ |
| Transactional core | on-chain                                                                 |
| Governance layer   | vendor managed institution console (or a dedicated instance if required) |
| Execution layer    | institution datacenter runtime                                           |

**Typical institutional fit**

* Internal policy or classification mandates on premises compute
* Maximum sovereignty over infrastructure, telemetry, and access controls is required
* Low latency integration with internal systems is a priority

**Security and governance characteristics**

* Strict segmentation and allowlisting within the datacenter
* Privileged access governance for administrative operations (MFA, session recording, time bounded access)
* Clear operational responsibility boundaries for patching, vulnerability management, and disaster recovery execution
* Standardized evidence capture for change governance and operational events

**Operational access models**

* Vendor assisted operations under institution controlled privileged access governance
* Institution executed operations using approved release packages and runbooks when policy prohibits vendor access

## What to expect in institutional due diligence

Levery provides an evidence pack aligned with typical institutional security questionnaires, including:

* trust boundary and data flow diagrams
* control mapping (policy to control to evidence)
* change and release evidence (approvals, immutable release identifiers, deployment outcomes)
* incident response plan and reporting format
* resilience evidence (RTO and RPO targets, backups, restore drill results)
* security testing summaries and remediation tracking
* portability and exit plan (especially for vendor hosted deployments)