Design phase, branding, language and audit
3 min read
Remy ships as a productised, versioned package - not a bespoke build - and is adopted after contracting in a joint design phase so that each skill, memory page and monitor matches the bank's own processes, systems, entitlemesnt model, terminology and operating environment. The package defines the contracts and the behaviour; the design phase decides the mappings, thresholds, routes and wording. No bank-specific code fork is created.
Where Remy is tailored - without a fork
What | Where it is configured | Examples |
|---|---|---|
Memory shape | The description file - one live copy per deployment, editable by compliance | Which topic pages are in scope; which fields are system-of-record mirrors; what is never stored; bank-specific fields |
Monitor rules | One policy file per monitor | Document lifetimes and alert steps · drift bands per mandate · what a complete suitability file contains · screening source tiers and thresholds |
Letters and drafts | The letter policy and templates | What a prepared letter may and may not say; tone; languages; sign-off |
Cadence | The scheduler | Daily, weekly, monthly, quarterly per monitor, aligned to the risk-based review cycle |
Routing | Design-phase configuration | How a finding travels: dashboard card, letter, task, case or escalation; recipient and approval routes; escalation windows |
Scope and entitlements | The bank's identity provider plus folder permissions | IdP group mapping, role mirroring, book and deputy rules, which skills and memories sit at user, team or organisation level, what is locked |
Connected systems | MCP servers added to the space | Outlook and Teams first; CRM and portfolio next; KYC platform, document vault, market data, house view, case management as approved |
UI | Dashboard configuration and brand pack | Cards and their order per user, team or organisation; ranking bands; languages, currency and time zone; corporate identity on briefs and PDFs |
Skills | The skills folder, at user, team or organisation level | Personal variants, desk-tuned versions, bank-standard skills, and new skills on the same memory and actions-register contract |
Precedence follows the most specific scope: user overrides team overrides organisation - except for what the bank locks. Configuration is versioned and tested like code. Every promotion, override and write is auditable.
Decisions a bank takes in the design phase
Memory and monitor decisions (pages in scope, mirrors, exclusions, promotion, where the policy files live) are listed on Configuring the memory and tuning the monitors; cadences on Schedules. The remaining decisions:
Decision | Default | Options |
|---|---|---|
Authoritative list of a user's clients | Client record system | Complemented by mailbox correspondents and the client document folders |
System of truth for KYC and client master data | Client record / KYC system, mirrored into the memory | Write-back of selected facts is a separately governed decision, not part of the package |
Web search | Enabled where approved | Subject to security and compliance approval; without it, web-dependent skills stay in the package but inactive |
Client-communication languages | English | Any languages agreed; templates per language |
Additional skills | The foundational skills | Organisation, team and user skills on the same contracts; which of the bank's teams own them after hand-over |
Hosting | The bank's own deployment of the platform | Public cloud, private cloud or on premises |
Branding and language
Rendered briefs and PDFs follow the bank's corporate identity through a brand pack - colours, typography, spacing, components - applied on top of the standard design system. Supplied by the bank; without it the standard design system is used.
Interaction with the relationship manager / financial advisor is in English; client communication in the languages agreed in the design phase, with templates per language.
Currency formatting and time zone are set per deployment; the schedule converts local times at install.
Accessibility: keyboard navigation, focus states, screen-reader labels, non-colour status indicators on every rendered page.
Auditing a deployment
What an auditor asks | Where the answer is |
|---|---|
Where did this fact come from? | The source reference on the fact - a followable link to the document, record, message or URL; bare system names are rejected |
Who changed this memory, when, why? | The append-only change log per client, plus the knowledge base's own versioning and audit log |
What did the screening / drift / expiry monitor find and when? | One alert ledger per monitor per client; dispositions are explicit, logged human acts |
Was anything sent by a machine? | Nothing can be; the mail log on the actions register records create / rewrite / sent / snooze for every prepared letter, and sent is written only after the mailbox confirms it |
Is the memory healthy? | The audit skill: coverage against sources, required pages present, broken links, stale mirrors, facts without source backup, unlogged writes - per client and per deployment. Read-only. Suggested quarterly. |
Which runs happened, with which sources? | Every mining and monitor report states the sources used and unavailable; the install report keeps the step graph |
Was a page edited outside a skill? | Flagged by the audit skill from the change log |