Open Questions and Decision Points
Eight architectural decisions still open — intentionally deferred until build time, with current preferences noted.
These decisions are open because they require production data, cost modelling, or regulatory sign-off before they can be finalised. The architecture is designed so that none of these decisions require significant rework once made — the interfaces are stable, the options are equivalent at the SDK or API level.
Decision Table
| # | Question | Options | Current Preference | Impact |
|---|---|---|---|---|
| 1 | LLM provider for AI Assistant | OpenAI GPT-4o · Anthropic Claude · AWS Bedrock (Claude/Llama) · Self-hosted | AWS Bedrock — data sovereignty for regulated banking environment | Cost, latency, data residency, compliance posture |
| 2 | Temporal Cloud vs self-hosted on EKS | Temporal Cloud (SaaS) · Self-hosted on EKS | No preference — both use the same Java SDK | Operational burden vs control; same SDK means code is portable |
| 3 | Agentic framework | LangChain · LangGraph · Anthropic APIs direct · OpenAI APIs direct | No preference — Python + FastAPI confirmed; framework TBD | Agent capability design is framework-agnostic (see tool catalogue) |
| 4 | Monorepo vs polyrepo | Monorepo (all services in one repo) · Polyrepo (one repo per service) | Monorepo — small team, shared CI/CD, shared type definitions, easier refactoring | Developer experience, CI/CD complexity, cross-service versioning |
| 5 | Aurora Serverless v2 vs provisioned | Serverless v2 (auto-scale) · Provisioned (fixed capacity) | Serverless v2 for temporal-db (bursty write load during workflow history replay); provisioned for platform-db (predictable OLTP load) |
Cost predictability vs operational simplicity |
| 6 | Document AI provider | AWS Textract + custom NLP · Azure Document Intelligence · Google Document AI | AWS Textract — stays in-cloud with EKS; native S3 event integration; no data leaves AWS boundary | OCR accuracy, cost per page, multi-format support |
| 7 | React UI component library | Ant Design · MUI (Material UI) · Shadcn/ui · Custom | Ant Design — enterprise table/form components are production-grade; large ecosystem; proven in banking UIs | Development speed, licensing, bundle size, design system coherence |
| 8 | Mobile scope: Phase 1 or later? | Mobile alongside web (Phase 1) · Mobile after MEDIUM is live (Phase 2+) | After Phase 2 — banker/RM mobile value peaks when MEDIUM segment is live; Document Review Agent makes the mobile AI features meaningful | Go-live timeline, engineering bandwidth, user adoption |
Decision Notes
LLM Provider (Decision 1)
This is the most consequential open decision. AWS Bedrock is preferred for three reasons:
- Data residency — no data leaves the AWS environment; critical for regulated banking
- Model variety — Bedrock hosts Anthropic Claude, Meta Llama, and Amazon Titan; switching models doesn’t change the integration
- IAM integration — Bedrock API calls use IAM roles; no API keys to manage in secrets
The agent service is written against an abstraction layer so that switching LLM providers requires changing only the provider configuration, not the agent code.
Temporal Cloud vs Self-Hosted (Decision 2)
Both options use the identical Java SDK — io.temporal:temporal-sdk. Workflow, activity, and signal code is 100% portable. The only difference is:
- Temporal Cloud: SaaS; Temporal Inc. manages the server;
namespace.account.tmprl.cloud:7233as the connection endpoint - Self-hosted: Helm chart deployed to the
temporalEKS namespace; team manages upgrades and availability
Given that Temporal is the most operationally complex component in the platform, Temporal Cloud is worth serious consideration — but the decision is deferred until infrastructure cost modelling is complete.
Monorepo (Decision 4)
The monorepo preference is firm for the early stages of the project. A small team benefits significantly from:
- Shared TypeScript type definitions between the React workspace and the REST API spec
- Single CI/CD pipeline with cross-service integration tests
- Atomic commits that span service boundaries (e.g., a new GraphQL field + the React component that uses it)
Polyrepo migration is possible later if team size warrants it — the service boundaries are already clean.