Day 5: Views Are the New Reports

The Insight

Yesterday we defined financial truth. Today we asked: How do you ask questions of that truth?

Traditional finance apps give you canned reports. "Spending by Category". "Income vs Expenses". "Monthly Summary". These are features, not primitives. They can't be customized, combined, or shared.

We realized: reports, dashboards, and exports are all just Views. Different ways of asking the same underlying question: "Show me transactions that match these filters, grouped this way, sorted this way."

Why Views Are Primitives

A View is not code. It's a declarative description of a financial perspective:

{
  name: "Spending by Category",
  type: "report",
  filters: [
    { field: "amount", operator: "lt", value: 0 },
    { field: "type", operator: "neq", value: "transfer" }
  ],
  grouping: { field: "categoryId" },
  sorting: [{ field: "amount", direction: "desc" }],
  columns: ["category", "amount"]
}

This is pure data. No callbacks. No code. No side effects. It describes what to query, not how to execute.

The View Primitive

Every View contains these fields:

The QueryEngine

Views don't execute themselves. The QueryEngine takes a View definition and returns results:

This separation is crucial. Views describe intent. The QueryEngine executes intent against financial truth. Neither stores derived results.

Filter Operators

We defined a complete set of filter operators:

eq       // equals
neq      // not equals
gt, gte  // greater than (or equal)
lt, lte  // less than (or equal)
in, nin  // in array / not in array
between  // between two values (inclusive)
contains // string contains
isNull   // is null
isNotNull// is not null

These cover every use case we could imagine:

• date between [start, end] — Date range queries
• amount lt 0 — Expenses only
• accountId in [a, b, c] — Multiple accounts
• reconciledAt isNull — Unreconciled transactions

Built-in Views

Every workspace gets seeded with canonical Views:

These are NOT special cases. They're just View definitions that happen to be pre-created. They use the same QueryEngine as custom views. You can create identical views yourself.

Why This Enables Future Features

Because Views are pure data, they enable:

What We Didn't Build

Constraints are features:

• No charts — Tables only. Charts come later.
• No mutations — Views are READ-ONLY. They don't change data.
• No stored results — Views don't cache. They always reflect current truth.
• No rules engine — Views query; they don't transform.

What We Built Today

• View Primitive — Fully typed schema with filters, grouping, sorting, columns
• Filter System — 12 operators covering all comparison types
• QueryEngine — Pure, read-only executor against LedgerService
• Built-in Views — 6 canonical views seeded for every workspace
• Views UI — List, select, execute, render with table output
• Create/Edit Views — Full CRUD with filter builder UI