Skip to main content

​
Separate local state from provider money

Perflo remains the source for money balances, transaction status, recipient grants, and card state. PostgreSQL stores the workflow, policy, and evidence needed to call Perflo safely.

​
Store local workflow state

PostgreSQL stores:
  • Customers, Auth0 bindings, and Perflo connection generations
  • Vault ciphertext for customer credentials and provider context, derived against the exact connection generation or resource row
  • Non-reversible provider-evidence claims that prevent one grant, transaction, beneficiary, or card identifier from completing two operations in the same provider-binding generation
  • Operations, action expiry, reconciliation schedule, and safe failure detail
  • Idempotency records and unique transactional outbox events
  • Beneficiary projections without plaintext provider destinations
  • Indicative quotes and exact United States dollar cash debits
  • Mandates, approved callers and rules, rolling-limit reservations, and upstream grant identifiers
  • Card projections, confirmation intents, and audit events
The request and audit JSON columns contain only safe identifiers, fingerprints, normalized amounts, and policy values.

​
Read provider evidence

The live adapter reads fiat accounts, recipient metadata, estimates, customer-wide activity, transaction status, recipient grants, cards, and card transactions. Strict normalization rejects missing money, identifiers, timestamps, and successful states. Unified activity is not a fiat-account ledger. It combines agent and Perfolio transaction feeds, filters to cash and payment rows, normalizes cash to United States dollars, deduplicates by transaction identifier and hash, and omits crypto details.

​
Preserve uncertain writes

An operation enters indeterminate when Perflo may have accepted a write. Reconciliation never repeats that write. Exact reads can complete transfers, card actions, and grant revocations; ambiguous evidence stays operator-visible.

​
Reinitialize this schema

The Alembic chain starts from one consolidated initial schema and applies later revisions incrementally — an empty database is initialized and an existing one is upgraded in place. make migrations proves the whole chain supports upgrade, check, downgrade, and upgrade.