---
title: Architecture and provenance
section: Model and reference
order: 34
summary: Understand the application boundaries, calculation lineage and durable review records.
---

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

## From source to result

```text
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](/docs/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](/docs/api-reference/) for the reviewed financial surfaces and [Contributing](/docs/contributing/) for development checks.