CASE STUDY

Chelaro

A local finance workspace where the AI holds exactly eight typed tools and cannot overwrite a confirmed figure with any of them: every change is a visible proposal the owner accepts or rejects.

Role: Product, architecture, implementation and release
Status: Public source preview, source-available, not production-ready

Chelaro finance overview with synthetic demo data: income, expenses, net cash flow and open receivables — Screenshot of the application, showing synthetic demo data.

STARTING POINT

Problem

Letting an AI near financial data has meant choosing between two bad options. Either the model may write, and sooner or later an amount sits in the database that nobody can trace back to a document. Or it may do nothing, and then it saves no work either. Underneath sits the older problem of receipt handling itself: once a figure has been typed out, the link to its original is gone.

HOW IT WORKS

Solution & architecture

Boundary

Eight tools, no write access

The model gets no shell, file, process, network or browser access. It gets exactly eight typed finance tools through an isolated router. Four of them read. The other four write nothing; they create a proposal awaiting review that must carry a rationale and the expected version of the record it touches. If the version no longer matches, the proposal is rejected rather than applied.

Four reading and four proposing tools, each with a strict JSON schema
Every proposal needs a rationale, or it is not accepted
Changes state the expected version; a stale one runs into a conflict
Arguments are capped at 16 KiB and unknown fields are rejected

Schematic: the AI model reaches eight typed tools. Reads go straight to the finance data, write proposals only pass through the owner’s review. — Schematic illustration, not a screenshot.

Provenance

The original is never overwritten

Every uploaded PDF, PNG and JPEG is stored unchanged and addressed by its SHA-256 hash, whose format the database itself enforces. Everything derived from it is a separately versioned derivation: extracted values, corrections, assignments. Remove a derived row and the original stays.

Immutable storage with a content hash and duplicate detection
Derived values never replace the uploaded file
Every receipt, name and amount shown is synthetic demo data

Chelaro document archive with synthetic receipts, content hash and status column — Screenshot of the application, showing synthetic demo data.

Review

Every correction stays visible

Receivables, partial payments and the typed invoice workbook are versioned rather than overwritten. A reversal is its own visible event instead of a silent delete, and every accepted and every rejected change lands as an entry in the audit ledger. Ask later why a figure looks the way it does and you get the chain, not just the end state.

Versioned receivables with partial payments and a visible correction history
Reversal instead of a silent delete
Accepted and rejected proposals both sit in the audit ledger

Chelaro invoice workbook with synthetic data, tabular amounts and a visible change history — Screenshot of the application, showing synthetic demo data.

ARCHITECTURE

From a receipt to a figure you can trace back

Original

PDF, PNG or JPEG, unchanged, with a SHA-256 hash

Proposal

rule or AI, always with a rationale

Review

the owner accepts or rejects

Version

the expected version, or a conflict

Canonical

applied, with an entry in the audit ledger

Denied
no shell, file, process, network or browser access for the model
Separate
distinct principals for owner, agent and finance assistant

Public source preview under PolyForm Noncommercial 1.0.0. No releases, no production use.

From the original receipt to the canonical finance record

Results

typed finance tools, and the model gets no others: 8typed finance tools, and the model gets no others
of them may overwrite canonical finance data: 0of them may overwrite canonical finance data
separate principals: owner, agent, finance assistant: 3separate principals: owner, agent, finance assistant
conflict instead of a silent overwrite on a stale state: 409conflict instead of a silent overwrite on a stale state

EVIDENCE & SCOPE

What is evidenced — and where the claim ends

These four fields separate my contribution, the project context, the measurement basis and the limits of the results.

My contribution: Sole author: the product decision, the architecture, the implementation across all four applications in the monorepo, the brand and licensing strategy, and the release as a source preview.
Team & context: A solo project with no client. The public Git history is a deliberately squashed state following a secrets and PII review, so it is not a measure of effort or duration. Logo, hero and screenshots were produced in a Codex agent workflow; their provenance is documented in the repository with hashes.
Measurement basis: What is verified is the structure, not the effect: eight typed tools in the tool contract, four of them proposal-only, 35 test files, local gates green. There are no user numbers, no runtime measurement and no time saved, because the system is not in use.
Limitations: A source preview, not production-ready. OCR, transaction import, the live FinTS adapter, secure local credential storage, and backup and restore are all missing; signing and notarisation are unfinished and there are no releases. The licence is source-available (PolyForm Noncommercial 1.0.0), not open source. Nothing is claimed about German GoBD rules, audit-proof retention or tax suitability.

BUILT WITH