System architecture
How Workpapers, practice data, processing services and AI providers fit together.
Source reviewed Engineering documentation
Workpapers uses BeforeMay accounts, practice membership and client records. Its screens connect to account, team, file and workpaper-processing services.
Main boundaries
Loading diagram…
Diagram source
flowchart TB
accTitle: Practice system architecture
accDescr: Workpapers uses account and client modules. Normal data access is scoped by membership; server functions coordinate privileged operations, Australian processing and external integrations.
A[Workpapers]
A --> P[Shared account, team, client and product modules]
P -->|Authorised account queries| D[(Authentication, practice data and private storage)]
P -->|Privileged or integration requests| F[Server functions: caller and practice checks]
F --> D
F -->|Queue work| W[Australian worker and recognition services]
W --> D
W --> G[Outbound identifier controls]
G --> AI[Configured external AI providers]
AI -->|Stage results| W
F --> E[Connected services]
class F,G controlArrows show responsibilities and principal connections, not every request or deployment unit. See data flow for processing locations.
| Layer | Responsibility |
|---|---|
| Browser applications | User interaction, previews, local file parsing and authorised requests |
| Database and private storage | Practice-scoped records, membership, source documents and output files |
| Server functions | Validate callers, enforce privileged operations and coordinate integrations |
| Australian processing services | Recognise documents, apply outbound identifier controls and run the workpaper process |
| External providers | The configured AI steps and connected services described in the Privacy Policy |
Workpapers' AI provider credentials remain server-side. A browser application's publishable connection configuration is not a privileged credential. Access must stay within the caller's authorised practice and permitted action.
A workpaper's route
- An authorised upload creates evidence in private storage and case metadata.
- Recognition and analysis prepare the document information used by the case.
- A build run reads the case evidence and generates a draft workbook.
- The selected review/repair stages and delivery policy determine release; some remaining findings can accompany a delivered workbook.
- The delivered/current version is available for the accountant's review, permitted edits and download.
A rendered draft and a delivered workbook are distinct states. The public MCP download tool exposes delivered output, not the earlier draft. Provider and model choices can change by stage through configuration; a vendor name in a historical architecture note is not the current runtime setting.
Read data flow for destinations and access controls for credentials. Maintainers should use the repository's source and current configuration for module, deployment and incident details.