Configuring the memory and tuning the monitors
3 min read
Configuring the memory
The shape of every client memory is defined in one file: the description file. It says which topic pages exist, what belongs on each, which fields are mirrors of a system of record, and what may never be stored. On first mine it is copied to the live location for the deployment; compliance edits that copy. No skill release is needed to change it.
Decision | Where | Notes |
|---|---|---|
Which of the 14 topic pages are in scope at launch | Description file - page inventory | Pages can be added later; the sufficiency test is that a meeting brief must be reproducible from the memory alone |
Which fields are system-of-record mirrors | Description file - authorship classes | Mirror fields are copied or left blank, never inferred; the CRM / KYC system stays the system of truth |
What is deliberately never stored | Description file - exclusion list | Ships with politics, health, inferred personality, gossip, relatives' finances, tax law; the bank extends it |
Bank-specific fields per tenant | Description file - page sections | Additional fields are configuration, not code |
What is promoted to team and organisation folders | Description file + folder permissions | Default: compliance, mandate, commitments, matters in flight, change log |
Where the description and policy files live | Deployment decision | One copy per user area (as shipped) or a central copy owned by compliance, with team or individual extensions through the skills cascade |
Tuning the monitors
Each monitor reads its rules from a policy file in the knowledge base. Changing a threshold is an edit to a file, not a change to a skill. Every policy edit is versioned by the knowledge base. How often each monitor runs is set in the scheduler, not here; defaults and when to change them are on Schedules.
Policy file | Governs | What you tune |
|---|---|---|
| Document expiry monitor | Document lifetimes per type; alert steps (T−60 deadline approaching, T−30 review required, expired = breach); "not on file" items |
| Portfolio drift monitor | Asset-class bands per mandate, single-issuer concentration limits, prohibited instruments (zero tolerance), persistence escalation |
| Suitability review monitor | What a complete file contains; review interval; what counts as a material change (risk profile, mandate, goals, life events, balance-sheet shifts) |
| Adverse-media and PEP screening | Source tiers (government, regulators, established press - never forums or gossip), thresholds, the two-key identity rule, escalation route |
| Market radar | Themes tracked, mapping to portfolios and risk appetite, impact scoring |
| Every prepared letter | What a letter may and may not say, tone, hedging rules, languages, sign-off, one-letter-per-addressee-per-day |
| Referral mining · source-of-wealth narrative | Third-party data floor, search depth, evidence coverage rules |
How a finding travels
Every monitor raises an open action with a stable ID, writes a prepared letter under the letter policy and keeps its own alert ledger. Where the finding goes from there - dashboard card, prepared letter, task, case or escalation - is the routing decided in the design phase and mapped onto the bank's existing service processes. Recipient and approval routes and escalation windows are configuration.
Screening and market radar depend on web search being approved; portfolio drift on a portfolio connector (otherwise it runs on the last mirrored figures and says so). Document expiry and suitability need no external input and run on the memory alone.