Architecture at a glance

Helm’s browser expresses questions and user intent. Its own API authenticates the caller, validates the request and delegates to user-scoped services. PostgreSQL supplies the financial foundation.

Request flow

1. An inquiry component calls a helper in src/lib/api.
2. The /api/v1 router resolves the method and route, authenticates the caller and checks scopes.
3. A service under src/server/services checks record ownership and domain constraints.
4. A read returns financial evidence; a command records an atomic domain change.
5. The client invalidates relevant cached queries and explains the fresh result.

The browser does not directly mutate financial tables.

Financial foundation

A transaction has at least two entries balanced separately in each stored currency. Currency exchanges can contain four entries. The controlled create_double_entry_transaction() database function is the financial write boundary.

People, obligations, matters, categories and tags add meaning without replacing money entries. Imported sources pass through review and explicit consent before recording.

Identity and sessions

Provider authentication identifies the user. Application admission and owned-session checks determine access. Public welcome, privacy, roadmap and documentation pages do not require a financial session; private views and financial API operations do.

To change a feature, trace both the UI caller and the registered service rather than inferring an API from a table name. Continue with frontend data flow, financial semantics and API authentication.