System architecture
How the practice apps, shared data, processing services and outside providers fit together.
Source reviewed Engineering documentation
The practice products use shared BeforeMay accounts, practice membership and client records. Product screens sit over shared modules for accounts, teams, clients, files, mail, signing and identity checks.
Main boundaries
Loading diagram…
Diagram source
flowchart TB
accTitle: Practice system architecture
accDescr: Practice apps share account and client modules. Normal data access is scoped by membership; server functions coordinate privileged operations, Australian processing and external integrations.
A[Workpapers, Clients, Sign, Verify and BAS Review]
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[Identity, mail and other connectors]
class F,G controlArrows show responsibilities and principal connections, not every request or deployment unit. Only the Workpapers processing route uses the AI branch shown here. Verify's direct identity capture and browser-local file processing are explained separately below and in data flow.
| 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, identity checks 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.
Local and external flows
Sift extracts digital PDFs locally. BAS Review parses the ledger export locally and stores only the documented review state. Outlook reads a member's connected mailbox and can file selected mail. Verify directs the person's identity capture to Didit. These flows must be assessed individually, not inferred from the Workpapers diagram.
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.