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

# Repository Model

> How Parmana separates storage interfaces from storage implementations

Parmana separates *what* the Runtime needs from storage (an interface, defined in `shared`) from *how* that need is actually met (an adapter, implemented in `storage`).

```
Application
        |
        v
Repository Interface
        |
        v
Storage Adapter
```

## Supported and planned adapters

* In-memory (used for tests and local development)
* PostgreSQL
* Supabase
* Other cloud-native databases
* Custom enterprise adapters

The Runtime never depends on a concrete storage technology — only on the repository contracts defined in [`shared`](/docs/packages/shared). This is part of why Parmana describes itself as **storage agnostic**: swapping the in-memory adapter for a PostgreSQL-backed one is a change confined to the [`storage`](/docs/packages/storage) package.

## Why this matters for trust

Because Execution Trust Records are append-only and immutable (see [Security Model](/docs/architecture/security-model)), the repository layer's job is narrower than in most systems: it never needs to support updates to historical rows, only inserts and reads. This significantly reduces the surface area for storage-layer bugs to corrupt trust evidence.