THE PROBLEM
Review journal and invoice exceptions.
A duplicate-looking journal entry and an absent invoice are different questions. Both need traceable inputs, a narrowly stated reason for review, and a person who can compare the underlying records. This independently owned prototype brings those signals together without treating a flag or a suggested amount as a conclusion.
FICTIONAL DISCOVERY BRIEF
Define the reviewer decision.
The imagined controller wants a view of open questions, while journal and AP reviewers need enough context to investigate their own queues. The prototype can prioritize a conversation; it cannot determine whether a posting is correct or authorize an accrual.
What should be reviewed?
Show the record pair or invoice pattern behind each signal before asking for a human disposition.
Fictional close data.
Use invented entries and vendor history. No ERP connection, ledger write, real model call, or client record.
Show advisory status and owner.
Prove that a duplicate candidate and a missing-invoice candidate remain advisory, with an explicit next owner.
ARCHITECTURE DECISIONS
Rules and review responses.
Generate review candidates with rules.
The source prototype applies explicit duplicate, unusual-amount, reversal, and invoice-cadence rules. They produce review candidates, not validated accounting findings.
Exclude future invoices.
The portfolio fork fixes cross-year month comparisons and excludes later invoices from historical views. Three period tests cover year boundaries, malformed periods, and future-invoice exclusion.
Use fixed browser responses.
The current fork removes its optional model API routes, while this site uses newly written fixed responses. Neither sends financial fields to a model or posts a journal entry.
EVIDENCE AND LIMITS
Prototype evidence and limitations.
The working static dashboard uses the independent project's fictional finance fixtures and deterministic rules. Its narrative actions replay fixed browser-local templates. The two smaller examples above are newly written fictional fixtures informed by the same rule shape, not captured outputs from a production run. The private derivative passes its static build, lint, TypeScript check, and period tests. Its pattern score is an unvalidated heuristic; its clean-entry share is not a validated readiness metric. Accounting accuracy, security, and real-system integration need independent review before a live pilot.