Architecture and provenance

Balsa separates evidence, company state and financial state. This is an application design boundary, not just a presentation convention.

From source to result

Source evidence
  -> extracted observations and normalized rows
  -> reviewed facts, mappings, obligations and decisions
  -> validated journals and projection schedules
  -> deterministic calculations and statements
  -> preserved plans, comparisons and signed reports

Source references connect the layers. A calculation should retain the formula version, inputs and output needed to inspect what it means. Unsupported results remain visibly unverified.

One financial engine

Actual, forecast and scenario journal entries carry explicit state and share the calculation path. Forecast settlement reduces identified expected entries to the unfulfilled portion; it does not create a separate accounting system.

Transfers are not revenue merely because cash moved. Journal validation, statement balances and cash roll-forwards are deterministic responsibilities. Language models are not the authoritative calculator or database.

Preserve decisions in transactions

Reviewed mutations validate ownership, current versions, approval state and input hashes as applicable. Financial changes commit with their audit, revision and recalculation-outbox work. A failed multi-effect decision or import approval rolls back rather than leaving half its effects applied.

Read-only financial previews can use a rolled-back transaction to exercise the same posting controls. Preview journal identities are not the final saved identities.

Snapshot versus current state

A preserved plan or outlook review stores its original inputs and result. A work review adds ownership and tasks; immutable sign-off preserves the exact report and dispositions that were signed. Refreshing a draft scope does not rewrite earlier sign-offs.

Current values can change after new evidence arrives. Saved values are not silently recalculated with a newer formula version. Replay incompatibility becomes an explicit limitation.

Company scope

Application reads and mutations resolve the active company and check ownership. The company-selection cookie is a preference, never authorization. Selected-record IDs and source references must belong to that company.

PostgreSQL policies add transaction-scoped protection for non-superuser roles. The current policy convention permits unscoped access when no company scope is set, so it does not replace application scoping. See Security.

Deployment boundary

The application uses Next.js, PostgreSQL, a configured model provider and persistent source-file storage. This website is a separate static documentation site. Neither the public docs nor its Markdown downloads contain customer financial records.

See Application API reference for the reviewed financial surfaces and Contributing for development checks.