Understand FloFi
Architecture
One semantic workflow engine connects product interfaces, integrations and bounded execution adapters.
On this page
Interfaces converge on one engine
Chat, the visual builder, the Developer API, SDK, MCP and conversational channels feed the shared FloFi platform. Canonical Semantic Workflow IR is checked against the capability registry and validated before producing artifacts.
Chat / Builder / API / MCP
↓
Canonical Semantic Workflow IR
↓
Capabilities → Validation → Simulation
↓
Strategy Manifest → Owner wallet authorization
↓
Execution → Reconciliation → Evidence BundleRepository responsibilities
| Location | Responsibility |
|---|---|
| apps/reference-dapp | Next.js product, public site, docs and integration routes |
| packages/workflow-contracts | Canonical schemas, hashes and lifecycle contracts |
| packages/action-registry | Action and capability definitions |
| packages/reference-linter / reference-compiler | Validation and bounded execution planning |
| packages/reference-executor / reference-reconciler | Execution tracking and outcome verification |
| packages/cloud-runtime | Durable platform / runtime infrastructure |
| packages/developer-sdk | Thin server-side API and webhook client |
Durable state, specific runtimes
The embedded cloud runtime uses PostgreSQL for platform state. Specific financial flow runtimes remain separately configured. Deployment availability is not inferred from the presence of a route or adapter.
Recovery preserves attempt history and evidence provenance. A semantic edit invalidates downstream commitments; a presentation edit does not. Read the Strategy Manifest and Security guides for the trust boundaries.
These guides summarize the repository’s current contracts. Detailed evidence and engineering history stay in their original records.
README.md docs/contracts/CANONICALIZATION_V1.md docs/deploy/CLOUD.md docs/AUTHORITY_MATRIX.md